diff options
| author | Tony Krowiak <akrowiak@linux.ibm.com> | 2023-08-15 14:43:24 -0400 |
|---|---|---|
| committer | Heiko Carstens <hca@linux.ibm.com> | 2023-08-18 15:09:28 +0200 |
| commit | 411b0109daa52d1cc5be39635631e22a5590c5d8 (patch) | |
| tree | 4bb8a0062a267dd6a62f852bb7f9d9bfb6e9cd88 /drivers/s390/crypto | |
| parent | 7aa7b2a80cb70d528785f06a54d6c8148826006d (diff) | |
s390/vfio-ap: wait for response code 05 to clear on queue reset
Response code 05, AP busy, is a valid response code for a ZAPQ or TAPQ.
Instead of returning error -EIO when a ZAPQ fails with response code 05,
let's wait until the queue is no longer busy and try the ZAPQ again.
Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>
Acked-by: Janosch Frank <frankja@linux.ibm.com>
Tested-by: Viktor Mihajlovski <mihajlov@linux.ibm.com>
Link: https://lore.kernel.org/r/20230815184333.6554-4-akrowiak@linux.ibm.com
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Diffstat (limited to 'drivers/s390/crypto')
| -rw-r--r-- | drivers/s390/crypto/vfio_ap_ops.c | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c index be92ba45226d..3f67cfb53d0c 100644 --- a/drivers/s390/crypto/vfio_ap_ops.c +++ b/drivers/s390/crypto/vfio_ap_ops.c @@ -1611,6 +1611,7 @@ static int apq_status_check(int apqn, struct ap_queue_status *status) case AP_RESPONSE_DECONFIGURED: return 0; case AP_RESPONSE_RESET_IN_PROGRESS: + case AP_RESPONSE_BUSY: return -EBUSY; default: WARN(true, @@ -1663,6 +1664,7 @@ retry_zapq: } break; case AP_RESPONSE_RESET_IN_PROGRESS: + case AP_RESPONSE_BUSY: /* * There is a reset issued by another process in progress. Let's wait * for that to complete. Since we have no idea whether it was a RAPQ or |