From: Lukas Wunner <lukas@wunner.de>
To: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org,
Rafael J Wysocki <rafael@kernel.org>,
Guixin Liu <kanie@linux.alibaba.com>,
Olof Johansson <olof@lixom.net>
Subject: Re: [PATCH v13 1/5] PCI/DPC: Ignore devices with no AER Capability
Date: Sun, 20 Sep 2026 08:11:56 +0200 [thread overview]
Message-ID: <aq95LGUHL-pnmTlr@wunner.de> (raw)
In-Reply-To: <20260919162655.3499010-2-sathyanarayanan.kuppuswamy@linux.intel.com>
On Sat, Sep 19, 2026 at 09:26:51AM -0700, Kuppuswamy Sathyanarayanan wrote:
> Downstream Ports may support DPC regardless of whether they support AER
> (see PCIe r7.0, sec 6.2.11.2). Previously, if the user booted with
> "pcie_ports=dpc-native", it was possible for dpc_probe() to succeed even if
> the device had no AER Capability, but dpc_get_aer_uncorrect_severity()
> depends on the AER Capability.
[...]
> +++ b/drivers/pci/pcie/dpc.c
> @@ -477,6 +477,9 @@ static int dpc_probe(struct pcie_device *dev)
> int status;
> u16 cap;
>
> + if (!pdev->aer_cap)
> + return -ENOTSUPP;
> +
> if (!pcie_aer_is_native(pdev) && !pcie_ports_dpc_native)
> return -ENOTSUPP;
I've got patches which make DPC work (again) on AER-unsupporting ports:
https://github.com/l1k/linux/commits/aer_baseline_v1/
In particular:
PCI/DPC: Avoid access to non-existent AER capability
https://github.com/l1k/linux/commit/85f209fd4732
PCI/DPC: Reinstate support for AER-incapable ports
https://github.com/l1k/linux/commit/2de89b762d79
I'm almost done with that series and hope to submit it this cycle.
Your patch [1/5] will cause a conflict with my patches.
Would you mind holding off on patch [1/5] for now?
There's another reason: I know of one product in particular,
Intel "Ponte Vecchio" data center GPUs, which support DPC but
lack an AER capability. DPC was tested and made to work on
those cards (see 53b54ad074de).
I didn't realize back then but know now that validation engineers
specifically used pcie_ports=dpc-native to be able to use DPC on
that product. And I believe this was also communicated to customers
as "best known method" for DPC on Ponte Vecchio. In other words,
using pcie_ports=dpc-native to make DPC work on non-AER-capable products
has become a feature. Your patch breaks those use cases.
That's why I chose to make DPC work (again) on non-AER-capable products
with the above-linked patches, instead of closing this loophole to
force-enable it.
Thanks,
Lukas
next prev parent reply other threads:[~2026-09-20 6:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-19 16:26 [PATCH v13 0/5] Simplify PCIe native ownership Kuppuswamy Sathyanarayanan
2026-09-19 16:26 ` [PATCH v13 1/5] PCI/DPC: Ignore devices with no AER Capability Kuppuswamy Sathyanarayanan
2026-09-20 6:11 ` Lukas Wunner [this message]
2026-09-19 16:26 ` [PATCH v13 2/5] PCI: Assume control of portdrv-related features only when portdrv enabled Kuppuswamy Sathyanarayanan
2026-09-20 6:17 ` Lukas Wunner
2026-09-19 16:26 ` [PATCH v13 3/5] PCI/ACPI: Tidy _OSC control bit checking Kuppuswamy Sathyanarayanan
2026-09-19 16:26 ` [PATCH v13 4/5] PCI/ACPI: Centralize pcie_ports_native checking Kuppuswamy Sathyanarayanan
2026-09-20 7:24 ` Guixin Liu
2026-09-19 16:26 ` [PATCH v13 5/5] PCI: Centralize pci_aer_available() checking Kuppuswamy Sathyanarayanan
-- strict thread matches above, loose matches on Subject: below --
2021-01-23 1:11 [PATCH v13 0/5] Simplify PCIe native ownership Kuppuswamy Sathyanarayanan
2021-01-23 1:11 ` [PATCH v13 1/5] PCI/DPC: Ignore devices with no AER Capability Kuppuswamy Sathyanarayanan
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=aq95LGUHL-pnmTlr@wunner.de \
--to=lukas@wunner.de \
--cc=bhelgaas@google.com \
--cc=kanie@linux.alibaba.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=olof@lixom.net \
--cc=rafael@kernel.org \
--cc=sathyanarayanan.kuppuswamy@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®