From: Bjorn Helgaas <helgaas@kernel.org>
To: "Kelley, Sean V" <sean.v.kelley@intel.com>
Cc: "Zhuo, Qiuxu" <qiuxu.zhuo@intel.com>,
"Jonathan.Cameron@huawei.com" <Jonathan.Cameron@huawei.com>,
"rjw@rjwysocki.net" <rjw@rjwysocki.net>,
"sathyanarayanan.kuppuswamy@linux.intel.com"
<sathyanarayanan.kuppuswamy@linux.intel.com>,
"Raj, Ashok" <ashok.raj@intel.com>,
"Luck, Tony" <tony.luck@intel.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 04/10] PCI/RCEC: Add pcie_walk_rcec() to walk associated RCiEPs
Date: Fri, 4 Sep 2020 21:23:08 -0500 [thread overview]
Message-ID: <20200905022308.GA379055@bjorn-Precision-5520> (raw)
In-Reply-To: <ae1885fcb2dd5f174c8e5f94d1fd31f389776807.camel@intel.com>
On Fri, Sep 04, 2020 at 10:18:30PM +0000, Kelley, Sean V wrote:
> Hi Bjorn,
>
> Quick question below...
>
> On Wed, 2020-09-02 at 14:55 -0700, Sean V Kelley wrote:
> > Hi Bjorn,
> >
> > On Wed, 2020-09-02 at 14:00 -0500, Bjorn Helgaas wrote:
> > > On Wed, Aug 12, 2020 at 09:46:53AM -0700, Sean V Kelley wrote:
> > > > From: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
> > > >
> > > > When an RCEC device signals error(s) to a CPU core, the CPU core
> > > > needs to walk all the RCiEPs associated with that RCEC to check
> > > > errors. So add the function pcie_walk_rcec() to walk all RCiEPs
> > > > associated with the RCEC device.
> > > >
> > > > Co-developed-by: Sean V Kelley <sean.v.kelley@intel.com>
> > > > Signed-off-by: Sean V Kelley <sean.v.kelley@intel.com>
> > > > Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
> > > > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > > > ---
> > > > drivers/pci/pci.h | 4 +++
> > > > drivers/pci/pcie/rcec.c | 76
> > > > +++++++++++++++++++++++++++++++++++++++++
> > > > 2 files changed, 80 insertions(+)
> > > >
> > > > diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> > > > index bd25e6047b54..8bd7528d6977 100644
> > > > --- a/drivers/pci/pci.h
> > > > +++ b/drivers/pci/pci.h
> > > > @@ -473,9 +473,13 @@ static inline void pci_dpc_init(struct
> > > > pci_dev
> > > > *pdev) {}
> > > > #ifdef CONFIG_PCIEPORTBUS
> > > > void pci_rcec_init(struct pci_dev *dev);
> > > > void pci_rcec_exit(struct pci_dev *dev);
> > > > +void pcie_walk_rcec(struct pci_dev *rcec, int (*cb)(struct
> > > > pci_dev
> > > > *, void *),
> > > > + void *userdata);
> > > > #else
> > > > static inline void pci_rcec_init(struct pci_dev *dev) {}
> > > > static inline void pci_rcec_exit(struct pci_dev *dev) {}
> > > > +static inline void pcie_walk_rcec(struct pci_dev *rcec, int
> > > > (*cb)(struct pci_dev *, void *),
> > > > + void *userdata) {}
> > > > #endif
> > > >
> > > > #ifdef CONFIG_PCI_ATS
> > > > diff --git a/drivers/pci/pcie/rcec.c b/drivers/pci/pcie/rcec.c
> > > > index 519ae086ff41..405f92fcdf7f 100644
> > > > --- a/drivers/pci/pcie/rcec.c
> > > > +++ b/drivers/pci/pcie/rcec.c
> > > > @@ -17,6 +17,82 @@
> > > >
> > > > #include "../pci.h"
> > > >
> > > > +static int pcie_walk_rciep_devfn(struct pci_bus *bus, int
> > > > (*cb)(struct pci_dev *, void *),
> > > > + void *userdata, const unsigned long
> > > > bitmap)
> > > > +{
> > > > + unsigned int devn, fn;
> > > > + struct pci_dev *dev;
> > > > + int retval;
> > > > +
> > > > + for_each_set_bit(devn, &bitmap, 32) {
> > > > + for (fn = 0; fn < 8; fn++) {
> > > > + dev = pci_get_slot(bus, PCI_DEVFN(devn, fn));
> > >
> > > Wow, this is a lot of churning to call pci_get_slot() 256 times per
> > > bus for the "associated bus numbers" case where we pass a bitmap of
> > > 0xffffffff. They didn't really make it easy for software when they
> > > added the next/last bus number thing.
> > >
> > > Just thinking out loud here. What if we could set dev->rcec during
> > > enumeration, and then use that to build pcie_walk_rcec()?
> >
> > I think follow what you are doing.
> >
> > As we enumerate an RCEC, use the time to discover RCiEPs and
> > associate
> > each RCiEP's dev->rcec. Although BIOS already set the bitmap for this
> > specific RCEC, it's more efficient to simply discover the devices
> > through the bus walk and verify each one found against the bitmap.
> >
> > Further, while we can be certain that an RCiEP found with a matching
> > device no. in a bitmap for an associated RCEC is correct, we cannot
> > be
> > certain that any RCiEP found on another bus range is correct unless
> > we
> > verify the bus is within that next/last bus range.
> >
> > Finally, that's where find_rcec() callback for rcec_assoc_rciep()
> > does
> > double duty by also checking on the "on-a-separate-bus" case captured
> > potentially by find_rcec() during an RCiEP's bus walk.
> >
> >
> > > bool rcec_assoc_rciep(rcec, rciep)
> > > {
> > > if (rcec->bus == rciep->bus)
> > > return (rcec->bitmap contains rciep->devfn);
> > >
> > > return (rcec->next/last contains rciep->bus);
> > > }
> > >
> > > link_rcec(dev, data)
> > > {
> > > struct pci_dev *rcec = data;
> > >
> > > if ((dev is RCiEP) && rcec_assoc_rciep(rcec, dev))
> > > dev->rcec = rcec;
> > > }
> > >
> > > find_rcec(dev, data)
> > > {
> > > struct pci_dev *rciep = data;
> > >
> > > if ((dev is RCEC) && rcec_assoc_rciep(dev, rciep))
> > > rciep->rcec = dev;
> > > }
> > >
> > > pci_setup_device
> > > ...
>
> I just noticed your use of pci_setup_device(). Are you suggesting
> moving the call to pci_rcec_init() out of pci_init_capabilities() and
> move it into pci_setup_device()? If so, would pci_rcec_exit() still
> remain in pci_release_capabilities()?
>
> I'm just wondering if it could just remain in pci_init_capabilities().
Yeah, I didn't mean in pci_setup_device() specifically, just somewhere
in the callchain of pci_setup_device(). But you're right, it probably
would make more sense in pci_init_capabilities(), so I *should* have
said pci_scan_single_device() to be a little less specific.
Bjorn
next prev parent reply other threads:[~2020-09-05 2:23 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-12 16:46 [PATCH v3 00/10] Add RCEC handling to PCI/AER Sean V Kelley
2020-08-12 16:46 ` [PATCH v3 01/10] PCI/RCEC: Add RCEC class code and extended capability Sean V Kelley
2020-08-12 16:46 ` [PATCH v3 02/10] PCI/RCEC: Bind RCEC devices to the Root Port driver Sean V Kelley
2020-08-12 16:46 ` [PATCH v3 03/10] PCI/RCEC: Cache RCEC capabilities in pci_init_capabilities() Sean V Kelley
2020-08-12 16:46 ` [PATCH v3 04/10] PCI/RCEC: Add pcie_walk_rcec() to walk associated RCiEPs Sean V Kelley
2020-09-02 19:00 ` Bjorn Helgaas
2020-09-02 21:55 ` Sean V Kelley
2020-09-04 22:18 ` Kelley, Sean V
2020-09-05 2:23 ` Bjorn Helgaas [this message]
2020-09-11 23:16 ` Sean V Kelley
2020-09-12 0:50 ` Bjorn Helgaas
2020-09-14 16:55 ` Sean V Kelley
2020-09-15 16:09 ` Sean V Kelley
2020-09-15 17:47 ` Sean V Kelley
2020-09-16 23:06 ` Bjorn Helgaas
2020-09-16 22:49 ` Bjorn Helgaas
2020-08-12 16:46 ` [PATCH v3 05/10] PCI/AER: Extend AER error handling to RCECs Sean V Kelley
2020-08-26 17:26 ` Kuppuswamy, Sathyanarayanan
2020-08-26 18:55 ` sean.v.kelley
2020-08-12 16:46 ` [PATCH v3 06/10] PCI/AER: Apply function level reset to RCiEP on fatal error Sean V Kelley
2020-08-12 16:46 ` [PATCH v3 07/10] PCI: Add 'rcec' field to pci_dev for associated RCiEPs Sean V Kelley
2020-09-02 16:35 ` Bjorn Helgaas
2020-09-02 22:24 ` Sean V Kelley
2020-08-12 16:46 ` [PATCH v3 08/10] PCI/AER: Add RCEC AER handling Sean V Kelley
2020-08-12 16:46 ` [PATCH v3 09/10] PCI/PME: Add RCEC PME handling Sean V Kelley
2020-08-12 16:46 ` [PATCH v3 10/10] PCI/AER: Add RCEC AER error injection support 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=20200905022308.GA379055@bjorn-Precision-5520 \
--to=helgaas@kernel.org \
--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=qiuxu.zhuo@intel.com \
--cc=rjw@rjwysocki.net \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=sean.v.kelley@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