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
next prev parent reply other threads:[~2026-07-29 13:23 UTC|newest]
Thread overview: 18+ 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)
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;
as well as URLs for NNTP newsgroup(s).