talos-op-linux/drivers/crypto/Kconfig, branch v4.3

crypto: vmx - VMX crypto should depend on CONFIG_VSX

2015-09-10T09:22:54+00:00

This code uses FP (floating point), Altivec and VSX (Vector-Scalar Extension). It can just depend on CONFIG_VSX though, because that already depends on FP and Altivec. Otherwise we get lots of link errors such as: drivers/built-in.o: In function `.p8_aes_setkey': aes.c:(.text+0x2d325c): undefined reference to `.enable_kernel_altivec' aes.c:(.text+0x2d326c): undefined reference to `.enable_kernel_vsx' Signed-off-by: Michael Ellerman Signed-off-by: Herbert Xu

crypto: sunxi-ss - Add Allwinner Security System crypto accelerator

2015-07-20T07:54:08+00:00

Add support for the Security System included in Allwinner SoC A20. The Security System is a hardware cryptographic accelerator that support: - MD5 and SHA1 hash algorithms - AES block cipher in CBC/ECB mode with 128/196/256bits keys. - DES and 3DES block cipher in CBC/ECB mode Signed-off-by: LABBE Corentin Signed-off-by: Herbert Xu

crypto: marvell/cesa - remove COMPILE_TEST dependency

2015-06-22T07:49:48+00:00

The CESA driver calls phys_to_virt() which is not available on all architectures. Remove the depency on COMPILE_TEST to prevent building this driver on non ARM architectures. Signed-off-by: Boris Brezillon Reported-by: Paul Gortmaker Suggested-by: Herbert Xu Signed-off-by: Herbert Xu

crypto: marvell/cesa - add TDMA support

2015-06-19T14:18:03+00:00

The CESA IP supports CPU offload through a dedicated DMA engine (TDMA) which can control the crypto block. When you use this mode, all the required data (operation metadata and payload data) are transferred using DMA, and the results are retrieved through DMA when possible (hash results are not retrieved through DMA yet), thus reducing the involvement of the CPU and providing better performances in most cases (for small requests, the cost of DMA preparation might exceed the performance gain). Note that some CESA IPs do not embed this dedicated DMA, hence the activation of this feature on a per platform basis. Signed-off-by: Boris Brezillon Signed-off-by: Arnaud Ebalard Signed-off-by: Herbert Xu

crypto: marvell/cesa - add a new driver for Marvell's CESA

2015-06-19T14:18:03+00:00

The existing mv_cesa driver supports some features of the CESA IP but is quite limited, and reworking it to support new features (like involving the TDMA engine to offload the CPU) is almost impossible. This driver has been rewritten from scratch to take those new features into account. This commit introduce the base infrastructure allowing us to add support for DMA optimization. It also includes support for one hash (SHA1) and one cipher (AES) algorithm, and enable those features on the Armada 370 SoC. Other algorithms and platforms will be added later on. Signed-off-by: Boris Brezillon Signed-off-by: Arnaud Ebalard Signed-off-by: Herbert Xu

crypto: mv_cesa - use gen_pool to reserve the SRAM memory region

2015-06-19T14:18:02+00:00

The mv_cesa driver currently expects the SRAM memory region to be passed as a platform device resource. This approach implies two drawbacks: - the DT representation is wrong - the only one that can access the SRAM is the crypto engine The last point is particularly annoying in some cases: for example on armada 370, a small region of the crypto SRAM is used to implement the cpuidle, which means you would not be able to enable both cpuidle and the CESA driver. To address that problem, we explicitly define the SRAM device in the DT and then reference the sram node from the crypto engine node. Also note that the old way of retrieving the SRAM memory region is still supported, or in other words, backward compatibility is preserved. Signed-off-by: Boris Brezillon Signed-off-by: Herbert Xu

crypto: drivers - Fix Kconfig selects

2015-06-18T06:45:36+00:00

This patch fixes a number of problems in crypto driver Kconfig entries: 1. Select BLKCIPHER instead of BLKCIPHER2. The latter is internal and should not be used outside of the crypto API itself. 2. Do not select ALGAPI unless you use a legacy type like CRYPTO_ALG_TYPE_CIPHER. 3. Select the algorithm type that you are implementing, e.g., AEAD. 4. Do not select generic C code such as CBC/ECB unless you use them as a fallback. 5. Remove default n since that is the default default. Signed-off-by: Herbert Xu

crypto: vmx - Remove duplicate PPC64 dependency

2015-06-16T06:35:01+00:00

The top-level CRYPTO_DEV_VMX option already depends on PPC64 so there is no need to depend on it again at CRYPTO_DEV_VMX_ENCRYPT. This patch also removes a redundant "default n". Signed-off-by: Herbert Xu

Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6

2015-05-28T03:16:41+00:00

Merge the crypto tree for 4.1 to pull in the changeset that disables algif_aead.

crypto: nx - add NX-842 platform frontend driver

2015-05-11T07:06:46+00:00

Add NX-842 frontend that allows using either the pSeries platform or PowerNV platform driver (to be added by later patch) for the NX-842 hardware. Update the MAINTAINERS file to include the new filenames. Update Kconfig files to clarify titles and descriptions, and correct dependencies. Signed-off-by: Dan Streetman Signed-off-by: Herbert Xu