s390/qdio: consistently restore the IRQ handler
authorJulian Wiedmann <jwi@linux.ibm.com>
Thu, 9 Apr 2020 08:55:16 +0000 (10:55 +0200)
committerVasily Gorbik <gor@linux.ibm.com>
Tue, 28 Apr 2020 11:49:47 +0000 (13:49 +0200)
commit7b942b4be971d49cb185ce4690d7fbf94636e88a
tree037e1821509496f7adc23558d4b2f9452a2176cf
parentde267a7c71ba6be7857da0185871759067513d9c
s390/qdio: consistently restore the IRQ handler

For rolling back after an error, qdio_establish() calls qdio_shutdown().
If the error occurs early enough, then the qdio_irq's state still is
QDIO_IRQ_STATE_INACTIVE and qdio_shutdown() does nothing.

But at _any_ point where qdio_establish() bails out in this way,
qdio_setup_irq() will have already replaced the IRQ handler. This then
won't be restored after an early error, and the device can end up being
returned to the device driver with qdio's IRQ handler still installed.

Slightly reorder qdio_setup_irq() so we can be 100% sure that the IRQ
handler was replaced. Then fix the bug in qdio_establish() by calling a
helper that rolls back only the IRQ handler modification.

Also use the new helper in qdio_shutdown() to keep things in sync, and
slightly clean up the locking while doing so.
This makes minor semantical changes, but holding setup_mutex gives us
sufficient leeway to eg. pull qdio_shutdown_thinint() outside of the
ccwdev lock's scope.

Fixes: 779e6e1c724d ("[S390] qdio: new qdio driver.")
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
drivers/s390/cio/qdio.h
drivers/s390/cio/qdio_main.c
drivers/s390/cio/qdio_setup.c