[PATCH v2 0/6] PCI/DPC: Decide DPC ownership with host_bridge->native_dpc

[PATCH v2 0/6] PCI/DPC: Decide DPC ownership with host_bridge->native_dpc

[Kuppuswamy Sathyanarayanan]

This series makes host_bridge->native_dpc the single decider for whether
Linux uses DPC, as Bjorn asked during the review of "Simplify PCIe native
ownership".

  https://lore.kernel.org/r/20261001221408.GA2731929@bhelgaas

Today the DPC service binds on host_bridge->native_aer, AER availability
and "pcie_ports=dpc-native".  host_bridge->native_dpc is only consulted
by pci_dpc_recovered().  After this series, native_dpc is the end result
of everything that decides DPC ownership, and portdrv binds the DPC
service on it.

The series depends on:

  - Three patches from v15 of "Simplify PCIe native ownership", merged
    into pci/portdrv.  They fold "pcie_ports=native" and
    "pcie_ports=dpc-native" into the _OSC control mask, so native_dpc
    already reflects the command line.

    https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/log/?h=portdrv

  - Two DPC patches from Lukas's "Error reporting for AER-incapable
    devices", which are included here directly as patches 1-2.

    https://lore.kernel.org/r/ae05fe2df3a3182594c4a9638daba1c72cf40358.1790531238.git.lukas@wunner.de
    https://lore.kernel.org/r/2ce502e5caa57db01e0a7bbc781210b66b73bec8.1790531238.git.lukas@wunner.de

Patch 1 keeps the DPC driver from accessing a non-existent AER
capability.

Patch 2 drops the AER ownership check from dpc_probe(), so DPC also
works on ports without an AER capability.

Patch 3 removes CONFIG_PCIE_EDR, which was another knob in deciding
whether to request DPC control in _OSC.

Patch 4 stops requiring pci_aer_available() to bind the DPC service,
since the DPC driver does not depend on MSI or on the AER driver.

Patch 5 requests DPC control only together with AER control, as PCI
Firmware r3.3, sec 4.5.2.4, requires.

Patch 6 binds the DPC service on host_bridge->native_dpc and logs a
message when the OS assumes DPC control that _OSC did not grant.

Changes since v1:

  - Include Lukas's two DPC patches instead of depending on his series
    (Bjorn).

  - Add Rafael's Acked-by to "Request DPC control only together with AER
    control".

  - Refer to "PCI/DPC: Reinstate support for AER-incapable ports" instead
    of Lukas's series in the native_dpc binding patch.

v1: https://lore.kernel.org/r/20261007165840.1604136-1-sathyanarayanan.kuppuswamy@linux.intel.com

Kuppuswamy Sathyanarayanan (4):
  PCI/EDR: Remove CONFIG_PCIE_EDR
  PCI/portdrv: Don't require AER to bind DPC service
  PCI/ACPI: Request DPC control only together with AER control
  PCI/portdrv: Bind DPC service based on host_bridge->native_dpc

Lukas Wunner (2):
  PCI/DPC: Avoid access to non-existent AER capability
  PCI/DPC: Reinstate support for AER-incapable ports

 drivers/acpi/pci_root.c    | 26 +++++++++++++++++++++++---
 drivers/pci/pcie/Kconfig   |  9 ---------
 drivers/pci/pcie/Makefile  |  5 ++++-
 drivers/pci/pcie/dpc.c     | 31 +++++++++++++------------------
 drivers/pci/pcie/portdrv.c |  7 +------
 include/linux/pci-acpi.h   |  4 ++--
 6 files changed, 43 insertions(+), 39 deletions(-)


base-commit: 4fe37866b0d92cdc45b62954a76489a9d9f8bd73
-- 
2.43.0

[PATCH v2 1/6] PCI/DPC: Avoid access to non-existent AER capability

[Kuppuswamy Sathyanarayanan]

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).

