From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: "Kuppuswamy,
Sathyanarayanan" <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>, <linux-pci@vger.kernel.org>,
<linux-acpi@vger.kernel.org>, <linuxarm@huawei.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Subject: Re: [PATCH 1/2] PCI/AER: Do not reset the device status if doing firmware first handling.
Date: Wed, 17 Jun 2020 10:31:20 +0100 [thread overview]
Message-ID: <20200617103120.00006dcd@Huawei.com> (raw)
In-Reply-To: <110fa7a9-1147-b755-2958-6f40c5d666a2@linux.intel.com>
On Tue, 16 Jun 2020 11:00:32 -0700
"Kuppuswamy, Sathyanarayanan" <sathyanarayanan.kuppuswamy@linux.intel.com> wrote:
> Hi Jonathan,
>
> On 6/16/20 10:47 AM, Bjorn Helgaas wrote:
> > [+cc Sathy]
> >
> > On Fri, May 22, 2020 at 01:31:33AM +0800, Jonathan Cameron wrote:
> >> pci_aer_clear_device_status() currently resets the device status even when
> >> firmware first handling is going on. In particular it resets it on the
> >> root port.
> >>
> >> This has been discussed previously
> >> https://lore.kernel.org/patchwork/patch/427375/.
> pci_aer_clear_device_status() is only used by handle_error_source(). And
> I don't think handle_error_source() is called in FF mode. Can you
> give more details on this issue ?
It's called in pcie_do_recovery
https://elixir.bootlin.com/linux/latest/source/drivers/pci/pcie/err.c#L200
Which is called from both handle_error_source and aer_recover_work_func.
indirectly called from ghes_handle_aer / ghes_do_proc
This particular flow will only happen (I think) on hardware reduced ACPI systems.
Jonathan
> >
> > I don't think this reference is really pertinent, is it? That patch
> > to b2c8881da764 changes pci_cleanup_aer_uncorrect_error_status() so it
> > doesn't clear PCI_ERR_UNCOR_STATUS in "firmware-first" mode.
> >
> > But your patch only affects PCI_EXP_DEVSTA, not PCI_ERR_UNCOR_STATUS.
> >
> >> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> >> ---
> >> drivers/pci/pcie/aer.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> >> index f4274d301235..43e78b97ace6 100644
> >> --- a/drivers/pci/pcie/aer.c
> >> +++ b/drivers/pci/pcie/aer.c
> >> @@ -373,6 +373,9 @@ void pci_aer_clear_device_status(struct pci_dev *dev)
> >> {
> >> u16 sta;
> >>
> >> + if (pcie_aer_get_firmware_first(dev))
> >> + return;
> >
> > This needs to be adjusted because pcie_aer_get_firmware_first() no
> > longer exists after 708b20003624 ("PCI/AER: Remove HEST/FIRMWARE_FIRST
> > parsing for AER ownership").
> >
> > This will use the _OSC AER ownership bit to gate clearing of the
> > status bits in the PCIe capability (not the AER capability).
> >
> > I think that's the right thing to do, but it's certainly not obvious
> > from the _OSC description in the PCI Firmware Spec r3.2. I think we
> > need a pointer to the ECN that clarifies this, i.e., sec 4.5.1 of:
> >
> > System Firmware Intermediary (SFI) _OSC and DPC Updates ECN, Feb 24,
> > 2020, affecting PCI Firmware Specification, Rev. 3.2
> > https://members.pcisig.com/wg/PCI-SIG/document/14076
> >
> >> pcie_capability_read_word(dev, PCI_EXP_DEVSTA, &sta);
> >> pcie_capability_write_word(dev, PCI_EXP_DEVSTA, sta);
> >> }
> >> --
> >> 2.19.1
> >>
>
next prev parent reply other threads:[~2020-06-17 9:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-21 17:31 [RFC PATCH 0/2] PCI/AER: handling for RCiEPs Jonathan Cameron
2020-05-21 17:31 ` [PATCH 1/2] PCI/AER: Do not reset the device status if doing firmware first handling Jonathan Cameron
2020-06-16 17:47 ` Bjorn Helgaas
2020-06-16 18:00 ` Kuppuswamy, Sathyanarayanan
2020-06-17 9:31 ` Jonathan Cameron [this message]
2020-06-17 20:57 ` Kuppuswamy, Sathyanarayanan
2020-06-17 9:18 ` Jonathan Cameron
2020-05-21 17:31 ` [PATCH 2/2] PCI/AER: Add partial initial support for RCiEPs using RCEC or firmware first Jonathan Cameron
2020-06-16 10:47 ` [RFC PATCH 0/2] PCI/AER: handling for RCiEPs Jonathan Cameron
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=20200617103120.00006dcd@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=lorenzo.pieralisi@arm.com \
--cc=sathyanarayanan.kuppuswamy@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.