PCI/DPC: Do not enable DPC if AER control is not allowed by the BIOS
PATCH v2 1/1 PCI/DPC: Do not enable DPC if AER control is not allowed by the BIOS
Commit eed85ff4c0da ("PCI/DPC: Enable DPC only if AER is available") made DPC control dependent whether AER is enabled in the OS. However, it does not take into account situations where BIOS has not given OS control of AER:
acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] acpi PNP0A08:00: _OSC: platform does not support [AER]
acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME PCIeCapability]
I think here it is better not to enable DPC even if the capability is available because then it would be against what "Determination of DPC Control" note in PCIe 4.0 sec 6.1.10 recommends.
---
Changes from v1:
* Rebased on top of pci.git/pci/portdrv
* Dropped the other patch that disables interrupt generation during suspend because there is development on-going to get rid of separate PCIe portdrv and move everything to the PCI core instead.
drivers/pci/pcie/portdrv_acpi.c | 4 ++-- drivers/pci/pcie/portdrv_core.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)
drivers/pci/pcie/portdrv_acpi.c +2 -2
@@ -47,11 +47,11 @@ void pcie_port_acpi_setup(struct pci_dev *port, int *srv_mask) flags = root->osc_control_set; - *srv_mask =PCIE_PORT_SERVICE_DPC ; + *srv_mask =0 ;if (flags &OSC_PCI_EXPRESS_NATIVE_HP_CONTROL ) *srv_mask |=PCIE_PORT_SERVICE_HP ;if (flags &OSC_PCI_EXPRESS_PME_CONTROL ) *srv_mask |=PCIE_PORT_SERVICE_PME ;if (flags &OSC_PCI_EXPRESS_AER_CONTROL ) - *srv_mask |=PCIE_PORT_SERVICE_AER ; + *srv_mask |=PCIE_PORT_SERVICE_AER |PCIE_PORT_SERVICE_DPC ; }
drivers/pci/pcie/portdrv_core.c +1 -1
@@ -236,7 +236,7 @@ static int get_port_device_capability(struct pci_dev *dev) }if (pci_find_ext_capability (dev,PCI_EXT_CAP_ID_DPC ) && -pci_aer_available ()) +pci_aer_available () && services &PCIE_PORT_SERVICE_AER ) services |=PCIE_PORT_SERVICE_DPC ;return services;
Signature · 1 line
2.16.2
Bjorn Helgaas
AppliedQuoted 9 lines · Mika Westerberg
Commit
eed85ff4c0da("PCI/DPC: Enable DPC only if AER is available") made DPC control dependent whether AER is enabled in the OS. However, it does not take into account situations where BIOS has not given OS control of AER:acpi PNP0A08:00:
_OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] acpi PNP0A08:00:_OSC: platform does not support [AER]
acpi PNP0A08:00:_OSC: OS now controls [PCIeHotplug PME PCIeCapability]
Quoted 5 lines
I think here it is better not to enable DPC even if the capability is available because then it would be against what "Determination of DPC Control" note in PCIe 4.0 sec 6.1.10 recommends.
Signed-off-by Mika Westerberg <[email protected]>
Applied to pci/portdrv for v4.17, thanks!
Quoted 50 lines
---
Changes from v1:* Rebased on top of pci.git/pci/portdrv
* Dropped the other patch that disables interrupt generation during suspend because there is development on-going to get rid of separate PCIe portdrv and move everything to the PCI core instead.drivers/pci/pcie/portdrv_acpi.c | 4 ++-- drivers/pci/pcie/portdrv_core.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)drivers/pci/pcie/portdrv_acpi.c +2
-2@@ -47,11 +47,11 @@ void pcie_port_acpi_setup(struct pci_dev *port, int *srv_mask) flags = root->osc_control_set; - *srv_mask =PCIE_PORT_SERVICE_DPC ; + *srv_mask =0 ;if (flags &OSC_PCI_EXPRESS_NATIVE_HP_CONTROL ) *srv_mask |=PCIE_PORT_SERVICE_HP ;if (flags &OSC_PCI_EXPRESS_PME_CONTROL ) *srv_mask |=PCIE_PORT_SERVICE_PME ;if (flags &OSC_PCI_EXPRESS_AER_CONTROL ) - *srv_mask |=PCIE_PORT_SERVICE_AER ; + *srv_mask |=PCIE_PORT_SERVICE_AER |PCIE_PORT_SERVICE_DPC ; }drivers/pci/pcie/portdrv_core.c +1
-1@@ -236,7 +236,7 @@ static int get_port_device_capability(struct pci_dev *dev) }if (pci_find_ext_capability (dev,PCI_EXT_CAP_ID_DPC ) && -pci_aer_available ()) +pci_aer_available () && services &PCIE_PORT_SERVICE_AER ) services |=PCIE_PORT_SERVICE_DPC ;return services;Signature · 6 lines
2.16.2 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html