From: sashiko-bot@kernel.org
To: "Xilin Wu" <sophon@radxa.com>
Cc: linux-pci@vger.kernel.org, dri-devel@lists.freedesktop.org,
devicetree@vger.kernel.org, linux-gpio@vger.kernel.org,
robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v3 1/4] arm64: dts: qcom: sc8280xp: enable PCIe ECAM and 64-bit memory
Date: Thu, 29 Oct 2026 09:58:24 +0000 [thread overview]
Message-ID: <sashiko-outbox-189076@kernel.org> (raw)
In-Reply-To: <20261029-q8b-dts-v3-1-655696dfec45@radxa.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] arm64: dts: qcom: sa8540p: unpreserved PCIe address maps for pcie2b/3b/4
--
commit 367f523cda7b8c336244029f70635c13b0b90574
Author: Xilin Wu <sophon@radxa.com>
arm64: dts: qcom: sc8280xp: enable PCIe ECAM and 64-bit memory
This commit enables PCIe ECAM and 64-bit memory windows for all five PCIe
controllers in sc8280xp.dtsi, while preserving the 32-bit address map for
pcie2a in sa8540p.dtsi to avoid regressions on SA8540P platforms.
> diff --git a/arch/arm64/boot/dts/qcom/sa8540p.dtsi b/arch/arm64/boot/dts/qcom/sa8540p.dtsi
> index 23888029cc117..e5393a237497c 100644
> --- a/arch/arm64/boot/dts/qcom/sa8540p.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sa8540p.dtsi
> @@ -180,6 +180,15 @@ &gpu_smmu {
>
> &pcie2a {
> compatible = "qcom,pcie-sa8540p";
> + reg = <0x0 0x01c20000 0x0 0x3000>,
> + <0x0 0x3c000000 0x0 0xf1d>,
> + <0x0 0x3c000f20 0x0 0xa8>,
> + <0x0 0x3c001000 0x0 0x1000>,
> + <0x0 0x3c100000 0x0 0x100000>,
> + <0x0 0x01c23000 0x0 0x1000>;
> +
> + ranges = <0x01000000 0x0 0x00000000 0x0 0x3c200000 0x0 0x100000>,
> + <0x02000000 0x0 0x3c300000 0x0 0x3c300000 0x0 0x1d00000>;
[Severity: High]
Should the 32-bit reg and ranges properties also be preserved for pcie2b,
pcie3b, and pcie4 in arch/arm64/boot/dts/qcom/sa8540p.dtsi?
While pcie3a already defines its own reg and ranges overrides in
sa8540p.dtsi, the remaining controllers in that file do not:
arch/arm64/boot/dts/qcom/sa8540p.dtsi:
&pcie2b {
compatible = "qcom,pcie-sa8540p";
linux,pci-domain = <1>;
interrupts = <GIC_SPI 263 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "msi";
};
...
&pcie3b {
compatible = "qcom,pcie-sa8540p";
linux,pci-domain = <3>;
interrupts = <GIC_SPI 565 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "msi";
};
&pcie4 {
compatible = "qcom,pcie-sa8540p";
linux,pci-domain = <4>;
interrupts = <GIC_SPI 518 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "msi";
};
Boards such as arch/arm64/boot/dts/qcom/sa8295p-adp.dts include
sa8540p.dtsi and enable pcie3b and pcie4:
arch/arm64/boot/dts/qcom/sa8295p-adp.dts:
&pcie3b {
pinctrl-names = "default";
pinctrl-0 = <&pcie3b_default>;
status = "okay";
};
...
&pcie4 {
pinctrl-names = "default";
pinctrl-0 = <&pcie4_default>;
status = "okay";
};
Without reg and ranges overrides in sa8540p.dtsi, pcie2b, pcie3b, and pcie4
inherit the new 64-bit ECAM config regions (at 0x4_c0000000, 0x4_40000000,
and 0x4_00000000) and 64-bit MMIO windows from sc8280xp.dtsi. When
qcom_pcie_probe() -> dw_pcie_host_init() -> pci_host_probe() runs on
SA8540P/SA8295P platforms, won't accessing those SC8280XP 64-bit address
ranges cause a regression due to the differing SA8540P memory map and
firmware protection rules?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261029-q8b-dts-v3-0-655696dfec45@radxa.com?part=1
next prev parent reply other threads:[~2026-10-29 9:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 9:44 [PATCH v3 0/4] arm64: dts: qcom: Add support for Radxa Dragon Q8B Xilin Wu
2026-10-29 9:44 ` [PATCH v3 1/4] arm64: dts: qcom: sc8280xp: enable PCIe ECAM and 64-bit memory Xilin Wu
2026-10-29 9:58 ` sashiko-bot [this message]
2026-10-29 9:44 ` [PATCH v3 2/4] dt-bindings: arm: qcom: document Radxa Dragon Q8B Xilin Wu
2026-10-29 9:47 ` sashiko-bot
2026-10-29 9:44 ` [PATCH v3 3/4] arm64: dts: qcom: sc8280xp: add " Xilin Wu
2026-10-29 9:58 ` sashiko-bot
2026-10-29 9:44 ` [PATCH v3 4/4] firmware: qcom: scm: Allow QSEECOM for " Xilin Wu
2026-10-29 9:53 ` 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=sashiko-outbox-189076@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=sophon@radxa.com \
/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.