Re: [PATCH 1/7] arm64: dts: imx8dxl-evk: rename vdevbuffer to vdev0buffer

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Incomplete fix leaves vring and rsc_table nodes with generic names, wasting memory and breaking attach mode.
- [High] Incomplete fix across the subsystem: numerous other i.MX device trees retain the broken vdevbuffer node name.
--

--- Patch [1]: [PATCH 1/7] arm64: dts: imx8dxl-evk: rename vdevbuffer to vdev0buffer ---
commit e44444bca004c2c221c3822282c9e7af15531374
Author: Peng Fan <[email protected]>

arm64: dts: imx8dxl-evk: rename vdevbuffer to vdev0buffer

This commit renames the "vdevbuffer" node to "vdev0buffer" in the
imx8dxl-evk device tree. This ensures the imx_rproc driver correctly skips
mapping the vdev buffer region, avoiding an unnecessary duplicate mapping.

> diff --git a/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts b/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts
> index 0ede0c7ed422c..6f79aaef2dbb7 100644
> --- a/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts

[ ... ]

> @@ -90,7 +90,7 @@ rsc_table: memory-rsc-table@900ff000 {
>  			no-map;
>  		};
>  

[Severity: High]
This is a pre-existing issue, but does this fix leave the rsc_table and
vring nodes with generic names that will also fail the driver's checks?

Looking at drivers/remoteproc/imx_rproc.c:imx_rproc_addr_init(), it expects
a specific node name prefix:

	if (strstarts(res.name, "rsc-table"))
		priv->rsc_table = priv->mem[b].cpu_addr;

Because the node is named "memory-rsc-table", this check fails, leaving
priv->rsc_table NULL and breaking imx_rproc_get_loaded_rsc_table().

Similarly, if the vring nodes are named "memory0" and "memory" instead of
"vdev0vring0" and "vdev0vring1", they are registered with those generic
names by imx_rproc_prepare(). The remoteproc core's rproc_alloc_vring()
then searches for "vdev0vring0", fails to find the carveout, and falls
back to dynamic allocation, wasting the reserved memory regions.

> -		vdevbuffer: memory-vdevbuffer@90400000 {
> +		vdev0buffer: vdev0buffer@90400000 {

[Severity: High]
This isn't a bug introduced by this patch, but are there other i.MX device
trees that still retain the broken vdevbuffer node name?

For instance, arch/arm64/boot/dts/freescale/imx8dxl-sr-som.dtsi still has:

		vdevbuffer: memory-vdevbuffer@90400000 {

Since drivers/remoteproc/imx_rproc.c:imx_rproc_prepare() uses string matching
to skip mapping the vdev buffer regions:

	if (strstarts(res.name, "vdev0buffer"))
		continue;

These other boards will still fail the check, causing redundant carveout
registration and wasted memory.

Should all affected boards (such as imx8qm-mek.dts and
imx93-11x11-evk-common.dtsi) be updated to use the expected names, or
could the driver be updated to rely on memory-region-names instead of
node names?

>  			compatible = "shared-dma-pool";
>  			reg = <0 0x90400000 0 0x100000>;
>  			no-map;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1