Re: [PATCH v4 4/6] arm64: dts: imx8mm: imx8mp: Add CM DTOs for Data Modul i.MX8M Mini and Plus eDM SBC

[Frank Li <Frank.li@oss.nxp.com>]

On Sun, Jul 05, 2026 at 08:24:38PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] The virtio device buffer node is named `vdevbuffer` instead of `vdev0buffer`, bypassing the driver's carveout exclusion logic.
> --
>
> commit b1e78cbda66a659316ae8170db75a75bd2d9d9d2
> Author: Marek Vasut <marex@nabladev.com>
>
> arm64: dts: imx8mm: imx8mp: Add CM DTOs for Data Modul i.MX8M Mini and Plus eDM SBC
>
> This commit adds device tree overlays for the CM4/CM7 cores on the Data
> Modul i.MX8M Mini and Plus eDM SBCs. The overlays allow CM4/CM7 firmware
> to be used with remoteproc and rpmsg without imposing the overhead on
> every user of the platform.
>
> [ ... ]
>
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-data-modul-edm-sbc-overlay-cm4.dtso b/arch/arm64/boot/dts/freescale/imx8mm-data-modul-edm-sbc-overlay-cm4.dtso
> > new file mode 100644
> > index 0000000000000..8d681c0eff0d4
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/freescale/imx8mm-data-modul-edm-sbc-overlay-cm4.dtso
> > @@ -0,0 +1,56 @@
> [ ... ]
> > +		rsc_table: rsc-table@b80ff000 {
> > +			reg = <0 0xb80ff000 0 0x1000>;
> > +			no-map;
> > +		};
> > +
> > +		vdevbuffer: vdevbuffer@b8400000 {
> > +			compatible = "shared-dma-pool";
> > +			reg = <0 0xb8400000 0 0x100000>;
>
> [Severity: Medium]
> Will this node name bypass the driver's carveout exclusion logic?
>
> Looking at imx_rproc_prepare(), it iterates over memory-regions and checks
> specifically for the name "vdev0buffer" to skip processing the vdev buffer:
>
> 	if (!strcmp(it.node->name, "rsc-table") ||
> 	    !strcmp(it.node->name, "vdev0vring0") ||
> 	    !strcmp(it.node->name, "vdev0vring1") ||
> 	    strstarts(res.name, "vdev0buffer"))
> 		continue;
>
> Because this node is named "vdevbuffer" instead of "vdev0buffer", it appears
> it will be mapped as a generic carveout via ioremap_wc() and unintentionally
> included in the remoteproc coredump.
>
> Could this node be renamed to "vdev0buffer" to avoid wasting vmalloc space
> and bloating the coredump?

Look like make sense, please check it.

It is not good to use node-name as ABI. Laurentiu is working on use
memory-region-namses.

Frank

>
> > +			no-map;
> > +		};
> > +	};
> > +
> > +	imx8mm-cm4 {
> [ ... ]
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mp-data-modul-edm-sbc-overlay-cm7.dtso b/arch/arm64/boot/dts/freescale/imx8mp-data-modul-edm-sbc-overlay-cm7.dtso
> > new file mode 100644
> > index 0000000000000..21e2a8c0bab0a
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/freescale/imx8mp-data-modul-edm-sbc-overlay-cm7.dtso
> > @@ -0,0 +1,57 @@
> [ ... ]
> > +		rsc_table: rsc-table@550ff000 {
> > +			reg = <0 0x550ff000 0 0x1000>;
> > +			no-map;
> > +		};
> > +
> > +		vdevbuffer: vdevbuffer@55400000 {
> > +			compatible = "shared-dma-pool";
> > +			reg = <0 0x55400000 0 0x100000>;
>
> [Severity: Medium]
> As with the CM4 overlay, will naming this node "vdevbuffer" instead of
> "vdev0buffer" cause the 1MB buffer to be unintentionally mapped as a generic
> carveout and dumped on a crash?
>
> > +			no-map;
> > +		};
> > +	};
> [ ... ]
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260705200534.151803-1-marex@nabladev.com?part=4