On Wed, Nov 27, 2019 at 4:24 PM Alexey Kardashevskiy <a...@ozlabs.ru> wrote: > > > > On 20/11/2019 12:28, Oliver O'Halloran wrote: > > Signed-off-by: Oliver O'Halloran <ooh...@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.