Re: [PATCH 3/7] arm64: dts: imx8qxp-mek: rename vdevbuffer to vdev0buffer

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

Pre-existing issues:
- [High] Incomplete fix for remoteproc driver node name string matching, causing wasted CMA memory and broken resource table loading.
--

--- Patch [3]: [PATCH 3/7] arm64: dts: imx8qxp-mek: rename vdevbuffer to vdev0buffer ---
commit 3123a86d4f3fafc543a5613360cdacc5946dbc06
Author: Peng Fan <[email protected]>
Date:   Wed Jul 29 01:25:38 2026 +0000

arm64: dts: imx8qxp-mek: rename vdevbuffer to vdev0buffer

The imx_rproc driver checks for the name "vdev0buffer" to skip mapping
the vdev buffer region. This commit renames the device tree node to
"vdev0buffer" to match what the driver expects.

diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
--- a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
+++ b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
@@ -267,7 +267,7 @@ rsc_table: memory@900ff000 {
 			no-map;
 		};
 
[Severity: High]
This is a pre-existing issue, but does this incomplete node renaming leave 
other remoteproc string-matching checks broken?

Since this patch corrects the node name for the vdev buffer, what about the
sibling nodes like the resource table above, or the vrings?

The imx_rproc driver's address initialization relies on the device tree
node name string to filter memory regions:

drivers/remoteproc/imx_rproc.c:imx_rproc_addr_init() {
    ...
    /* Not map vdevbuffer, vdevring region */
    if (strstarts(res.name, "vdev"))
        continue;
    ...
}

Because the vring nodes (like vdev0vring0) and the resource table node are
still generically named "memory" in the device tree, they will fail these 
checks. 

Does this cause the vring memory to be unnecessarily mapped, forcing
rproc_alloc_vring() to dynamically allocate CMA memory and waste the
pre-reserved regions because it cannot find its pre-registered carveout?

Furthermore, does the rsc_table name mismatch break the fallback logic
that loads a memory-provided resource table, since priv->rsc_table is
never successfully populated?

Other boards appear to have identical issues. For example, in imx8qm-mek.dts,
dsp_vdev0buffer is also named "memory" instead of "dsp_vdev0buffer". Should 
we update the node names for the vrings and resource tables across these 
boards as well to fully fix the string matching logic?

> -		vdevbuffer: memory@90400000 {
> +		vdev0buffer: vdev0buffer@90400000 {
>  			compatible = "shared-dma-pool";
>  			reg = <0 0x90400000 0 0x100000>;
>  			no-map;

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