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: imx@lists.linux.dev, devicetree@vger.kernel.org, robh@kernel.org,
	conor+dt@kernel.org, Frank.Li@kernel.org
Subject: Re: [PATCH v2 02/12] arm64: dts: imx8qm-mek: fix reserved memory node names for remoteproc
Date: Wed, 29 Jul 2026 13:23:54 +0000	[thread overview]
Message-ID: <20260729132354.D58EC1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260729-rproc-dts-v2-2-debbe0816202@nxp.com>

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

Pre-existing issues:
- [High] Renaming the vring memory nodes for cm4-1 to `vdev2vring0` and `vdev3vring0` breaks static vring matching in the remoteproc core, causing a fallback to dynamic allocation and breaking IPC.
- [High] The DSP's vdev buffer and vring nodes in `imx8qm-mek.dts` were missed during the rename, leaving them with the generic `memory` node name, which breaks the driver's memory region parsing and IPC.
--

--- Patch [2]: [PATCH v2 02/12] arm64: dts: imx8qm-mek: fix reserved memory node names for remoteproc ---
commit b33c57fd7f12629e7e4a66a20b899d545ad3c226
Author: Peng Fan <peng.fan@nxp.com>

arm64: dts: imx8qm-mek: fix reserved memory node names for remoteproc
    
The imx_rproc driver uses node names to identify reserved memory regions.
It checks for "vdev0buffer" to skip mapping, "rsc-table" to locate the
resource table, and "vdev" prefix to filter vdev regions.

> diff --git a/arch/arm64/boot/dts/freescale/imx8qm-mek.dts b/arch/arm64/boot/dts/freescale/imx8qm-mek.dts
> index 9e49ac377162b..8b67fb5d670da 100644
> --- a/arch/arm64/boot/dts/freescale/imx8qm-mek.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8qm-mek.dts
> @@ -44,57 +44,57 @@ reserved-memory {
>  		#size-cells = <2>;
>  		ranges;

[ ... ]

> -		vdev2vring0: memory@90100000 {
> +		vdev2vring0: vdev2vring0@90100000 {

[Severity: High]
This isn't a bug introduced by this patch, but will this renaming actually
work for the cm4-1 remoteproc instance?

Since imx8qm-cm4-1 is an independent rproc instance, its first virtio device
index is 0. Looking at the remoteproc core, rproc_alloc_vring() searches for
vring carveouts using the format string "vdev%dvring%d".

Because of this, won't the core search for "vdev0vring0" and "vdev0vring1"
instead of "vdev2vring0"? If so, the mismatch would cause rproc_alloc_vring()
to fail finding the carveout and fall back to dynamic allocation, potentially
breaking IPC.

>  			reg = <0 0x90100000 0 0x8000>;
>  			no-map;
>  		};

[ ... ]

[Severity: High]
This is a pre-existing issue, but were the DSP vdev buffer and vring nodes
missed during this rename?

Looking at dsp_vdev0buffer in the same file (which currently remains as
memory@94300000), the imx_dsp_rproc driver will fail to skip the node
because it evaluates strstarts(res.name, "vdev0buffer").

Since the node name remains "memory", won't remoteproc_virtio fall back to
dynamic allocation from system memory and break IPC for the DSP?

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

  reply	other threads:[~2026-07-29 13:23 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-29 13:07 [PATCH v2 00/12] arm64: dts: freescale: fix reserved memory node names for remoteproc Peng Fan (OSS)
2026-07-29 13:07 ` [PATCH v2 01/12] arm64: dts: imx8dxl-evk: " Peng Fan (OSS)
2026-07-29 13:29   ` sashiko-bot
2026-07-29 13:07 ` [PATCH v2 02/12] arm64: dts: imx8qm-mek: " Peng Fan (OSS)
2026-07-29 13:23   ` sashiko-bot [this message]
2026-07-29 13:07 ` [PATCH v2 03/12] arm64: dts: imx8qm-mek: fix dsp " Peng Fan (OSS)
2026-07-29 13:20   ` sashiko-bot
2026-07-29 13:08 ` [PATCH v2 04/12] arm64: dts: imx8qxp-mek: fix " Peng Fan (OSS)
2026-07-29 13:08 ` [PATCH v2 05/12] arm64: dts: imx8qxp-mek: fix dsp " Peng Fan (OSS)
2026-07-29 13:08 ` [PATCH v2 06/12] arm64: dts: imx8ulp-evk: fix " Peng Fan (OSS)
2026-07-29 13:36   ` sashiko-bot
2026-07-29 13:08 ` [PATCH v2 07/12] arm64: dts: imx93-11x11-frdm: " Peng Fan (OSS)
2026-07-29 13:08 ` [PATCH v2 08/12] arm64: dts: imx93-14x14-evk: " Peng Fan (OSS)
2026-07-29 13:08 ` [PATCH v2 09/12] arm64: dts: imx93-9x9-qsb: " Peng Fan (OSS)
2026-07-29 13:08 ` [PATCH v2 10/12] arm64: dts: imx8dxl-sr-som: " Peng Fan (OSS)
2026-07-29 14:05   ` sashiko-bot
2026-07-29 13:08 ` [PATCH v2 11/12] arm64: dts: imx93-11x11-evk: " Peng Fan (OSS)
2026-07-29 13:08 ` [PATCH v2 12/12] arm64: dts: imx95-15x15-frdm: " Peng Fan (OSS)
2026-07-29 17:07 ` [PATCH v2 00/12] arm64: dts: freescale: " Frank Li

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=20260729132354.D58EC1F00A3A@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