In February 2019, commit 9f08a5d896ce ("PCI/DPC: Fix print AER status in
DPC event handling") amended the DPC driver to access the AER capability
without checking for its presence.

In May 2020, commit 708b20003624 ("PCI/AER: Remove HEST/FIRMWARE_FIRST
parsing for AER ownership") fixed it by inserting a call to
pcie_aer_is_native() in dpc_probe(), which implicitly checks for presence
of an AER capability.

However already in October 2019, commit 35a0b2378c19 ("PCI/DPC: Add
"pcie_ports=dpc-native" to allow DPC without AER control") made it
possible to override the check:  The DPC driver may access a non-existent
AER capability if "pcie_ports=dpc-native" is passed on the command line.

Fix it by making the DPC driver cope with AER-unsupporting Downstream
Ports.

There are two places where the AER capability is accessed:

- dpc_get_aer_uncorrect_severity() uses it to discern whether a Fatal or
  Non-Fatal Error triggered DPC.  Access the Device Status Register
  instead, in accordance with PCIe r7.1 sec 6.2.5.

- dpc_is_surprise_removal() uses it to detect whether a Surprise Down
  Error triggered DPC.  Return false on AER-unsupporting devices.  The
  function works around an AMD-specific quirk and it seems reasonable to
  assume that all affected products are AER-supporting.  In any case the
  detection is not possible without AER capability.

Insert a temporary check for an AER capability after the call to
aer_get_device_error_info() because the function currently returns false
for AER-unsupporting devices.  The check will become obsolete and will be
removed with the imminent baseline capability error reporting.

Fixes: 35a0b2378c19 ("PCI/DPC: Add "pcie_ports=dpc-native" to allow DPC without AER control")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: stable@vger.kernel.org # v5.5+
---
 drivers/pci/pcie/dpc.c | 23 ++++++++++-------------
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
index 2b779bd1d861..793a799053f1 100644
--- a/drivers/pci/pcie/dpc.c
+++ b/drivers/pci/pcie/dpc.c
@@ -236,21 +236,15 @@ static void dpc_process_rp_pio_error(struct pci_dev *pdev)
 static int dpc_get_aer_uncorrect_severity(struct pci_dev *dev,
 					  struct aer_err_info *info)
 {
-	int pos = dev->aer_cap;
-	u32 status, mask, sev;
+	u16 devsta;
 
-	pci_read_config_dword(dev, pos + PCI_ERR_UNCOR_STATUS, &status);
-	pci_read_config_dword(dev, pos + PCI_ERR_UNCOR_MASK, &mask);
-	status &= ~mask;
-	if (!status)
-		return 0;
-
-	pci_read_config_dword(dev, pos + PCI_ERR_UNCOR_SEVER, &sev);
-	status &= sev;
-	if (status)
+	pcie_capability_read_word(dev, PCI_EXP_DEVSTA, &devsta);
+	if (devsta & PCI_EXP_DEVSTA_FED)
 		info->severity = AER_FATAL;
-	else
+	else if (devsta & PCI_EXP_DEVSTA_NFED)
 		info->severity = AER_NONFATAL;
+	else
+		return 0;
 
 	info->level = KERN_ERR;
 
@@ -275,7 +269,7 @@ void dpc_process_error(struct pci_dev *pdev)
 		pci_warn(pdev, "containment event, status:%#06x: unmasked uncorrectable error detected\n",
 			 status);
 		if (dpc_get_aer_uncorrect_severity(pdev, &info) &&
-		    aer_get_device_error_info(&info, 0)) {
+		    (aer_get_device_error_info(&info, 0) || !pdev->aer_cap)) {
 			aer_print_error(&info, 0);
 			pci_aer_clear_nonfatal_status(pdev);
 			pci_aer_clear_fatal_status(pdev);
@@ -353,6 +347,9 @@ static bool dpc_is_surprise_removal(struct pci_dev *pdev)
 	if (!pdev->is_hotplug_bridge)
 		return false;
 
+	if (!pdev->aer_cap)
+		return false;
+
 	if (pci_read_config_word(pdev, pdev->aer_cap + PCI_ERR_UNCOR_STATUS,
 				 &status))
 		return false;
-- 
2.43.0

Re: [PATCH v2 1/6] PCI/DPC: Avoid access to non-existent AER capability

[Yazen Ghannam]

On Tue, Oct 20, 2026 at 11:19:18AM -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).
> 
> In February 2019, commit 9f08a5d896ce ("PCI/DPC: Fix print AER status in
> DPC event handling") amended the DPC driver to access the AER capability
> without checking for its presence.
> 
> In May 2020, commit 708b20003624 ("PCI/AER: Remove HEST/FIRMWARE_FIRST
> parsing for AER ownership") fixed it by inserting a call to
> pcie_aer_is_native() in dpc_probe(), which implicitly checks for presence
> of an AER capability.
> 
> However already in October 2019, commit 35a0b2378c19 ("PCI/DPC: Add
> "pcie_ports=dpc-native" to allow DPC without AER control") made it
> possible to override the check:  The DPC driver may access a non-existent
> AER capability if "pcie_ports=dpc-native" is passed on the command line.
> 
> Fix it by making the DPC driver cope with AER-unsupporting Downstream
> Ports.
> 
> There are two places where the AER capability is accessed:
> 
> - dpc_get_aer_uncorrect_severity() uses it to discern whether a Fatal or
>   Non-Fatal Error triggered DPC.  Access the Device Status Register
>   instead, in accordance with PCIe r7.1 sec 6.2.5.
> 
> - dpc_is_surprise_removal() uses it to detect whether a Surprise Down
>   Error triggered DPC.  Return false on AER-unsupporting devices.  The
>   function works around an AMD-specific quirk and it seems reasonable to
>   assume that all affected products are AER-supporting.  In any case the
>   detection is not possible without AER capability.
> 
> Insert a temporary check for an AER capability after the call to
> aer_get_device_error_info() because the function currently returns false
> for AER-unsupporting devices.  The check will become obsolete and will be
> removed with the imminent baseline capability error reporting.
> 
> Fixes: 35a0b2378c19 ("PCI/DPC: Add "pcie_ports=dpc-native" to allow DPC without AER control")
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> Cc: stable@vger.kernel.org # v5.5+
> ---
>  drivers/pci/pcie/dpc.c | 23 ++++++++++-------------
>  1 file changed, 10 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
> index 2b779bd1d861..793a799053f1 100644
> --- a/drivers/pci/pcie/dpc.c
> +++ b/drivers/pci/pcie/dpc.c
> @@ -236,21 +236,15 @@ static void dpc_process_rp_pio_error(struct pci_dev *pdev)
>  static int dpc_get_aer_uncorrect_severity(struct pci_dev *dev,
>  					  struct aer_err_info *info)
>  {
> -	int pos = dev->aer_cap;
> -	u32 status, mask, sev;
> +	u16 devsta;
>  
> -	pci_read_config_dword(dev, pos + PCI_ERR_UNCOR_STATUS, &status);
> -	pci_read_config_dword(dev, pos + PCI_ERR_UNCOR_MASK, &mask);
> -	status &= ~mask;
> -	if (!status)
> -		return 0;
> -
> -	pci_read_config_dword(dev, pos + PCI_ERR_UNCOR_SEVER, &sev);
> -	status &= sev;
> -	if (status)
> +	pcie_capability_read_word(dev, PCI_EXP_DEVSTA, &devsta);
> +	if (devsta & PCI_EXP_DEVSTA_FED)
>  		info->severity = AER_FATAL;
> -	else
> +	else if (devsta & PCI_EXP_DEVSTA_NFED)
>  		info->severity = AER_NONFATAL;
> +	else
> +		return 0;
>  
>  	info->level = KERN_ERR;

Did you settle your question from here?

https://lore.kernel.org/all/74fe0d79-dc90-4c05-ba9c-9a0eec1ada48@linux.intel.com/

Thanks,
Yazen

Re: [PATCH v2 1/6] PCI/DPC: Avoid access to non-existent AER capability

[Kuppuswamy Sathyanarayanan]

Hi,

On 11/3/2026 11:47 AM, Yazen Ghannam wrote:
> On Tue, Oct 20, 2026 at 11:19:18AM -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).
>>
>> In February 2019, commit 9f08a5d896ce ("PCI/DPC: Fix print AER status in
>> DPC event handling") amended the DPC driver to access the AER capability
>> without checking for its presence.
>>
>> In May 2020, commit 708b20003624 ("PCI/AER: Remove HEST/FIRMWARE_FIRST
>> parsing for AER ownership") fixed it by inserting a call to
>> pcie_aer_is_native() in dpc_probe(), which implicitly checks for presence
>> of an AER capability.
>>
>> However already in October 2019, commit 35a0b2378c19 ("PCI/DPC: Add
>> "pcie_ports=dpc-native" to allow DPC without AER control") made it
>> possible to override the check:  The DPC driver may access a non-existent
>> AER capability if "pcie_ports=dpc-native" is passed on the command line.
>>
>> Fix it by making the DPC driver cope with AER-unsupporting Downstream
>> Ports.
>>
>> There are two places where the AER capability is accessed:
>>
>> - dpc_get_aer_uncorrect_severity() uses it to discern whether a Fatal or
>>   Non-Fatal Error triggered DPC.  Access the Device Status Register
>>   instead, in accordance with PCIe r7.1 sec 6.2.5.
>>
>> - dpc_is_surprise_removal() uses it to detect whether a Surprise Down
>>   Error triggered DPC.  Return false on AER-unsupporting devices.  The
>>   function works around an AMD-specific quirk and it seems reasonable to
>>   assume that all affected products are AER-supporting.  In any case the
>>   detection is not possible without AER capability.
>>
>> Insert a temporary check for an AER capability after the call to
>> aer_get_device_error_info() because the function currently returns false
>> for AER-unsupporting devices.  The check will become obsolete and will be
>> removed with the imminent baseline capability error reporting.
>>
>> Fixes: 35a0b2378c19 ("PCI/DPC: Add "pcie_ports=dpc-native" to allow DPC without AER control")
>> Signed-off-by: Lukas Wunner <lukas@wunner.de>
>> Cc: stable@vger.kernel.org # v5.5+
>> ---
>>  drivers/pci/pcie/dpc.c | 23 ++++++++++-------------
>>  1 file changed, 10 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
>> index 2b779bd1d861..793a799053f1 100644
>> --- a/drivers/pci/pcie/dpc.c
>> +++ b/drivers/pci/pcie/dpc.c
>> @@ -236,21 +236,15 @@ static void dpc_process_rp_pio_error(struct pci_dev *pdev)
>>  static int dpc_get_aer_uncorrect_severity(struct pci_dev *dev,
>>  					  struct aer_err_info *info)
>>  {
>> -	int pos = dev->aer_cap;
>> -	u32 status, mask, sev;
>> +	u16 devsta;
>>  
>> -	pci_read_config_dword(dev, pos + PCI_ERR_UNCOR_STATUS, &status);
>> -	pci_read_config_dword(dev, pos + PCI_ERR_UNCOR_MASK, &mask);
>> -	status &= ~mask;
>> -	if (!status)
>> -		return 0;
>> -
>> -	pci_read_config_dword(dev, pos + PCI_ERR_UNCOR_SEVER, &sev);
>> -	status &= sev;
>> -	if (status)
>> +	pcie_capability_read_word(dev, PCI_EXP_DEVSTA, &devsta);
>> +	if (devsta & PCI_EXP_DEVSTA_FED)
>>  		info->severity = AER_FATAL;
>> -	else
>> +	else if (devsta & PCI_EXP_DEVSTA_NFED)
>>  		info->severity = AER_NONFATAL;
>> +	else
>> +		return 0;
>>  
>>  	info->level = KERN_ERR;
> 
> Did you settle your question from here?
> 
> https://lore.kernel.org/all/74fe0d79-dc90-4c05-ba9c-9a0eec1ada48@linux.intel.com/

No, not yet.  Lukas hasn't replied, and v2 carries his patch unchanged.

The concern still stands.  For a port with an AER capability, the
Fatal/Non-Fatal Error Detected bits in Device Status are set
regardless of the Uncorrectable Error Mask (PCIe r7.1 sec 7.5.3.5).
So a masked Fatal error next to the unmasked Non-Fatal error that
triggered DPC is now reported as Fatal.

If Lukas agrees, I can fix it in v3 by keeping the AER-based logic
when dev->aer_cap is present and using Device Status only for ports
without AER.

> 
> Thanks,
> Yazen

-- 
Sathyanarayanan Kuppuswamy
Linux Kernel Developer

Re: [PATCH v2 1/6] PCI/DPC: Avoid access to non-existent AER capability

[Lukas Wunner]

On Tue, Nov 03, 2026 at 12:25:58PM -0800, Kuppuswamy Sathyanarayanan wrote:
> On 11/3/2026 11:47 AM, Yazen Ghannam wrote:
> > Did you settle your question from here?
> > 
> > https://lore.kernel.org/all/74fe0d79-dc90-4c05-ba9c-9a0eec1ada48@linux.intel.com/
> 
> No, not yet.  Lukas hasn't replied, and v2 carries his patch unchanged.

I'm rebasing my patches on v7.4-rc1 right now and will resubmit
them with this issue and all the others fixed.

Thanks,

Lukas

[PATCH v2 2/6] PCI/DPC: Reinstate support for AER-incapable ports

[Kuppuswamy Sathyanarayanan]

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+
---
 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);
-- 
2.43.0

Re: [PATCH v2 2/6] PCI/DPC: Reinstate support for AER-incapable ports

[Yazen Ghannam]

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

[PATCH v2 3/6] PCI/EDR: Remove CONFIG_PCIE_EDR

[Kuppuswamy Sathyanarayanan]

Error Disconnect Recover (EDR) is the ACPI half of the hybrid DPC model,
where firmware owns DPC and notifies the OS of containment events.

CONFIG_PCIE_EDR made EDR optional on top of CONFIG_PCIE_DPC.  This adds
another knob to the decision to request DPC control in _OSC.  The OS
requests DPC control only if it also supports EDR, so with
CONFIG_PCIE_EDR=n it never requests DPC control.  There is little reason
to build DPC without EDR on ACPI systems.

Remove the option and build edr.c whenever CONFIG_PCIE_DPC and
CONFIG_ACPI are both enabled.

Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
---
 drivers/acpi/pci_root.c   | 6 +++---
 drivers/pci/pcie/Kconfig  | 9 ---------
 drivers/pci/pcie/Makefile | 5 ++++-
 drivers/pci/pcie/dpc.c    | 5 +++--
 include/linux/pci-acpi.h  | 4 ++--
 5 files changed, 12 insertions(+), 17 deletions(-)

diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index a1a9c06012f8..b0e0b33e3254 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -438,7 +438,7 @@ static u32 calculate_support(void)
 		support |= OSC_PCI_ASPM_SUPPORT | OSC_PCI_CLOCK_PM_SUPPORT;
 	if (pci_msi_enabled())
 		support |= OSC_PCI_MSI_SUPPORT;
-	if (IS_ENABLED(CONFIG_PCIE_EDR))
+	if (IS_ENABLED(CONFIG_PCIE_DPC))
 		support |= OSC_PCI_EDR_SUPPORT;
 
 	return support;
@@ -515,9 +515,9 @@ static u32 calculate_control(void)
 	 * Per the Downstream Port Containment Related Enhancements ECN to
 	 * the PCI Firmware Spec, r3.2, sec 4.5.1, table 4-5,
 	 * OSC_PCI_EXPRESS_DPC_CONTROL indicates the OS supports both DPC
-	 * and EDR.
+	 * and EDR.  EDR is always built with DPC on ACPI systems.
 	 */
-	if (IS_ENABLED(CONFIG_PCIE_DPC) && IS_ENABLED(CONFIG_PCIE_EDR))
+	if (IS_ENABLED(CONFIG_PCIE_DPC))
 		control |= OSC_PCI_EXPRESS_DPC_CONTROL;
 
 	return control;
diff --git a/drivers/pci/pcie/Kconfig b/drivers/pci/pcie/Kconfig
index 207c2deae35f..de4ea33b4524 100644
--- a/drivers/pci/pcie/Kconfig
+++ b/drivers/pci/pcie/Kconfig
@@ -137,12 +137,3 @@ config PCIE_PTM
 	  This is only useful if you have devices that support PTM, but it
 	  is safe to enable even if you don't.
 
-config PCIE_EDR
-	bool "PCI Express Error Disconnect Recover support"
-	depends on PCIE_DPC && ACPI
-	help
-	  This option adds Error Disconnect Recover support as specified
-	  in the Downstream Port Containment Related Enhancements ECN to
-	  the PCI Firmware Specification r3.2.  Enable this if you want to
-	  support hybrid DPC model which uses both firmware and OS to
-	  implement DPC.
diff --git a/drivers/pci/pcie/Makefile b/drivers/pci/pcie/Makefile
index b0b43a18c304..46b24311f659 100644
--- a/drivers/pci/pcie/Makefile
+++ b/drivers/pci/pcie/Makefile
@@ -13,4 +13,7 @@ obj-$(CONFIG_PCIEAER_INJECT)	+= aer_inject.o
 obj-$(CONFIG_PCIE_PME)		+= pme.o
 obj-$(CONFIG_PCIE_DPC)		+= dpc.o
 obj-$(CONFIG_PCIE_PTM)		+= ptm.o
-obj-$(CONFIG_PCIE_EDR)		+= edr.o
+
+ifdef CONFIG_ACPI
+obj-$(CONFIG_PCIE_DPC)		+= edr.o
+endif
diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
index 104ff2b91f1f..71adc0e94bca 100644
--- a/drivers/pci/pcie/dpc.c
+++ b/drivers/pci/pcie/dpc.c
@@ -109,10 +109,11 @@ bool pci_dpc_recovered(struct pci_dev *pdev)
 
 	/*
 	 * Synchronization between hotplug and DPC is not supported
-	 * if DPC is owned by firmware and EDR is not enabled.
+	 * if DPC is owned by firmware and there is no EDR, i.e., on
+	 * non-ACPI systems.
 	 */
 	host = pci_find_host_bridge(pdev->bus);
-	if (!host->native_dpc && !IS_ENABLED(CONFIG_PCIE_EDR))
+	if (!host->native_dpc && !IS_ENABLED(CONFIG_ACPI))
 		return false;
 
 	/*
diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
index c0c54baadf04..9715351c0d51 100644
--- a/include/linux/pci-acpi.h
+++ b/include/linux/pci-acpi.h
@@ -123,13 +123,13 @@ extern const guid_t pci_acpi_dsm_guid;
 #define DSM_PCI_POWER_ON_RESET_DELAY		0x08
 #define DSM_PCI_DEVICE_READINESS_DURATIONS	0x09
 
-#ifdef CONFIG_PCIE_EDR
+#ifdef CONFIG_PCIE_DPC
 void pci_acpi_add_edr_notifier(struct pci_dev *pdev);
 void pci_acpi_remove_edr_notifier(struct pci_dev *pdev);
 #else
 static inline void pci_acpi_add_edr_notifier(struct pci_dev *pdev) { }
 static inline void pci_acpi_remove_edr_notifier(struct pci_dev *pdev) { }
-#endif /* CONFIG_PCIE_EDR */
+#endif /* CONFIG_PCIE_DPC */
 
 int pci_acpi_set_companion_lookup_hook(struct acpi_device *(*func)(struct pci_dev *));
 void pci_acpi_clear_companion_lookup_hook(void);
-- 
2.43.0

Re: [PATCH v2 3/6] PCI/EDR: Remove CONFIG_PCIE_EDR

[Yazen Ghannam]

On Tue, Oct 20, 2026 at 11:19:20AM -0700, Kuppuswamy Sathyanarayanan wrote:
> Error Disconnect Recover (EDR) is the ACPI half of the hybrid DPC model,
> where firmware owns DPC and notifies the OS of containment events.
> 
> CONFIG_PCIE_EDR made EDR optional on top of CONFIG_PCIE_DPC.  This adds
> another knob to the decision to request DPC control in _OSC.  The OS
> requests DPC control only if it also supports EDR, so with
> CONFIG_PCIE_EDR=n it never requests DPC control.  There is little reason
> to build DPC without EDR on ACPI systems.
> 
> Remove the option and build edr.c whenever CONFIG_PCIE_DPC and
> CONFIG_ACPI are both enabled.
> 
> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
> ---
>  drivers/acpi/pci_root.c   | 6 +++---
>  drivers/pci/pcie/Kconfig  | 9 ---------
>  drivers/pci/pcie/Makefile | 5 ++++-
>  drivers/pci/pcie/dpc.c    | 5 +++--
>  include/linux/pci-acpi.h  | 4 ++--
>  5 files changed, 12 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index a1a9c06012f8..b0e0b33e3254 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -438,7 +438,7 @@ static u32 calculate_support(void)
>  		support |= OSC_PCI_ASPM_SUPPORT | OSC_PCI_CLOCK_PM_SUPPORT;
>  	if (pci_msi_enabled())
>  		support |= OSC_PCI_MSI_SUPPORT;
> -	if (IS_ENABLED(CONFIG_PCIE_EDR))
> +	if (IS_ENABLED(CONFIG_PCIE_DPC))
>  		support |= OSC_PCI_EDR_SUPPORT;
>  
>  	return support;
> @@ -515,9 +515,9 @@ static u32 calculate_control(void)
>  	 * Per the Downstream Port Containment Related Enhancements ECN to
>  	 * the PCI Firmware Spec, r3.2, sec 4.5.1, table 4-5,
>  	 * OSC_PCI_EXPRESS_DPC_CONTROL indicates the OS supports both DPC
> -	 * and EDR.
> +	 * and EDR.  EDR is always built with DPC on ACPI systems.
>  	 */
> -	if (IS_ENABLED(CONFIG_PCIE_DPC) && IS_ENABLED(CONFIG_PCIE_EDR))
> +	if (IS_ENABLED(CONFIG_PCIE_DPC))
>  		control |= OSC_PCI_EXPRESS_DPC_CONTROL;
>  
>  	return control;
> diff --git a/drivers/pci/pcie/Kconfig b/drivers/pci/pcie/Kconfig
> index 207c2deae35f..de4ea33b4524 100644
> --- a/drivers/pci/pcie/Kconfig
> +++ b/drivers/pci/pcie/Kconfig
> @@ -137,12 +137,3 @@ config PCIE_PTM
>  	  This is only useful if you have devices that support PTM, but it
>  	  is safe to enable even if you don't.
>  
> -config PCIE_EDR
> -	bool "PCI Express Error Disconnect Recover support"
> -	depends on PCIE_DPC && ACPI
> -	help
> -	  This option adds Error Disconnect Recover support as specified
> -	  in the Downstream Port Containment Related Enhancements ECN to
> -	  the PCI Firmware Specification r3.2.  Enable this if you want to
> -	  support hybrid DPC model which uses both firmware and OS to
> -	  implement DPC.

What about keeping 'PCIE_EDR' and using it like 'PCIE_PME'?

IOW, remove the user-visible parts have it default to (PCIE_DPC &&
ACPI)?

I understand EDR as its own feature on top of DPC. So I think there's
value in having the EDR bits clearly distinct from the DPC bits.

Also, it would reduce the changes in this patch.

> diff --git a/drivers/pci/pcie/Makefile b/drivers/pci/pcie/Makefile
> index b0b43a18c304..46b24311f659 100644
> --- a/drivers/pci/pcie/Makefile
> +++ b/drivers/pci/pcie/Makefile
> @@ -13,4 +13,7 @@ obj-$(CONFIG_PCIEAER_INJECT)	+= aer_inject.o
>  obj-$(CONFIG_PCIE_PME)		+= pme.o
>  obj-$(CONFIG_PCIE_DPC)		+= dpc.o
>  obj-$(CONFIG_PCIE_PTM)		+= ptm.o
> -obj-$(CONFIG_PCIE_EDR)		+= edr.o
> +
> +ifdef CONFIG_ACPI
> +obj-$(CONFIG_PCIE_DPC)		+= edr.o
> +endif
> diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
> index 104ff2b91f1f..71adc0e94bca 100644
> --- a/drivers/pci/pcie/dpc.c
> +++ b/drivers/pci/pcie/dpc.c
> @@ -109,10 +109,11 @@ bool pci_dpc_recovered(struct pci_dev *pdev)
>  
>  	/*
>  	 * Synchronization between hotplug and DPC is not supported
> -	 * if DPC is owned by firmware and EDR is not enabled.
> +	 * if DPC is owned by firmware and there is no EDR, i.e., on
> +	 * non-ACPI systems.
>  	 */
>  	host = pci_find_host_bridge(pdev->bus);
> -	if (!host->native_dpc && !IS_ENABLED(CONFIG_PCIE_EDR))
> +	if (!host->native_dpc && !IS_ENABLED(CONFIG_ACPI))
>  		return false;
>  

This seems like dead code, and it was deleted in an older version.

The conditions seem to be mutually exclusive.

Maybe it should just be removed in a pre-patch?

Thanks,
Yazen

Re: [PATCH v2 3/6] PCI/EDR: Remove CONFIG_PCIE_EDR

[Kuppuswamy Sathyanarayanan]

Hi,

On 11/3/2026 12:46 PM, Yazen Ghannam wrote:
> On Tue, Oct 20, 2026 at 11:19:20AM -0700, Kuppuswamy Sathyanarayanan wrote:
>> Error Disconnect Recover (EDR) is the ACPI half of the hybrid DPC model,
>> where firmware owns DPC and notifies the OS of containment events.
>>
>> CONFIG_PCIE_EDR made EDR optional on top of CONFIG_PCIE_DPC.  This adds
>> another knob to the decision to request DPC control in _OSC.  The OS
>> requests DPC control only if it also supports EDR, so with
>> CONFIG_PCIE_EDR=n it never requests DPC control.  There is little reason
>> to build DPC without EDR on ACPI systems.
>>
>> Remove the option and build edr.c whenever CONFIG_PCIE_DPC and
>> CONFIG_ACPI are both enabled.
>>
>> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
>> ---
>>  drivers/acpi/pci_root.c   | 6 +++---
>>  drivers/pci/pcie/Kconfig  | 9 ---------
>>  drivers/pci/pcie/Makefile | 5 ++++-
>>  drivers/pci/pcie/dpc.c    | 5 +++--
>>  include/linux/pci-acpi.h  | 4 ++--
>>  5 files changed, 12 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
>> index a1a9c06012f8..b0e0b33e3254 100644
>> --- a/drivers/acpi/pci_root.c
>> +++ b/drivers/acpi/pci_root.c
>> @@ -438,7 +438,7 @@ static u32 calculate_support(void)
>>  		support |= OSC_PCI_ASPM_SUPPORT | OSC_PCI_CLOCK_PM_SUPPORT;
>>  	if (pci_msi_enabled())
>>  		support |= OSC_PCI_MSI_SUPPORT;
>> -	if (IS_ENABLED(CONFIG_PCIE_EDR))
>> +	if (IS_ENABLED(CONFIG_PCIE_DPC))
>>  		support |= OSC_PCI_EDR_SUPPORT;
>>  
>>  	return support;
>> @@ -515,9 +515,9 @@ static u32 calculate_control(void)
>>  	 * Per the Downstream Port Containment Related Enhancements ECN to
>>  	 * the PCI Firmware Spec, r3.2, sec 4.5.1, table 4-5,
>>  	 * OSC_PCI_EXPRESS_DPC_CONTROL indicates the OS supports both DPC
>> -	 * and EDR.
>> +	 * and EDR.  EDR is always built with DPC on ACPI systems.
>>  	 */
>> -	if (IS_ENABLED(CONFIG_PCIE_DPC) && IS_ENABLED(CONFIG_PCIE_EDR))
>> +	if (IS_ENABLED(CONFIG_PCIE_DPC))
>>  		control |= OSC_PCI_EXPRESS_DPC_CONTROL;
>>  
>>  	return control;
>> diff --git a/drivers/pci/pcie/Kconfig b/drivers/pci/pcie/Kconfig
>> index 207c2deae35f..de4ea33b4524 100644
>> --- a/drivers/pci/pcie/Kconfig
>> +++ b/drivers/pci/pcie/Kconfig
>> @@ -137,12 +137,3 @@ config PCIE_PTM
>>  	  This is only useful if you have devices that support PTM, but it
>>  	  is safe to enable even if you don't.
>>  
>> -config PCIE_EDR
>> -	bool "PCI Express Error Disconnect Recover support"
>> -	depends on PCIE_DPC && ACPI
>> -	help
>> -	  This option adds Error Disconnect Recover support as specified
>> -	  in the Downstream Port Containment Related Enhancements ECN to
>> -	  the PCI Firmware Specification r3.2.  Enable this if you want to
>> -	  support hybrid DPC model which uses both firmware and OS to
>> -	  implement DPC.
> 
> What about keeping 'PCIE_EDR' and using it like 'PCIE_PME'?
> 
> IOW, remove the user-visible parts have it default to (PCIE_DPC &&
> ACPI)?
> 
> I understand EDR as its own feature on top of DPC. So I think there's
> value in having the EDR bits clearly distinct from the DPC bits.
> 
> Also, it would reduce the changes in this patch.

Good idea.  I'll make PCIE_EDR a def_bool that depends on PCIE_DPC &&
ACPI in v3.  That still removes the user-visible knob and keeps the
rest of the code as is.

> 
>> diff --git a/drivers/pci/pcie/Makefile b/drivers/pci/pcie/Makefile
>> index b0b43a18c304..46b24311f659 100644
>> --- a/drivers/pci/pcie/Makefile
>> +++ b/drivers/pci/pcie/Makefile
>> @@ -13,4 +13,7 @@ obj-$(CONFIG_PCIEAER_INJECT)	+= aer_inject.o
>>  obj-$(CONFIG_PCIE_PME)		+= pme.o
>>  obj-$(CONFIG_PCIE_DPC)		+= dpc.o
>>  obj-$(CONFIG_PCIE_PTM)		+= ptm.o
>> -obj-$(CONFIG_PCIE_EDR)		+= edr.o
>> +
>> +ifdef CONFIG_ACPI
>> +obj-$(CONFIG_PCIE_DPC)		+= edr.o
>> +endif
>> diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
>> index 104ff2b91f1f..71adc0e94bca 100644
>> --- a/drivers/pci/pcie/dpc.c
>> +++ b/drivers/pci/pcie/dpc.c
>> @@ -109,10 +109,11 @@ bool pci_dpc_recovered(struct pci_dev *pdev)
>>  
>>  	/*
>>  	 * Synchronization between hotplug and DPC is not supported
>> -	 * if DPC is owned by firmware and EDR is not enabled.
>> +	 * if DPC is owned by firmware and there is no EDR, i.e., on
>> +	 * non-ACPI systems.
>>  	 */
>>  	host = pci_find_host_bridge(pdev->bus);
>> -	if (!host->native_dpc && !IS_ENABLED(CONFIG_PCIE_EDR))
>> +	if (!host->native_dpc && !IS_ENABLED(CONFIG_ACPI))
>>  		return false;
>>  
> 
> This seems like dead code, and it was deleted in an older version.
> 
> The conditions seem to be mutually exclusive.
> 
> Maybe it should just be removed in a pre-patch?

Agreed that it is dead, but only after this patch.  Before it, the
check is still reachable with CONFIG_ACPI=y, CONFIG_PCIE_EDR=n and
firmware-owned DPC.  Once EDR is always built with DPC on ACPI,
native_dpc can only be cleared on ACPI systems, where EDR is present.
So I'll remove the check in this patch.

Thanks for the review.

> 
> Thanks,
> Yazen

-- 
Sathyanarayanan Kuppuswamy
Linux Kernel Developer

[PATCH v2 4/6] PCI/portdrv: Don't require AER to bind DPC service

[Kuppuswamy Sathyanarayanan]

get_port_device_capability() binds the DPC service only if
pci_aer_available() is true.  pci_aer_available() is false with
"pci=noaer" or when MSI is disabled.

The DPC driver does not need either of these.  pci_aer_available()
depends on MSI only because the AER driver does not work with INTx
(commit 3e77a3f7895e ("PCI: Disable AER with pci=nomsi")).  The DPC
driver does not depend on MSI or on the AER driver, and it works on
ports without an AER capability.

PCIe r7.0 sec 6.2.11 recommends that the OS link control of DPC to
control of AER.  PCI Firmware r3.3, sec 4.5.2.4, requires the same for
_OSC.  Both are about ownership, not about using the AER driver.
host->native_aer and the _OSC negotiation already cover ownership.

Drop the pci_aer_available() check.

The changes in behavior are:

  - ACPI systems booted with "pci=noaer" or with MSI disabled, and with
    "pcie_ports=native" or "pcie_ports=dpc-native".  The OS now uses DPC
    there, which is what those options ask for.  Without them nothing
    changes, because the OS does not request AER control in _OSC, so
    host->native_aer is not set.

  - Non-ACPI systems booted with "pci=noaer" or with MSI disabled.
    host->native_aer is set there, so the OS now uses DPC.  An
    uncorrectable error that used to be ignored with "pci=noaer" now
    triggers DPC, which takes the link down and resets the devices below
    the port.

Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
---
 drivers/pci/pcie/portdrv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/pci/pcie/portdrv.c b/drivers/pci/pcie/portdrv.c
index 32fc623dd410..b77680fd3b75 100644
--- a/drivers/pci/pcie/portdrv.c
+++ b/drivers/pci/pcie/portdrv.c
@@ -263,7 +263,6 @@ static int get_port_device_capability(struct pci_dev *dev)
 	 * permission to use AER.
 	 */
 	if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) &&
-	    pci_aer_available() &&
 	    (pcie_ports_dpc_native || host->native_aer))
 		services |= PCIE_PORT_SERVICE_DPC;
 
-- 
2.43.0

Re: [PATCH v2 4/6] PCI/portdrv: Don't require AER to bind DPC service

[Yazen Ghannam]

On Tue, Oct 20, 2026 at 11:19:21AM -0700, Kuppuswamy Sathyanarayanan wrote:
> get_port_device_capability() binds the DPC service only if
> pci_aer_available() is true.  pci_aer_available() is false with
> "pci=noaer" or when MSI is disabled.
> 
> The DPC driver does not need either of these.  pci_aer_available()
> depends on MSI only because the AER driver does not work with INTx
> (commit 3e77a3f7895e ("PCI: Disable AER with pci=nomsi")).  The DPC
> driver does not depend on MSI or on the AER driver, and it works on
> ports without an AER capability.
> 
> PCIe r7.0 sec 6.2.11 recommends that the OS link control of DPC to
> control of AER.  PCI Firmware r3.3, sec 4.5.2.4, requires the same for
> _OSC.  Both are about ownership, not about using the AER driver.
> host->native_aer and the _OSC negotiation already cover ownership.
> 
> Drop the pci_aer_available() check.
> 
> The changes in behavior are:
> 
>   - ACPI systems booted with "pci=noaer" or with MSI disabled, and with
>     "pcie_ports=native" or "pcie_ports=dpc-native".  The OS now uses DPC
>     there, which is what those options ask for.  Without them nothing
>     changes, because the OS does not request AER control in _OSC, so
>     host->native_aer is not set.
> 
>   - Non-ACPI systems booted with "pci=noaer" or with MSI disabled.
>     host->native_aer is set there, so the OS now uses DPC.  An
>     uncorrectable error that used to be ignored with "pci=noaer" now
>     triggers DPC, which takes the link down and resets the devices below
>     the port.
> 
> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
> ---
>  drivers/pci/pcie/portdrv.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/pci/pcie/portdrv.c b/drivers/pci/pcie/portdrv.c
> index 32fc623dd410..b77680fd3b75 100644
> --- a/drivers/pci/pcie/portdrv.c
> +++ b/drivers/pci/pcie/portdrv.c
> @@ -263,7 +263,6 @@ static int get_port_device_capability(struct pci_dev *dev)
>  	 * permission to use AER.
>  	 */
>  	if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) &&
> -	    pci_aer_available() &&
>  	    (pcie_ports_dpc_native || host->native_aer))
>  		services |= PCIE_PORT_SERVICE_DPC;
>  
> -- 

Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com>

Thanks,
Yazen

[PATCH v2 5/6] PCI/ACPI: Request DPC control only together with AER control

[Kuppuswamy Sathyanarayanan]

PCI Firmware r3.3, sec 4.5.2.4, requires the OS to request AER control
when it requests DPC control.  calculate_control() requests DPC control
whenever CONFIG_PCIE_DPC is enabled, even if it does not request AER
control, e.g., with "pci=noaer" or when MSI is disabled.

Request DPC control only if AER control is also requested.

Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
---
 drivers/acpi/pci_root.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index b0e0b33e3254..5c674d5b6bb8 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -516,8 +516,12 @@ static u32 calculate_control(void)
 	 * the PCI Firmware Spec, r3.2, sec 4.5.1, table 4-5,
 	 * OSC_PCI_EXPRESS_DPC_CONTROL indicates the OS supports both DPC
 	 * and EDR.  EDR is always built with DPC on ACPI systems.
+	 *
+	 * PCI Firmware r3.3, sec 4.5.2.4, requires the OS to request AER
+	 * control while requesting DPC control.
 	 */
-	if (IS_ENABLED(CONFIG_PCIE_DPC))
+	if (IS_ENABLED(CONFIG_PCIE_DPC) &&
+	    (control & OSC_PCI_EXPRESS_AER_CONTROL))
 		control |= OSC_PCI_EXPRESS_DPC_CONTROL;
 
 	return control;
-- 
2.43.0

Re: [PATCH v2 5/6] PCI/ACPI: Request DPC control only together with AER control

[Yazen Ghannam]

On Tue, Oct 20, 2026 at 11:19:22AM -0700, Kuppuswamy Sathyanarayanan wrote:
> PCI Firmware r3.3, sec 4.5.2.4, requires the OS to request AER control
> when it requests DPC control.  calculate_control() requests DPC control
> whenever CONFIG_PCIE_DPC is enabled, even if it does not request AER
> control, e.g., with "pci=noaer" or when MSI is disabled.
> 
> Request DPC control only if AER control is also requested.
> 
> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
> Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
> ---
>  drivers/acpi/pci_root.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index b0e0b33e3254..5c674d5b6bb8 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -516,8 +516,12 @@ static u32 calculate_control(void)
>  	 * the PCI Firmware Spec, r3.2, sec 4.5.1, table 4-5,
>  	 * OSC_PCI_EXPRESS_DPC_CONTROL indicates the OS supports both DPC
>  	 * and EDR.  EDR is always built with DPC on ACPI systems.
> +	 *
> +	 * PCI Firmware r3.3, sec 4.5.2.4, requires the OS to request AER
> +	 * control while requesting DPC control.

What about folding this last line into the rest of the comment above?

Or maybe just drop the spec details and leave that for the commit
message?

>  	 */
> -	if (IS_ENABLED(CONFIG_PCIE_DPC))
> +	if (IS_ENABLED(CONFIG_PCIE_DPC) &&
> +	    (control & OSC_PCI_EXPRESS_AER_CONTROL))
>  		control |= OSC_PCI_EXPRESS_DPC_CONTROL;
>  
>  	return control;
> -- 

Otherwise, looks good to me.

Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com>

Thanks,
Yazen

Re: [PATCH v2 5/6] PCI/ACPI: Request DPC control only together with AER control

[Kuppuswamy Sathyanarayanan]

Hi,

On 11/4/2026 8:13 AM, Yazen Ghannam wrote:
> On Tue, Oct 20, 2026 at 11:19:22AM -0700, Kuppuswamy Sathyanarayanan wrote:
>> PCI Firmware r3.3, sec 4.5.2.4, requires the OS to request AER control
>> when it requests DPC control.  calculate_control() requests DPC control
>> whenever CONFIG_PCIE_DPC is enabled, even if it does not request AER
>> control, e.g., with "pci=noaer" or when MSI is disabled.
>>
>> Request DPC control only if AER control is also requested.
>>
>> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
>> Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
>> ---
>>  drivers/acpi/pci_root.c | 6 +++++-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
>> index b0e0b33e3254..5c674d5b6bb8 100644
>> --- a/drivers/acpi/pci_root.c
>> +++ b/drivers/acpi/pci_root.c
>> @@ -516,8 +516,12 @@ static u32 calculate_control(void)
>>  	 * the PCI Firmware Spec, r3.2, sec 4.5.1, table 4-5,
>>  	 * OSC_PCI_EXPRESS_DPC_CONTROL indicates the OS supports both DPC
>>  	 * and EDR.  EDR is always built with DPC on ACPI systems.
>> +	 *
>> +	 * PCI Firmware r3.3, sec 4.5.2.4, requires the OS to request AER
>> +	 * control while requesting DPC control.
> 
> What about folding this last line into the rest of the comment above?
> 
> Or maybe just drop the spec details and leave that for the commit
> message?

I'll fold it into the comment above in v3.

> 
>>  	 */
>> -	if (IS_ENABLED(CONFIG_PCIE_DPC))
>> +	if (IS_ENABLED(CONFIG_PCIE_DPC) &&
>> +	    (control & OSC_PCI_EXPRESS_AER_CONTROL))
>>  		control |= OSC_PCI_EXPRESS_DPC_CONTROL;
>>  
>>  	return control;
>> -- 
> 
> Otherwise, looks good to me.
> 
> Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com>

Thanks.

> 
> Thanks,
> Yazen

-- 
Sathyanarayanan Kuppuswamy
Linux Kernel Developer

[PATCH v2 6/6] PCI/portdrv: Bind DPC service based on host_bridge->native_dpc

[Kuppuswamy Sathyanarayanan]

get_port_device_capability() binds the DPC service if the port has a DPC
capability and either "pcie_ports=dpc-native" was given or the OS
controls AER.  This repeats decisions that are already made elsewhere.
It also ignores host_bridge->native_dpc, which is meant to say whether
the OS owns DPC.

Make host_bridge->native_dpc the single decider:

  - In acpi_pci_root_create(), assume DPC control whenever _OSC grants
    AER control.  PCI Firmware r3.3, sec 4.5.2.4, requires platforms to
    retain AER if they retain DPC.  Put the other way, firmware that
    grants AER does not keep DPC.  PCIe r7.0 sec 6.2.11 recommends that
    the OS link control of DPC to control of AER.  Commit 97ca178c899d
    ("PCI/DPC: Allow DPC on all Downstream Ports when OS controls AER")
    relied on this link.  Keeping it means DPC still works with firmware
    that predates the _OSC DPC control bit.  Such firmware grants AER but
    masks DPC.  The OS cannot tell such firmware from firmware that
    retains DPC on purpose, so log a message when it assumes DPC control
    that _OSC did not grant.  Only do this if the OS requested DPC
    control, i.e., if CONFIG_PCIE_DPC is enabled.

  - "pcie_ports=native" and "pcie_ports=dpc-native" are already folded
    into the _OSC control mask, so they are reflected in native_dpc.

Then bind the DPC service if the port has a DPC capability and
host_bridge->native_dpc is set.

The only change in behavior is for firmware that grants DPC control but
retains AER control.  PCI Firmware r3.3, sec 4.5.2.4, does not forbid
this.  The OS now uses DPC there because firmware granted it.  Since
"PCI/DPC: Reinstate support for AER-incapable ports", dpc_probe() no
longer requires AER control.

Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
---
 drivers/acpi/pci_root.c    | 16 ++++++++++++++++
 drivers/pci/pcie/portdrv.c |  6 +-----
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index 5c674d5b6bb8..b380b6d8874d 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -1056,6 +1056,22 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
 	ctrl = root->osc_control_set;
 	ext_ctrl = root->osc_ext_control_set;
 
+	/*
+	 * PCI Firmware r3.3, sec 4.5.2.4, requires platforms to retain AER
+	 * if they retain DPC.  Put the other way, firmware that grants AER
+	 * does not keep DPC.  PCIe r7.0 sec 6.2.11 recommends that the OS
+	 * link control of DPC to control of AER.  Firmware that predates
+	 * the _OSC DPC control bit grants AER without DPC, so assume control
+	 * of DPC whenever we control AER.
+	 */
+	if (IS_ENABLED(CONFIG_PCIE_DPC) &&
+	    (ctrl & OSC_PCI_EXPRESS_AER_CONTROL) &&
+	    !(ctrl & OSC_PCI_EXPRESS_DPC_CONTROL)) {
+		decode_osc_control(root, "OS assuming control (AER granted) of",
+				   OSC_PCI_EXPRESS_DPC_CONTROL);
+		ctrl |= OSC_PCI_EXPRESS_DPC_CONTROL;
+	}
+
 	/*
 	 * If the user specified "pcie_ports=native", use the PCIe port
 	 * services regardless of what _OSC says, i.e., proceed as though the
diff --git a/drivers/pci/pcie/portdrv.c b/drivers/pci/pcie/portdrv.c
index b77680fd3b75..f1beb440a3dc 100644
--- a/drivers/pci/pcie/portdrv.c
+++ b/drivers/pci/pcie/portdrv.c
@@ -258,12 +258,8 @@ static int get_port_device_capability(struct pci_dev *dev)
 		pcie_pme_interrupt_enable(dev, false);
 	}
 
-	/*
-	 * With dpc-native, allow Linux to use DPC even if it doesn't have
-	 * permission to use AER.
-	 */
 	if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) &&
-	    (pcie_ports_dpc_native || host->native_aer))
+	    host->native_dpc)
 		services |= PCIE_PORT_SERVICE_DPC;
 
 	/* Enable bandwidth control if more than one speed is supported. */
-- 
2.43.0

Re: [PATCH v2 6/6] PCI/portdrv: Bind DPC service based on host_bridge->native_dpc

[Yazen Ghannam]

On Tue, Oct 20, 2026 at 11:19:23AM -0700, Kuppuswamy Sathyanarayanan wrote:
> get_port_device_capability() binds the DPC service if the port has a DPC
> capability and either "pcie_ports=dpc-native" was given or the OS
> controls AER.  This repeats decisions that are already made elsewhere.
> It also ignores host_bridge->native_dpc, which is meant to say whether
> the OS owns DPC.
> 
> Make host_bridge->native_dpc the single decider:
> 
>   - In acpi_pci_root_create(), assume DPC control whenever _OSC grants
>     AER control.  PCI Firmware r3.3, sec 4.5.2.4, requires platforms to
>     retain AER if they retain DPC.  Put the other way, firmware that
>     grants AER does not keep DPC.  PCIe r7.0 sec 6.2.11 recommends that
>     the OS link control of DPC to control of AER.  Commit 97ca178c899d
>     ("PCI/DPC: Allow DPC on all Downstream Ports when OS controls AER")
>     relied on this link.  Keeping it means DPC still works with firmware
>     that predates the _OSC DPC control bit.  Such firmware grants AER but
>     masks DPC.  The OS cannot tell such firmware from firmware that
>     retains DPC on purpose, so log a message when it assumes DPC control
>     that _OSC did not grant.  Only do this if the OS requested DPC
>     control, i.e., if CONFIG_PCIE_DPC is enabled.
> 
>   - "pcie_ports=native" and "pcie_ports=dpc-native" are already folded
>     into the _OSC control mask, so they are reflected in native_dpc.
> 
> Then bind the DPC service if the port has a DPC capability and
> host_bridge->native_dpc is set.
> 
> The only change in behavior is for firmware that grants DPC control but
> retains AER control.  PCI Firmware r3.3, sec 4.5.2.4, does not forbid
> this.  The OS now uses DPC there because firmware granted it.  Since
> "PCI/DPC: Reinstate support for AER-incapable ports", dpc_probe() no
> longer requires AER control.
> 
> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
> ---
>  drivers/acpi/pci_root.c    | 16 ++++++++++++++++
>  drivers/pci/pcie/portdrv.c |  6 +-----
>  2 files changed, 17 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index 5c674d5b6bb8..b380b6d8874d 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -1056,6 +1056,22 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
>  	ctrl = root->osc_control_set;
>  	ext_ctrl = root->osc_ext_control_set;
>  
> +	/*
> +	 * PCI Firmware r3.3, sec 4.5.2.4, requires platforms to retain AER
> +	 * if they retain DPC.  Put the other way, firmware that grants AER
> +	 * does not keep DPC.  PCIe r7.0 sec 6.2.11 recommends that the OS
> +	 * link control of DPC to control of AER.  Firmware that predates
> +	 * the _OSC DPC control bit grants AER without DPC, so assume control
> +	 * of DPC whenever we control AER.
> +	 */

Oh, I see now that this got rewritten.

But it really does repeat the same info from the commit message. So IMO
it can just be removed or summarized further.

> +	if (IS_ENABLED(CONFIG_PCIE_DPC) &&
> +	    (ctrl & OSC_PCI_EXPRESS_AER_CONTROL) &&
> +	    !(ctrl & OSC_PCI_EXPRESS_DPC_CONTROL)) {
> +		decode_osc_control(root, "OS assuming control (AER granted) of",
> +				   OSC_PCI_EXPRESS_DPC_CONTROL);
> +		ctrl |= OSC_PCI_EXPRESS_DPC_CONTROL;
> +	}
> +
>  	/*
>  	 * If the user specified "pcie_ports=native", use the PCIe port
>  	 * services regardless of what _OSC says, i.e., proceed as though the
> diff --git a/drivers/pci/pcie/portdrv.c b/drivers/pci/pcie/portdrv.c
> index b77680fd3b75..f1beb440a3dc 100644
> --- a/drivers/pci/pcie/portdrv.c
> +++ b/drivers/pci/pcie/portdrv.c
> @@ -258,12 +258,8 @@ static int get_port_device_capability(struct pci_dev *dev)
>  		pcie_pme_interrupt_enable(dev, false);
>  	}
>  
> -	/*
> -	 * With dpc-native, allow Linux to use DPC even if it doesn't have
> -	 * permission to use AER.
> -	 */
>  	if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) &&
> -	    (pcie_ports_dpc_native || host->native_aer))
> +	    host->native_dpc)
>  		services |= PCIE_PORT_SERVICE_DPC;
>  
>  	/* Enable bandwidth control if more than one speed is supported. */
> -- 

