Re: [PATCH v3 3/3] riscv: dts: sophgo: Add Milk-V Duo 256M board support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] Missing explicit pinctrl configuration for the status LED.
- [Low] Device tree node ordering violation for `gpio4`.
--

--- Patch [3]: [PATCH v3 3/3] riscv: dts: sophgo: Add Milk-V Duo 256M board support ---
commit 40bbbb1b4ad92a0f96cf454940bcf6e5942c12cb
Author: Chen-Yu Yeh <chenyou910331@gmail.com>

riscv: dts: sophgo: Add Milk-V Duo 256M board support

The Milk-V Duo 256M is a small form factor development board based on
the Sophgo SG2002 SoC. This patch adds basic device tree support for the
board, including UART, SD/MMC, USB host, and a status LED.

> diff --git a/arch/riscv/boot/dts/sophgo/cv180x.dtsi b/arch/riscv/boot/dts/sophgo/cv180x.dtsi
> index 06b0ce5a2db7a..25ad2bd265d76 100644
> --- a/arch/riscv/boot/dts/sophgo/cv180x.dtsi
> +++ b/arch/riscv/boot/dts/sophgo/cv180x.dtsi
> @@ -160,6 +160,24 @@ portd: gpio-controller@0 {
>  			};
>  		};
>  
> +		gpio4: gpio@5021000 {
> +			compatible = "snps,dw-apb-gpio";
> +			reg = <0x5021000 0x1000>;

[Severity: Low]
This isn't a bug, but are these device tree nodes ordered correctly?

The node gpio4: gpio@5021000 is placed immediately after gpio3: gpio@3023000
but before saradc: adc@30f0000. Device tree nodes within a bus or SoC node
are typically sorted ascendingly by their unit-address. Since 0x5021000 is
greater than 0x030f0000, this node appears to be structurally out of order.

> +			#address-cells = <1>;
> +			#size-cells = <0>;

[ ... ]

> diff --git a/arch/riscv/boot/dts/sophgo/sg2002-milkv-duo256m.dts b/arch/riscv/boot/dts/sophgo/sg2002-milkv-duo256m.dts
> new file mode 100644
> index 0000000000000..21ef6ed9f0d21
> --- /dev/null
> +++ b/arch/riscv/boot/dts/sophgo/sg2002-milkv-duo256m.dts
> @@ -0,0 +1,121 @@

[ ... ]

> +	leds {
> +		compatible = "gpio-leds";
> +
> +		led-0 {
> +			gpios = <&porte 2 GPIO_ACTIVE_HIGH>;
> +			color = <LED_COLOR_ID_BLUE>;

[Severity: Low]
Is it intentional to omit the explicit pinctrl configuration for the status
LED?

Without a pinctrl-0 or pinctrl-names reference, the led-0 node relies
entirely on the bootloader's default pinmux configuration to remain in
GPIO mode. If the board is booted with firmware that does not pre-configure
this pin, the LED functionality could fail.

> +			function = LED_FUNCTION_STATUS;
> +			linux,default-trigger = "heartbeat";
> +		};
> +	};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710075917.159969-1-chenyou910331@gmail.com?part=3