summaryrefslogtreecommitdiff
path: root/drivers/s390/crypto
diff options
context:
space:
mode:
authorTony Krowiak <akrowiak@linux.ibm.com>2023-08-15 14:43:24 -0400
committerHeiko Carstens <hca@linux.ibm.com>2023-08-18 15:09:28 +0200
commit411b0109daa52d1cc5be39635631e22a5590c5d8 (patch)
tree4bb8a0062a267dd6a62f852bb7f9d9bfb6e9cd88 /drivers/s390/crypto
parent7aa7b2a80cb70d528785f06a54d6c8148826006d (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.c2
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