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

[sashiko-bot@kernel.org]

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?

> +			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