linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Kuppuswamy, Sathyanarayanan"  <sathyanarayanan.kuppuswamy@linux.intel.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: ashok.raj@intel.com, knsathya@kernel.org,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	Bjorn Helgaas <bhelgaas@google.com>,
	Olof Johansson <olof@lixom.net>
Subject: Re: [PATCH 1/5] PCI/DPC: Ignore devices with no AER Capability
Date: Sat, 28 Nov 2020 13:49:46 -0800	[thread overview]
Message-ID: <c2a7c9e6-8916-2c14-4968-a963266e6c53@linux.intel.com> (raw)
In-Reply-To: <20201128202408.GA906784@bjorn-Precision-5520>



On 11/28/20 12:24 PM, Bjorn Helgaas wrote:
> On Wed, Nov 25, 2020 at 06:01:57PM -0800, Kuppuswamy, Sathyanarayanan wrote:
>> On 11/25/20 5:18 PM, Bjorn Helgaas wrote:
>>> From: Bjorn Helgaas <bhelgaas@google.com>
>>>
>>> Downstream Ports may support DPC regardless of whether they support AER
>>> (see PCIe r5.0, sec 6.2.10.2).  Previously, if the user booted with
>>> "pcie_ports=dpc-native", it was possible for dpc_probe() to succeed even if
>>> the device had no AER Capability, but dpc_get_aer_uncorrect_severity()
>>> depends on the AER Capability.
>>>
>>> dpc_probe() previously failed if:
>>>
>>>     !pcie_aer_is_native(pdev) && !pcie_ports_dpc_native
>>>     !(pcie_aer_is_native() || pcie_ports_dpc_native)    # by De Morgan's law
>>>
>>> so it succeeded if:
>>>
>>>     pcie_aer_is_native() || pcie_ports_dpc_native
>>>
>>> Fail dpc_probe() if the device has no AER Capability.
>>>
>>> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>>> Cc: Olof Johansson <olof@lixom.net>
>>> ---
>>>    drivers/pci/pcie/dpc.c | 3 +++
>>>    1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
>>> index e05aba86a317..ed0dbc43d018 100644
>>> --- a/drivers/pci/pcie/dpc.c
>>> +++ b/drivers/pci/pcie/dpc.c
>>> @@ -287,6 +287,9 @@ static int dpc_probe(struct pcie_device *dev)
>>>    	int status;
>>>    	u16 ctl, cap;
>>> +	if (!pdev->aer_cap)
>>> +		return -ENOTSUPP;
>> Don't we check aer_cap support in drivers/pci/pcie/portdrv_core.c ?
>>
>> We don't enable DPC service, if AER service is not enabled. And AER
>> service is only enabled if AER capability is supported.
>>
>> So dpc_probe() should not happen if AER capability is not supported?
> 
> I don't think that's always true.  If I'm reading this right, we have
> this:
> 
>    get_port_device_capability(...)
>    {
>    #ifdef CONFIG_PCIEAER
>      if (dev->aer_cap && ...)
>        services |= PCIE_PORT_SERVICE_AER;
>    #endif
> 
>      if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) &&
>          pci_aer_available() &&
>          (pcie_ports_dpc_native || (services & PCIE_PORT_SERVICE_AER)))
>        services |= PCIE_PORT_SERVICE_DPC;
>    }
> 
> and in the case where:
> 
>    - CONFIG_PCIEAER=y
>    - booted with "pcie_ports=dpc-native" (pcie_ports_dpc_native is true)
>    - "dev" has no AER capability
>    - "dev" has DPC capability
> 
> I think we do enable PCIE_PORT_SERVICE_DPC.
Got it. But further looking into it, I am wondering whether
we should keep this dependency? Currently we just use it to
dump the error information. Do we need to create dependency
between DPC and AER (which is functionality not dependent) just
to see more details about the error?
> 
>> 206 static int get_port_device_capability(struct pci_dev *dev)
>> ...
>> ...
>> 251         if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) &&
>> 252             host->native_dpc &&
>> 253             (host->native_dpc || (services & PCIE_PORT_SERVICE_AER)))
>> 254                 services |= PCIE_PORT_SERVICE_DPC;
>> 255
>>
>>> +
>>>    	if (!pcie_aer_is_native(pdev) && !pcie_ports_dpc_native)
>>>    		return -ENOTSUPP;
>>>
>>
>> -- 
>> Sathyanarayanan Kuppuswamy
>> Linux Kernel Developer

-- 
Sathyanarayanan Kuppuswamy
Linux Kernel Developer

  reply	other threads:[~2020-11-28 22:00 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-26  1:18 [PATCH v12 0/5] Simplify PCIe native ownership Bjorn Helgaas
2020-11-26  1:18 ` [PATCH 1/5] PCI/DPC: Ignore devices with no AER Capability Bjorn Helgaas
2020-11-26  2:01   ` Kuppuswamy, Sathyanarayanan
2020-11-28 20:24     ` Bjorn Helgaas
2020-11-28 21:49       ` Kuppuswamy, Sathyanarayanan [this message]
2020-11-28 21:53         ` Bjorn Helgaas
2020-11-28 21:56           ` Kuppuswamy, Sathyanarayanan
2020-11-28 23:25             ` Bjorn Helgaas
2020-11-29  4:32               ` Kuppuswamy, Sathyanarayanan
2020-12-01 15:34                 ` Bjorn Helgaas
2020-11-26  1:18 ` [PATCH 2/5] PCI: Assume control of portdrv-related features only when portdrv enabled Bjorn Helgaas
2020-11-26  1:18 ` [PATCH 3/5] PCI/ACPI: Tidy _OSC control bit checking Bjorn Helgaas
2020-11-26  1:18 ` [PATCH 4/5] PCI/ACPI: Centralize pcie_ports_native checking Bjorn Helgaas
2020-11-26  3:20   ` Kuppuswamy, Sathyanarayanan
2020-11-28 21:45     ` Bjorn Helgaas
2020-11-26  1:18 ` [PATCH 5/5] PCI/ACPI: Centralize pci_aer_available() checking Bjorn Helgaas
2020-11-26  3:48 ` [PATCH v12 0/5] Simplify PCIe native ownership Kuppuswamy, Sathyanarayanan
2020-12-01  1:11   ` Kuppuswamy, Sathyanarayanan
2020-12-08  6:03     ` Kuppuswamy, Sathyanarayanan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c2a7c9e6-8916-2c14-4968-a963266e6c53@linux.intel.com \
    --to=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=ashok.raj@intel.com \
    --cc=bhelgaas@google.com \
    --cc=helgaas@kernel.org \
    --cc=knsathya@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=olof@lixom.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).