Re: [PATCH v4 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 1 potential issue(s) to consider:
- [Medium] Potentially incorrect coprocessor RTOS memory region address causing memory fragmentation and risking memory corruption.
--

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

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

This commit adds basic device tree support for the Milk-V Duo 256M board 
based on the Sophgo SG2002 SoC. It includes configurations for UART, SD/MMC, 
USB host, and the onboard status LED.

> 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

[ ... ]

> +	reserved-memory {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +
> +		coprocessor_rtos: region@83f40000 {
> +			reg = <0x83f40000 0xc0000>;
> +			no-map;
> +		};

[Severity: Medium]
Is this reserved memory address correct for the 256M board?

This address (0x83f40000) is at the top of the 64MB boundary, which matches
the 64MB Milk-V Duo. Since the Milk-V Duo 256M has 256MB of RAM, would the
RTOS usually be placed near the top of the 256MB space instead?

If the bootloader places the RTOS at the top of memory but the device tree
reserves this lower address, could Linux inadvertently overwrite the actual
RTOS memory during allocation? This might also artificially fragment the
contiguous Linux memory pool around the 64MB mark.

> +	};
> +};

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