Linux kernel and device drivers for NXP i.MX platforms
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: hongxing.zhu@oss.nxp.com
Cc: imx@lists.linux.dev, conor+dt@kernel.org, robh@kernel.org,
	devicetree@vger.kernel.org, Frank.Li@kernel.org
Subject: Re: [PATCH v1 1/3] arm64: dts: imx95: Avoid 32-bit PCIe window System RAM overlap
Date: Thu, 20 Aug 2026 08:42:07 +0000	[thread overview]
Message-ID: <20260820084208.5CF311F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260820083620.877251-2-hongxing.zhu@oss.nxp.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The commit message inaccurately claims to change the 'CPU address', but the patch actually changes the 'PCI address'.
--

--- Patch [1]: [PATCH v1 1/3] arm64: dts: imx95: Avoid 32-bit PCIe window System RAM overlap ---
commit 1e55a58df93bb33b1e5b78cb2403b958366907f0
Author: Richard Zhu <hongxing.zhu@nxp.com>

arm64: dts: imx95: Avoid 32-bit PCIe window System RAM overlap

This commit updates the device tree configuration for the PCIe controllers
on the imx95 platform. It adjusts the ranges property to prevent memory
window overlaps.

> Move the PCIe non-prefetchable memory CPU address from 0xe0000000
> to 0x10000000 to avoid overlap with DRAM.

[Severity: Medium]
Is this description of the change accurate?

The device tree ranges property uses the format:
<PCI_HI PCI_MID PCI_LO CPU_HI CPU_LO SIZE_HI SIZE_LO>

> diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
> --- a/arch/arm64/boot/dts/freescale/imx95.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
> @@ -1948,7 +1948,7 @@ pcie0: pcie@4c300000 {
[ ... ]
>  			reg-names = "dbi", "config", "atu", "app";
>  			ranges = <0x43000000 0x9 0x00000000 0x9 0x00000000 0x0 0xe0000000>,
> -				 <0x82000000 0x0 0xe0000000 0x9 0xe0000000 0x0 0x10000000>,
> +				 <0x82000000 0x0 0x10000000 0x9 0xe0000000 0x0 0x10000000>,

Looking at the modification to pcie0, the CPU (parent) bus address is
represented by the 4th and 5th cells (0x9 0xe0000000). These cells remain
unchanged in this patch.

The cell that is updated from 0xe0000000 to 0x10000000 is the 3rd cell,
which corresponds to the lower 32 bits of the PCI (child) bus address.

Could the commit message be clarified to state that the PCI address is
being changed, or was the intent to actually update the CPU address in
the 5th cell?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260820083620.877251-1-hongxing.zhu@oss.nxp.com?part=1

  reply	other threads:[~2026-08-20  8:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-20  8:36 [PATCH v1 0/3] arm64: dts: imx9x: Fix PCIe memory window overlap with System RAM hongxing.zhu
2026-08-20  8:36 ` [PATCH v1 1/3] arm64: dts: imx95: Avoid 32-bit PCIe window System RAM overlap hongxing.zhu
2026-08-20  8:42   ` sashiko-bot [this message]
2026-08-20  8:36 ` [PATCH v1 2/3] arm64: dts: imx94: Avoid 32-bit pcie window system ram overlap hongxing.zhu
2026-08-20  8:40   ` sashiko-bot
2026-08-20  8:36 ` [PATCH v1 3/3] arm64: dts: imx943: Avoid 32-bit PCIe window System RAM overlap hongxing.zhu
2026-08-20  8:40   ` sashiko-bot

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=20260820084208.5CF311F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=hongxing.zhu@oss.nxp.com \
    --cc=imx@lists.linux.dev \
    --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