From: "Sean V Kelley" <sean.v.kelley@intel.com>
To: "Jonathan Cameron" <Jonathan.Cameron@huawei.com>
Cc: bhelgaas@google.com, rjw@rjwysocki.net, tony.luck@intel.com,
"Raj, Ashok" <ashok.raj@intel.com>,
sathyanarayanan.kuppuswamy@linux.intel.com,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 4/9] PCI/AER: Extend AER error handling to RCECs
Date: Mon, 27 Jul 2020 08:00:11 -0700 [thread overview]
Message-ID: <BBEF2C05-521A-42D9-9AA4-F0B537E063F5@intel.com> (raw)
In-Reply-To: <20200727150426.00005cde@huawei.com>
On 27 Jul 2020, at 7:04, Jonathan Cameron wrote:
> On Fri, 24 Jul 2020 10:22:18 -0700
> Sean V Kelley <sean.v.kelley@intel.com> wrote:
>
>> From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>>
>> Currently the kernel does not handle AER errors for Root Complex
>> integrated
>> End Points (RCiEPs)[0]. These devices sit on a root bus within the
>> Root Complex
>> (RC). AER handling is performed by a Root Complex Event Collector
>> (RCEC) [1]
>> which is a effectively a type of RCiEP on the same root bus.
>>
>> For an RCEC (technically not a Bridge), error messages "received"
>> from
>> associated RCiEPs must be enabled for "transmission" in order to
>> cause a
>> System Error via the Root Control register or (when the Advanced
>> Error
>> Reporting Capability is present) reporting via the Root Error Command
>> register and logging in the Root Error Status register and Error
>> Source
>> Identification register.
>>
>> In addition to the defined OS level handling of the reset flow for
>> the
>> associated RCiEPs of an RCEC, it is possible to also have a firmware
>> first
>> model. In that case there is no need to take any actions on the RCEC
>> because
>> the firmware is responsible for them. This is true where APEI [2] is
>> used
>> to report the AER errors via a GHES[v2] HEST entry [3] and relevant
>> AER CPER record [4] and Firmware First handling is in use.
>>
>> We effectively end up with two different types of discovery for
>> purposes of handling AER errors:
>>
>> 1) Normal bus walk - we pass the downstream port above a bus to which
>> the device is attached and it walks everything below that point.
>>
>> 2) An RCiEP with no visible association with an RCEC as there is no
>> need to
>> walk devices. In that case, the flow is to just call the callbacks
>> for the actual
>> device.
>>
>> A new walk function, similar to pci_bus_walk is provided that takes a
>> pci_dev
>> instead of a bus. If that dev corresponds to a downstream port it
>> will walk
>> the subordinate bus of that downstream port. If the dev does not then
>> it
>> will call the function on that device alone.
>>
>> [0] ACPI PCI Express Base Specification 5.0-1 1.3.2.3 Root Complex
>> Integrated
>> Endpoint Rules.
>> [1] ACPI PCI Express Base Specification 5.0-1 6.2 Error Signalling
>> and Logging
>> [2] ACPI Specification 6.3 Chapter 18 ACPI Platform Error Interface
>> (APEI)
>> [3] ACPI Specification 6.3 18.2.3.7 Generic Hardware Error Source
>> [4] UEFI Specification 2.8, N.2.7 PCI Express Error Section
>>
>> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>> Signed-off-by: Sean V Kelley <sean.v.kelley@intel.com>
>> ---
> ...
>
>
>> pci_dbg(dev, "broadcast resume message\n");
>> - pci_walk_bus(bus, report_resume, &status);
>> + pci_walk_dev_affected(dev, report_resume, &status);
>>
>> - pci_aer_clear_device_status(dev);
>> - pci_aer_clear_nonfatal_status(dev);
>
> This code had changed a little in Bjorn's pci/next branch so do a
> rebase on that
> before v2.
Will ensure rebase includes pci/next.
Thanks,
Sean
>
>> + if ((pci_pcie_type(dev) == PCI_EXP_TYPE_ROOT_PORT ||
>> + pci_pcie_type(dev) == PCI_EXP_TYPE_DOWNSTREAM ||
>> + pci_pcie_type(dev) == PCI_EXP_TYPE_RC_EC)) {
>> + pci_aer_clear_device_status(dev);
>> + pci_aer_clear_nonfatal_status(dev);
>> + }
>> pci_info(dev, "device recovery successful\n");
>> return status;
>>
next prev parent reply other threads:[~2020-07-27 15:00 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-24 17:22 [RFC PATCH 0/9] Add RCEC handling to PCI/AER Sean V Kelley
2020-07-24 17:22 ` [RFC PATCH 1/9] pci_ids: Add class code and extended capability for RCEC Sean V Kelley
2020-07-27 10:00 ` Jonathan Cameron
2020-07-27 10:21 ` Jonathan Cameron
2020-07-27 15:22 ` Sean V Kelley
2020-07-24 17:22 ` [RFC PATCH 2/9] PCI: Extend Root Port Driver to support RCEC Sean V Kelley
2020-07-27 12:30 ` Jonathan Cameron
2020-07-27 15:05 ` Sean V Kelley
2020-07-24 17:22 ` [RFC PATCH 3/9] PCI/portdrv: Add pcie_walk_rcec() to walk RCiEPs associated with RCEC Sean V Kelley
2020-07-27 10:49 ` Jonathan Cameron
2020-07-27 15:21 ` Sean V Kelley
2020-07-24 17:22 ` [RFC PATCH 4/9] PCI/AER: Extend AER error handling to RCECs Sean V Kelley
2020-07-27 11:00 ` Jonathan Cameron
2020-07-27 14:58 ` Sean V Kelley
2020-07-27 14:04 ` Jonathan Cameron
2020-07-27 15:00 ` Sean V Kelley [this message]
2020-07-24 17:22 ` [RFC PATCH 5/9] PCI/AER: Apply function level reset to RCiEP on fatal error Sean V Kelley
2020-07-27 11:17 ` Jonathan Cameron
2020-07-28 13:27 ` Zhuo, Qiuxu
2020-07-28 16:14 ` Sean V Kelley
2020-07-28 17:02 ` Jonathan Cameron
2020-07-28 17:42 ` Sean V Kelley
2020-07-24 17:22 ` [RFC PATCH 6/9] PCI: Add 'rcec' field to pci_dev for associated RCiEPs Sean V Kelley
2020-07-27 11:23 ` Jonathan Cameron
2020-07-27 15:39 ` Sean V Kelley
2020-07-27 16:11 ` Jonathan Cameron
2020-07-27 16:28 ` Sean V Kelley
2020-07-24 17:22 ` [RFC PATCH 7/9] PCI/AER: Add RCEC AER handling Sean V Kelley
2020-07-27 12:22 ` Jonathan Cameron
2020-07-27 15:19 ` Sean V Kelley
2020-07-27 17:14 ` Jonathan Cameron
2020-07-24 17:22 ` [RFC PATCH 8/9] PCI/PME: Add RCEC PME handling Sean V Kelley
2020-08-04 8:35 ` Jay Fang
2020-08-04 9:47 ` Jonathan Cameron
2020-07-24 17:22 ` [RFC PATCH 9/9] PCI/AER: Add RCEC AER error injection support Sean V Kelley
2020-07-27 12:37 ` [RFC PATCH 0/9] Add RCEC handling to PCI/AER Jonathan Cameron
2020-07-27 14:56 ` Sean V Kelley
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=BBEF2C05-521A-42D9-9AA4-F0B537E063F5@intel.com \
--to=sean.v.kelley@intel.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=ashok.raj@intel.com \
--cc=bhelgaas@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=tony.luck@intel.com \
/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).