From: sashiko-bot@kernel.org
To: "Nicolin Chen" <nicolinc@nvidia.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v5 2/3] PCI: Allow ATS to be always on for pre-CXL devices
Date: Wed, 20 May 2026 20:46:47 +0000 [thread overview]
Message-ID: <20260520204648.615B91F00A39@smtp.kernel.org> (raw)
In-Reply-To: <35e75bf0abfa48f76bc87d73a772a3faf6271a9f.1779304390.git.nicolinc@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The matching logic in `pci_dev_specific_ats_required()` is flawed: it ignores the `device` field when a callback is provided and fails to handle `PCI_ANY_ID` wildcards when a callback is absent.
--
commit fb36e847666c196ca64ced94fef31e14f46cf42d
Author: Nicolin Chen <nicolinc@nvidia.com>
PCI: Allow ATS to be always on for pre-CXL devices
This commit introduces a pci_dev_specific_ats_required() quirk function to
allow certain pre-CXL devices to keep ATS always on. It adds a list of IDs
for these devices and integrates the quirk into pci_ats_required().
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index caaed1a01dc02..c0242f3e9f063 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
[ ... ]
> +bool pci_dev_specific_ats_required(struct pci_dev *pdev)
> +{
> + const struct pci_dev_ats_required *i;
> +
> + for (i = pci_dev_ats_required; i->vendor; i++) {
> + if (i->vendor != pdev->vendor)
> + continue;
> + if (i->ats_required && i->ats_required(pdev))
> + return true;
> + if (!i->ats_required && i->device == pdev->device)
> + return true;
> + }
> +
> + return false;
> +}
[Severity: Medium]
Does this matching logic inadvertently ignore the device field when a
callback is provided, and miss handling PCI_ANY_ID when a callback is absent?
If a future entry specifies a precise device ID along with a callback (e.g.,
{ VENDOR, 0x1234, my_quirk }), the specific device ID will be ignored, and
the callback will execute for all devices from that vendor.
Alternatively, if a callback is absent, a catch-all definition like
{ VENDOR, PCI_ANY_ID, NULL } would literally compare pdev->device against
0xFFFF and silently fail to match because it lacks a PCI_ANY_ID check.
While this functionally works for the two currently defined table entries in
the patch, could this be updated to mirror standard PCI quirk parsing
behavior (like pci_dev_specific_reset()) to prevent issues for future
additions?
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1779304390.git.nicolinc@nvidia.com?part=2
next prev parent reply other threads:[~2026-05-20 20:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-20 19:46 [PATCH v5 0/3] Allow ATS to be always on for certain ATS-capable devices Nicolin Chen
2026-05-20 19:46 ` [PATCH v5 1/3] PCI: Add pci_ats_required() for CXL.cache capable devices Nicolin Chen
2026-05-20 20:03 ` Bjorn Helgaas
2026-05-20 20:20 ` Nicolin Chen
2026-05-20 20:26 ` sashiko-bot
2026-05-20 19:46 ` [PATCH v5 2/3] PCI: Allow ATS to be always on for pre-CXL devices Nicolin Chen
2026-05-20 20:04 ` Bjorn Helgaas
2026-05-20 20:46 ` sashiko-bot [this message]
2026-05-20 19:46 ` [PATCH v5 3/3] iommu/arm-smmu-v3: Allow ATS to be always on Nicolin Chen
2026-05-20 21:33 ` sashiko-bot
2026-05-20 22:35 ` Nicolin Chen
2026-05-21 13:44 ` Jason Gunthorpe
2026-05-21 17:44 ` Nicolin Chen
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=20260520204648.615B91F00A39@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--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 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.