From: sashiko-bot@kernel.org
To: "Peng Fan (OSS)" <peng.fan@oss.nxp.com>
Cc: robh@kernel.org, imx@lists.linux.dev, conor+dt@kernel.org,
devicetree@vger.kernel.org, Frank.Li@kernel.org
Subject: Re: [PATCH 3/7] arm64: dts: imx8qxp-mek: rename vdevbuffer to vdev0buffer
Date: Wed, 29 Jul 2026 01:36:32 +0000 [thread overview]
Message-ID: <20260729013632.BB00A1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260729-rproc-dts-v1-3-368bca0b309f@nxp.com>
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 <peng.fan@nxp.com>
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/20260729-rproc-dts-v1-0-368bca0b309f@nxp.com?part=3
next prev parent reply other threads:[~2026-07-29 1:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 1:25 [PATCH 0/7] arm64: dts: freescale: rename vdevbuffer to vdev0buffer Peng Fan (OSS)
2026-07-29 1:25 ` [PATCH 1/7] arm64: dts: imx8dxl-evk: " Peng Fan (OSS)
2026-07-29 1:36 ` sashiko-bot
2026-07-29 1:25 ` [PATCH 2/7] arm64: dts: imx8qm-mek: " Peng Fan (OSS)
2026-07-29 1:37 ` sashiko-bot
2026-07-29 1:25 ` [PATCH 3/7] arm64: dts: imx8qxp-mek: " Peng Fan (OSS)
2026-07-29 1:36 ` sashiko-bot [this message]
2026-07-29 1:25 ` [PATCH 4/7] arm64: dts: imx8ulp-evk: " Peng Fan (OSS)
2026-07-29 1:35 ` sashiko-bot
2026-07-29 1:25 ` [PATCH 5/7] arm64: dts: imx93-11x11-frdm: " Peng Fan (OSS)
2026-07-29 1:25 ` [PATCH 6/7] arm64: dts: imx93-14x14-evk: " Peng Fan (OSS)
2026-07-29 1:25 ` [PATCH 7/7] arm64: dts: imx93-9x9-qsb: " Peng Fan (OSS)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260729013632.BB00A1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=imx@lists.linux.dev \
--cc=peng.fan@oss.nxp.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox