Linux kernel and device drivers for NXP i.MX platforms
 help / color / mirror / Atom feed
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

  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