From: sashiko-bot@kernel.org
To: "Thierry Reding" <thierry.reding@kernel.org>
Cc: conor+dt@kernel.org, robh@kernel.org, devicetree@vger.kernel.org,
linux-pci@vger.kernel.org
Subject: Re: [PATCH v8 4/6] PCI: tegra: Add Tegra264 support
Date: Thu, 16 Jul 2026 17:19:46 +0000 [thread overview]
Message-ID: <20260716171946.E85D71F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260716-tegra264-pcie-v8-4-23e51589229b@nvidia.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Heap out-of-bounds read on 32-bit platforms due to union aliasing of `pci_config_window->win`.
- [Medium] Missing runtime PM usage counter decrement on `pm_runtime_get_sync()` failure.
- [Low] Incorrect unit multiplier used in bandwidth request error message.
--
--- Patch [4]: [PATCH v8 4/6] PCI: tegra: Add Tegra264 support ---
commit 4da3b5a2d216f984d21597a5d585e8a8eb97b293
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.
> --- /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]));
> +
> + /*
> + * We don't want to error out here because a boot-critical device
> + * could be connected to this root port. Failure to set the bandwidth
> + * request may have an adverse impact on performance, but it is not
> + * generally fatal, so we opt to continue regardless so that users
> + * get a chance to fix things.
> + */
> + err = icc_set_bw(pcie->icc_path, value, value);
> + if (err < 0)
> + dev_err(pcie->dev,
> + "failed to request bandwidth (%u MBps): %pe\n",
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[Severity: Low]
This isn't a bug, but does this log message print the wrong units?
The value calculated by Mbps_to_icc() appears to be in kilobytes per
second, but the message labels it as "MBps".
[ ... ]
> +static int tegra264_pcie_probe(struct platform_device *pdev)
> +{
[ ... ]
> + pcie->bpmp = tegra_bpmp_get_with_id(dev, &pcie->ctl_id);
> + if (IS_ERR(pcie->bpmp))
> + return dev_err_probe(dev, PTR_ERR(pcie->bpmp),
> + "failed to get BPMP\n");
> +
> + err = devm_pm_runtime_set_active_enabled(dev);
> + if (err < 0) {
> + dev_err_probe(dev, err, "failed to enable runtime PM\n");
> + goto err_put_bpmp;
> + }
> +
> + err = pm_runtime_get_sync(dev);
> + if (err < 0) {
> + dev_err_probe(dev, err, "failed to power on device\n");
> + goto err_put_bpmp;
^^^^^^^^^^^^^^^^^^
[Severity: Medium]
Does this error path leak the runtime PM usage counter?
When pm_runtime_get_sync() fails, it still increments the usage counter. By
jumping directly to err_put_bpmp, the counter is not decremented, which
could prevent the device from entering runtime suspend if probed again later.
> + }
> +
> + /* sanity check that programmed ranges match what's in DT */
> + if (!tegra264_pcie_check_ranges(pdev)) {
> + err = -EINVAL;
> + goto err_put_pm;
> + }
> +
> + pcie->cfg = pci_ecam_create(dev, res, bus->res, &pci_generic_ecam_ops);
> + if (IS_ERR(pcie->cfg)) {
> + err = dev_err_probe(dev, PTR_ERR(pcie->cfg),
> + "failed to create ECAM\n");
> + goto err_put_pm;
> + }
> +
> + bridge->ops = (struct pci_ops *)&pci_generic_ecam_ops.pci_ops;
> + bridge->sysdata = pcie->cfg;
> + pcie->ecam = pcie->cfg->win;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[Severity: High]
Can this assignment cause an out-of-bounds heap read on 32-bit platforms?
If the driver is compiled on a 32-bit architecture (e.g. via COMPILE_TEST)
where per_bus_mapping is true, the pci_config_window->win union aliases the
dynamically allocated cfg->winp array pointer.
When the driver later dereferences pcie->ecam using readw() in
tegra264_pcie_link_up():
u16 value = readw(pcie->ecam + XTL_RC_PCIE_CFG_LINK_STATUS);
It will read from the heap array pointer instead of mapped I/O memory,
resulting in a crash or garbage read.
> +
> + tegra264_pcie_init(pcie);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260716-tegra264-pcie-v8-0-23e51589229b@nvidia.com?part=4
next prev parent reply other threads:[~2026-07-16 17:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-16 17:07 [PATCH v8 0/6] PCI: tegra: Add Tegra264 support Thierry Reding
2026-07-16 17:07 ` [PATCH v8 1/6] dt-bindings: pci: tegra264: Strictly distinguish C0 from C1-C5 Thierry Reding
2026-07-16 17:20 ` sashiko-bot
2026-07-16 17:07 ` [PATCH v8 2/6] dt-bindings: pci: tegra264: Switch to PCIe root port bindings Thierry Reding
2026-07-16 17:12 ` sashiko-bot
2026-07-16 17:07 ` [PATCH v8 3/6] PCI: Use standard wait times for PCIe link monitoring Thierry Reding
2026-07-16 17:33 ` sashiko-bot
2026-07-16 17:07 ` [PATCH v8 4/6] PCI: tegra: Add Tegra264 support Thierry Reding
2026-07-16 17:19 ` sashiko-bot [this message]
2026-07-16 17:07 ` [PATCH v8 5/6] arm64: tegra: Reorder reg and reg-names to match bindings Thierry Reding
2026-07-16 17:13 ` sashiko-bot
2026-07-16 17:07 ` [PATCH v8 6/6] arm64: tegra: Add PCIe root ports on Tegra264 Thierry Reding
2026-07-16 17:17 ` 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=20260716171946.E85D71F000E9@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.