From: Yazen Ghannam <yazen.ghannam@amd.com>
To: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Lukas Wunner <lukas@wunner.de>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Mahesh J Salgaonkar <mahesh@linux.ibm.com>,
Oliver O'Halloran <oohall@gmail.com>, Len Brown <lenb@kernel.org>,
linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/6] PCI/DPC: Reinstate support for AER-incapable ports
Date: Tue, 3 Nov 2026 15:14:49 -0500 [thread overview]
Message-ID: <20261103201449.GB314988@yaz-khff2.amd.com> (raw)
In-Reply-To: <20261020181924.3003553-3-sathyanarayanan.kuppuswamy@linux.intel.com>
On Tue, Oct 20, 2026 at 11:19:19AM -0700, Kuppuswamy Sathyanarayanan wrote:
> From: Lukas Wunner <lukas@wunner.de>
>
> Downstream Port Containment does not mandate presence of an Advanced Error
> Reporting capability, so a Downstream Port may support DPC, but not AER
> (PCIe r7.1 sec 6.2.11.2).
>
> Commit 708b20003624 ("PCI/AER: Remove HEST/FIRMWARE_FIRST parsing for AER
> ownership") seemingly inadvertently constrained DPC to AER-supporting
> Downstream Ports by inserting a call to pcie_aer_is_native() in
> dpc_probe(), which implicitly checks for presence of an AER capability.
>
> Drop the call. It is superfluous because it duplicates the conditions
> applied by the PCIe port service driver when it decides whether to
> instantiate a DPC port service (see get_port_device_capability()).
> If the conditions are not met, no port service is instantiated and
> dpc_probe() isn't executed.
>
> The only difference between the conditions in dpc_probe() and the ones in
> get_port_device_capability() is the check for the AER capability, so by
> removing the checks from dpc_probe(), DPC is supported on AER-incapable
> Downstream Ports again.
>
> Fixes: 708b20003624 ("PCI/AER: Remove HEST/FIRMWARE_FIRST parsing for AER ownership")
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> Cc: stable@vger.kernel.org # v5.8+
Another open question from the other set:
https://lore.kernel.org/all/02a33171-b901-400b-921a-c40fe167b424@linux.intel.com/
Maybe the issue is more about how to handle the Fixes tag?
The recent commit is where this seems to functionally break.
The older commit is where this logically broke.
> ---
> drivers/pci/pcie/dpc.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
> index 793a799053f1..104ff2b91f1f 100644
> --- a/drivers/pci/pcie/dpc.c
> +++ b/drivers/pci/pcie/dpc.c
> @@ -474,9 +474,6 @@ static int dpc_probe(struct pcie_device *dev)
> int status;
> u16 cap;
>
> - if (!pcie_aer_is_native(pdev) && !pcie_ports_dpc_native)
> - return -ENOTSUPP;
> -
> status = devm_request_threaded_irq(device, dev->irq, dpc_irq,
> dpc_handler, IRQF_SHARED,
> "pcie-dpc", pdev);
> --
But I agree this is okay otherwise.
Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com>
Thanks,
Yazen
next prev parent reply other threads:[~2026-11-03 20:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-20 18:19 [PATCH v2 0/6] PCI/DPC: Decide DPC ownership with host_bridge->native_dpc Kuppuswamy Sathyanarayanan
2026-10-20 18:19 ` [PATCH v2 1/6] PCI/DPC: Avoid access to non-existent AER capability Kuppuswamy Sathyanarayanan
2026-11-03 19:47 ` Yazen Ghannam
2026-11-03 20:25 ` Kuppuswamy Sathyanarayanan
2026-11-03 21:00 ` Lukas Wunner
2026-10-20 18:19 ` [PATCH v2 2/6] PCI/DPC: Reinstate support for AER-incapable ports Kuppuswamy Sathyanarayanan
2026-11-03 20:14 ` Yazen Ghannam [this message]
2026-10-20 18:19 ` [PATCH v2 3/6] PCI/EDR: Remove CONFIG_PCIE_EDR Kuppuswamy Sathyanarayanan
2026-11-03 20:46 ` Yazen Ghannam
2026-10-20 18:19 ` [PATCH v2 4/6] PCI/portdrv: Don't require AER to bind DPC service Kuppuswamy Sathyanarayanan
2026-10-20 18:19 ` [PATCH v2 5/6] PCI/ACPI: Request DPC control only together with AER control Kuppuswamy Sathyanarayanan
2026-10-20 18:19 ` [PATCH v2 6/6] PCI/portdrv: Bind DPC service based on host_bridge->native_dpc 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=20261103201449.GB314988@yaz-khff2.amd.com \
--to=yazen.ghannam@amd.com \
--cc=bhelgaas@google.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mahesh@linux.ibm.com \
--cc=oohall@gmail.com \
--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®