Searched hist:"8256 adda1f44ea1ec763711aefcd25f8c0cf93f3" (Results 1 – 2 of 2) sorted by relevance
| /linux/arch/s390/include/asm/ |
| H A D | pci.h | diff 8256adda1f44ea1ec763711aefcd25f8c0cf93f3 Thu Jul 22 12:38:29 CEST 2021 Niklas Schnelle <schnelle@linux.ibm.com> s390/pci: handle FH state mismatch only on disable
Instead of always treating CLP_RC_SETPCIFN_ALRDY as success and blindly
updating the function handle restrict this special handling to the
disable case by moving it into zpci_disable_device() and still treating
it as an error while also updating the function handle such that
a subsequent zpci_disable_device() succeeds or the caller can ignore the
error when aborting is not an option such as for zPCI event 0x304.
Also print this occurrence to the log such that an admin can tell why
a disable operation returned an error.
A mismatch between the state of the underlying device and our view of it
can naturally happen when the device suddenly enters the error state but
we haven't gotten the error notification yet, it must not happen on
enable though.
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
|
| /linux/arch/s390/pci/ |
| H A D | pci.c | diff 8256adda1f44ea1ec763711aefcd25f8c0cf93f3 Thu Jul 22 12:38:29 CEST 2021 Niklas Schnelle <schnelle@linux.ibm.com> s390/pci: handle FH state mismatch only on disable
Instead of always treating CLP_RC_SETPCIFN_ALRDY as success and blindly
updating the function handle restrict this special handling to the
disable case by moving it into zpci_disable_device() and still treating
it as an error while also updating the function handle such that
a subsequent zpci_disable_device() succeeds or the caller can ignore the
error when aborting is not an option such as for zPCI event 0x304.
Also print this occurrence to the log such that an admin can tell why
a disable operation returned an error.
A mismatch between the state of the underlying device and our view of it
can naturally happen when the device suddenly enters the error state but
we haven't gotten the error notification yet, it must not happen on
enable though.
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
|