aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/s390/cio/device.c
diff options
context:
space:
mode:
authorNiklas Schnelle <schnelle@linux.ibm.com>2021-09-07 16:43:29 +0200
committerVasily Gorbik <gor@linux.ibm.com>2021-10-04 09:49:36 +0200
commit1c8174fdc798489159a79466fca782daa231219a (patch)
tree6913106928ed29c2ca6b16cb4c45b43076027f6f /drivers/s390/cio/device.c
parents390/kprobes: add sanity check (diff)
downloadlinux-dev-1c8174fdc798489159a79466fca782daa231219a.tar.xz
linux-dev-1c8174fdc798489159a79466fca782daa231219a.zip
s390/pci: tolerate inconsistent handle in recover
Since commit 8256adda1f44 ("s390/pci: handle FH state mismatch only on disable") zpci_disable_device() returns -EINVAL when the platform detects an attempt to disable a PCI function that it sees as already disabled. In most situations we want to abort whenever this happens and abort is possible since it either means that the device vanished but we haven't gotten an availability event yet, or the FH got out of sync which should not happen. Unfortunately there is an inconsistency between the LPAR and z/VM hypervisors on whether error events for PCI functions contain an an enabled or a general handle. So under z/VM it can happen that our most up to date function handle is enabled but trying to disable the function results in the aforementioned error. Since recover is designed to be used to recover functions from the error state let's make it robust to this inconsistency by explicitly treating it as a successful disable. Acked-by: Pierre Morel <pmorel@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Diffstat (limited to 'drivers/s390/cio/device.c')
0 files changed, 0 insertions, 0 deletions