mbox series

[v2,0/6] crypto: engine - Permit to enqueue all async requests

Message ID 20180126191534.17569-1-clabbe.montjoie@gmail.com
Headers show
Series crypto: engine - Permit to enqueue all async requests | expand

Message

Corentin Labbe Jan. 26, 2018, 7:15 p.m. UTC
Hello

The current crypto_engine support only ahash and ablkcipher request.
My first patch which try to add skcipher was Nacked, it will add too many functions
and adding other algs(aead, asymetric_key) will make the situation worst.

This patchset remove all algs specific stuff and now only process generic crypto_async_request.

The requests handler function pointer are now moved out of struct engine and
are now stored directly in a crypto_engine_reqctx.

The original proposal of Herbert [1] cannot be done completly since the crypto_engine
could only dequeue crypto_async_request and it is impossible to access any request_ctx
without knowing the underlying request type.

So I do something near that was requested: adding crypto_engine_reqctx in TFM context.
Note that the current implementation expect that crypto_engine_reqctx
is the first member of the context.

The first patch is a try to document the crypto engine API.
The second patch convert the crypto engine with the new way,
while the following patchs convert the 4 existing users of crypto_engine.
Note that this split break bisection, so probably the final commit will be all merged.

Appart from virtio, all 4 latest patch were compile tested only.
But the crypto engine is tested with my new sun8i-ce driver.

Regards

[1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1474434.html

Changes since V1:
- renamed crypto_engine_reqctx to crypto_engine_ctx
- indentation fix in function parameter
- do not export crypto_transfer_request
- Add aead support
- crypto_finalize_request is now static

Changes since RFC:
- Added a documentation patch
- Added patch for stm32-cryp
- Changed parameter of all crypto_engine_op functions from
	crypto_async_request to void*
- Reintroduced crypto_transfer_xxx_request_to_engine functions

Corentin Labbe (6):
  Documentation: crypto: document crypto engine API
  crypto: engine - Permit to enqueue all async requests
  crypto: omap: convert to new crypto engine API
  crypto: virtio: convert to new crypto engine API
  crypto: stm32-hash: convert to the new crypto engine API
  crypto: stm32-cryp: convert to the new crypto engine API

 Documentation/crypto/crypto_engine.rst       |  48 +++++
 crypto/crypto_engine.c                       | 301 +++++++++++++++------------
 drivers/crypto/omap-aes.c                    |  21 +-
 drivers/crypto/omap-aes.h                    |   3 +
 drivers/crypto/omap-des.c                    |  24 ++-
 drivers/crypto/stm32/stm32-cryp.c            |  29 ++-
 drivers/crypto/stm32/stm32-hash.c            |  20 +-
 drivers/crypto/virtio/virtio_crypto_algs.c   |  16 +-
 drivers/crypto/virtio/virtio_crypto_common.h |   3 +-
 drivers/crypto/virtio/virtio_crypto_core.c   |   3 -
 include/crypto/engine.h                      |  68 +++---
 11 files changed, 332 insertions(+), 204 deletions(-)
 create mode 100644 Documentation/crypto/crypto_engine.rst

-- 
2.13.6

Comments

Corentin Labbe Feb. 16, 2018, 3:36 p.m. UTC | #1
On Thu, Feb 15, 2018 at 11:51:00PM +0800, Herbert Xu wrote:
> On Fri, Jan 26, 2018 at 08:15:28PM +0100, Corentin Labbe wrote:

> > Hello

> > 

> > The current crypto_engine support only ahash and ablkcipher request.

> > My first patch which try to add skcipher was Nacked, it will add too many functions

> > and adding other algs(aead, asymetric_key) will make the situation worst.

> > 

> > This patchset remove all algs specific stuff and now only process generic crypto_async_request.

> > 

> > The requests handler function pointer are now moved out of struct engine and

> > are now stored directly in a crypto_engine_reqctx.

> > 

> > The original proposal of Herbert [1] cannot be done completly since the crypto_engine

> > could only dequeue crypto_async_request and it is impossible to access any request_ctx

> > without knowing the underlying request type.

> > 

> > So I do something near that was requested: adding crypto_engine_reqctx in TFM context.

> > Note that the current implementation expect that crypto_engine_reqctx

> > is the first member of the context.

> > 

> > The first patch is a try to document the crypto engine API.

> > The second patch convert the crypto engine with the new way,

> > while the following patchs convert the 4 existing users of crypto_engine.

> > Note that this split break bisection, so probably the final commit will be all merged.

> > 

> > Appart from virtio, all 4 latest patch were compile tested only.

> > But the crypto engine is tested with my new sun8i-ce driver.

> > 

> > Regards

> > 

> > [1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1474434.html

> > 

> > Changes since V1:

> > - renamed crypto_engine_reqctx to crypto_engine_ctx

> > - indentation fix in function parameter

> > - do not export crypto_transfer_request

> > - Add aead support

> > - crypto_finalize_request is now static

> > 

> > Changes since RFC:

> > - Added a documentation patch

> > - Added patch for stm32-cryp

> > - Changed parameter of all crypto_engine_op functions from

> > 	crypto_async_request to void*

> > - Reintroduced crypto_transfer_xxx_request_to_engine functions

> > 

> > Corentin Labbe (6):

> >   Documentation: crypto: document crypto engine API

> >   crypto: engine - Permit to enqueue all async requests

> >   crypto: omap: convert to new crypto engine API

> >   crypto: virtio: convert to new crypto engine API

> >   crypto: stm32-hash: convert to the new crypto engine API

> >   crypto: stm32-cryp: convert to the new crypto engine API

> 

> All applied.  Thanks.


Hello

As mentionned in the cover letter, all patchs (except documentation one) should be squashed.
A kbuild robot reported a build error on cryptodev due to this.

Regards
Herbert Xu Feb. 17, 2018, 4:42 a.m. UTC | #2
On Fri, Feb 16, 2018 at 04:36:56PM +0100, Corentin Labbe wrote:
>

> As mentionned in the cover letter, all patchs (except documentation one) should be squashed.

> A kbuild robot reported a build error on cryptodev due to this.


It's too late now.  In future if you want the patches to be squashed
then please send them in one email.

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt