kernel/linux.git/drivers/crypto/marvell/cipher.c, branch linux-4.20.y

crypto: marvell - Switch cipher algs to the skcipher interface

2017-11-03T13:53:32+00:00

crypto_alg is not supposed to be directly implemented by crypto engine driver. Drivers should instead implement specialized interfaces like ahash_alg or skcipher_alg. Migrate to all cipher algorithms to the skcipher_alg interface. While at it, get rid of all references to ablkcipher including in internal struct or function names. Signed-off-by: Boris Brezillon Signed-off-by: Herbert Xu

crypto: marvell - Use an unique pool to copy results of requests

2016-10-21T03:03:40+00:00

So far, we used a dedicated dma pool to copy the result of outer IV for cipher requests. Instead of using a dma pool per outer data, we prefer use the op dma pool that contains all part of the request from the SRAM. Then, the outer data that is likely to be used by the 'complete' operation, is copied later. In this way, any type of result can be retrieved by DMA for cipher or ahash requests. Signed-off-by: Romain Perier Acked-by: Boris Brezillon Signed-off-by: Herbert Xu

crypto: marvell - Don't copy IV vectors from the _process op for ciphers

2016-07-29T10:30:17+00:00

The IV output vectors should only be copied from the _complete operation and not from the _process operation, i.e only from the operation that is designed to copy the result of the request to the right location. This copy is already done in the _complete operation, so this commit removes the duplicated code in the _process op. Fixes: 3610d6cd5231 ("crypto: marvell - Add a complete...") Signed-off-by: Romain Perier Acked-by: Boris Brezillon Signed-off-by: Herbert Xu

crypto: marvell - Fix memory leaks in TDMA chain for cipher requests

2016-07-28T05:04:42+00:00

So far in mv_cesa_ablkcipher_dma_req_init, if an error is thrown while the tdma chain is built there is a memory leak. This issue exists because the chain is assigned later at the end of the function, so the cleanup function is called with the wrong version of the chain. Fixes: db509a45339f ("crypto: marvell/cesa - add TDMA support") Signed-off-by: Romain Perier Acked-by: Boris Brezillon Signed-off-by: Herbert Xu

crypto: marvell - Add support for chaining crypto requests in TDMA mode

2016-06-23T10:29:51+00:00

The Cryptographic Engines and Security Accelerators (CESA) supports the Multi-Packet Chain Mode. With this mode enabled, multiple tdma requests can be chained and processed by the hardware without software intervention. This mode was already activated, however the crypto requests were not chained together. By doing so, we reduce significantly the number of IRQs. Instead of being interrupted at the end of each crypto request, we are interrupted at the end of the last cryptographic request processed by the engine. This commits re-factorizes the code, changes the code architecture and adds the required data structures to chain cryptographic requests together before sending them to an engine (stopped or possibly already running). Signed-off-by: Romain Perier Acked-by: Boris Brezillon Signed-off-by: Herbert Xu

crypto: marvell - Add load balancing between engines

2016-06-23T10:29:51+00:00

This commits adds support for fine grained load balancing on multi-engine IPs. The engine is pre-selected based on its current load and on the weight of the crypto request that is about to be processed. The global crypto queue is also moved to each engine. These changes are required to allow chaining crypto requests at the DMA level. By using a crypto queue per engine, we make sure that we keep the state of the tdma chain synchronized with the crypto queue. We also reduce contention on 'cesa_dev->lock' and improve parallelism. Signed-off-by: Romain Perier Acked-by: Boris Brezillon Signed-off-by: Herbert Xu

crypto: marvell - Move SRAM I/O operations to step functions

2016-06-23T10:17:25+00:00

Currently the crypto requests were sent to engines sequentially. This commit moves the SRAM I/O operations from the prepare to the step functions. It provides flexibility for future works and allow to prepare a request while the engine is running. Signed-off-by: Romain Perier Acked-by: Boris Brezillon Signed-off-by: Herbert Xu

crypto: marvell - Add a complete operation for async requests

2016-06-23T10:17:24+00:00

So far, the 'process' operation was used to check if the current request was correctly handled by the engine, if it was the case it copied information from the SRAM to the main memory. Now, we split this operation. We keep the 'process' operation, which still checks if the request was correctly handled by the engine or not, then we add a new operation for completion. The 'complete' method copies the content of the SRAM to memory. This will soon become useful if we want to call the process and the complete operations from different locations depending on the type of the request (different cleanup logic). Signed-off-by: Romain Perier Acked-by: Boris Brezillon Signed-off-by: Herbert Xu

crypto: marvell - Move tdma chain out of mv_cesa_tdma_req and remove it

2016-06-23T10:17:23+00:00

Currently, the only way to access the tdma chain is to use the 'req' union from a mv_cesa_{ablkcipher,ahash}. This will soon become a problem if we want to handle the TDMA chaining vs standard/non-DMA processing in a generic way (with generic functions at the cesa.c level detecting whether the request should be queued at the DMA level or not). Hence the decision to move the chain field a the mv_cesa_req level at the expense of adding 2 void * fields to all request contexts (including non-DMA ones) and to remove the type completly. To limit the overhead, we get rid of the type field, which can now be deduced from the req->chain.first value. Once these changes are done the union is no longer needed, so remove it and move mv_cesa_ablkcipher_std_req and mv_cesa_req to mv_cesa_ablkcipher_req directly. There are also no needs to keep the 'base' field into the union of mv_cesa_ahash_req, so move it into the upper structure. Signed-off-by: Romain Perier Acked-by: Boris Brezillon Signed-off-by: Herbert Xu

crypto: marvell - Copy IV vectors by DMA transfers for acipher requests

2016-06-23T10:14:03+00:00

Add a TDMA descriptor at the end of the request for copying the output IV vector via a DMA transfer. This is a good way for offloading as much as processing as possible to the DMA and the crypto engine. This is also required for processing multiple cipher requests in chained mode, otherwise the content of the IV vector would be overwritten by the last processed request. Signed-off-by: Romain Perier Acked-by: Boris Brezillon Signed-off-by: Herbert Xu