s390/zcrypt: Fixed reset and interrupt handling of AP queues

In case of request timeouts an AP queue reset will be triggered to
recover and reinitialize the AP queue. The previous behavior was an
immediate reset execution regardless of current/pending requests.
Due to newly changed firmware behavior the reset may be delayed, based
on the priority of pending request. The device driver's waiting time
frame was limited, hence it did not received the reset response. As a
consequence interrupts would not be enabled afterwards.

The RAPQ (queue reset) and AQIC (interrupt control) commands will be
treated fully asynchronous now. The device driver will check the reset and
interrupt states periodically, thus it can handle the reinitialization
properly.

Signed-off-by: Ingo Tuchscherer <ingo.tuchscherer@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
This commit is contained in:
Ingo Tuchscherer
2015-06-17 16:19:15 +02:00
committed by Martin Schwidefsky
parent 3c8e5105e7
commit c50a160c17
3 changed files with 239 additions and 200 deletions

View File

@@ -39,7 +39,7 @@
* But the maximum time limit managed by the stomper code is set to 60sec.
* Hence we have to wait at least that time period.
*/
#define CEX4_CLEANUP_TIME (61*HZ)
#define CEX4_CLEANUP_TIME (900*HZ)
static struct ap_device_id zcrypt_cex4_ids[] = {
{ AP_DEVICE(AP_DEVICE_TYPE_CEX4) },