From: Manikanta Maddireddy <mmaddireddy@nvidia.com>
To: Manivannan Sadhasivam <mani@kernel.org>,
sashiko-reviews@lists.linux.dev,
Thierry Reding <thierry.reding@kernel.org>
Cc: linux-pci@vger.kernel.org, conor+dt@kernel.org, robh@kernel.org,
devicetree@vger.kernel.org
Subject: Re: [PATCH v9 3/5] PCI: tegra: Add Tegra264 support
Date: Fri, 7 Aug 2026 10:35:30 +0530 [thread overview]
Message-ID: <9cc29a0b-6a9c-4b97-9cfd-f24ccad654fc@nvidia.com> (raw)
In-Reply-To: <sdpakcbeferzpxn6bf2acic4kfnfoaa6kgxmmi3asw7jqprekf@66cnwvuwk4ye>
On 05/08/26 9:21 pm, Manivannan Sadhasivam wrote:
> On Wed, Aug 05, 2026 at 12:10:38PM +0000, sashiko-bot@kernel.org wrote:
>> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
>> - [High] The driver incorrectly accesses the ECAM window via `pcie->cfg->win` to read the root port configuration space, causing an out-of-bounds heap read on 32-bit platforms.
>> - [High] The driver incorrectly uses the Negotiated Link Width (NLW) to set interconnect bandwidth for hotplug-capable ports when the link is down, permanently setting it to 0.
>> --
>>
>> --- Patch [3]: [PATCH v9 3/5] PCI: tegra: Add Tegra264 support ---
>> commit af63006f768e2991e49a48de9855ea58d20662ed
>> Author: Thierry Reding <treding@nvidia.com>
>>
>> PCI: tegra: Add Tegra264 support
>>
>> Add a driver for the PCIe controller found on NVIDIA Tegra264 SoCs. The
>> driver is very small, with its main purpose being to set up the address
>> translation registers and then creating a standard PCI host using ECAM.
>>
>>> diff --git a/drivers/pci/controller/pcie-tegra264.c b/drivers/pci/controller/pcie-tegra264.c
>>> new file mode 100644
>>> index 0000000000000..e0c5b9d0d20bf
>>> --- /dev/null
>>> +++ b/drivers/pci/controller/pcie-tegra264.c
>> [ ... ]
>>> +static void tegra264_pcie_icc_set(struct tegra264_pcie *pcie)
>>> +{
>>> + u32 value, speed, width;
>>> + int err;
>>> +
>>> + value = readw(pcie->ecam + XTL_RC_PCIE_CFG_LINK_STATUS);
>>> + speed = FIELD_GET(PCI_EXP_LNKSTA_CLS, value);
>>> + width = FIELD_GET(PCI_EXP_LNKSTA_NLW, value);
>>> +
>>> + value = Mbps_to_icc(width * PCIE_SPEED2MBS_ENC(pcie_link_speed[speed]));
>>
>> [Severity: High]
>> Will this permanently set the interconnect bandwidth to 0 for hotplug-capable
>> ports if the link is initially down?
>>
>> When the link is down, the Negotiated Link Width (NLW) is 0, which means
>> the bandwidth value will be calculated as 0. Since the generic pciehp driver
>> handles hotplug but doesn't know about this driver's specific interconnect
>> bandwidth requirements, it appears there is no way to dynamically increase
>> the bandwidth later when a device is actually inserted.
>>
>
> I think this is a valid concern. If the ICC BW is set to 0, then the hotplugged
> device won't work properly.
>
>> Should this read the Maximum Link Width and Speed from PCI_EXP_LNKCAP
>> instead of PCI_EXP_LNKSTA to properly reserve bandwidth for a hotplug slot?
>>
>
> If possible, BW should be updated once the device is added, but that requires
> detecting Link Up using some custom IRQ if available.
>
> - Mani
>
Custom IRQ support for link up and down events is not available in this
IP. For now, we have two options:
1. Don’t set ICC BW for the hot-plug controller.
2. Set ICC BW according to the Link Cap settings when the link is down
and it is a hot-plug controller. When the link is up, use the Link
Status settings.
We can get changes in link speed/width from the BW notification status.
IIRC, the BW notification port driver has been reverted. If it comes
back, we can consider integrating the ICC BW set logic into it instead
of implementing it in each controller driver.
--
nvpublic
next prev parent reply other threads:[~2026-08-07 5:05 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 11:57 [PATCH v9 0/5] PCI: tegra: Add Tegra264 support Thierry Reding
2026-08-05 11:57 ` [PATCH v9 1/5] dt-bindings: pci: tegra264: Strictly distinguish C0 from C1-C5 Thierry Reding
2026-08-05 12:06 ` sashiko-bot
2026-08-05 11:57 ` [PATCH v9 2/5] dt-bindings: pci: tegra264: Switch to PCIe root port bindings Thierry Reding
2026-08-05 12:09 ` sashiko-bot
2026-08-05 15:12 ` Rob Herring (Arm)
2026-08-05 11:57 ` [PATCH v9 3/5] PCI: tegra: Add Tegra264 support Thierry Reding
2026-08-05 12:10 ` sashiko-bot
2026-08-05 15:51 ` Manivannan Sadhasivam
2026-08-07 5:05 ` Manikanta Maddireddy [this message]
2026-08-07 5:19 ` Manivannan Sadhasivam
2026-08-05 11:57 ` [PATCH v9 4/5] arm64: tegra: Reorder reg and reg-names to match bindings Thierry Reding
2026-08-05 12:05 ` sashiko-bot
2026-08-05 11:57 ` [PATCH v9 5/5] arm64: tegra: Add PCIe root ports on Tegra264 Thierry Reding
2026-08-05 12:05 ` sashiko-bot
2026-08-05 15:55 ` Manivannan Sadhasivam
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=9cc29a0b-6a9c-4b97-9cfd-f24ccad654fc@nvidia.com \
--to=mmaddireddy@nvidia.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mani@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox