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:

committed by
Martin Schwidefsky

parent
3c8e5105e7
commit
c50a160c17
@@ -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) },
|
||||
|
Reference in New Issue
Block a user