diff options
author | Julian Wiedmann | 2020-04-09 10:55:16 +0200 |
---|---|---|
committer | Vasily Gorbik | 2020-04-28 13:49:47 +0200 |
commit | 7b942b4be971d49cb185ce4690d7fbf94636e88a (patch) | |
tree | 037e1821509496f7adc23558d4b2f9452a2176cf /drivers/soc/versatile | |
parent | de267a7c71ba6be7857da0185871759067513d9c (diff) |
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>
Diffstat (limited to 'drivers/soc/versatile')
0 files changed, 0 insertions, 0 deletions