From: sashiko-bot@kernel.org
To: "Peng Fan (OSS)" <peng.fan@oss.nxp.com>
Cc: Frank.Li@kernel.org, conor+dt@kernel.org, imx@lists.linux.dev,
robh@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH 1/4] arm64: dts: imx95-19x19-evk: Add CM7 node and related memory nodes
Date: Wed, 15 Jul 2026 07:17:41 +0000 [thread overview]
Message-ID: <20260715071741.79CA81F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260715-imx-rproc-dts-v1-1-d02b583c507b@nxp.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The virtio device buffer memory region is named `vdevbuffer` which fails the driver's hardcoded check for `vdev0buffer`, leading to it being erroneously registered as a carveout and double-mapped.
--
--- Patch [1]: [PATCH 1/4] arm64: dts: imx95-19x19-evk: Add CM7 node and related memory nodes ---
commit b818b56116c9f6f62676b904ae89c90565f8f036
Author: Peng Fan <peng.fan@nxp.com>
arm64: dts: imx95-19x19-evk: Add CM7 node and related memory nodes
This commit adds a remoteproc CM7 node and reserved memory regions to enable
the Cortex-M7 remote processor. The reserved memory includes firmware memory,
vring buffers, a resource table, and a shared DMA pool for inter-processor
communication.
> diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
> --- a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
[ ... ]
> + rsc_table: rsc-table@88220000 {
> + reg = <0 0x88220000 0 0x1000>;
> + no-map;
> + };
> +
> + vdevbuffer: vdevbuffer@88020000 {
> + compatible = "shared-dma-pool";
> + reg = <0 0x88020000 0 0x100000>;
> + no-map;
> + };
[Severity: Medium]
Will this node name cause the region to be mapped twice?
During device probe, the driver iterates over the memory-region nodes in
imx_rproc_prepare() and attempts to skip the virtio buffer by checking:
strstarts(res.name, "vdev0buffer")
Because this node is named vdevbuffer instead of vdev0buffer, it appears the
strstarts() check will fail. Does this cause the 1MB region to be erroneously
registered as a carveout and unnecessarily double-mapped via ioremap_wc() into
the vmalloc space?
> };
>
> flexcan1_phy: can-phy0 {
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260715-imx-rproc-dts-v1-0-d02b583c507b@nxp.com?part=1
next prev parent reply other threads:[~2026-07-15 7:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-15 7:10 [PATCH 0/4] arm64: dts: freescale: Add remoteproc support for i.MX EVKs Peng Fan (OSS)
2026-07-15 7:10 ` [PATCH 1/4] arm64: dts: imx95-19x19-evk: Add CM7 node and related memory nodes Peng Fan (OSS)
2026-07-15 7:17 ` sashiko-bot [this message]
2026-07-15 16:12 ` Frank Li
2026-07-15 7:10 ` [PATCH 2/4] arm64: dts: imx952-evk: " Peng Fan (OSS)
2026-07-15 7:10 ` [PATCH 3/4] arm64: dts: imx943-evk: Add CM7 and CM33S nodes Peng Fan (OSS)
2026-07-15 7:18 ` sashiko-bot
2026-07-15 7:10 ` [PATCH 4/4] arm64: dts: imx8ulp-evk: Update rpmsg resource table address 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=20260715071741.79CA81F000E9@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.