From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>, <linux-pci@vger.kernel.org>,
<linux-acpi@vger.kernel.org>, <linuxarm@huawei.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.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:18:22 +0100 [thread overview]
Message-ID: <20200617101822.00000f3d@Huawei.com> (raw)
In-Reply-To: <20200616174731.GA1969609@bjorn-Precision-5520>
On Tue, 16 Jun 2020 12:47:31 -0500
Bjorn Helgaas <helgaas@kernel.org> 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/.
>
> 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.
I'll be honest I've mostly forgotten my reasoning behind including that
reference. Might have been as simple as I got lost in the renames.
I'll drop the reference.
>
> > 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
Thanks. I'll add that (though can't check the document currently
for reasons you can probably figure out *sigh*)
Note this patch is rather tangential to patch 2 which is the one
I really need feedback on. Whilst this appeared to be
wrong it is 'mostly harmless'.
>
> > 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:19 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
2020-06-17 20:57 ` Kuppuswamy, Sathyanarayanan
2020-06-17 9:18 ` Jonathan Cameron [this message]
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=20200617101822.00000f3d@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.