[Very RFC 35/46] powernv/pci: Remove open-coded PE lookup in pnv_pci_release_device

Oliver O'Halloran oohall at gmail.com
Wed Nov 27 20:51:03 AEDT 2019


On Wed, Nov 27, 2019 at 4:24 PM Alexey Kardashevskiy <aik at ozlabs.ru> wrote:
>
>
>
> On 20/11/2019 12:28, Oliver O'Halloran wrote:
> > Signed-off-by: Oliver O'Halloran <oohall at gmail.com>
> > ---
> >  arch/powerpc/platforms/powernv/pci-ioda.c | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
> > index 4f38652c7cd7..8525642b1256 100644
> > --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> > +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> > @@ -3562,14 +3562,14 @@ static void pnv_ioda_release_pe(struct pnv_ioda_pe *pe)
> >  static void pnv_pci_release_device(struct pci_dev *pdev)
> >  {
> >       struct pnv_phb *phb = pci_bus_to_pnvhb(pdev->bus);
> > +     struct pnv_ioda_pe *pe = pnv_ioda_get_pe(pdev);
> >       struct pci_dn *pdn = pci_get_pdn(pdev);
> > -     struct pnv_ioda_pe *pe;
> >
> >       /* The VF PE state is torn down when sriov_disable() is called */
> >       if (pdev->is_virtfn)
> >               return;
> >
> > -     if (!pdn || pdn->pe_number == IODA_INVALID_PE)
> > +     if (WARN_ON(!pe))
>
>
> Is that WARN_ON because there is always a PE - from upstream bridge or a

The device should always belong to a PE. If it doesn't (at this point)
then something deeply strange has happened.

> reserved one?

If it's associated with the reserved PE the rmap is set to
IODA_PE_INVALID, so would return NULL and we'd hit the WARN_ON(). I
think that's ok though since PE assignment should always succeed. If
it failed, or we're tearing down the device before we got to the point
of assigning a PE then there's probably a bug.


More information about the Linuxppc-dev mailing list