summaryrefslogtreecommitdiffstats
path: root/drivers/s390/crypto/zcrypt_cex4.c
AgeCommit message (Collapse)Author
2016-12-14s390/zcrypt: add multi domain supportIngo Tuchscherer
Currently the ap infrastructure only supports one domain at a time. This feature extends the generic cryptographic device driver to support multiple cryptographic domains simultaneously. There are now card and queue devices on the AP bus with independent card and queue drivers. The new /sys layout is as follows: /sys/bus/ap devices <xx>.<yyyy> -> ../../../devices/ap/card<xx>/<xx>.<yyyy> ... card<xx> -> ../../../devices/ap/card<xx> ... drivers <drv>card card<xx> -> ../../../../devices/ap/card<xx> <drv>queue <xx>.<yyyy> -> ../../../../devices/ap/card<xx>/<xx>.<yyyy> ... /sys/devices/ap card<xx> <xx>.<yyyy> driver -> ../../../../bus/ap/drivers/<zzz>queue ... driver -> ../../../bus/ap/drivers/<drv>card ... The two digit <xx> field is the card number, the four digit <yyyy> field is the queue number and <drv> is the name of the device driver, e.g. "cex4". For compatability /sys/bus/ap/card<xx> for the old layout has to exist, including the attributes that used to reside there. With additional contributions from Harald Freudenberger and Martin Schwidefsky. Signed-off-by: Ingo Tuchscherer <ingo.tuchscherer@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2016-12-14s390/zcrypt: Introduce workload balancingIngo Tuchscherer
Crypto requests are very different in complexity and thus runtime. Also various crypto adapters are differ with regard to the execution time. Crypto requests can be balanced much better when the request type and eligible crypto adapters are rated in a more precise granularity. Therefore, request weights and adapter speed rates for dedicated requests will be introduced. Signed-off-by: Ingo Tuchscherer <ingo.tuchscherer@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2016-12-14s390/zcrypt: simplify message type handlingMartin Schwidefsky
Now that the message type modules are linked with the zcrypt_api into a single module the zcrypt_ops_list is initialized by the module init function of the zcyppt.ko module. After that the list is static and all message types are present. Drop the zcrypt_ops_list_lock spinlock and the module handling in regard to the message types. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2016-07-31s390/zcrypt: Fix zcrypt suspend/resume behaviorIngo Tuchscherer
The device suspend call triggers all ap devices to fetch potentially available response messages from the queues. Therefore the corresponding zcrypt device, that is allocated asynchronously after ap device probing, needs to be fully prepared. This race condition could lead to uninitialized response buffers while trying to read from the queues. Introduce a new callback within the ap layer to get noticed when a zcrypt device is fully prepared. Additional checks prevent reading from devices that are not fully prepared. Signed-off-by: Ingo Tuchscherer <ingo.tuchscherer@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-06-25s390/zcrypt: Fixed reset and interrupt handling of AP queuesIngo Tuchscherer
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>
2015-01-23s390/zcrypt: Add support for new crypto express (CEX5S) adapter.Ingo Tuchscherer
Extends the generic cryptographic device driver (zcrypt) to support the Crypto Express 5S adapter. Signed-off-by: Ingo Tuchscherer <ingo.tuchscherer@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2013-12-18s390/zcrypt: add support for EP11 coprocessor cardsIngo Tuchscherer
This feature extends the generic cryptographic device driver (zcrypt) with a new capability to service EP11 requests for the Crypto Express4S card in EP11 (Enterprise PKCS#11 mode) coprocessor mode. Signed-off-by: Ingo Tuchscherer <ingo.tuchscherer@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2012-09-26s390/zcrypt: Add support for CEX4 crypto cardHolger Dengler
New zcrypt module supports IBM CryptoExpress 4 cards. Signed-off-by: Holger Dengler <hd@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>