[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0058b993-0663-7fed-ed31-cb0adf845a39@linux.intel.com>
Date: Wed, 22 Apr 2020 15:50:17 -0700
From: "Kuppuswamy, Sathyanarayanan"
<sathyanarayanan.kuppuswamy@...ux.intel.com>
To: Jon Derrick <jonathan.derrick@...el.com>,
Bjorn Helgaas <helgaas@...nel.org>
Cc: linux-pci@...r.kernel.org, Keith Busch <kbusch@...nel.org>,
Russell Currey <ruscur@...sell.cc>,
Sam Bobroff <sbobroff@...ux.ibm.com>,
Oliver O'Halloran <oohall@...il.com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Frederick Lawler <fred@...dlawl.com>,
Rajat Jain <rajatja@...gle.com>,
"Patel, Mayurkumar" <mayurkumar.patel@...el.com>,
Olof Johansson <olof@...om.net>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
Alex Williamson <alex.williamson@...hat.com>,
linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] PCI/DPC: Allow Native DPC Host Bridges to use DPC
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 <jonathan.derrick@...el.com>
> ---
> 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 ||
>
Powered by blists - more mailing lists