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, robh@kernel.org, Frank.Li@kernel.org,
	conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v2 01/12] arm64: dts: imx8dxl-evk: fix reserved memory node names for remoteproc
Date: Wed, 29 Jul 2026 13:29:49 +0000	[thread overview]
Message-ID: <20260729132949.823EB1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260729-rproc-dts-v2-1-debbe0816202@nxp.com>

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

New issues:
- [Medium] The newly introduced reserved-memory node names violate Devicetree naming conventions and schema.

Pre-existing issues:
- [High] Incomplete fix leaving remoteproc broken on sibling i.MX device trees.
--

--- Patch [1]: [PATCH v2 01/12] arm64: dts: imx8dxl-evk: fix reserved memory node names for remoteproc ---
commit e2a2dbe393a11711fef30985552292a1360dcdae
Author: Peng Fan <peng.fan@nxp.com>

arm64: dts: imx8dxl-evk: 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.

Rename the reserved memory nodes to use the expected names so the driver
can correctly identify and handle each region.

Fixes: ee39dbd9a6cb ("arm64: dts: imx8dxl-evk: add imx8dxl_cm4, lsio mu5, related memory region")
Signed-off-by: Peng Fan <peng.fan@nxp.com>

> diff --git a/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts b/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts
> index 0ede0c7ed422c..71eff3efa6d32 100644
> --- a/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts

[Severity: High]
This isn't a bug introduced by this patch, but does this leave remoteproc
broken on sibling i.MX device trees?

When the imx_rproc driver calls of_reserved_mem_region_to_resource(), it
expects res.name to start with vdev or rsc-table. Unconditionally on boot,
other i.MX boards still use generic memory@... node names. For example, in
arch/arm64/boot/dts/freescale/imx8dxl-sr-som.dtsi under reserved-memory:

vdev0vring0: memory0@90000000 {

And similarly in arch/arm64/boot/dts/freescale/imx8qm-mek.dts:

vdev0vring0: memory@90000000 {

Could these sibling device trees be updated as well so virtio rings and
buffers are mapped correctly instead of as regular memory carveouts?

[ ... ]

> @@ -65,32 +65,32 @@ linux,cma {
>  			linux,cma-default;
>  		};
>  
> -		vdev0vring0: memory0@90000000 {
> +		vdev0vring0: vdev0vring0@90000000 {

[Severity: Medium]
Do these new reserved-memory node names violate Devicetree naming conventions
and schema validation?

Building the device tree with schema validation enabled triggers dtbs_check
warnings because nodes like vdev0vring0@90000000 violate the strict
reserved-memory regex: ^([a-z0-9-]+-)?(memory|sram|ram)(@[0-9a-f]+)?$

The underlying driver code in drivers/remoteproc/imx_rproc.c enforces this
via hardcoded string matching:

imx_rproc_addr_init() {
    ...
    if (strstarts(res.name, "vdev"))
        continue;
    ...
}

Could the node names append -memory (e.g., vdev0vring0-memory@90000000) to
satisfy both the schema's optional prefix and the driver's strstarts()
checks? 

Alternatively, could the driver be updated to use memory-region-names via
of_reserved_mem_region_to_resource_byname() while keeping the generic
memory node names?

[ ... ]

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

  reply	other threads:[~2026-07-29 13:29 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 [this message]
2026-07-29 13:07 ` [PATCH v2 02/12] arm64: dts: imx8qm-mek: " Peng Fan (OSS)
2026-07-29 13:23   ` sashiko-bot
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=20260729132949.823EB1F000E9@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