linux/drivers/crypto/Makefile, branch v5.7

crypto: marvell - create common Kconfig and Makefile for Marvell

2020-03-20T03:36:51Z

Creats common Kconfig and Makefile for Marvell crypto drivers. Signed-off-by: SrujanaChalla Signed-off-by: Herbert Xu

crypto: xilinx - Add Xilinx AES driver

2020-02-28T00:36:46Z

This patch adds AES driver support for the Xilinx ZynqMP SoC. Signed-off-by: Mohan Marutirao Dhanawade Signed-off-by: Kalyani Akula Acked-by: Michal Simek Signed-off-by: Herbert Xu

crypto: sun4i-ss - Move to Allwinner directory

2019-11-01T05:38:31Z

Since we have a dedicated Allwinner directory for crypto driver, move the sun4i-ss driver in it. Acked-by: Maxime Ripard Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu

crypto: allwinner - Add allwinner subdirectory

2019-11-01T05:38:31Z

Since a second Allwinner crypto driver will be added, it is better to create a dedicated subdirectory. Acked-by: Maxime Ripard Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu

crypto: amlogic - Add crypto accelerator for amlogic GXL

2019-10-25T15:09:58Z

This patch adds support for the amlogic GXL cryptographic offloader present on GXL SoCs. This driver supports AES cipher in CBC/ECB mode. Signed-off-by: Corentin Labbe Reviewed-by: Neil Armstrong Signed-off-by: Herbert Xu

crypto: atmel-i2c - add support for SHA204A random number generator

2019-05-30T07:35:45Z

The Linaro/96boards Secure96 mezzanine contains (among other things) an Atmel SHA204A symmetric crypto processor. This chip implements a number of different functionalities, but one that is highly useful for many different 96boards platforms is the random number generator. So let's implement a driver for the SHA204A, and for the time being, implement support for the random number generator only. Reviewed-by: Linus Walleij Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu

crypto: atmel-ecc - factor out code that can be shared

2019-05-30T07:35:45Z

In preparation of adding support for the random number generator in Atmel atsha204a devices, refactor the existing atmel-ecc driver (which drives hardware that is closely related) so we can share the basic I2C and command queuing routines. Reviewed-by: Linus Walleij Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu

crypto: mxc-scc - Remove broken driver

2019-04-16T01:03:08Z

This driver has been completely broken since the very beginning because it doesn't even have a setkey function. This means that nobody has ever used it as it would crash during setkey. This patch removes this driver. Fixes: d293b640ebd5 ("crypto: mxc-scc - add basic driver for the...") Signed-off-by: Herbert Xu

crypto: caam/qi2 - add DPAA2-CAAM driver

2018-09-21T05:24:51Z

Add CAAM driver that works using the DPSECI backend, i.e. manages DPSECI DPAA2 objects sitting on the Management Complex (MC) fsl-mc bus. Data transfers (crypto requests) are sent/received to/from CAAM crypto engine via Queue Interface (v2), this being similar to existing caam/qi. OTOH, configuration/setup (obtaining virtual queue IDs, authorization etc.) is done by sending commands to the MC f/w. Note that the CAAM accelerator included in DPAA2 platforms still has Job Rings. However, the driver being added does not handle access via this backend. Kconfig & Makefile are updated such that DPAA2-CAAM (a.k.a. "caam/qi2") driver does not depend on caam/jr or caam/qi backends - which rely on platform bus support (ctrl.c). Support for the following aead and authenc algorithms is also added in this patch: -aead: gcm(aes) rfc4106(gcm(aes)) rfc4543(gcm(aes)) -authenc: authenc(hmac({md5,sha*}),cbc({aes,des,des3_ede})) echainiv(authenc(hmac({md5,sha*}),cbc({aes,des,des3_ede}))) authenc(hmac({md5,sha*}),rfc3686(ctr(aes)) seqiv(authenc(hmac({md5,sha*}),rfc3686(ctr(aes))) Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: hisilicon - SEC security accelerator driver

2018-08-03T10:06:02Z

This accelerator is found inside hisilicon hip06 and hip07 SoCs. Each instance provides a number of queues which feed a different number of backend acceleration units. The queues are operating in an out of order mode in the interests of throughput. The silicon does not do tracking of dependencies between multiple 'messages' or update of the IVs as appropriate for training. Hence where relevant we need to do this in software. Signed-off-by: Jonathan Cameron Signed-off-by: Herbert Xu