Re: [PATCH 2/7] arm64: dts: imx8qm-mek: rename vdevbuffer to vdev0buffer

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The patch only renames the `vdev0buffer` node, missing identical node-name string-matching bugs for the DSP vdev buffer, the vrings, and the resource tables in the same file.
- [High] The fix for the vdev buffer node name is strictly isolated to imx8qm-mek, leaving numerous other i.MX device trees suffering from the exact same bug.
--

--- Patch [2]: [PATCH 2/7] arm64: dts: imx8qm-mek: rename vdevbuffer to vdev0buffer ---
commit ce17c79a2ee7822b12884c5a6ce5b992a2195b5e
Author: Peng Fan <peng.fan@nxp.com>

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

This commit renames the vdevbuffer node to vdev0buffer in the imx8qm-mek
device tree. This ensures the imx_rproc driver correctly identifies the node
by name and skips mapping the vdev buffer region.

> diff --git a/arch/arm64/boot/dts/freescale/imx8qm-mek.dts b/arch/arm64/boot/dts/freescale/imx8qm-mek.dts
> index 9e49ac377162b..50aa1e3419651 100644
> --- a/arch/arm64/boot/dts/freescale/imx8qm-mek.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8qm-mek.dts
> @@ -94,7 +94,7 @@ rsc_table1: memory@901ff000 {
>  			no-map;
>  		};
>  
> -		vdevbuffer: memory@90400000 {
> +		vdev0buffer: vdev0buffer@90400000 {

[Severity: High]
This is a pre-existing issue, but this patch only renames the vdev0buffer
node, missing identical node-name string-matching bugs for the DSP vdev
buffer, the vrings, and the resource tables in this same file.

For example, rsc_table0 is named memory@900ff000:

arch/arm64/boot/dts/freescale/imx8qm-mek.dts:
    rsc_table0: memory@900ff000 {
        ...

This causes it to fail the strstarts() check for "rsc-table" in the driver:

drivers/remoteproc/imx_rproc.c:imx_rproc_addr_init() {
    ...
    if (strstarts(res.name, "rsc-table"))
        priv->rsc_table = priv->mem[b].cpu_addr;
    ...
}

This completely breaks IPC/virtio initialization if the remote processor is
attached in a running state, leaving priv->rsc_table as NULL.

Similarly, vdev0vring0 and dsp_vdev0buffer are named memory@..., failing
their respective strstarts() checks and causing them to be incorrectly
mapped.

Could these other nodes be renamed as well to fix the matching logic?

[Severity: High]
This is also a pre-existing issue, but the fix for the vdev buffer node name
seems strictly isolated to imx8qm-mek, leaving numerous other i.MX device
trees suffering from the exact same bug.

For example, imx93-11x11-evk-common.dtsi uses vdevbuffer@a4020000:

arch/arm64/boot/dts/freescale/imx93-11x11-evk-common.dtsi:
    vdevbuffer: vdevbuffer@a4020000 {
        ...

And imx8qxp-mek.dts uses memory@900ff000 for the rsc_table.

These boards will continue to experience unnecessary carveout mappings and
broken resource table lookups because they fail the same strict strstarts()
checks.

Could this be addressed across all affected device trees, or perhaps the
driver itself could be modified to match the existing generic names
(e.g., matching "vdev" instead of exactly "vdev0buffer")?

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

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260729-rproc-dts-v1-0-368bca0b309f@nxp.com?part=2