On Fri, 2015-23-10 at 06:19:46 UTC, Andrew Donnellan wrote: > In eeh_pci_enable(), after making the request to set the new options, we > call eeh_ops->wait_state() to check that the request finished successfully. > > At the moment, if eeh_ops->wait_state() returns 0, we return 0 without > checking that it reflects the expected outcome. This can lead to callers > further up the chain incorrectly assuming the slot has been successfully > unfrozen and continuing to attempt recovery. > > On powernv, this will occur if pnv_eeh_get_pe_state() or > pnv_eeh_get_phb_state() return 0, which in turn occurs if the relevant OPAL > call returns OPAL_EEH_STOPPED_MMIO_DMA_FREEZE or > OPAL_EEH_PHB_ERROR respectively. > > On pseries, this will occur if pseries_eeh_get_state() returns 0, which in > turn occurs if RTAS reports that the PE is in the MMIO Stopped and DMA > Stopped states. > > Obviously, none of these cases represent a successful completion of a > request to thaw MMIO or DMA. > > Fix the check so that a wait_state() return value of 0 won't be considered > successful for the EEH_OPT_THAW_MMIO or EEH_OPT_THAW_DMA cases. > > Cc: Gavin Shan <gws...@linux.vnet.ibm.com> > Signed-off-by: Andrew Donnellan <andrew.donnel...@au1.ibm.com> > Acked-by: Gavin Shan <gws...@linux.vnet.ibm.com> > Reviewed-by: Daniel Axtens <d...@axtens.net> > Reviewed-by: Daniel Axtens <d...@axtens.net>
Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/949e9b827eb4736d96df520c67 cheers _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
