linux-stable.git/arch/powerpc/kernel/eeh.c, branch linux-4.7.y

Revert "powerpc/eeh: Fix crash in eeh_add_device_early() on Cell"

2016-05-12T09:52:21+00:00

This reverts commit 89a51df5ab1d38b257300b8ac940bbac3bb0eb9b.

The function eeh_add_device_early() is used to perform EEH
initialization in devices added later on the system, like in
hotplug/DLPAR scenarios. Since the commit 89a51df5ab1d ("powerpc/eeh:
Fix crash in eeh_add_device_early() on Cell") a new check was introduced
in this function - Cell has no EEH capabilities which led to kernel oops
if hotplug was performed, so checking for eeh_enabled() was introduced
to avoid the issue.

However, in architectures that EEH is present like pSeries or PowerNV,
we might reach a case in which no PCI devices are present on boot time
and so EEH is not initialized. Then, if a device is added via DLPAR for
example, eeh_add_device_early() fails because eeh_enabled() is false,
and EEH end up not being enabled at all.

This reverts the aforementioned patch since a new verification was
introduced by the commit d91dafc02f42 ("powerpc/eeh: Delay probing EEH
device during hotplug") and so the original Cell issue does not happen
anymore.

Cc: stable@vger.kernel.org # v4.1+
Reviewed-by: Gavin Shan 
Signed-off-by: Guilherme G. Piccoli 
Signed-off-by: Michael Ellerman

powerpc/eeh: Drop unnecessary label in eeh_pe_change_owner()

2016-05-12T09:52:20+00:00

The label "reset" in eeh_pe_change_owner() is used only for once.
No need to keep it and just drop it. No logical changes introduced.

Signed-off-by: Gavin Shan 
Reviewed-by: David Gibson 
Reviewed-by: Russell Currey 
Signed-off-by: Michael Ellerman

powerpc/eeh: rename EEH from "extended" to "enhanced" error handling

2016-04-11T10:30:42+00:00

IBM online documentation for EEH uses "extended error handling" and
"enhanced error handling" to refer to the same thing, in different
places.  The only place mentioning it as "enhanced error handling" in the
kernel is the MAINTAINERS file, and it's "extended" in some documentation.

IBM originally defined EEH as "enhanced error handling", so standardise
all mentions of EEH to use that term.

Signed-off-by: Russell Currey 
Acked-by: Gavin Shan 
Signed-off-by: Michael Ellerman

powerpc/eeh: eeh_pci_enable(): fix checking of post-request state

2016-03-09T00:33:30+00:00

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.

Signed-off-by: Andrew Donnellan 
Acked-by: Gavin Shan 
Reviewed-by: Daniel Axtens 
Signed-off-by: Michael Ellerman

powerpc/eeh: Remove duplicated check in eeh_dump_pe_log()

2016-03-08T23:25:35+00:00

When eeh_dump_pe_log() is only called by eeh_slot_error_detail(),
we already have the check that the PE isn't in PCI config blocked
state in eeh_slot_error_detail(). So we needn't the duplicated
check in eeh_dump_pe_log().

This removes the duplicated check in eeh_dump_pe_log(). No logical
changes introduced.

Signed-off-by: Gavin Shan 
Reviewed-by: Andrew Donnellan 
Signed-off-by: Michael Ellerman

powerpc/eeh: Synchronize recovery in host/guest

2016-03-08T22:58:28+00:00

When passing through SRIOV VFs to guest, we possibly encounter EEH
error on PF. In this case, the VF PEs are put into frozen state.
The error could be reported to guest before it's captured by the
host. That means the guest could attempt to recover errors on VFs
before host gets chance to recover errors on PFs. The VFs won't be
recovered successfully.

This enforces the recovery order for above case: the recovery on
child PE in guest is hold until the recovery on parent PE in host
is completed.

Signed-off-by: Gavin Shan 
Reviewed-by: Russell Currey 
Signed-off-by: Michael Ellerman

powerpc/eeh: powerpc/eeh: Support error recovery for VF PE

2016-03-08T22:58:23+00:00

PFs are enumerated on PCI bus, while VFs are created by PF's driver.

In EEH recovery, it has two cases:
1. Device and driver is EEH aware, error handlers are called.
2. Device and driver is not EEH aware, un-plug the device and plug it again
by enumerating it.

The special thing happens on the second case. For a PF, we could use the
original pci core to enumerate the bus, while for VF we need to record the
VFs which aer un-plugged then plug it again.

Also The patch caches the VF index in pci_dn, which can be used to
calculate VF's bus, device and function number. Those information helps to
locate the VF's PCI device instance when doing hotplug during EEH recovery
if necessary.

Signed-off-by: Wei Yang 
Acked-by: Gavin Shan 
Signed-off-by: Michael Ellerman

powerpc/powernv: Support EEH reset for VF PE

2016-03-08T22:58:21+00:00

PEs for VFs don't have primary bus. So they have to have their own reset
backend, which is used during EEH recovery. The patch implements the reset
backend for VF's PE by issuing FLR or AF FLR to the VFs, which are contained
in the PE.

Signed-off-by: Wei Yang 
Acked-by: Gavin Shan 
Signed-off-by: Michael Ellerman

powerpc/eeh: fix incorrect function name in comment

2016-02-08T11:34:59+00:00

The comment block above pcibios_set_pcie_reset_state() incorrectly refers
to pcibios_set_pcie_slot_reset(). Fix the comment accordingly.

Signed-off-by: Andrew Donnellan 
Acked-by: Gavin Shan 
Signed-off-by: Michael Ellerman

powerpc/eeh: More relaxed condition for enabled IO path

2015-10-21T09:41:43+00:00

When one or both of the below two flags are marked in the PE state, the
PE's IO path is regarded as enabled: EEH_STATE_MMIO_ACTIVE or
EEH_STATE_MMIO_ENABLED.

Signed-off-by: Gavin Shan 
Signed-off-by: Michael Ellerman