I am trying to rewrite a AES HW crypto driver based on old code from the kernel v2.6 era. The old code was using the blkcipher API, but I feel that it would make more sense to have a HW engine using at least Async (ablkciper). Going this route, the choice would be to use the skcipher API which should make my code conform with the "latest" standards.

I would like to use the crypt-engine to handle queue requests etc. What is not clear to me is how to get a new request to process before I return the result from the previous request. My hardware is not completely autonomous, but can use PDMA to process the input and output. Using interrupts to notify process complete, but also input buffer empty. I would like to use the last one to start a new request even before the previous request is completely processed.

What would be the best practice to implement such a driver? I have already looked over the code for atmel-aes, omap-aes and the marvel and mediatek solutions. All have different approaches to this problem.

The resulting "frame-work" would be the basis for my next project, so I would like to be as generic as possible. Any advice will be appreciated.

Okay, so I will start writing my own replies.

After spending a lot of time on research for this little project I found the following:

* ablkcipher is depreciated over the skcipher

* crypto_engine is only available since kernel v4.6

* crypto_engine does NOT! allow the use of skcipher_request (even there was a patch in June 2017)

Rewriting the code to use ablkcipher now...or I may end up writing the queue-handling from the crypto-engine in my own driver!!

How do developers even keep up with all the API changes and which patches for merged and not??

Crypto is one area where the programmer requires a lot of experience specifically in cryptography. To keep track of changes, you have to read all the changelogs.