Besides my comment on the comment, looks good to me.

Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com>

Thanks,
Yazen

Re: [PATCH v2 6/6] PCI/portdrv: Bind DPC service based on host_bridge->native_dpc

[Kuppuswamy Sathyanarayanan]

On 11/4/2026 8:35 AM, Yazen Ghannam wrote:
> On Tue, Oct 20, 2026 at 11:19:23AM -0700, Kuppuswamy Sathyanarayanan wrote:
>> get_port_device_capability() binds the DPC service if the port has a DPC
>> capability and either "pcie_ports=dpc-native" was given or the OS
>> controls AER.  This repeats decisions that are already made elsewhere.
>> It also ignores host_bridge->native_dpc, which is meant to say whether
>> the OS owns DPC.
>>
>> Make host_bridge->native_dpc the single decider:
>>
>>   - In acpi_pci_root_create(), assume DPC control whenever _OSC grants
>>     AER control.  PCI Firmware r3.3, sec 4.5.2.4, requires platforms to
>>     retain AER if they retain DPC.  Put the other way, firmware that
>>     grants AER does not keep DPC.  PCIe r7.0 sec 6.2.11 recommends that
>>     the OS link control of DPC to control of AER.  Commit 97ca178c899d
>>     ("PCI/DPC: Allow DPC on all Downstream Ports when OS controls AER")
>>     relied on this link.  Keeping it means DPC still works with firmware
>>     that predates the _OSC DPC control bit.  Such firmware grants AER but
>>     masks DPC.  The OS cannot tell such firmware from firmware that
>>     retains DPC on purpose, so log a message when it assumes DPC control
>>     that _OSC did not grant.  Only do this if the OS requested DPC
>>     control, i.e., if CONFIG_PCIE_DPC is enabled.
>>
>>   - "pcie_ports=native" and "pcie_ports=dpc-native" are already folded
>>     into the _OSC control mask, so they are reflected in native_dpc.
>>
>> Then bind the DPC service if the port has a DPC capability and
>> host_bridge->native_dpc is set.
>>
>> The only change in behavior is for firmware that grants DPC control but
>> retains AER control.  PCI Firmware r3.3, sec 4.5.2.4, does not forbid
>> this.  The OS now uses DPC there because firmware granted it.  Since
>> "PCI/DPC: Reinstate support for AER-incapable ports", dpc_probe() no
>> longer requires AER control.
>>
>> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
>> ---
>>  drivers/acpi/pci_root.c    | 16 ++++++++++++++++
>>  drivers/pci/pcie/portdrv.c |  6 +-----
>>  2 files changed, 17 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
>> index 5c674d5b6bb8..b380b6d8874d 100644
>> --- a/drivers/acpi/pci_root.c
>> +++ b/drivers/acpi/pci_root.c
>> @@ -1056,6 +1056,22 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
>>  	ctrl = root->osc_control_set;
>>  	ext_ctrl = root->osc_ext_control_set;
>>  
>> +	/*
>> +	 * PCI Firmware r3.3, sec 4.5.2.4, requires platforms to retain AER
>> +	 * if they retain DPC.  Put the other way, firmware that grants AER
>> +	 * does not keep DPC.  PCIe r7.0 sec 6.2.11 recommends that the OS
>> +	 * link control of DPC to control of AER.  Firmware that predates
>> +	 * the _OSC DPC control bit grants AER without DPC, so assume control
>> +	 * of DPC whenever we control AER.
>> +	 */
> 
> Oh, I see now that this got rewritten.
> 
> But it really does repeat the same info from the commit message. So IMO
> it can just be removed or summarized further.

