The two patches here force AER and DPC to honor the Host Bridge's Native
AER/DPC settings. This is under the assumption that when these bits are set,
that Firmware-First AER/DPC should not be in use for these ports. This
assumption seems to be true in ACPI, which explicitly clears these capability
settings in the host bridge if the service cannot be negotiated with _OSC.
This also fixes an issue I've seen in a few platforms whose BIOS and/or switch
firmware leaves DPC preconfigured. In these cases, the kernel DPC driver cannot
bind a handler to the interrupt and could result in unmanaged DPC link down
events.
Jon Derrick (2):
PCI/AER: Allow Native AER Host Bridges to use AER
PCI/DPC: Allow Native DPC Host Bridges to use DPC
drivers/pci/pcie/aer.c | 3 +++
drivers/pci/pcie/dpc.c | 3 ++-
drivers/pci/pcie/portdrv_core.c | 3 ++-
3 files changed, 7 insertions(+), 2 deletions(-)
--
1.8.3.1
The existing portdrv model prevents DPC services without either OS
control (_OSC) granted to AER services, a Host Bridge requesting Native
AER, or using one of the 'pcie_ports=' parameters of 'native' or
'dpc-native'.
The DPC port service driver itself will also fail to probe if the kernel
assumes the port is using Firmware-First AER. It's a reasonable
expectation that a port using Firmware-First AER will also be using
Firmware-First DPC, however if a Host Bridge requests Native DPC, the
DPC driver should allow it and not fail to bind due to AER capability
settings.
Host Bridges which request Native DPC port services will also likely
request Native AER, however it shouldn't be a requirement. This patch
allows ports on those Host Bridges to have DPC port services.
This will avoid the unlikely situation where the port is Firmware-First
AER and Native DPC, and a BIOS or switch firmware preconfiguration of
the DPC trigger could result in unhandled DPC events.
Signed-off-by: Jon Derrick <[email protected]>
---
drivers/pci/pcie/dpc.c | 3 ++-
drivers/pci/pcie/portdrv_core.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
index 7621704..3f3106f 100644
--- a/drivers/pci/pcie/dpc.c
+++ b/drivers/pci/pcie/dpc.c
@@ -284,7 +284,8 @@ static int dpc_probe(struct pcie_device *dev)
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 &&
+ !pci_find_host_bridge(pdev->bus)->native_dpc)
return -ENOTSUPP;
status = devm_request_threaded_irq(device, dev->irq, dpc_irq,
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index 50a9522..f2139a1 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -256,7 +256,8 @@ static int get_port_device_capability(struct pci_dev *dev)
*/
if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) &&
pci_aer_available() &&
- (pcie_ports_dpc_native || (services & PCIE_PORT_SERVICE_AER)))
+ (pcie_ports_dpc_native || host->native_dpc ||
+ (services & PCIE_PORT_SERVICE_AER)))
services |= PCIE_PORT_SERVICE_DPC;
if (pci_pcie_type(dev) == PCI_EXP_TYPE_DOWNSTREAM ||
--
1.8.3.1
On 4/20/20 2:37 PM, Jon Derrick wrote:
> The existing portdrv model prevents DPC services without either OS
> control (_OSC) granted to AER services, a Host Bridge requesting Native
> AER, or using one of the 'pcie_ports=' parameters of 'native' or
> 'dpc-native'.
>
> The DPC port service driver itself will also fail to probe if the kernel
> assumes the port is using Firmware-First AER. It's a reasonable
> expectation that a port using Firmware-First AER will also be using
> Firmware-First DPC, however if a Host Bridge requests Native DPC, the
> DPC driver should allow it and not fail to bind due to AER capability
> settings.
>
> Host Bridges which request Native DPC port services will also likely
> request Native AER, however it shouldn't be a requirement. This patch
> allows ports on those Host Bridges to have DPC port services.
>
> This will avoid the unlikely situation where the port is Firmware-First
> AER and Native DPC, and a BIOS or switch firmware preconfiguration of
> the DPC trigger could result in unhandled DPC events.
>
> Signed-off-by: Jon Derrick <[email protected]>
> ---
> drivers/pci/pcie/dpc.c | 3 ++-
> drivers/pci/pcie/portdrv_core.c | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
> index 7621704..3f3106f 100644
> --- a/drivers/pci/pcie/dpc.c
> +++ b/drivers/pci/pcie/dpc.c
> @@ -284,7 +284,8 @@ static int dpc_probe(struct pcie_device *dev)
> 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 &&
> + !pci_find_host_bridge(pdev->bus)->native_dpc)
Why do it in probe as well ? if host->native_dpc is not set then the
device DPC probe it self won't happen right ?
> return -ENOTSUPP;
>
> status = devm_request_threaded_irq(device, dev->irq, dpc_irq,
> diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
> index 50a9522..f2139a1 100644
> --- a/drivers/pci/pcie/portdrv_core.c
> +++ b/drivers/pci/pcie/portdrv_core.c
> @@ -256,7 +256,8 @@ static int get_port_device_capability(struct pci_dev *dev)
> */
> if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) &&
> pci_aer_available() &&
> - (pcie_ports_dpc_native || (services & PCIE_PORT_SERVICE_AER)))
> + (pcie_ports_dpc_native || host->native_dpc ||
> + (services & PCIE_PORT_SERVICE_AER)))
> services |= PCIE_PORT_SERVICE_DPC;
>
> if (pci_pcie_type(dev) == PCI_EXP_TYPE_DOWNSTREAM ||
>
Hi Sathyanarayanan,
On Wed, 2020-04-22 at 15:50 -0700, Kuppuswamy, Sathyanarayanan wrote:
>
> On 4/20/20 2:37 PM, Jon Derrick wrote:
> > The existing portdrv model prevents DPC services without either OS
> > control (_OSC) granted to AER services, a Host Bridge requesting Native
> > AER, or using one of the 'pcie_ports=' parameters of 'native' or
> > 'dpc-native'.
> >
> > The DPC port service driver itself will also fail to probe if the kernel
> > assumes the port is using Firmware-First AER. It's a reasonable
> > expectation that a port using Firmware-First AER will also be using
> > Firmware-First DPC, however if a Host Bridge requests Native DPC, the
> > DPC driver should allow it and not fail to bind due to AER capability
> > settings.
> >
> > Host Bridges which request Native DPC port services will also likely
> > request Native AER, however it shouldn't be a requirement. This patch
> > allows ports on those Host Bridges to have DPC port services.
> >
> > This will avoid the unlikely situation where the port is Firmware-First
> > AER and Native DPC, and a BIOS or switch firmware preconfiguration of
> > the DPC trigger could result in unhandled DPC events.
> >
> > Signed-off-by: Jon Derrick <[email protected]>
> > ---
> > drivers/pci/pcie/dpc.c | 3 ++-
> > drivers/pci/pcie/portdrv_core.c | 3 ++-
> > 2 files changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
> > index 7621704..3f3106f 100644
> > --- a/drivers/pci/pcie/dpc.c
> > +++ b/drivers/pci/pcie/dpc.c
> > @@ -284,7 +284,8 @@ static int dpc_probe(struct pcie_device *dev)
> > 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 &&
> > + !pci_find_host_bridge(pdev->bus)->native_dpc)
> Why do it in probe as well ? if host->native_dpc is not set then the
> device DPC probe it self won't happen right ?
Portdrv only enables the interrupt and allows the probe to occur.
The probe itself will still fail if there's a mixed-mode _OSC
negotiated AER & DPC, due to pcie_aer_get_firmware_first returning 1
for AER and no check for DPC.
I don't know if such a platform will exist, but the kernel is already
wired for 'dpc-native' so it makes sense to extend it for this..
This transform might be more readable:
if (pcie_aer_get_firmware_first(pdev) &&
!(pcie_ports_dpc_native || hb->native_dpc))
> > return -ENOTSUPP;
> >
> > status = devm_request_threaded_irq(device, dev->irq, dpc_irq,
> > diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
> > index 50a9522..f2139a1 100644
> > --- a/drivers/pci/pcie/portdrv_core.c
> > +++ b/drivers/pci/pcie/portdrv_core.c
> > @@ -256,7 +256,8 @@ static int get_port_device_capability(struct pci_dev *dev)
> > */
> > if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) &&
> > pci_aer_available() &&
> > - (pcie_ports_dpc_native || (services & PCIE_PORT_SERVICE_AER)))
> > + (pcie_ports_dpc_native || host->native_dpc ||
> > + (services & PCIE_PORT_SERVICE_AER)))
> > services |= PCIE_PORT_SERVICE_DPC;
> >
> > if (pci_pcie_type(dev) == PCI_EXP_TYPE_DOWNSTREAM ||
> >
On 4/23/20 8:11 AM, Derrick, Jonathan wrote:
> Hi Sathyanarayanan,
>
> On Wed, 2020-04-22 at 15:50 -0700, Kuppuswamy, Sathyanarayanan wrote:
>>
>> On 4/20/20 2:37 PM, Jon Derrick wrote:
>>> The existing portdrv model prevents DPC services without either OS
>>> control (_OSC) granted to AER services, a Host Bridge requesting Native
>>> AER, or using one of the 'pcie_ports=' parameters of 'native' or
>>> 'dpc-native'.
>>>
>>> The DPC port service driver itself will also fail to probe if the kernel
>>> assumes the port is using Firmware-First AER. It's a reasonable
>>> expectation that a port using Firmware-First AER will also be using
>>> Firmware-First DPC, however if a Host Bridge requests Native DPC, the
>>> DPC driver should allow it and not fail to bind due to AER capability
>>> settings.
>>>
>>> Host Bridges which request Native DPC port services will also likely
>>> request Native AER, however it shouldn't be a requirement. This patch
>>> allows ports on those Host Bridges to have DPC port services.
>>>
>>> This will avoid the unlikely situation where the port is Firmware-First
>>> AER and Native DPC, and a BIOS or switch firmware preconfiguration of
>>> the DPC trigger could result in unhandled DPC events.
>>>
>>> Signed-off-by: Jon Derrick <[email protected]>
>>> ---
>>> drivers/pci/pcie/dpc.c | 3 ++-
>>> drivers/pci/pcie/portdrv_core.c | 3 ++-
>>> 2 files changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
>>> index 7621704..3f3106f 100644
>>> --- a/drivers/pci/pcie/dpc.c
>>> +++ b/drivers/pci/pcie/dpc.c
>>> @@ -284,7 +284,8 @@ static int dpc_probe(struct pcie_device *dev)
>>> 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 &&
>>> + !pci_find_host_bridge(pdev->bus)->native_dpc)
>> Why do it in probe as well ? if host->native_dpc is not set then the
>> device DPC probe it self won't happen right ?
>
> Portdrv only enables the interrupt and allows the probe to occur.
Please check the following snippet of code (from portdrv_core.c).
IIUC, pcie_device_init() will not be called if PCIE_PORT_SERVICE_DPC is
not set in capabilities. Your change in portdrv_core.c already
selectively enables the PCIE_PORT_SERVICE_DPC service based on
native_dpc value.
So IMO, adding native_dpc check in dpc_probe() is redundant.
int pcie_port_device_register(struct pci_dev *dev)
/* Allocate child services if any */
status = -ENODEV;
nr_service = 0;
for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++) {
int service = 1 << i;
if (!(capabilities & service))
continue;
if (!pcie_device_init(dev, service, irqs[i]))
nr_service++;
}
>
> The probe itself will still fail if there's a mixed-mode _OSC
> negotiated AER & DPC, due to pcie_aer_get_firmware_first returning 1
> for AER and no check for DPC.
>
> I don't know if such a platform will exist, but the kernel is already
> wired for 'dpc-native' so it makes sense to extend it for this..
>
> This transform might be more readable:
> if (pcie_aer_get_firmware_first(pdev) &&
> !(pcie_ports_dpc_native || hb->native_dpc))
>
>
>
>>> return -ENOTSUPP;
>>>
>>> status = devm_request_threaded_irq(device, dev->irq, dpc_irq,
>>> diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
>>> index 50a9522..f2139a1 100644
>>> --- a/drivers/pci/pcie/portdrv_core.c
>>> +++ b/drivers/pci/pcie/portdrv_core.c
>>> @@ -256,7 +256,8 @@ static int get_port_device_capability(struct pci_dev *dev)
>>> */
>>> if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) &&
>>> pci_aer_available() &&
>>> - (pcie_ports_dpc_native || (services & PCIE_PORT_SERVICE_AER)))
>>> + (pcie_ports_dpc_native || host->native_dpc ||
>>> + (services & PCIE_PORT_SERVICE_AER)))
>>> services |= PCIE_PORT_SERVICE_DPC;
>>>
>>> if (pci_pcie_type(dev) == PCI_EXP_TYPE_DOWNSTREAM ||
>>>
Hi Sathyanarayanan,
On Sat, 2020-04-25 at 13:46 -0700, Kuppuswamy, Sathyanarayanan wrote:
>
> On 4/23/20 8:11 AM, Derrick, Jonathan wrote:
> > Hi Sathyanarayanan,
> >
> > On Wed, 2020-04-22 at 15:50 -0700, Kuppuswamy, Sathyanarayanan wrote:
> > > On 4/20/20 2:37 PM, Jon Derrick wrote:
> > > > The existing portdrv model prevents DPC services without either OS
> > > > control (_OSC) granted to AER services, a Host Bridge requesting Native
> > > > AER, or using one of the 'pcie_ports=' parameters of 'native' or
> > > > 'dpc-native'.
> > > >
> > > > The DPC port service driver itself will also fail to probe if the kernel
> > > > assumes the port is using Firmware-First AER. It's a reasonable
> > > > expectation that a port using Firmware-First AER will also be using
> > > > Firmware-First DPC, however if a Host Bridge requests Native DPC, the
> > > > DPC driver should allow it and not fail to bind due to AER capability
> > > > settings.
> > > >
> > > > Host Bridges which request Native DPC port services will also likely
> > > > request Native AER, however it shouldn't be a requirement. This patch
> > > > allows ports on those Host Bridges to have DPC port services.
> > > >
> > > > This will avoid the unlikely situation where the port is Firmware-First
> > > > AER and Native DPC, and a BIOS or switch firmware preconfiguration of
> > > > the DPC trigger could result in unhandled DPC events.
> > > >
> > > > Signed-off-by: Jon Derrick <[email protected]>
> > > > ---
> > > > drivers/pci/pcie/dpc.c | 3 ++-
> > > > drivers/pci/pcie/portdrv_core.c | 3 ++-
> > > > 2 files changed, 4 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
> > > > index 7621704..3f3106f 100644
> > > > --- a/drivers/pci/pcie/dpc.c
> > > > +++ b/drivers/pci/pcie/dpc.c
> > > > @@ -284,7 +284,8 @@ static int dpc_probe(struct pcie_device *dev)
> > > > 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 &&
> > > > + !pci_find_host_bridge(pdev->bus)->native_dpc)
> > > Why do it in probe as well ? if host->native_dpc is not set then the
> > > device DPC probe it self won't happen right ?
> >
> > Portdrv only enables the interrupt and allows the probe to occur.
>
> Please check the following snippet of code (from portdrv_core.c).
>
> IIUC, pcie_device_init() will not be called if PCIE_PORT_SERVICE_DPC is
> not set in capabilities. Your change in portdrv_core.c already
> selectively enables the PCIE_PORT_SERVICE_DPC service based on
> native_dpc value.
>
That's right. So pcie_device_init registers the port service driver
allowing the services enumeration to occur.
> So IMO, adding native_dpc check in dpc_probe() is redundant.
>
> int pcie_port_device_register(struct pci_dev *dev)
> /* Allocate child services if any */
> status = -ENODEV;
> nr_service = 0;
> for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++) {
> int service = 1 << i;
> if (!(capabilities & service))
> continue;
> if (!pcie_device_init(dev, service, irqs[i]))
> nr_service++;
> }
>
This is the tricky part
There's still a check in dpc_probe for AER FFS or pcie_ports=dpc-
native:
if (pcie_aer_get_firmware_first(pdev) && !pcie_ports_dpc_native)
return -ENOTSUPP;
One option is to move that to get_port_device_capability and remove the
dpc_probe check
> > The probe itself will still fail if there's a mixed-mode _OSC
> > negotiated AER & DPC, due to pcie_aer_get_firmware_first returning 1
> > for AER and no check for DPC.
> >
> > I don't know if such a platform will exist, but the kernel is already
> > wired for 'dpc-native' so it makes sense to extend it for this..
> >
> > This transform might be more readable:
> > if (pcie_aer_get_firmware_first(pdev) &&
> > !(pcie_ports_dpc_native || hb->native_dpc))
> >
> >
> >
> > > > return -ENOTSUPP;
> > > >
> > > > status = devm_request_threaded_irq(device, dev->irq, dpc_irq,
> > > > diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
> > > > index 50a9522..f2139a1 100644
> > > > --- a/drivers/pci/pcie/portdrv_core.c
> > > > +++ b/drivers/pci/pcie/portdrv_core.c
> > > > @@ -256,7 +256,8 @@ static int get_port_device_capability(struct pci_dev *dev)
> > > > */
> > > > if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) &&
> > > > pci_aer_available() &&
> > > > - (pcie_ports_dpc_native || (services & PCIE_PORT_SERVICE_AER)))
> > > > + (pcie_ports_dpc_native || host->native_dpc ||
> > > > + (services & PCIE_PORT_SERVICE_AER)))
> > > > services |= PCIE_PORT_SERVICE_DPC;
> > > >
> > > > if (pci_pcie_type(dev) == PCI_EXP_TYPE_DOWNSTREAM ||
> > > >
On 4/27/20 8:15 AM, Derrick, Jonathan wrote:
> Hi Sathyanarayanan,
>
> On Sat, 2020-04-25 at 13:46 -0700, Kuppuswamy, Sathyanarayanan wrote:
>>
>> On 4/23/20 8:11 AM, Derrick, Jonathan wrote:
>>> Hi Sathyanarayanan,
>>>
>>> On Wed, 2020-04-22 at 15:50 -0700, Kuppuswamy, Sathyanarayanan wrote:
>>>> On 4/20/20 2:37 PM, Jon Derrick wrote:
>>>>> The existing portdrv model prevents DPC services without either OS
>>>>> control (_OSC) granted to AER services, a Host Bridge requesting Native
>>>>> AER, or using one of the 'pcie_ports=' parameters of 'native' or
>>>>> 'dpc-native'.
>>>>>
>>>>> The DPC port service driver itself will also fail to probe if the kernel
>>>>> assumes the port is using Firmware-First AER. It's a reasonable
>>>>> expectation that a port using Firmware-First AER will also be using
>>>>> Firmware-First DPC, however if a Host Bridge requests Native DPC, the
>>>>> DPC driver should allow it and not fail to bind due to AER capability
>>>>> settings.
>>>>>
>>>>> Host Bridges which request Native DPC port services will also likely
>>>>> request Native AER, however it shouldn't be a requirement. This patch
>>>>> allows ports on those Host Bridges to have DPC port services.
>>>>>
>>>>> This will avoid the unlikely situation where the port is Firmware-First
>>>>> AER and Native DPC, and a BIOS or switch firmware preconfiguration of
>>>>> the DPC trigger could result in unhandled DPC events.
>>>>>
>>>>> Signed-off-by: Jon Derrick <[email protected]>
>>>>> ---
>>>>> drivers/pci/pcie/dpc.c | 3 ++-
>>>>> drivers/pci/pcie/portdrv_core.c | 3 ++-
>>>>> 2 files changed, 4 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
>>>>> index 7621704..3f3106f 100644
>>>>> --- a/drivers/pci/pcie/dpc.c
>>>>> +++ b/drivers/pci/pcie/dpc.c
>>>>> @@ -284,7 +284,8 @@ static int dpc_probe(struct pcie_device *dev)
>>>>> 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 &&
>>>>> + !pci_find_host_bridge(pdev->bus)->native_dpc)
>>>> Why do it in probe as well ? if host->native_dpc is not set then the
>>>> device DPC probe it self won't happen right ?
>>>
>>> Portdrv only enables the interrupt and allows the probe to occur.
>>
>> Please check the following snippet of code (from portdrv_core.c).
>>
>> IIUC, pcie_device_init() will not be called if PCIE_PORT_SERVICE_DPC is
>> not set in capabilities. Your change in portdrv_core.c already
>> selectively enables the PCIE_PORT_SERVICE_DPC service based on
>> native_dpc value.
>>
> That's right. So pcie_device_init registers the port service driver
> allowing the services enumeration to occur.
>
>> So IMO, adding native_dpc check in dpc_probe() is redundant.
>>
>> int pcie_port_device_register(struct pci_dev *dev)
>> /* Allocate child services if any */
>> status = -ENODEV;
>> nr_service = 0;
>> for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++) {
>> int service = 1 << i;
>> if (!(capabilities & service))
>> continue;
>> if (!pcie_device_init(dev, service, irqs[i]))
>> nr_service++;
>> }
>>
> This is the tricky part
> There's still a check in dpc_probe for AER FFS or pcie_ports=dpc-
> native:
>
> if (pcie_aer_get_firmware_first(pdev) && !pcie_ports_dpc_native)
> return -ENOTSUPP;
>
> One option is to move that to get_port_device_capability and remove the
> dpc_probe check
Yes, its better to group them together in get_port_device_capability().
But it should be done in a separate patch.
>
>>> The probe itself will still fail if there's a mixed-mode _OSC
>>> negotiated AER & DPC, due to pcie_aer_get_firmware_first returning 1
>>> for AER and no check for DPC.
>>>
>>> I don't know if such a platform will exist, but the kernel is already
>>> wired for 'dpc-native' so it makes sense to extend it for this..
>>>
>>> This transform might be more readable:
>>> if (pcie_aer_get_firmware_first(pdev) &&
>>> !(pcie_ports_dpc_native || hb->native_dpc))
>>>
>>>
>>>
>>>>> return -ENOTSUPP;
>>>>>
>>>>> status = devm_request_threaded_irq(device, dev->irq, dpc_irq,
>>>>> diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
>>>>> index 50a9522..f2139a1 100644
>>>>> --- a/drivers/pci/pcie/portdrv_core.c
>>>>> +++ b/drivers/pci/pcie/portdrv_core.c
>>>>> @@ -256,7 +256,8 @@ static int get_port_device_capability(struct pci_dev *dev)
>>>>> */
>>>>> if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) &&
>>>>> pci_aer_available() &&
>>>>> - (pcie_ports_dpc_native || (services & PCIE_PORT_SERVICE_AER)))
>>>>> + (pcie_ports_dpc_native || host->native_dpc ||
>>>>> + (services & PCIE_PORT_SERVICE_AER)))
>>>>> services |= PCIE_PORT_SERVICE_DPC;
>>>>>
>>>>> if (pci_pcie_type(dev) == PCI_EXP_TYPE_DOWNSTREAM ||
>>>>>