[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