[PATCH v5 2/2] ARM: dts: aspeed: add device tree for ASRock Rack ALTRAD8 BMC

[Andrew Jeffery]

Hi Rebecca,

On Thu, 2025-12-11 at 09:56 -0700, Rebecca Cran wrote:
> The ALTRAD8 BMC is an Aspeed AST2500-based BMC for the ASRock Rack
> ALTRAD8UD-1L2T and ALTRAD8UD2-1L2Q boards.
> 
> Signed-off-by: Rebecca Cran <rebecca at bsdio.com>
> ---
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-altrad8.dts
> b/arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-altrad8.dts
> new file mode 100644
> index 000000000000..4898ddede1c2
> --- /dev/null
> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-altrad8.dts
> @@ -0,0 +1,624 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/dts-v1/;
> +
> +#include "aspeed-g5.dtsi"
> +#include <dt-bindings/gpio/aspeed-gpio.h>
> +#include <dt-bindings/leds/common.h>
> +#include <dt-bindings/i2c/i2c.h>
> +
> +/ {
> +	model = "ASRock ALTRAD8 BMC";
> +	compatible = "asrock,altrad8-bmc", "aspeed,ast2500";
> +
> +	aliases {
> +		serial4 = &uart5;
> +		i2c50 = &nvme1;
> +		i2c51 = &pcie4;
> +		i2c52 = &pcie5;
> +		i2c53 = &pcie6;
> +		i2c54 = &pcie7;
> +		i2c55 = &nvme3;
> +		i2c56 = &nvme2;
> +		i2c57 = &nvme0;
> +		i2c58 = &nvme4;
> +		i2c59 = &nvme5;
> +		i2c60 = &nvme6;
> +		i2c61 = &nvme7;
> +		i2c62 = &nvme8;
> +		i2c63 = &nvme9;
> +		i2c64 = &nvme10;
> +		i2c65 = &nvme11;
> +	};
> +
> +	chosen {
> +		stdout-path = "uart5:115200n8";
> +	};
> +
> +	iio-hwmon {
> +		compatible = "iio-hwmon";
> +		io-channels =	<&adc 0>, <&adc 1>, <&adc 2>, <&adc
> 3>,
> +				<&adc 4> ,<&adc 5>, <&adc 6>, <&adc
> 7>,
> +				<&adc 8>, <&adc 9>, <&adc 10>, <&adc
> 11>,
> +				<&adc 12>, <&adc 13>, <&adc 14>,
> <&adc 15>;
> +	};
> +

*snip*

> +&adc {
> +	status = "okay";

Please add the necessary pinctrl properties to request the ADC lines as
used for the iio-hwmon bridge. This ensures their exclusive use so they
can't otherwise be muxed as e.g. GPIOs and produce surprising system
behaviour.

> +};
> +

*snip*

> +&pinctrl {
> +	aspeed,external-nodes = <&gfx &lhc>;

This property is now set in aspeed-g5.dtsi so it's unnecessary to do so
here in the dts. I also have a cleanup at [1] that impacts it, so the
less we can propagate the problem the better

[1]: https://lore.kernel.org/all/20251211-dev-dt-warnings-all-v1-0-21b18b9ada77@codeconstruct.com.au/

Otherwise the patch looks okay to me.

Andrew