Re: [PATCH 2/2] riscv: dts: sophgo: sg2002-milkv-duo256m: drop reserved memory node

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] dts: ABI breakage by dropping coprocessor reserved-memory node
--

commit fa1a6e529f0f63c13f25ecb8772efefbd481942e
Author: Andrei Lalaev <andrey.lalaev@gmail.com>

riscv: dts: sophgo: sg2002-milkv-duo256m: drop reserved memory node

This commit drops the reserved-memory node for the coprocessor from the
sg2002-milkv-duo256m device tree. The change is based on the premise that
the current FSBL handles this dynamically at runtime.

> diff --git a/arch/riscv/boot/dts/sophgo/sg2002-milkv-duo256m.dts b/arch/riscv/boot/dts/sophgo/sg2002-milkv-duo256m.dts
> index a2797c0bd7671..d4e86c15664e6 100644
> --- a/arch/riscv/boot/dts/sophgo/sg2002-milkv-duo256m.dts
> +++ b/arch/riscv/boot/dts/sophgo/sg2002-milkv-duo256m.dts
> @@ -36,17 +36,6 @@ led-0 {
>  			linux,default-trigger = "heartbeat";
>  		};
>  	};
> -
> -	reserved-memory {
> -		#address-cells = <1>;
> -		#size-cells = <1>;
> -		ranges;
> -
> -		coprocessor_rtos: region@8fe00000 {
> -			reg = <0x8fe00000 0x200000>;
> -			no-map;
> -		};
> -	};

[Severity: Critical]
Does removing this static fallback node introduce a regression for systems
using an older bootloader?

While newer FSBLs might dynamically inject or update the reserved-memory
node, older FSBLs rely on this static reservation in the device tree. Without
the no-map property for 0x8fe00000, will the kernel treat the 2MB coprocessor
region as general-purpose RAM, since it falls within the standard memory
space?

This could lead to memory corruption if Linux and the active coprocessor
overwrite each other's memory when users upgrade their kernel and device
tree without also upgrading their bootloader, breaking the standard backward
compatibility contract.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260921-sophgo-remove-coprocessor-node-v1-0-ace29446b327@gmail.com?part=2