Re: [PATCH v5 2/5] arm64: dts: ti: k3-am62p-ti-ipc-firmware: Move wkup reserved memory

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Moving `wkup_r5fss0_core0_memory_region` to the shared `k3-am62p-ti-ipc-firmware.dtsi` silently truncates the reserved memory size for Verdin boards from 30MB to 15MB.
- [Medium] Moving `wkup_r5fss0_core0_memory_region` to the shared `k3-am62p-ti-ipc-firmware.dtsi` causes fatal `dtc` duplicate label errors and overlapping reserved memory regions for Var-SOM boards.
--

commit 65cd200377411c4597f1b662700915ea23cfe5f8
Author: Markus Schneider-Pargmann (TI) <msp@baylibre.com>

arm64: dts: ti: k3-am62p-ti-ipc-firmware: Move wkup reserved memory

The commit moves the wkup_r5fss0_core0 memory regions to a common
k3-am62p-ti-ipc-firmware.dtsi file to combine identical definitions
across boards.

>     Move the reserved memory regions used for wkup_r5fss0_core0 to the
>     k3-am62p-ti-ipc-firmware.dtsi. These are all the same for the other
>     boards as well, so we can combine them here similar to what is already
>     done for the mcu_r5fss0_core0 memory regions.

[Severity: High]
Are these regions exactly the same for all other boards?

k3-am62p-verdin.dtsi explicitly defines the wkup_r5fss0_core0_memory_region
with a size of 30MB (0x01e00000):

wkup_r5fss0_core0_memory_region: memory@9c900000 {
	compatible = "shared-dma-pool";
	reg = <0x00 0x9c900000 0x00 0x01e00000>;
	no-map;
};

Because k3-am62p-verdin.dtsi includes k3-am62p-ti-ipc-firmware.dtsi at the
very end of the file, dtc cleanly merges the identically-named node paths, and
the new generic definition silently overrides the board-specific 30MB size
down to 15MB.

Does this halving of the available memory for IPC on Verdin boards cause
firmware load failures or runtime out-of-memory crashes on the R5 core?

(Note: A subsequent patch in the series 'arm64: dts: ti:
k3-am62p-ti-ipc-firmware: Split r5f memory region' changes the label and size
to 1MB, which further truncates the region without fixing the underlying
overwrite.)

> diff --git a/arch/arm64/boot/dts/ti/k3-am62p-ti-ipc-firmware.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-ti-ipc-firmware.dtsi
> index 5d7f701420e2d..12902231e58a7 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62p-ti-ipc-firmware.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62p-ti-ipc-firmware.dtsi
> @@ -17,6 +17,18 @@ mcu_r5fss0_core0_memory_region: memory@9b900000 {
>  		reg = <0x00 0x9b900000 0x00 0xf00000>;
>  		no-map;
>  	};
> +
> +	wkup_r5fss0_core0_dma_memory_region: memory@9c800000 {
> +		compatible = "shared-dma-pool";
> +		reg = <0x00 0x9c800000 0x00 0x100000>;
> +		no-map;
> +	};

[Severity: Medium]
Will this cause dtc duplicate label errors and overlapping regions for
Var-SOM boards?

k3-am62p5-var-som.dtsi defines its reserved memory nodes using non-standard
node names (r5f-dma-memory@9c800000 and r5f-memory@9c900000):

wkup_r5fss0_core0_dma_memory_region: r5f-dma-memory@9c800000 {
	compatible = "shared-dma-pool";
	reg = <0x00 0x9c800000 0x00 0x00100000>;
	no-map;
};

Since the node names differ between the board file and the generic include
(r5f-dma-memory vs memory), dtc won't merge them.

Because both sets of nodes reuse the exact same node labels
(wkup_r5fss0_core0_dma_memory_region), could this trigger a fatal duplicate
label compilation error that breaks the build, or emit duplicate, overlapping
reserved-memory regions at boot if bypassed?

> +
> +	wkup_r5fss0_core0_memory_region: memory@9c900000 {
> +		compatible = "shared-dma-pool";
> +		reg = <0x00 0x9c900000 0x00 0xf00000>;
> +		no-map;
> +	};
>  };

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260601-topic-am62a-ioddr-dt-v6-19-v5-0-3856a023aff2@baylibre.com?part=2