Re: [PATCH v5 06/14] crypto: marvell/CESA: add DES support
On Tue, Jun 16, 2015 at 5:59 AM, Boris Brezillon boris.brezil...@free-electrons.com wrote: Add support for DES operations. Why on Earth should we do that? DES is demonstrably insecure. The only possible excuse for allowing it anywhere in a modern code base is that you need it to implement triple DES, and even that should by now be deprecated in favour of more modern ciphers which are much faster and thought to be more secure. Here's documentation from around the turn of the century http://www.freeswan.org/freeswan_trees/freeswan-1.5/doc/DES.html Moore's Law applies, so the $200,000 FPGA machine that broke DES in days in 1998 might be dirt cheap today. Certainly breaking DES on one of today's clusters would be fast and cheap as well, given that it took only a few months in 1998 using the Internet as the Conectio fabric. http://www.interhack.net/pubs/des-key-crack/ -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 05/14] crypto: marvell/CESA: add TDMA support
On Wed, Jun 17, 2015 at 05:34:02PM +0200, Boris Brezillon wrote: I can check for that too, but note that it doesn't prevent one from providing different scatterlist structures pointing to the same memory region. Pointing to the same memory should be fine, it's the act of passing the same SG list to dma_map_sg twice that's wrong because dma_map_sg will modify the SG list. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 05/14] crypto: marvell/CESA: add TDMA support
On Wed, Jun 17, 2015 at 05:58:28PM +0200, Boris Brezillon wrote: Here is an incremental patch [1], please let me know if something else is missing. Looks good. Thanks! -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Crypto Fixes for 4.1
Hi Linus: This push fixes the following issues: 1) Crash in caam hash due to uninitialised buffer lengths. 2) Alignment issue in caam RNG that may lead to non-random output. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git Steve Cornelius (2): crypto: caam - improve initalization for context state saves crypto: caam - fix RNG buffer cache alignment drivers/crypto/caam/caamhash.c |2 ++ drivers/crypto/caam/caamrng.c |2 +- 2 files changed, 3 insertions(+), 1 deletion(-) Thanks, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 04/14] crypto: add a new driver for Marvell's CESA
On Wed, 17 Jun 2015 13:58:24 +0800 Herbert Xu herb...@gondor.apana.org.au wrote: On Tue, Jun 16, 2015 at 11:58:58AM +0200, Boris Brezillon wrote: +config CRYPTO_DEV_MARVELL_CESA + tristate New Marvell's Cryptographic Engine driver + depends on (PLAT_ORION || ARCH_MVEBU || COMPILE_TEST) HAS_DMA HAS_IOMEM + select CRYPTO_ALGAPI + select CRYPTO_AES + select CRYPTO_DES + select CRYPTO_BLKCIPHER2 + select CRYPTO_HASH While you're fixing the DMA issue, could you also replace BLKCIPHER2 with BLKCIPHER and kill the select on ALGAPI? BLKCIPHER2 is internal to the crypto API and should not be used elsewhere while ALGAPI is only meant to be selected by crypto types such as BLKCIPHER. I know the existing driver does this too and I will fix that now. Fixed. -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 08/14] crypto: marvell/CESA: add MD5 support
From: Arnaud Ebalard a...@natisbad.org
Add support for MD5 operations.
Signed-off-by: Arnaud Ebalard a...@natisbad.org
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/hash.c | 172 +-
3 files changed, 174 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index c0b1b49..047c1c0 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -178,7 +178,9 @@ static struct crypto_alg *armada_370_cipher_algs[] = {
};
static struct ahash_alg *armada_370_ahash_algs[] = {
+ mv_md5_alg,
mv_sha1_alg,
+ mv_ahmac_md5_alg,
mv_ahmac_sha1_alg,
};
diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h
index 2e8b7fc..2a7e21a 100644
--- a/drivers/crypto/marvell/cesa.h
+++ b/drivers/crypto/marvell/cesa.h
@@ -774,7 +774,9 @@ int mv_cesa_dma_add_op_transfers(struct mv_cesa_tdma_chain
*chain,
/* Algorithm definitions */
+extern struct ahash_alg mv_md5_alg;
extern struct ahash_alg mv_sha1_alg;
+extern struct ahash_alg mv_ahmac_md5_alg;
extern struct ahash_alg mv_ahmac_sha1_alg;
extern struct crypto_alg mv_cesa_ecb_des_alg;
diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
index e7e0774..1c82d9b 100644
--- a/drivers/crypto/marvell/hash.c
+++ b/drivers/crypto/marvell/hash.c
@@ -12,6 +12,7 @@
* by the Free Software Foundation.
*/
+#include crypto/md5.h
#include crypto/sha.h
#include cesa.h
@@ -346,8 +347,16 @@ static int mv_cesa_ahash_process(struct
crypto_async_request *req, u32 status)
ahashreq-nbytes - creq-cache_ptr);
if (creq-last_req) {
- for (i = 0; i digsize / 4; i++)
- creq-state[i] = cpu_to_be32(creq-state[i]);
+ for (i = 0; i digsize / 4; i++) {
+ /*
+* Hardware provides MD5 digest in a different
+* endianness than SHA-1 and SHA-256 ones.
+*/
+ if (digsize == MD5_DIGEST_SIZE)
+ creq-state[i] = cpu_to_le32(creq-state[i]);
+ else
+ creq-state[i] = cpu_to_be32(creq-state[i]);
+ }
memcpy(ahashreq-result, creq-state, digsize);
}
@@ -790,6 +799,95 @@ static int mv_cesa_ahash_finup(struct ahash_request *req)
return ret;
}
+static int mv_cesa_md5_init(struct ahash_request *req)
+{
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(tmpl, CESA_SA_DESC_CFG_MACM_MD5);
+
+ mv_cesa_ahash_init(req, tmpl);
+
+ return 0;
+}
+
+static int mv_cesa_md5_export(struct ahash_request *req, void *out)
+{
+ struct md5_state *out_state = out;
+ struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
+ struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
+ unsigned int digsize = crypto_ahash_digestsize(ahash);
+
+ out_state-byte_count = creq-len;
+ memcpy(out_state-hash, creq-state, digsize);
+ memset(out_state-block, 0, sizeof(out_state-block));
+ if (creq-cache)
+ memcpy(out_state-block, creq-cache, creq-cache_ptr);
+
+ return 0;
+}
+
+static int mv_cesa_md5_import(struct ahash_request *req, const void *in)
+{
+ const struct md5_state *in_state = in;
+ struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
+ struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
+ unsigned int digsize = crypto_ahash_digestsize(ahash);
+ unsigned int cache_ptr;
+ int ret;
+
+ creq-len = in_state-byte_count;
+ memcpy(creq-state, in_state-hash, digsize);
+ creq-cache_ptr = 0;
+
+ cache_ptr = creq-len % sizeof(in_state-block);
+ if (!cache_ptr)
+ return 0;
+
+ ret = mv_cesa_ahash_alloc_cache(req);
+ if (ret)
+ return ret;
+
+ memcpy(creq-cache, in_state-block, cache_ptr);
+ creq-cache_ptr = cache_ptr;
+
+ return 0;
+}
+
+static int mv_cesa_md5_digest(struct ahash_request *req)
+{
+ int ret;
+
+ ret = mv_cesa_md5_init(req);
+ if (ret)
+ return ret;
+
+ return mv_cesa_ahash_finup(req);
+}
+
+struct ahash_alg mv_md5_alg = {
+ .init = mv_cesa_md5_init,
+ .update = mv_cesa_ahash_update,
+ .final = mv_cesa_ahash_final,
+ .finup = mv_cesa_ahash_finup,
+ .digest = mv_cesa_md5_digest,
+ .export = mv_cesa_md5_export,
+ .import = mv_cesa_md5_import,
+ .halg = {
+ .digestsize = MD5_DIGEST_SIZE,
+ .base = {
+ .cra_name = md5,
+ .cra_driver_name = mv-md5,
+ .cra_priority = 300,
+
[PATCH v6 04/14] crypto: add a new driver for Marvell's CESA
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 boris.brezil...@free-electrons.com
Signed-off-by: Arnaud Ebalard a...@natisbad.org
---
drivers/crypto/Kconfig | 15 +
drivers/crypto/Makefile | 1 +
drivers/crypto/marvell/Makefile | 2 +
drivers/crypto/marvell/cesa.c | 417 +++
drivers/crypto/marvell/cesa.h | 554 +++
drivers/crypto/marvell/cipher.c | 331 ++
drivers/crypto/marvell/hash.c | 720
7 files changed, 2040 insertions(+)
create mode 100644 drivers/crypto/marvell/Makefile
create mode 100644 drivers/crypto/marvell/cesa.c
create mode 100644 drivers/crypto/marvell/cesa.h
create mode 100644 drivers/crypto/marvell/cipher.c
create mode 100644 drivers/crypto/marvell/hash.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index a6bbea8..cbc3d3d 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -174,6 +174,21 @@ config CRYPTO_DEV_MV_CESA
Currently the driver supports AES in ECB and CBC mode without DMA.
+config CRYPTO_DEV_MARVELL_CESA
+ tristate New Marvell's Cryptographic Engine driver
+ depends on (PLAT_ORION || ARCH_MVEBU || COMPILE_TEST) HAS_DMA
HAS_IOMEM
+ select CRYPTO_AES
+ select CRYPTO_DES
+ select CRYPTO_BLKCIPHER
+ select CRYPTO_HASH
+ select SRAM
+ help
+ This driver allows you to utilize the Cryptographic Engines and
+ Security Accelerator (CESA) which can be found on the Armada 370.
+
+ This driver is aimed at replacing the mv_cesa driver. This will only
+ happen once it has received proper testing.
+
config CRYPTO_DEV_NIAGARA2
tristate Niagara2 Stream Processing Unit driver
select CRYPTO_DES
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index fb84be7..e35c07a 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_CRYPTO_DEV_HIFN_795X) += hifn_795x.o
obj-$(CONFIG_CRYPTO_DEV_IMGTEC_HASH) += img-hash.o
obj-$(CONFIG_CRYPTO_DEV_IXP4XX) += ixp4xx_crypto.o
obj-$(CONFIG_CRYPTO_DEV_MV_CESA) += mv_cesa.o
+obj-$(CONFIG_CRYPTO_DEV_MARVELL_CESA) += marvell/
obj-$(CONFIG_CRYPTO_DEV_MXS_DCP) += mxs-dcp.o
obj-$(CONFIG_CRYPTO_DEV_NIAGARA2) += n2_crypto.o
n2_crypto-y := n2_core.o n2_asm.o
diff --git a/drivers/crypto/marvell/Makefile b/drivers/crypto/marvell/Makefile
new file mode 100644
index 000..68d0982
--- /dev/null
+++ b/drivers/crypto/marvell/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_CRYPTO_DEV_MARVELL_CESA) += marvell-cesa.o
+marvell-cesa-objs := cesa.o cipher.o hash.o
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
new file mode 100644
index 000..76a6943
--- /dev/null
+++ b/drivers/crypto/marvell/cesa.c
@@ -0,0 +1,417 @@
+/*
+ * Support for Marvell's Cryptographic Engine and Security Accelerator (CESA)
+ * that can be found on the following platform: Orion, Kirkwood, Armada. This
+ * driver supports the TDMA engine on platforms on which it is available.
+ *
+ * Author: Boris Brezillon boris.brezil...@free-electrons.com
+ * Author: Arnaud Ebalard a...@natisbad.org
+ *
+ * This work is based on an initial version written by
+ * Sebastian Andrzej Siewior sebastian at breakpoint dot cc
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/genalloc.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/kthread.h
+#include linux/mbus.h
+#include linux/platform_device.h
+#include linux/scatterlist.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/clk.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/of_irq.h
+
+#include cesa.h
+
+struct mv_cesa_dev *cesa_dev;
+
+static void mv_cesa_dequeue_req_unlocked(struct mv_cesa_engine *engine)
+{
+ struct crypto_async_request *req, *backlog;
+ struct mv_cesa_ctx *ctx;
+
+ spin_lock_bh(cesa_dev-lock);
+ backlog = crypto_get_backlog(cesa_dev-queue);
+ req = crypto_dequeue_request(cesa_dev-queue);
+ engine-req = req;
+ spin_unlock_bh(cesa_dev-lock);
+
+ if (!req)
+ return;
+
+ if (backlog)
+ backlog-complete(backlog, -EINPROGRESS);
+
+ ctx =
[PATCH v6 06/14] crypto: marvell/CESA: add DES support
Add support for DES operations.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Signed-off-by: Arnaud Ebalard a...@natisbad.org
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/cipher.c | 150
3 files changed, 154 insertions(+)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 986f024..212840e 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -169,6 +169,8 @@ static void mv_cesa_remove_algs(struct mv_cesa_dev *cesa)
}
static struct crypto_alg *armada_370_cipher_algs[] = {
+ mv_cesa_ecb_des_alg,
+ mv_cesa_cbc_des_alg,
mv_cesa_ecb_aes_alg,
mv_cesa_cbc_aes_alg,
};
diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h
index 1a48323..2ee48fe 100644
--- a/drivers/crypto/marvell/cesa.h
+++ b/drivers/crypto/marvell/cesa.h
@@ -777,6 +777,8 @@ int mv_cesa_dma_add_op_transfers(struct mv_cesa_tdma_chain
*chain,
extern struct ahash_alg mv_sha1_alg;
extern struct ahash_alg mv_ahmac_sha1_alg;
+extern struct crypto_alg mv_cesa_ecb_des_alg;
+extern struct crypto_alg mv_cesa_cbc_des_alg;
extern struct crypto_alg mv_cesa_ecb_aes_alg;
extern struct crypto_alg mv_cesa_cbc_aes_alg;
diff --git a/drivers/crypto/marvell/cipher.c b/drivers/crypto/marvell/cipher.c
index a1f4013..ee49f5f 100644
--- a/drivers/crypto/marvell/cipher.c
+++ b/drivers/crypto/marvell/cipher.c
@@ -13,9 +13,15 @@
*/
#include crypto/aes.h
+#include crypto/des.h
#include cesa.h
+struct mv_cesa_des_ctx {
+ struct mv_cesa_ctx base;
+ u8 key[DES_KEY_SIZE];
+};
+
struct mv_cesa_aes_ctx {
struct mv_cesa_ctx base;
struct crypto_aes_ctx aes;
@@ -231,6 +237,30 @@ static int mv_cesa_aes_setkey(struct crypto_ablkcipher
*cipher, const u8 *key,
return 0;
}
+static int mv_cesa_des_setkey(struct crypto_ablkcipher *cipher, const u8 *key,
+ unsigned int len)
+{
+ struct crypto_tfm *tfm = crypto_ablkcipher_tfm(cipher);
+ struct mv_cesa_des_ctx *ctx = crypto_tfm_ctx(tfm);
+ u32 tmp[DES_EXPKEY_WORDS];
+ int ret;
+
+ if (len != DES_KEY_SIZE) {
+ crypto_ablkcipher_set_flags(cipher, CRYPTO_TFM_RES_BAD_KEY_LEN);
+ return -EINVAL;
+ }
+
+ ret = des_ekey(tmp, key);
+ if (!ret (tfm-crt_flags CRYPTO_TFM_REQ_WEAK_KEY)) {
+ tfm-crt_flags |= CRYPTO_TFM_RES_WEAK_KEY;
+ return -EINVAL;
+ }
+
+ memcpy(ctx-key, key, DES_KEY_SIZE);
+
+ return 0;
+}
+
static int mv_cesa_ablkcipher_dma_req_init(struct ablkcipher_request *req,
const struct mv_cesa_op_ctx *op_templ)
{
@@ -351,6 +381,126 @@ static int mv_cesa_ablkcipher_req_init(struct
ablkcipher_request *req,
return ret;
}
+static int mv_cesa_des_op(struct ablkcipher_request *req,
+ struct mv_cesa_op_ctx *tmpl)
+{
+ struct mv_cesa_des_ctx *ctx = crypto_tfm_ctx(req-base.tfm);
+ int ret;
+
+ mv_cesa_update_op_cfg(tmpl, CESA_SA_DESC_CFG_CRYPTM_DES,
+ CESA_SA_DESC_CFG_CRYPTM_MSK);
+
+ memcpy(tmpl-ctx.blkcipher.key, ctx-key, DES_KEY_SIZE);
+
+ ret = mv_cesa_ablkcipher_req_init(req, tmpl);
+ if (ret)
+ return ret;
+
+ ret = mv_cesa_queue_req(req-base);
+ if (ret ret != -EINPROGRESS)
+ mv_cesa_ablkcipher_cleanup(req);
+
+ return ret;
+}
+
+static int mv_cesa_ecb_des_encrypt(struct ablkcipher_request *req)
+{
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(tmpl,
+ CESA_SA_DESC_CFG_CRYPTCM_ECB |
+ CESA_SA_DESC_CFG_DIR_ENC);
+
+ return mv_cesa_des_op(req, tmpl);
+}
+
+static int mv_cesa_ecb_des_decrypt(struct ablkcipher_request *req)
+{
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(tmpl,
+ CESA_SA_DESC_CFG_CRYPTCM_ECB |
+ CESA_SA_DESC_CFG_DIR_DEC);
+
+ return mv_cesa_des_op(req, tmpl);
+}
+
+struct crypto_alg mv_cesa_ecb_des_alg = {
+ .cra_name = ecb(des),
+ .cra_driver_name = mv-ecb-des,
+ .cra_priority = 300,
+ .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+CRYPTO_ALG_KERN_DRIVER_ONLY | CRYPTO_ALG_ASYNC,
+ .cra_blocksize = DES_BLOCK_SIZE,
+ .cra_ctxsize = sizeof(struct mv_cesa_des_ctx),
+ .cra_alignmask = 0,
+ .cra_type = crypto_ablkcipher_type,
+ .cra_module = THIS_MODULE,
+ .cra_init = mv_cesa_ablkcipher_cra_init,
+ .cra_u = {
+ .ablkcipher = {
+ .min_keysize = DES_KEY_SIZE,
+ .max_keysize = DES_KEY_SIZE,
+ .setkey = mv_cesa_des_setkey,
+ .encrypt = mv_cesa_ecb_des_encrypt,
+ .decrypt =
[PATCH v6 09/14] crypto: marvell/CESA: add SHA256 support
From: Arnaud Ebalard a...@natisbad.org
Add support for SHA256 operations.
Signed-off-by: Arnaud Ebalard a...@natisbad.org
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/hash.c | 159 ++
3 files changed, 163 insertions(+)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 047c1c0..9c43cd7e 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -180,8 +180,10 @@ static struct crypto_alg *armada_370_cipher_algs[] = {
static struct ahash_alg *armada_370_ahash_algs[] = {
mv_md5_alg,
mv_sha1_alg,
+ mv_sha256_alg,
mv_ahmac_md5_alg,
mv_ahmac_sha1_alg,
+ mv_ahmac_sha256_alg,
};
static const struct mv_cesa_caps armada_370_caps = {
diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h
index 2a7e21a..a328938 100644
--- a/drivers/crypto/marvell/cesa.h
+++ b/drivers/crypto/marvell/cesa.h
@@ -776,8 +776,10 @@ int mv_cesa_dma_add_op_transfers(struct mv_cesa_tdma_chain
*chain,
extern struct ahash_alg mv_md5_alg;
extern struct ahash_alg mv_sha1_alg;
+extern struct ahash_alg mv_sha256_alg;
extern struct ahash_alg mv_ahmac_md5_alg;
extern struct ahash_alg mv_ahmac_sha1_alg;
+extern struct ahash_alg mv_ahmac_sha256_alg;
extern struct crypto_alg mv_cesa_ecb_des_alg;
extern struct crypto_alg mv_cesa_cbc_des_alg;
diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
index 1c82d9b..f90a510 100644
--- a/drivers/crypto/marvell/hash.c
+++ b/drivers/crypto/marvell/hash.c
@@ -977,6 +977,95 @@ struct ahash_alg mv_sha1_alg = {
}
};
+static int mv_cesa_sha256_init(struct ahash_request *req)
+{
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(tmpl, CESA_SA_DESC_CFG_MACM_SHA256);
+
+ mv_cesa_ahash_init(req, tmpl);
+
+ return 0;
+}
+
+static int mv_cesa_sha256_digest(struct ahash_request *req)
+{
+ int ret;
+
+ ret = mv_cesa_sha256_init(req);
+ if (ret)
+ return ret;
+
+ return mv_cesa_ahash_finup(req);
+}
+
+static int mv_cesa_sha256_export(struct ahash_request *req, void *out)
+{
+ struct sha256_state *out_state = out;
+ struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
+ struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
+ unsigned int ds = crypto_ahash_digestsize(ahash);
+
+ out_state-count = creq-len;
+ memcpy(out_state-state, creq-state, ds);
+ memset(out_state-buf, 0, sizeof(out_state-buf));
+ if (creq-cache)
+ memcpy(out_state-buf, creq-cache, creq-cache_ptr);
+
+ return 0;
+}
+
+static int mv_cesa_sha256_import(struct ahash_request *req, const void *in)
+{
+ const struct sha256_state *in_state = in;
+ struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
+ struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
+ unsigned int digsize = crypto_ahash_digestsize(ahash);
+ unsigned int cache_ptr;
+ int ret;
+
+ creq-len = in_state-count;
+ memcpy(creq-state, in_state-state, digsize);
+ creq-cache_ptr = 0;
+
+ cache_ptr = creq-len % SHA256_BLOCK_SIZE;
+ if (!cache_ptr)
+ return 0;
+
+ ret = mv_cesa_ahash_alloc_cache(req);
+ if (ret)
+ return ret;
+
+ memcpy(creq-cache, in_state-buf, cache_ptr);
+ creq-cache_ptr = cache_ptr;
+
+ return 0;
+}
+
+struct ahash_alg mv_sha256_alg = {
+ .init = mv_cesa_sha256_init,
+ .update = mv_cesa_ahash_update,
+ .final = mv_cesa_ahash_final,
+ .finup = mv_cesa_ahash_finup,
+ .digest = mv_cesa_sha256_digest,
+ .export = mv_cesa_sha256_export,
+ .import = mv_cesa_sha256_import,
+ .halg = {
+ .digestsize = SHA256_DIGEST_SIZE,
+ .base = {
+ .cra_name = sha256,
+ .cra_driver_name = mv-sha256,
+ .cra_priority = 300,
+ .cra_flags = CRYPTO_ALG_ASYNC |
+CRYPTO_ALG_KERN_DRIVER_ONLY,
+ .cra_blocksize = SHA256_BLOCK_SIZE,
+ .cra_ctxsize = sizeof(struct mv_cesa_hash_ctx),
+ .cra_init = mv_cesa_ahash_cra_init,
+ .cra_module = THIS_MODULE,
+}
+ }
+};
+
struct mv_cesa_ahash_result {
struct completion completion;
int error;
@@ -1282,3 +1371,73 @@ struct ahash_alg mv_ahmac_sha1_alg = {
}
}
};
+
+static int mv_cesa_ahmac_sha256_setkey(struct crypto_ahash *tfm, const u8 *key,
+ unsigned int keylen)
+{
+ struct mv_cesa_hmac_ctx *ctx = crypto_tfm_ctx(crypto_ahash_tfm(tfm));
+ struct sha256_state istate, ostate;
+ int ret, i;
+
+
Re: [PATCH v6 05/14] crypto: marvell/CESA: add TDMA support
On Wed, 17 Jun 2015 17:50:01 +0800 Herbert Xu herb...@gondor.apana.org.au wrote: On Wed, Jun 17, 2015 at 09:45:33AM +0200, Boris Brezillon wrote: + ret = dma_map_sg(cesa_dev-dev, req-src, creq-src_nents, +DMA_TO_DEVICE); + if (!ret) + return -ENOMEM; + + creq-src_nents = ret; DMA-API-HOWTO says that you must retain the original nents and use it when you call dma_unmap_sg. So I'm afraid one more repost is needed :) My bad (again :-/). Actually, I think I don't need to save the dma_map_sg return val, since I'm using the sg_next function to iterate over the scatterlist. Am I right ? IOW, is the -map_sg() function (in dma_map_ops) supposed to merge the contiguous entries and then flag the unused entries with the is_chain flag ? If that's not the case, and the -map_sg() just marks the merged entries as empty (length = 0), then I'll have to rework my iterator algorithm. -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 05/14] crypto: marvell/CESA: add TDMA support
On Wed, Jun 17, 2015 at 01:33:24PM +0200, Boris Brezillon wrote: Actually, I think I don't need to save the dma_map_sg return val, since I'm using the sg_next function to iterate over the scatterlist. Am I right ? IOW, is the -map_sg() function (in dma_map_ops) supposed to merge the contiguous entries and then flag the unused entries with the is_chain flag ? Right. If you're simply using sg_dma_length in conjunction with sg_next then you don't need the new length. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 05/14] crypto: marvell/CESA: add TDMA support
On Wed, 17 Jun 2015 15:18:29 +0800 Herbert Xu herb...@gondor.apana.org.au wrote: On Wed, Jun 17, 2015 at 09:15:03AM +0200, Boris Brezillon wrote: Anyway, now I'm doing the following test: if (creq-src_nents !ret) return -ENOMEM; Best not call dma_map_sg at all in the !src_nents case as I think some architectures will WARN or BUG if you give it a zero-length list. Okay, I've changed it to test for the !src_nents before calling dma_map_sg. Thanks, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
crypto: drivers - Fix Kconfig selects
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 herb...@gondor.apana.org.au --- drivers/crypto/Kconfig | 41 + drivers/crypto/caam/Kconfig |5 ++--- drivers/crypto/ccp/Kconfig |1 - drivers/crypto/nx/Kconfig|8 drivers/crypto/qat/Kconfig |6 ++ drivers/crypto/ux500/Kconfig |4 ++-- 6 files changed, 19 insertions(+), 46 deletions(-) diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index 92c899f..7a72797 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -162,9 +162,8 @@ config CRYPTO_GHASH_S390 config CRYPTO_DEV_MV_CESA tristate Marvell's Cryptographic Engine depends on PLAT_ORION - select CRYPTO_ALGAPI select CRYPTO_AES - select CRYPTO_BLKCIPHER2 + select CRYPTO_BLKCIPHER select CRYPTO_HASH help This driver allows you to utilize the Cryptographic Engines and @@ -176,7 +175,8 @@ config CRYPTO_DEV_MV_CESA config CRYPTO_DEV_NIAGARA2 tristate Niagara2 Stream Processing Unit driver select CRYPTO_DES - select CRYPTO_ALGAPI + select CRYPTO_BLKCIPHER + select CRYPTO_HASH depends on SPARC64 help Each core of a Niagara2 processor contains a Stream @@ -189,7 +189,6 @@ config CRYPTO_DEV_NIAGARA2 config CRYPTO_DEV_HIFN_795X tristate Driver HIFN 795x crypto accelerator chips select CRYPTO_DES - select CRYPTO_ALGAPI select CRYPTO_BLKCIPHER select HW_RANDOM if CRYPTO_DEV_HIFN_795X_RNG depends on PCI @@ -208,8 +207,10 @@ source drivers/crypto/caam/Kconfig config CRYPTO_DEV_TALITOS tristate Talitos Freescale Security Engine (SEC) - select CRYPTO_ALGAPI + select CRYPTO_AEAD select CRYPTO_AUTHENC + select CRYPTO_BLKCIPHER + select CRYPTO_HASH select HW_RANDOM depends on FSL_SOC help @@ -244,7 +245,7 @@ config CRYPTO_DEV_IXP4XX tristate Driver for IXP4xx crypto hardware acceleration depends on ARCH_IXP4XX IXP4XX_QMGR IXP4XX_NPE select CRYPTO_DES - select CRYPTO_ALGAPI + select CRYPTO_AEAD select CRYPTO_AUTHENC select CRYPTO_BLKCIPHER help @@ -254,7 +255,6 @@ config CRYPTO_DEV_PPC4XX tristate Driver AMCC PPC4xx crypto accelerator depends on PPC 4xx select CRYPTO_HASH - select CRYPTO_ALGAPI select CRYPTO_BLKCIPHER help This option allows you to have support for AMCC crypto acceleration. @@ -275,7 +275,7 @@ config CRYPTO_DEV_OMAP_AES tristate Support for OMAP AES hw engine depends on ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP2PLUS select CRYPTO_AES - select CRYPTO_BLKCIPHER2 + select CRYPTO_BLKCIPHER help OMAP processors have AES module accelerator. Select this if you want to use the OMAP module for AES algorithms. @@ -284,7 +284,7 @@ config CRYPTO_DEV_OMAP_DES tristate Support for OMAP DES3DES hw engine depends on ARCH_OMAP2PLUS select CRYPTO_DES - select CRYPTO_BLKCIPHER2 + select CRYPTO_BLKCIPHER help OMAP processors have DES/3DES module accelerator. Select this if you want to use the OMAP module for DES and 3DES algorithms. Currently @@ -294,9 +294,10 @@ config CRYPTO_DEV_OMAP_DES config CRYPTO_DEV_PICOXCELL tristate Support for picoXcell IPSEC and Layer2 crypto engines depends on ARCH_PICOXCELL HAVE_CLK + select CRYPTO_AEAD select CRYPTO_AES select CRYPTO_AUTHENC - select CRYPTO_ALGAPI + select CRYPTO_BLKCIPHER select CRYPTO_DES select CRYPTO_CBC select CRYPTO_ECB @@ -322,7 +323,6 @@ config CRYPTO_DEV_S5P tristate Support for Samsung S5PV210/Exynos crypto accelerator depends on ARCH_S5PV210 || ARCH_EXYNOS select CRYPTO_AES - select CRYPTO_ALGAPI select CRYPTO_BLKCIPHER help This option allows you to have support for S5P crypto acceleration. @@ -345,7 +345,6 @@ endif config CRYPTO_DEV_UX500 tristate Driver for ST-Ericsson UX500 crypto hardware acceleration depends on ARCH_U8500 - select CRYPTO_ALGAPI help Driver for ST-Ericsson UX500 crypto engine. @@ -363,10 +362,7 @@ config CRYPTO_DEV_BFIN_CRC config CRYPTO_DEV_ATMEL_AES tristate Support for Atmel AES hw accelerator depends on
Re: [PATCH RFC 05/11] crypto: caam - Add cache coherency support to Freescale CAAM scatterlist implementation
On Mon, Jun 15, 2015 at 04:52:53PM -0700, Victoria Milhoan wrote:
Add cache coherency support to the CAAM scatterlist implementation.
Signed-off-by: Victoria Milhoan vicki.milh...@freescale.com
---
drivers/crypto/caam/sg_sw_sec4.h | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/caam/sg_sw_sec4.h
b/drivers/crypto/caam/sg_sw_sec4.h
index 6365585..6730b01 100644
--- a/drivers/crypto/caam/sg_sw_sec4.h
+++ b/drivers/crypto/caam/sg_sw_sec4.h
@@ -91,9 +91,14 @@ static int dma_map_sg_chained(struct device *dev, struct
scatterlist *sg,
{
if (unlikely(chained)) {
int i;
+ struct scatterlist *tsg = sg;
+
+ /* We use a local copy of the sg pointer to avoid moving the
+ * head of the list pointed to by sg as we wall the list.
+ */
for (i = 0; i nents; i++) {
- dma_map_sg(dev, sg, 1, dir);
- sg = sg_next(sg);
+ dma_map_sg(dev, tsg, 1, dir);
+ tsg = scatterwalk_sg_next(tsg);
}
} else {
dma_map_sg(dev, sg, nents, dir);
@@ -106,6 +111,9 @@ static int dma_unmap_sg_chained(struct device *dev,
struct scatterlist *sg,
unsigned int nents, enum dma_data_direction dir,
bool chained)
{
+ if ((dir == DMA_FROM_DEVICE) || (dir == DMA_BIDIRECTIONAL))
+ dma_sync_sg_for_cpu(dev, sg, nents, dir);
+
if (unlikely(chained)) {
int i;
for (i = 0; i nents; i++) {
You don't need to sync here, because you unmap it directly afterwards.
Regards,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 05/14] crypto: marvell/CESA: add TDMA support
On Wed, Jun 17, 2015 at 09:15:03AM +0200, Boris Brezillon wrote: Anyway, now I'm doing the following test: if (creq-src_nents !ret) return -ENOMEM; Best not call dma_map_sg at all in the !src_nents case as I think some architectures will WARN or BUG if you give it a zero-length list. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 00/14] crypto: add a new driver for Marvell's CESA
Hello, This patch series adds a new driver supporting Marvell's CESA IP. This driver addresses some limitations of the existing one. From a performance and CPU load point of view the most important limitation in the existing driver is the lack of DMA support, thus preventing us from chaining crypto operations. I know we usually try to adapt existing drivers instead of replacing them by new ones, but after trying to refactor the mv_cesa driver I realized it would take longer than writing an new one from scratch. Here are the main features brought by this new driver: - support for armada SoCs (up to 38x) while keeping support for older ones (Orion and Kirkwood). Note that old DT bindings (those used on Orion and Kirkwood platforms) are supported, or IOTW, old DTs are compatible with this new driver. - DMA mode to offload the CPU in case of intensive crypto usage - new algorithms: SHA256, DES and 3DES I'd like to thank Arnaud, who has carefully reviewed several iterations of this driver, helped me improved my implementation, provided support for several crypto algorithms, provided support for armada-370 and tested the driver on different platforms, hence the SoB and dual MODULE_AUTHOR in the driver code. In this version I dropped the DT changes, but you'll find them in my cesa-v6 branch [1]. In this branch you'll find everything you need to test on all Marvell platforms (including the old ones). I'll post a series updating all the DTs once this driver has been merged. Best Regards, Boris [1]https://github.com/bbrezillon/linux-marvell/tree/cesa-v6 Changes since v5: - fix the dma_map_sg return code check (again) - fix select entries in the Kconfig option Changes since v4: - fix the dma_map_sg return code check - add import/export functions to all HMAC algos - update the passed IV when handling cipher requests - properly handle requests in the crypto queue backlog - use sg_nents_for_len Changes since v3: - add import functions for hash algorithms - patch mv_cesa driver to support the new DT bindings - few fixes in the documentation - replace mv_mbus_dram_info() call by mv_mbus_dram_info_nooverlap() - remove DT updates from the series Changes since v2: - fixes in the cipher code (-dst_nents was assigned the -src_nents value and CBC state was overwritten by the IV after each chunk operation) - spit the code as suggested by Sebastian Changes since v1: - (suggested by Jason) kept the existing CESA driver and added a mechanism to prevent the new driver from probing devices handled my the existing one (Orion and Kirkwood platforms) - (reported by Paul) addressed a few Kconfig and module definition issues - (suggested by Andrew) added DT changes to the series Arnaud Ebalard (4): crypto: marvell/CESA: add Triple-DES support crypto: marvell/CESA: add MD5 support crypto: marvell/CESA: add SHA256 support crypto: marvell/CESA: add support for Kirkwood and Dove SoCs Boris Brezillon (10): crypto: mv_cesa: document the clocks property crypto: mv_cesa: use gen_pool to reserve the SRAM memory region crypto: mv_cesa: explicitly define kirkwood and dove compatible strings crypto: add a new driver for Marvell's CESA crypto: marvell/CESA: add TDMA support crypto: marvell/CESA: add DES support crypto: marvell/CESA: add support for all armada SoCs crypto: marvell/CESA: add allhwsupport module parameter crypto: marvell/CESA: add support for Orion SoCs crypto: marvell/CESA: add DT bindings documentation .../devicetree/bindings/crypto/marvell-cesa.txt| 45 + .../devicetree/bindings/crypto/mv_cesa.txt | 31 +- drivers/crypto/Kconfig | 17 + drivers/crypto/Makefile|1 + drivers/crypto/marvell/Makefile|2 + drivers/crypto/marvell/cesa.c | 548 drivers/crypto/marvell/cesa.h | 791 +++ drivers/crypto/marvell/cipher.c| 784 +++ drivers/crypto/marvell/hash.c | 1443 drivers/crypto/marvell/tdma.c | 224 +++ drivers/crypto/mv_cesa.c | 60 +- 11 files changed, 3922 insertions(+), 24 deletions(-) create mode 100644 Documentation/devicetree/bindings/crypto/marvell-cesa.txt create mode 100644 drivers/crypto/marvell/Makefile create mode 100644 drivers/crypto/marvell/cesa.c create mode 100644 drivers/crypto/marvell/cesa.h create mode 100644 drivers/crypto/marvell/cipher.c create mode 100644 drivers/crypto/marvell/hash.c create mode 100644 drivers/crypto/marvell/tdma.c -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 12/14] crypto: marvell/CESA: add support for Orion SoCs
Add the Orion SoC description, and select this implementation by default
to support non-DT probing: Orion is the only platform where non-DT boards
are declaring the CESA block.
Control the allhwsupport module parameter to avoid probing the CESA IP when
the old CESA driver is enabled (unless it is explicitly requested to do
so).
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 42 +++---
1 file changed, 35 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index a05b5cb..8e5ea72 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -172,6 +172,22 @@ static void mv_cesa_remove_algs(struct mv_cesa_dev *cesa)
crypto_unregister_alg(cesa-caps-cipher_algs[i]);
}
+static struct crypto_alg *orion_cipher_algs[] = {
+ mv_cesa_ecb_des_alg,
+ mv_cesa_cbc_des_alg,
+ mv_cesa_ecb_des3_ede_alg,
+ mv_cesa_cbc_des3_ede_alg,
+ mv_cesa_ecb_aes_alg,
+ mv_cesa_cbc_aes_alg,
+};
+
+static struct ahash_alg *orion_ahash_algs[] = {
+ mv_md5_alg,
+ mv_sha1_alg,
+ mv_ahmac_md5_alg,
+ mv_ahmac_sha1_alg,
+};
+
static struct crypto_alg *armada_370_cipher_algs[] = {
mv_cesa_ecb_des_alg,
mv_cesa_cbc_des_alg,
@@ -190,6 +206,15 @@ static struct ahash_alg *armada_370_ahash_algs[] = {
mv_ahmac_sha256_alg,
};
+static const struct mv_cesa_caps orion_caps = {
+ .nengines = 1,
+ .cipher_algs = orion_cipher_algs,
+ .ncipher_algs = ARRAY_SIZE(orion_cipher_algs),
+ .ahash_algs = orion_ahash_algs,
+ .nahash_algs = ARRAY_SIZE(orion_ahash_algs),
+ .has_tdma = false,
+};
+
static const struct mv_cesa_caps armada_370_caps = {
.nengines = 1,
.cipher_algs = armada_370_cipher_algs,
@@ -209,6 +234,7 @@ static const struct mv_cesa_caps armada_xp_caps = {
};
static const struct of_device_id mv_cesa_of_match_table[] = {
+ { .compatible = marvell,orion-crypto, .data = orion_caps },
{ .compatible = marvell,armada-370-crypto, .data = armada_370_caps },
{ .compatible = marvell,armada-xp-crypto, .data = armada_xp_caps },
{ .compatible = marvell,armada-375-crypto, .data = armada_xp_caps },
@@ -334,7 +360,7 @@ static void mv_cesa_put_sram(struct platform_device *pdev,
int idx)
static int mv_cesa_probe(struct platform_device *pdev)
{
- const struct mv_cesa_caps *caps = NULL;
+ const struct mv_cesa_caps *caps = orion_caps;
const struct mbus_dram_target_info *dram;
const struct of_device_id *match;
struct device *dev = pdev-dev;
@@ -349,14 +375,16 @@ static int mv_cesa_probe(struct platform_device *pdev)
return -EEXIST;
}
- if (!dev-of_node)
- return -ENOTSUPP;
+ if (dev-of_node) {
+ match = of_match_node(mv_cesa_of_match_table, dev-of_node);
+ if (!match || !match-data)
+ return -ENOTSUPP;
- match = of_match_node(mv_cesa_of_match_table, dev-of_node);
- if (!match || !match-data)
- return -ENOTSUPP;
+ caps = match-data;
+ }
- caps = match-data;
+ if (caps == orion_caps !allhwsupport)
+ return -ENOTSUPP;
cesa = devm_kzalloc(dev, sizeof(*cesa), GFP_KERNEL);
if (!cesa)
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 01/14] crypto: mv_cesa: document the clocks property
On Dove platforms, the crypto engine requires a clock. Document this clocks property in the mv_cesa bindings doc. Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com --- Documentation/devicetree/bindings/crypto/mv_cesa.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/crypto/mv_cesa.txt b/Documentation/devicetree/bindings/crypto/mv_cesa.txt index 47229b1..eaa2873 100644 --- a/Documentation/devicetree/bindings/crypto/mv_cesa.txt +++ b/Documentation/devicetree/bindings/crypto/mv_cesa.txt @@ -7,6 +7,8 @@ Required properties: length - reg-names : regs , sram; - interrupts : interrupt number +- clocks: reference to the crypto engines clocks. This property is only + required for Dove platforms Examples: -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 03/14] crypto: mv_cesa: explicitly define kirkwood and dove compatible strings
We are about to add a new driver to support new features like using the
TDMA engine to offload the CPU.
Orion, Dove and Kirkwood platforms are already using the mv_cesa driver,
but Orion SoCs do not embed the TDMA engine, which means we will have to
differentiate them if we want to get TDMA support on Dove and Kirkwood.
In the other hand, the migration from the old driver to the new one is not
something all people are willing to do without first auditing the new
driver.
Hence we have to support the new compatible in the mv_cesa driver so that
new platforms with updated DTs can still attach their crypto engine device
to this driver.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
Documentation/devicetree/bindings/crypto/mv_cesa.txt | 5 -
drivers/crypto/mv_cesa.c | 4 +++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/crypto/mv_cesa.txt
b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
index 13b8fc5..c0c35f0 100644
--- a/Documentation/devicetree/bindings/crypto/mv_cesa.txt
+++ b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
@@ -1,7 +1,10 @@
Marvell Cryptographic Engines And Security Accelerator
Required properties:
-- compatible : should be marvell,orion-crypto
+- compatible: should be one of the following string
+ marvell,orion-crypto
+ marvell,kirkwood-crypto
+ marvell,dove-crypto
- reg: base physical address of the engine and length of memory mapped
region. Can also contain an entry for the SRAM attached to the CESA,
but this representation is deprecated and marvell,crypto-srams should
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index a4c8637..fcab963 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -1034,7 +1034,7 @@ static int mv_cesa_get_sram(struct platform_device *pdev,
sram_size);
cp-sram_size = sram_size;
- cp-sram_pool = of_get_named_gen_pool(pdev-dev.of_node,
+ cp-sram_pool = of_get_named_gen_pool(pdev-dev.of_node,
marvell,crypto-srams, 0);
if (cp-sram_pool) {
cp-sram = gen_pool_dma_alloc(cp-sram_pool, sram_size,
@@ -1197,6 +1197,8 @@ static int mv_remove(struct platform_device *pdev)
static const struct of_device_id mv_cesa_of_match_table[] = {
{ .compatible = marvell,orion-crypto, },
+ { .compatible = marvell,kirkwood-crypto, },
+ { .compatible = marvell,dove-crypto, },
{}
};
MODULE_DEVICE_TABLE(of, mv_cesa_of_match_table);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 05/14] crypto: marvell/CESA: add TDMA support
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 boris.brezil...@free-electrons.com
Signed-off-by: Arnaud Ebalard a...@natisbad.org
---
drivers/crypto/Kconfig | 1 +
drivers/crypto/marvell/Makefile | 2 +-
drivers/crypto/marvell/cesa.c | 68 +++
drivers/crypto/marvell/cesa.h | 229 ++
drivers/crypto/marvell/cipher.c | 166 +++-
drivers/crypto/marvell/hash.c | 416 +++-
drivers/crypto/marvell/tdma.c | 224 ++
7 files changed, 1090 insertions(+), 16 deletions(-)
create mode 100644 drivers/crypto/marvell/tdma.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index cbc3d3d..cdca762 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -185,6 +185,7 @@ config CRYPTO_DEV_MARVELL_CESA
help
This driver allows you to utilize the Cryptographic Engines and
Security Accelerator (CESA) which can be found on the Armada 370.
+ This driver supports CPU offload through DMA transfers.
This driver is aimed at replacing the mv_cesa driver. This will only
happen once it has received proper testing.
diff --git a/drivers/crypto/marvell/Makefile b/drivers/crypto/marvell/Makefile
index 68d0982..0c12b13 100644
--- a/drivers/crypto/marvell/Makefile
+++ b/drivers/crypto/marvell/Makefile
@@ -1,2 +1,2 @@
obj-$(CONFIG_CRYPTO_DEV_MARVELL_CESA) += marvell-cesa.o
-marvell-cesa-objs := cesa.o cipher.o hash.o
+marvell-cesa-objs := cesa.o cipher.o hash.o tdma.o
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 76a6943..986f024 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -184,6 +184,7 @@ static const struct mv_cesa_caps armada_370_caps = {
.ncipher_algs = ARRAY_SIZE(armada_370_cipher_algs),
.ahash_algs = armada_370_ahash_algs,
.nahash_algs = ARRAY_SIZE(armada_370_ahash_algs),
+ .has_tdma = true,
};
static const struct of_device_id mv_cesa_of_match_table[] = {
@@ -192,6 +193,66 @@ static const struct of_device_id mv_cesa_of_match_table[]
= {
};
MODULE_DEVICE_TABLE(of, mv_cesa_of_match_table);
+static void
+mv_cesa_conf_mbus_windows(struct mv_cesa_engine *engine,
+ const struct mbus_dram_target_info *dram)
+{
+ void __iomem *iobase = engine-regs;
+ int i;
+
+ for (i = 0; i 4; i++) {
+ writel(0, iobase + CESA_TDMA_WINDOW_CTRL(i));
+ writel(0, iobase + CESA_TDMA_WINDOW_BASE(i));
+ }
+
+ for (i = 0; i dram-num_cs; i++) {
+ const struct mbus_dram_window *cs = dram-cs + i;
+
+ writel(((cs-size - 1) 0x) |
+ (cs-mbus_attr 8) |
+ (dram-mbus_dram_target_id 4) | 1,
+ iobase + CESA_TDMA_WINDOW_CTRL(i));
+ writel(cs-base, iobase + CESA_TDMA_WINDOW_BASE(i));
+ }
+}
+
+static int mv_cesa_dev_dma_init(struct mv_cesa_dev *cesa)
+{
+ struct device *dev = cesa-dev;
+ struct mv_cesa_dev_dma *dma;
+
+ if (!cesa-caps-has_tdma)
+ return 0;
+
+ dma = devm_kzalloc(dev, sizeof(*dma), GFP_KERNEL);
+ if (!dma)
+ return -ENOMEM;
+
+ dma-tdma_desc_pool = dmam_pool_create(tdma_desc, dev,
+ sizeof(struct mv_cesa_tdma_desc),
+ 16, 0);
+ if (!dma-tdma_desc_pool)
+ return -ENOMEM;
+
+ dma-op_pool = dmam_pool_create(cesa_op, dev,
+ sizeof(struct mv_cesa_op_ctx), 16, 0);
+ if (!dma-op_pool)
+ return -ENOMEM;
+
+ dma-cache_pool = dmam_pool_create(cesa_cache, dev,
+ CESA_MAX_HASH_BLOCK_SIZE, 1, 0);
+ if (!dma-cache_pool)
+ return -ENOMEM;
+
+ dma-padding_pool = dmam_pool_create(cesa_padding, dev, 72, 1, 0);
+ if (!dma-cache_pool)
+ return -ENOMEM;
+
+ cesa-dma = dma;
+
+ return 0;
+}
+
static int mv_cesa_get_sram(struct platform_device *pdev, int idx)
{
struct mv_cesa_dev *cesa = platform_get_drvdata(pdev);
@@ -299,6 +360,10 @@ static int mv_cesa_probe(struct platform_device *pdev)
if (IS_ERR(cesa-regs))
return -ENOMEM;
+
Re: [PATCH RFC 01/11] crypto: caam - Add cache coherency support
On Mon, Jun 15, 2015 at 04:52:49PM -0700, Victoria Milhoan wrote:
Freescale i.MX6 ARM platforms do not support hardware cache coherency. This
patch adds cache coherency support to the CAAM driver.
Signed-off-by: Victoria Milhoan vicki.milh...@freescale.com
---
drivers/crypto/caam/caamhash.c | 28 +--
drivers/crypto/caam/caamrng.c| 10 +-
drivers/crypto/caam/jr.c | 42
+++-
drivers/crypto/caam/key_gen.c| 4 +++-
drivers/crypto/caam/sg_sw_sec4.h | 1 +
5 files changed, 72 insertions(+), 13 deletions(-)
diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index ba0532e..1662c65 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -500,6 +500,7 @@ static int hash_digest_key(struct caam_hash_ctx *ctx,
const u8 *key_in,
#endif
}
dma_unmap_single(jrdev, src_dma, *keylen, DMA_TO_DEVICE);
+ dma_sync_single_for_cpu(jrdev, dst_dma, digestsize, DMA_FROM_DEVICE);
dma_unmap_single(jrdev, dst_dma, digestsize, DMA_FROM_DEVICE);
*keylen = digestsize;
@@ -608,8 +609,11 @@ static inline void ahash_unmap(struct device *dev,
if (edesc-src_nents)
dma_unmap_sg_chained(dev, req-src, edesc-src_nents,
DMA_TO_DEVICE, edesc-chained);
- if (edesc-dst_dma)
+ if (edesc-dst_dma) {
+ dma_sync_single_for_cpu(dev, edesc-dst_dma, dst_len,
+ DMA_FROM_DEVICE);
dma_unmap_single(dev, edesc-dst_dma, dst_len, DMA_FROM_DEVICE);
+ }
if (edesc-sec4_sg_bytes)
dma_unmap_single(dev, edesc-sec4_sg_dma,
@@ -624,8 +628,12 @@ static inline void ahash_unmap_ctx(struct device *dev,
struct caam_hash_ctx *ctx = crypto_ahash_ctx(ahash);
struct caam_hash_state *state = ahash_request_ctx(req);
- if (state-ctx_dma)
+ if (state-ctx_dma) {
+ if ((flag == DMA_FROM_DEVICE) || (flag == DMA_BIDIRECTIONAL))
+ dma_sync_single_for_cpu(dev, state-ctx_dma,
+ ctx-ctx_len, flag);
dma_unmap_single(dev, state-ctx_dma, ctx-ctx_len, flag);
+ }
ahash_unmap(dev, edesc, req, dst_len);
}
Unneeded syncing, dma_unmap does it as long as it is not told otherwise.
(...)
diff --git a/drivers/crypto/caam/caamrng.c b/drivers/crypto/caam/caamrng.c
index 26a544b..a8c4af9 100644
--- a/drivers/crypto/caam/caamrng.c
+++ b/drivers/crypto/caam/caamrng.c
@@ -80,9 +80,12 @@ static struct caam_rng_ctx *rng_ctx;
static inline void rng_unmap_buf(struct device *jrdev, struct buf_data *bd)
{
- if (bd-addr)
+ if (bd-addr) {
+ dma_sync_single_for_cpu(jrdev, bd-addr, RN_BUF_SIZE,
+ DMA_FROM_DEVICE);
dma_unmap_single(jrdev, bd-addr, RN_BUF_SIZE,
DMA_FROM_DEVICE);
+ }
}
dito
static inline void rng_unmap_ctx(struct caam_rng_ctx *ctx)
@@ -108,6 +111,10 @@ static void rng_done(struct device *jrdev, u32 *desc,
u32 err, void *context)
atomic_set(bd-empty, BUF_NOT_EMPTY);
complete(bd-filled);
+
+ /* Buffer refilled, invalidate cache */
+ dma_sync_single_for_cpu(jrdev, bd-addr, RN_BUF_SIZE, DMA_FROM_DEVICE);
+
This seems to be okay, though.
#ifdef DEBUG
print_hex_dump(KERN_ERR, rng refreshed buf@: ,
DUMP_PREFIX_ADDRESS, 16, 4, bd-buf, RN_BUF_SIZE, 1);
@@ -211,6 +218,7 @@ static inline int rng_create_sh_desc(struct caam_rng_ctx
*ctx)
print_hex_dump(KERN_ERR, rng shdesc@: , DUMP_PREFIX_ADDRESS, 16, 4,
desc, desc_bytes(desc), 1);
#endif
+
return 0;
}
diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c
index b8b5d47..a693bf7 100644
--- a/drivers/crypto/caam/jr.c
+++ b/drivers/crypto/caam/jr.c
@@ -168,6 +168,9 @@ static void caam_jr_dequeue(unsigned long devarg)
void (*usercall)(struct device *dev, u32 *desc, u32 status, void *arg);
u32 *userdesc, userstatus;
void *userarg;
+ dma_addr_t outbusaddr;
+
+ outbusaddr = rd_reg64(jrp-rregs-outring_base);
while (rd_reg32(jrp-rregs-outring_used)) {
@@ -177,10 +180,19 @@ static void caam_jr_dequeue(unsigned long devarg)
sw_idx = tail = jrp-tail;
hw_idx = jrp-out_ring_read_index;
+ dma_sync_single_for_cpu(dev, outbusaddr,
+ sizeof(struct jr_outentry) * JOBR_DEPTH,
+ DMA_FROM_DEVICE);
This one and ...
(...)
@@ -321,7 +346,7 @@ int caam_jr_enqueue(struct device *dev, u32 *desc,
struct caam_drv_private_jr *jrp = dev_get_drvdata(dev);
struct caam_jrentry_info *head_entry;
int head, tail, desc_size;
- dma_addr_t desc_dma;
+
Re: [PATCH 0/3] crypto: picoxcell - Clamp AEAD SG list by input length
On Thu, Jun 11, 2015 at 11:27:03AM +0800, Herbert Xu wrote: Hi: This series of patches adds a couple of minor fixes to picoxcell, but most importantly allows it to be used with the new AEAD interface by ensuring that it clamps the AD SG list by the AD length. This is compile-tested only. Looks good, thanks Herbert! Acked-by: Jamie Iles ja...@jamieiles.com -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 06/11] crypto: caam - Enable MXC devices to select CAAM driver in Kconfig
On Mon, Jun 15, 2015 at 04:52:54PM -0700, Victoria Milhoan wrote: From: Steve Cornelius steve.cornel...@freescale.com Allow CAAM to be selected in the kernel for Freescale i.MX6 devices if ARCH_MXC is enabled. Signed-off-by: Steve Cornelius steve.cornel...@freescale.com Signed-off-by: Victoria Milhoan vicki.milh...@freescale.com --- drivers/crypto/caam/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/caam/Kconfig b/drivers/crypto/caam/Kconfig index e7555ff..bc9aa07 100644 --- a/drivers/crypto/caam/Kconfig +++ b/drivers/crypto/caam/Kconfig @@ -1,6 +1,6 @@ config CRYPTO_DEV_FSL_CAAM tristate Freescale CAAM-Multicore driver backend - depends on FSL_SOC + depends on FSL_SOC || ARCH_MXC Is this right? Are there other i.MX that have the CAAM IP core? Sounds like it should be SOC_IMX6 instead. Regards, Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v7 0/3] crypto: Introduce Public Key Encryption API
On Tue, Jun 16, 2015 at 10:30:50AM -0700, Tadeusz Struk wrote: This patch set introduces a Public Key Encryption API. What is proposed is a new crypto type called crypto_akcipher_type, plus new struct akcipher_alg and struct crypto_akcipher, together with number of helper functions to register akcipher type algorithms and allocate tfm instances. This is to make it similar to how the existing crypto API works for the ablkcipher, ahash, and aead types. The operations the new interface will allow to provide are: int (*sign)(struct akcipher_request *req); int (*verify)(struct akcipher_request *req); int (*encrypt)(struct akcipher_request *req); int (*decrypt)(struct akcipher_request *req); All applied with two minor changes. First of all I made AKCIPHER invisible to the user like the other type config options. I also added a missing select on ASN1 that broke my build. Thanks, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: poly1305 - Pass key as first two message blocks to each desc_ctx
On Tue, Jun 16, 2015 at 11:34:16AM +0200, Martin Willi wrote: The Poly1305 authenticator requires a unique key for each generated tag. This implies that we can't set the key per tfm, as multiple users set individual keys. Instead we pass a desc specific key as the first two blocks of the message to authenticate in update(). Signed-off-by: Martin Willi mar...@strongswan.org Patch applied. Thanks Martin! -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 05/14] crypto: marvell/CESA: add TDMA support
On Wed, Jun 17, 2015 at 09:45:33AM +0200, Boris Brezillon wrote: + ret = dma_map_sg(cesa_dev-dev, req-src, creq-src_nents, + DMA_TO_DEVICE); + if (!ret) + return -ENOMEM; + + creq-src_nents = ret; DMA-API-HOWTO says that you must retain the original nents and use it when you call dma_unmap_sg. So I'm afraid one more repost is needed :) Thanks, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 05/14] crypto: marvell/CESA: add TDMA support
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 boris.brezil...@free-electrons.com
Signed-off-by: Arnaud Ebalard a...@natisbad.org
---
Hi Herbert,
I send you this patch alone so that you can verify I'm now properly
manipulating the SG list. Once I have your confirmation I'll send
the whole series again and annoy all the people in Cc one more time
;-).
Best Regards,
Boris
drivers/crypto/Kconfig | 1 +
drivers/crypto/marvell/Makefile | 2 +-
drivers/crypto/marvell/cesa.c | 68 +++
drivers/crypto/marvell/cesa.h | 229 ++
drivers/crypto/marvell/cipher.c | 162 +++-
drivers/crypto/marvell/hash.c | 414 +++-
drivers/crypto/marvell/tdma.c | 224 ++
7 files changed, 1084 insertions(+), 16 deletions(-)
create mode 100644 drivers/crypto/marvell/tdma.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index cbc3d3d..cdca762 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -185,6 +185,7 @@ config CRYPTO_DEV_MARVELL_CESA
help
This driver allows you to utilize the Cryptographic Engines and
Security Accelerator (CESA) which can be found on the Armada 370.
+ This driver supports CPU offload through DMA transfers.
This driver is aimed at replacing the mv_cesa driver. This will only
happen once it has received proper testing.
diff --git a/drivers/crypto/marvell/Makefile b/drivers/crypto/marvell/Makefile
index 68d0982..0c12b13 100644
--- a/drivers/crypto/marvell/Makefile
+++ b/drivers/crypto/marvell/Makefile
@@ -1,2 +1,2 @@
obj-$(CONFIG_CRYPTO_DEV_MARVELL_CESA) += marvell-cesa.o
-marvell-cesa-objs := cesa.o cipher.o hash.o
+marvell-cesa-objs := cesa.o cipher.o hash.o tdma.o
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 76a6943..986f024 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -184,6 +184,7 @@ static const struct mv_cesa_caps armada_370_caps = {
.ncipher_algs = ARRAY_SIZE(armada_370_cipher_algs),
.ahash_algs = armada_370_ahash_algs,
.nahash_algs = ARRAY_SIZE(armada_370_ahash_algs),
+ .has_tdma = true,
};
static const struct of_device_id mv_cesa_of_match_table[] = {
@@ -192,6 +193,66 @@ static const struct of_device_id mv_cesa_of_match_table[]
= {
};
MODULE_DEVICE_TABLE(of, mv_cesa_of_match_table);
+static void
+mv_cesa_conf_mbus_windows(struct mv_cesa_engine *engine,
+ const struct mbus_dram_target_info *dram)
+{
+ void __iomem *iobase = engine-regs;
+ int i;
+
+ for (i = 0; i 4; i++) {
+ writel(0, iobase + CESA_TDMA_WINDOW_CTRL(i));
+ writel(0, iobase + CESA_TDMA_WINDOW_BASE(i));
+ }
+
+ for (i = 0; i dram-num_cs; i++) {
+ const struct mbus_dram_window *cs = dram-cs + i;
+
+ writel(((cs-size - 1) 0x) |
+ (cs-mbus_attr 8) |
+ (dram-mbus_dram_target_id 4) | 1,
+ iobase + CESA_TDMA_WINDOW_CTRL(i));
+ writel(cs-base, iobase + CESA_TDMA_WINDOW_BASE(i));
+ }
+}
+
+static int mv_cesa_dev_dma_init(struct mv_cesa_dev *cesa)
+{
+ struct device *dev = cesa-dev;
+ struct mv_cesa_dev_dma *dma;
+
+ if (!cesa-caps-has_tdma)
+ return 0;
+
+ dma = devm_kzalloc(dev, sizeof(*dma), GFP_KERNEL);
+ if (!dma)
+ return -ENOMEM;
+
+ dma-tdma_desc_pool = dmam_pool_create(tdma_desc, dev,
+ sizeof(struct mv_cesa_tdma_desc),
+ 16, 0);
+ if (!dma-tdma_desc_pool)
+ return -ENOMEM;
+
+ dma-op_pool = dmam_pool_create(cesa_op, dev,
+ sizeof(struct mv_cesa_op_ctx), 16, 0);
+ if (!dma-op_pool)
+ return -ENOMEM;
+
+ dma-cache_pool = dmam_pool_create(cesa_cache, dev,
+ CESA_MAX_HASH_BLOCK_SIZE, 1, 0);
+ if (!dma-cache_pool)
+ return -ENOMEM;
+
+ dma-padding_pool = dmam_pool_create(cesa_padding, dev, 72, 1, 0);
+ if (!dma-cache_pool)
+ return -ENOMEM;
+
+ cesa-dma = dma;
+
+ return 0;
+}
+
static int mv_cesa_get_sram(struct
Re: [PATCH] crypto: caam - fix non-64-bit write/read access
On Tue, 16 Jun 2015 12:59:07 +0200 Steffen Trumtrar s.trumt...@pengutronix.de wrote: The patch crypto: caam - Add definition of rd/wr_reg64 for little endian platform added support for little endian platforms to the CAAM driver. Namely a write and read function for 64 bit registers. The only user of this functions is the Job Ring driver (drivers/crypto/caam/jr.c). It uses the functions to set the DMA addresses for the input/output rings. However, at least in the default configuration, the least significant 32 bits are always in the base+0x0004 address; independent of the endianness of the bytes itself. That means the addresses do not change with the system endianness. DMA addresses are only 32 bits wide on non-64-bit systems, writing the upper 32 bits of this value to the register for the least significant bits results in the DMA address being set to 0. Fix this by always writing the registers in the same way. Suggested-by: Russell King li...@arm.linux.org.uk Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de --- This patch is only compile-tested for PowerPC and tested on ARM. According to the datasheets for i.MX6 and P1010 this should be correct, though. I can confirm that this patch works on both QorIQ/PowerPC and ARM devices. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
crypto: tcrypt - Add rfc4309(ccm(aes)) speed test
This patch adds a speed test for rfc4309(ccm(aes)) as mode 212.
Signed-off-by: Herbert Xu herb...@gondor.apana.org.au
---
crypto/tcrypt.c |5 +
crypto/tcrypt.h |1 +
2 files changed, 6 insertions(+)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 4b4a931..5146367 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -1761,6 +1761,11 @@ static int do_test(const char *alg, u32 type, u32 mask,
int m)
NULL, 0, 16, 8, aead_speed_template_20);
break;
+ case 212:
+ test_aead_speed(rfc4309(ccm(aes)), ENCRYPT, sec,
+ NULL, 0, 16, 8, aead_speed_template_19);
+ break;
+
case 300:
if (alg) {
test_hash_speed(alg, sec, generic_hash_speed_template);
diff --git a/crypto/tcrypt.h b/crypto/tcrypt.h
index 6c7e21a..6cc1b85 100644
--- a/crypto/tcrypt.h
+++ b/crypto/tcrypt.h
@@ -65,6 +65,7 @@ static u8 speed_template_32_64[] = {32, 64, 0};
/*
* AEAD speed tests
*/
+static u8 aead_speed_template_19[] = {19, 0};
static u8 aead_speed_template_20[] = {20, 0};
/*
--
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
crypto: tcrypt - Fixed AEAD speed test setup
The AEAD speed test SG list setup did not correctly mark the AD,
potentially causing a crash.
Signed-off-by: Herbert Xu herb...@gondor.apana.org.au
---
crypto/tcrypt.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 5146367..9f6f10b 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -258,12 +258,12 @@ static void sg_init_aead(struct scatterlist *sg, char
*xbuf[XBUFSIZE],
rem = buflen % PAGE_SIZE;
}
- sg_init_table(sg, np);
+ sg_init_table(sg, np + 1);
np--;
for (k = 0; k np; k++)
- sg_set_buf(sg[k], xbuf[k], PAGE_SIZE);
+ sg_set_buf(sg[k + 1], xbuf[k], PAGE_SIZE);
- sg_set_buf(sg[k], xbuf[k], rem);
+ sg_set_buf(sg[k + 1], xbuf[k], rem);
}
static void test_aead_speed(const char *algo, int enc, unsigned int secs,
@@ -337,8 +337,6 @@ static void test_aead_speed(const char *algo, int enc,
unsigned int secs,
do {
assoc = axbuf[0];
memset(assoc, 0xff, aad_size);
- sg_set_buf(sg[0], assoc, aad_size);
- sg_set_buf(sgout[0], assoc, aad_size);
if ((*keysize + *b_size) TVMEMSIZE * PAGE_SIZE) {
pr_err(template (%u) too big for tvmem
(%lu)\n,
@@ -374,12 +372,15 @@ static void test_aead_speed(const char *algo, int enc,
unsigned int secs,
goto out;
}
- sg_init_aead(sg[1], xbuf,
+ sg_init_aead(sg, xbuf,
*b_size + (enc ? authsize : 0));
- sg_init_aead(sgout[1], xoutbuf,
+ sg_init_aead(sgout, xoutbuf,
*b_size + (enc ? authsize : 0));
+ sg_set_buf(sg[0], assoc, aad_size);
+ sg_set_buf(sgout[0], assoc, aad_size);
+
aead_request_set_crypt(req, sg, sgout, *b_size, iv);
aead_request_set_ad(req, aad_size);
--
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 13/14] crypto: marvell/CESA: add support for Kirkwood and Dove SoCs
From: Arnaud Ebalard a...@natisbad.org
Add the Kirkwood and Dove SoC descriptions, and control the allhwsupport
module parameter to avoid probing the CESA IP when the old CESA driver is
enabled (unless it is explicitly requested to do so).
Signed-off-by: Arnaud Ebalard a...@natisbad.org
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 8e5ea72..a432633 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -215,6 +215,15 @@ static const struct mv_cesa_caps orion_caps = {
.has_tdma = false,
};
+static const struct mv_cesa_caps kirkwood_caps = {
+ .nengines = 1,
+ .cipher_algs = orion_cipher_algs,
+ .ncipher_algs = ARRAY_SIZE(orion_cipher_algs),
+ .ahash_algs = orion_ahash_algs,
+ .nahash_algs = ARRAY_SIZE(orion_ahash_algs),
+ .has_tdma = true,
+};
+
static const struct mv_cesa_caps armada_370_caps = {
.nengines = 1,
.cipher_algs = armada_370_cipher_algs,
@@ -235,6 +244,8 @@ static const struct mv_cesa_caps armada_xp_caps = {
static const struct of_device_id mv_cesa_of_match_table[] = {
{ .compatible = marvell,orion-crypto, .data = orion_caps },
+ { .compatible = marvell,kirkwood-crypto, .data = kirkwood_caps },
+ { .compatible = marvell,dove-crypto, .data = kirkwood_caps },
{ .compatible = marvell,armada-370-crypto, .data = armada_370_caps },
{ .compatible = marvell,armada-xp-crypto, .data = armada_xp_caps },
{ .compatible = marvell,armada-375-crypto, .data = armada_xp_caps },
@@ -383,7 +394,7 @@ static int mv_cesa_probe(struct platform_device *pdev)
caps = match-data;
}
- if (caps == orion_caps !allhwsupport)
+ if ((caps == orion_caps || caps == kirkwood_caps) !allhwsupport)
return -ENOTSUPP;
cesa = devm_kzalloc(dev, sizeof(*cesa), GFP_KERNEL);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 14/14] crypto: marvell/CESA: add DT bindings documentation
Add DT bindings documentation for the new marvell-cesa driver.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
.../devicetree/bindings/crypto/marvell-cesa.txt| 45 ++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/marvell-cesa.txt
diff --git a/Documentation/devicetree/bindings/crypto/marvell-cesa.txt
b/Documentation/devicetree/bindings/crypto/marvell-cesa.txt
new file mode 100644
index 000..c6c6a4a0
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/marvell-cesa.txt
@@ -0,0 +1,45 @@
+Marvell Cryptographic Engines And Security Accelerator
+
+Required properties:
+- compatible: should be one of the following string
+ marvell,orion-crypto
+ marvell,kirkwood-crypto
+ marvell,dove-crypto
+ marvell,armada-370-crypto
+ marvell,armada-xp-crypto
+ marvell,armada-375-crypto
+ marvell,armada-38x-crypto
+- reg: base physical address of the engine and length of memory mapped
+ region. Can also contain an entry for the SRAM attached to the CESA,
+ but this representation is deprecated and marvell,crypto-srams should
+ be used instead
+- reg-names: regs. Can contain an sram entry, but this representation
+is deprecated and marvell,crypto-srams should be used instead
+- interrupts: interrupt number
+- clocks: reference to the crypto engines clocks. This property is not
+ required for orion and kirkwood platforms
+- clock-names: cesaX and cesazX, X should be replaced by the crypto engine
+ id.
+ This property is not required for the orion and kirkwoord
+ platforms.
+ cesazX clocks are not required on armada-370 platforms
+- marvell,crypto-srams: phandle to crypto SRAM definitions
+
+Optional properties:
+- marvell,crypto-sram-size: SRAM size reserved for crypto operations, if not
+ specified the whole SRAM is used (2KB)
+
+
+Examples:
+
+ crypto@9 {
+ compatible = marvell,armada-xp-crypto;
+ reg = 0x9 0x1;
+ reg-names = regs;
+ interrupts = 48, 49;
+ clocks = gateclk 23, gateclk 23;
+ clock-names = cesa0, cesa1;
+ marvell,crypto-srams = crypto_sram0, crypto_sram1;
+ marvell,crypto-sram-size = 0x600;
+ status = okay;
+ };
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 11/14] crypto: marvell/CESA: add allhwsupport module parameter
The old and new marvell CESA drivers both support Orion and Kirkwood SoCs. Add a module parameter to choose whether these SoCs should be attached to the new or the old driver. The default policy is to keep attaching those IPs to the old driver if it is enabled, until we decide the new CESA driver is stable/secure enough. Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com --- drivers/crypto/marvell/cesa.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c index af590bf..a05b5cb 100644 --- a/drivers/crypto/marvell/cesa.c +++ b/drivers/crypto/marvell/cesa.c @@ -31,6 +31,10 @@ #include cesa.h +static int allhwsupport = !IS_ENABLED(CONFIG_CRYPTO_DEV_MV_CESA); +module_param_named(allhwsupport, allhwsupport, int, 0444); +MODULE_PARM_DESC(allhwsupport, Enable support for all hardware (even it if overlaps with the mv_cesa driver)); + struct mv_cesa_dev *cesa_dev; static void mv_cesa_dequeue_req_unlocked(struct mv_cesa_engine *engine) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 05/14] crypto: marvell/CESA: add TDMA support
On Wed, Jun 17, 2015 at 03:32:02PM +0200, Boris Brezillon wrote: Hi Herbert, I send you this patch alone so that you can verify I'm now properly manipulating the SG list. Once I have your confirmation I'll send the whole series again and annoy all the people in Cc one more time ;-). Thanks. The only problem that I can see is the fact you're not checking for req-src == req-dst. If they're equal then you must not map it twice. Instead it should be mapped as DMA_BIDIRECTIONAL. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 05/14] crypto: marvell/CESA: add TDMA support
On Wed, 17 Jun 2015 23:08:08 +0800 Herbert Xu herb...@gondor.apana.org.au wrote: On Wed, Jun 17, 2015 at 03:32:02PM +0200, Boris Brezillon wrote: Hi Herbert, I send you this patch alone so that you can verify I'm now properly manipulating the SG list. Once I have your confirmation I'll send the whole series again and annoy all the people in Cc one more time ;-). Thanks. The only problem that I can see is the fact you're not checking for req-src == req-dst. If they're equal then you must not map it twice. Instead it should be mapped as DMA_BIDIRECTIONAL. I can check for that too, but note that it doesn't prevent one from providing different scatterlist structures pointing to the same memory region. This being said, checking for req-src == req-dst should fix the case where dst and src are pointing to the same scatterlist, which is a good start. Thanks, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v7 0/3] crypto: Introduce Public Key Encryption API
On 06/17/2015 02:14 AM, Herbert Xu wrote: This patch set introduces a Public Key Encryption API. What is proposed is a new crypto type called crypto_akcipher_type, plus new struct akcipher_alg and struct crypto_akcipher, together with number of helper functions to register akcipher type algorithms and allocate tfm instances. This is to make it similar to how the existing crypto API works for the ablkcipher, ahash, and aead types. The operations the new interface will allow to provide are: int (*sign)(struct akcipher_request *req); int (*verify)(struct akcipher_request *req); int (*encrypt)(struct akcipher_request *req); int (*decrypt)(struct akcipher_request *req); All applied with two minor changes. First of all I made AKCIPHER invisible to the user like the other type config options. I also added a missing select on ASN1 that broke my build. Thank you very much for all your help with this Herbert -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
