From: sashiko-bot@kernel.org
To: "Thierry Reding" <thierry.reding@kernel.org>
Cc: linux-pci@vger.kernel.org, robh@kernel.org,
devicetree@vger.kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v10 4/5] arm64: tegra: Reorder reg and reg-names to match bindings
Date: Fri, 14 Aug 2026 15:52:21 +0000 [thread overview]
Message-ID: <20260814155221.AF30F1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260814-tegra264-pcie-v10-4-05d08c592b05@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Incorrect register offset for PCIe Link Capabilities causes garbage ICC bandwidth calculation
--
--- Patch [4]: [PATCH v10 4/5] arm64: tegra: Reorder reg and reg-names to match bindings ---
commit 1aff20381185113aa8fbe2813f31f1849b4105ad
Author: Thierry Reding <treding@nvidia.com>
arm64: tegra: Reorder reg and reg-names to match bindings
This commit reorders the "reg" and "reg-names" properties for the tegra264
PCIe controller nodes so that the ECAM region is listed last. This ensures
that the first entry matches the unit-address in the device tree nodes.
> diff --git a/arch/arm64/boot/dts/nvidia/tegra264.dtsi b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
> index 013228a817237..ab1e83d856fd9 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra264.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
> @@ -3537,11 +3537,11 @@ cmdqv4: cmdqv@b200000 {
>
> pci@c000000 {
> compatible = "nvidia,tegra264-pcie";
> - reg = <0xd0 0xb0000000 0x0 0x10000000>,
> - <0x00 0x0c000000 0x0 0x00004000>,
> + reg = <0x00 0x0c000000 0x0 0x00004000>,
> <0x00 0x0c004000 0x0 0x00001000>,
> - <0x00 0x0c005000 0x0 0x00001000>;
> - reg-names = "ecam", "xal", "xtl", "xtl-pri";
> + <0x00 0x0c005000 0x0 0x00001000>,
> + <0xd0 0xb0000000 0x0 0x10000000>;
> + reg-names = "xal", "xtl", "xtl-pri", "ecam";
[Severity: High]
Is the offset for XTL_RC_PCIE_CFG_LINK_CAPS in the tegra264 PCIe driver
correct? The PCIe Capability structure starts at 0x48, making the 32-bit
Link Capabilities register offset 0x48 + 0x0c = 0x54.
However, the driver defines it as 0x56:
drivers/pci/controller/pcie-tegra264.c:
#define XTL_RC_PCIE_CFG_LINK_CAPS 0x56
When the link is down and the port supports hotplug, tegra264_pcie_icc_set()
calculates bandwidth using this offset:
drivers/pci/controller/pcie-tegra264.c:tegra264_pcie_icc_set() {
...
value = readw(pcie->ecam + XTL_RC_PCIE_CFG_LINK_CAPS);
speed = FIELD_GET(PCI_EXP_LNKCAP_SLS, value);
width = FIELD_GET(PCI_EXP_LNKCAP_MLW, value);
...
}
Does this readw() at offset 0x56 extract the upper 16 bits of the Link
Capabilities register instead of the lower 16 bits?
If so, this would cause FIELD_GET() to extract garbage data for both speed
and width (bits 16-19 for SLS and 20-25 for MLW), which could result in a
0 MB/s bandwidth request and starve the PCIe controller when a device is
later hotplugged.
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260814-tegra264-pcie-v10-0-05d08c592b05@nvidia.com?part=4
next prev parent reply other threads:[~2026-08-14 15:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-14 15:38 [PATCH v10 0/5] PCI: tegra: Add Tegra264 support Thierry Reding
2026-08-14 15:38 ` [PATCH v10 1/5] dt-bindings: pci: tegra264: Strictly distinguish C0 from C1-C5 Thierry Reding
2026-08-14 15:46 ` sashiko-bot
2026-08-14 15:38 ` [PATCH v10 2/5] dt-bindings: pci: tegra264: Switch to PCIe root port bindings Thierry Reding
2026-08-14 15:44 ` sashiko-bot
2026-08-14 15:38 ` [PATCH v10 3/5] PCI: tegra: Add Tegra264 support Thierry Reding
2026-08-14 15:51 ` sashiko-bot
2026-08-14 15:38 ` [PATCH v10 4/5] arm64: tegra: Reorder reg and reg-names to match bindings Thierry Reding
2026-08-14 15:52 ` sashiko-bot [this message]
2026-08-14 15:38 ` [PATCH v10 5/5] arm64: tegra: Add PCIe root ports on Tegra264 Thierry Reding
2026-08-14 15:44 ` 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=20260814155221.AF30F1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=thierry.reding@kernel.org \
/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.