| Message ID | 1587067157-2291-1-git-send-email-jonathan.derrick@intel.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | PCI/DPC: Allow Non-ACPI Native ports to use DPC | expand |
| Context | Check | Description |
|---|---|---|
| snowpatch_ozlabs/apply_patch | success | Successfully applied on branch powerpc/merge (a9aa21d05c33c556e48c5062b6632a9b94906570) |
| snowpatch_ozlabs/build-ppc64le | success | Build succeeded |
| snowpatch_ozlabs/build-ppc64be | success | Build succeeded |
| snowpatch_ozlabs/build-ppc64e | success | Build succeeded |
| snowpatch_ozlabs/build-pmac32 | warning | Upstream build failed, couldn't test patch |
| snowpatch_ozlabs/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 13 lines checked |
| snowpatch_ozlabs/needsstable | success | Patch has no Fixes tags |
Hi, On 4/16/20 12:59 PM, Jon Derrick wrote: > Some platforms have a mix of ports whose capabilities can be negotiated > by _OSC, and some ports which are not described by ACPI and instead > managed by Native drivers. The existing Firmware-First HEST model can > incorrectly tag these Native, Non-ACPI ports as Firmware-First capable > ports by advertising the HEST Global flag and specifying the type and > class (aer_hest_parse). > > This ultimately can lead to bad situations if the BIOS or port firmware > leaves DPC preconfigured and the Linux DPC driver is unable to bind to > the port to handle DPC events. > > This patch adds the check for Native DPC in the port's host bridge in > order to allow DPC services to bind to the port. > > Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> > --- > drivers/pci/pcie/dpc.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c > index 7621704..a1e355d 100644 > --- a/drivers/pci/pcie/dpc.c > +++ b/drivers/pci/pcie/dpc.c > @@ -281,10 +281,12 @@ static int dpc_probe(struct pcie_device *dev) > { > struct pci_dev *pdev = dev->port; > struct device *device = &dev->device; > + struct pci_host_bridge *host = pci_find_host_bridge(pdev->bus); > int status; > u16 ctl, cap; > > - if (pcie_aer_get_firmware_first(pdev) && !pcie_ports_dpc_native) > + if (pcie_aer_get_firmware_first(pdev) && !pcie_ports_dpc_native && For other PCIe services, this check is added in get_port_device_capability(). Why not add it there for DPC as well ? > + !host->native_dpc) > return -ENOTSUPP; > > status = devm_request_threaded_irq(device, dev->irq, dpc_irq, >
On Thu, 2020-04-16 at 13:32 -0700, Kuppuswamy, Sathyanarayanan wrote: > Hi, > > On 4/16/20 12:59 PM, Jon Derrick wrote: > > Some platforms have a mix of ports whose capabilities can be negotiated > > by _OSC, and some ports which are not described by ACPI and instead > > managed by Native drivers. The existing Firmware-First HEST model can > > incorrectly tag these Native, Non-ACPI ports as Firmware-First capable > > ports by advertising the HEST Global flag and specifying the type and > > class (aer_hest_parse). > > > > This ultimately can lead to bad situations if the BIOS or port firmware > > leaves DPC preconfigured and the Linux DPC driver is unable to bind to > > the port to handle DPC events. > > > > This patch adds the check for Native DPC in the port's host bridge in > > order to allow DPC services to bind to the port. > > > > Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> > > --- > > drivers/pci/pcie/dpc.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c > > index 7621704..a1e355d 100644 > > --- a/drivers/pci/pcie/dpc.c > > +++ b/drivers/pci/pcie/dpc.c > > @@ -281,10 +281,12 @@ static int dpc_probe(struct pcie_device *dev) > > { > > struct pci_dev *pdev = dev->port; > > struct device *device = &dev->device; > > + struct pci_host_bridge *host = pci_find_host_bridge(pdev->bus); > > int status; > > u16 ctl, cap; > > > > - if (pcie_aer_get_firmware_first(pdev) && !pcie_ports_dpc_native) > > + if (pcie_aer_get_firmware_first(pdev) && !pcie_ports_dpc_native && > For other PCIe services, this check is added in > get_port_device_capability(). > Why not add it there for DPC as well ? Sure. Looking at this, it seems like it needs some more de-tangling to fit into my model. > > + !host->native_dpc) > > return -ENOTSUPP; > > > > status = devm_request_threaded_irq(device, dev->irq, dpc_irq, > >
diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c index 7621704..a1e355d 100644 --- a/drivers/pci/pcie/dpc.c +++ b/drivers/pci/pcie/dpc.c @@ -281,10 +281,12 @@ static int dpc_probe(struct pcie_device *dev) { struct pci_dev *pdev = dev->port; struct device *device = &dev->device; + struct pci_host_bridge *host = pci_find_host_bridge(pdev->bus); int status; u16 ctl, cap; - if (pcie_aer_get_firmware_first(pdev) && !pcie_ports_dpc_native) + if (pcie_aer_get_firmware_first(pdev) && !pcie_ports_dpc_native && + !host->native_dpc) return -ENOTSUPP; status = devm_request_threaded_irq(device, dev->irq, dpc_irq,
Some platforms have a mix of ports whose capabilities can be negotiated by _OSC, and some ports which are not described by ACPI and instead managed by Native drivers. The existing Firmware-First HEST model can incorrectly tag these Native, Non-ACPI ports as Firmware-First capable ports by advertising the HEST Global flag and specifying the type and class (aer_hest_parse). This ultimately can lead to bad situations if the BIOS or port firmware leaves DPC preconfigured and the Linux DPC driver is unable to bind to the port to handle DPC events. This patch adds the check for Native DPC in the port's host bridge in order to allow DPC services to bind to the port. Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> --- drivers/pci/pcie/dpc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)