Agreed.  I'll shorten it in v3 to something like:

	/*
	 * Firmware that predates the _OSC DPC control bit grants AER but
	 * masks DPC.  Link DPC control to AER control, as PCIe r7.0 sec
	 * 6.2.11 recommends.
	 */

> 
>> +	if (IS_ENABLED(CONFIG_PCIE_DPC) &&
>> +	    (ctrl & OSC_PCI_EXPRESS_AER_CONTROL) &&
>> +	    !(ctrl & OSC_PCI_EXPRESS_DPC_CONTROL)) {
>> +		decode_osc_control(root, "OS assuming control (AER granted) of",
>> +				   OSC_PCI_EXPRESS_DPC_CONTROL);
>> +		ctrl |= OSC_PCI_EXPRESS_DPC_CONTROL;
>> +	}
>> +
>>  	/*
>>  	 * If the user specified "pcie_ports=native", use the PCIe port
>>  	 * services regardless of what _OSC says, i.e., proceed as though the
>> diff --git a/drivers/pci/pcie/portdrv.c b/drivers/pci/pcie/portdrv.c
>> index b77680fd3b75..f1beb440a3dc 100644
>> --- a/drivers/pci/pcie/portdrv.c
>> +++ b/drivers/pci/pcie/portdrv.c
>> @@ -258,12 +258,8 @@ static int get_port_device_capability(struct pci_dev *dev)
>>  		pcie_pme_interrupt_enable(dev, false);
>>  	}
>>  
>> -	/*
>> -	 * With dpc-native, allow Linux to use DPC even if it doesn't have
>> -	 * permission to use AER.
>> -	 */
>>  	if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) &&
>> -	    (pcie_ports_dpc_native || host->native_aer))
>> +	    host->native_dpc)
>>  		services |= PCIE_PORT_SERVICE_DPC;
>>  
>>  	/* Enable bandwidth control if more than one speed is supported. */
>> -- 
> 
> Besides my comment on the comment, looks good to me.
> 
> Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com>
> 

Thanks!


> Thanks,
> Yazen

-- 
Sathyanarayanan Kuppuswamy
Linux Kernel Developer