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
In addition to this driver comes a bunch of DT updates adding crypto device
nodes to several Marvell SoCs (those are only the tested ones, others might
be added later).
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.
Best Regards,
Boris
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 (6):
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 SoCs
ARM: marvell/dt: add crypto node to armada 370 dtsi
ARM: marvell/dt: add crypto node to kirkwood dtsi
Boris Brezillon (10):
crypto: mv_cesa: request registers memory region
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: update DT bindings documentation
ARM: marvell/dt: add crypto node to armada-xp.dtsi
ARM: marvell/dt: enable crypto on armada-xp-gp
.../devicetree/bindings/crypto/marvell-cesa.txt | 46 +
arch/arm/boot/dts/armada-370.dtsi | 20 +
arch/arm/boot/dts/armada-xp-gp.dts | 4 +-
arch/arm/boot/dts/armada-xp.dtsi | 31 +
arch/arm/boot/dts/kirkwood.dtsi | 2 +-
drivers/crypto/Kconfig | 18 +
drivers/crypto/Makefile | 1 +
drivers/crypto/marvell/Makefile | 2 +
drivers/crypto/marvell/cesa.c | 543 ++++++++
drivers/crypto/marvell/cesa.h | 804 ++++++++++++
drivers/crypto/marvell/cipher.c | 769 +++++++++++
drivers/crypto/marvell/hash.c | 1349 ++++++++++++++++++++
drivers/crypto/marvell/tdma.c | 224 ++++
drivers/crypto/mv_cesa.c | 13 +-
14 files changed, 3816 insertions(+), 10 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
The mv_cesa driver does not request the CESA registers memory region.
Since we're about to add a new CESA driver, we need to make sure only one
of these drivers probe the CESA device, and requesting the registers memory
region is a good way to achieve that.
Signed-off-by: Boris Brezillon <[email protected]>
---
drivers/crypto/mv_cesa.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index f91f15d..27b2373 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -1041,23 +1041,23 @@ static int mv_probe(struct platform_device *pdev)
spin_lock_init(&cp->lock);
crypto_init_queue(&cp->queue, 50);
- cp->reg = ioremap(res->start, resource_size(res));
- if (!cp->reg) {
- ret = -ENOMEM;
+ cp->reg = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(cp->reg)) {
+ ret = PTR_ERR(cp->reg);
goto err;
}
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sram");
if (!res) {
ret = -ENXIO;
- goto err_unmap_reg;
+ goto err;
}
cp->sram_size = resource_size(res);
cp->max_req_size = cp->sram_size - SRAM_CFG_SPACE;
cp->sram = ioremap(res->start, cp->sram_size);
if (!cp->sram) {
ret = -ENOMEM;
- goto err_unmap_reg;
+ goto err;
}
if (pdev->dev.of_node)
@@ -1136,8 +1136,6 @@ err_thread:
kthread_stop(cp->queue_th);
err_unmap_sram:
iounmap(cp->sram);
-err_unmap_reg:
- iounmap(cp->reg);
err:
kfree(cp);
cpg = NULL;
@@ -1158,7 +1156,6 @@ static int mv_remove(struct platform_device *pdev)
free_irq(cp->irq, cp);
memset(cp->sram, 0, cp->sram_size);
iounmap(cp->sram);
- iounmap(cp->reg);
if (!IS_ERR(cp->clk)) {
clk_disable_unprepare(cp->clk);
--
1.9.1
From: Arnaud Ebalard <[email protected]>
Add support for MD5 operations.
Signed-off-by: Arnaud Ebalard <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/hash.c | 142 +++++++++++++++++++++++++++++++++++++++++-
3 files changed, 144 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index b1f7d38..092304a 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -174,7 +174,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 d886280..23c4603 100644
--- a/drivers/crypto/marvell/cesa.h
+++ b/drivers/crypto/marvell/cesa.h
@@ -787,7 +787,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 94b3f97..644c97d 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);
}
@@ -786,6 +795,67 @@ 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_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,
+ .halg = {
+ .digestsize = MD5_DIGEST_SIZE,
+ .base = {
+ .cra_name = "md5",
+ .cra_driver_name = "mv-md5",
+ .cra_priority = 300,
+ .cra_flags = CRYPTO_ALG_ASYNC |
+ CRYPTO_ALG_KERN_DRIVER_ONLY,
+ .cra_blocksize = MD5_HMAC_BLOCK_SIZE,
+ .cra_ctxsize = sizeof(struct mv_cesa_hash_ctx),
+ .cra_init = mv_cesa_ahash_cra_init,
+ .cra_module = THIS_MODULE,
+ }
+ }
+};
+
static int mv_cesa_sha1_init(struct ahash_request *req)
{
struct mv_cesa_op_ctx tmpl;
@@ -1013,6 +1083,74 @@ static int mv_cesa_ahmac_cra_init(struct crypto_tfm *tfm)
return 0;
}
+static int mv_cesa_ahmac_md5_init(struct ahash_request *req)
+{
+ struct mv_cesa_hmac_ctx *ctx = crypto_tfm_ctx(req->base.tfm);
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(&tmpl, CESA_SA_DESC_CFG_MACM_HMAC_MD5);
+ memcpy(tmpl.ctx.hash.iv, ctx->iv, sizeof(ctx->iv));
+
+ mv_cesa_ahash_init(req, &tmpl);
+
+ return 0;
+}
+
+static int mv_cesa_ahmac_md5_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 md5_state istate, ostate;
+ int ret, i;
+
+ ret = mv_cesa_ahmac_setkey("mv-md5", key, keylen, &istate, &ostate);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < ARRAY_SIZE(istate.hash); i++)
+ ctx->iv[i] = be32_to_cpu(istate.hash[i]);
+
+ for (i = 0; i < ARRAY_SIZE(ostate.hash); i++)
+ ctx->iv[i + 8] = be32_to_cpu(ostate.hash[i]);
+
+ return 0;
+}
+
+static int mv_cesa_ahmac_md5_digest(struct ahash_request *req)
+{
+ int ret;
+
+ ret = mv_cesa_ahmac_md5_init(req);
+ if (ret)
+ return ret;
+
+ return mv_cesa_ahash_finup(req);
+}
+
+struct ahash_alg mv_ahmac_md5_alg = {
+ .init = mv_cesa_ahmac_md5_init,
+ .update = mv_cesa_ahash_update,
+ .final = mv_cesa_ahash_final,
+ .finup = mv_cesa_ahash_finup,
+ .digest = mv_cesa_ahmac_md5_digest,
+ .setkey = mv_cesa_ahmac_md5_setkey,
+ .halg = {
+ .digestsize = MD5_DIGEST_SIZE,
+ .statesize = sizeof(struct md5_state),
+ .base = {
+ .cra_name = "hmac(md5)",
+ .cra_driver_name = "mv-hmac-md5",
+ .cra_priority = 300,
+ .cra_flags = CRYPTO_ALG_ASYNC |
+ CRYPTO_ALG_KERN_DRIVER_ONLY,
+ .cra_blocksize = MD5_HMAC_BLOCK_SIZE,
+ .cra_ctxsize = sizeof(struct mv_cesa_hmac_ctx),
+ .cra_init = mv_cesa_ahmac_cra_init,
+ .cra_module = THIS_MODULE,
+ }
+ }
+};
+
static int mv_cesa_ahmac_sha1_init(struct ahash_request *req)
{
struct mv_cesa_hmac_ctx *ctx = crypto_tfm_ctx(req->base.tfm);
--
1.9.1
From: Arnaud Ebalard <[email protected]>
Add support for SHA256 operations.
Signed-off-by: Arnaud Ebalard <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/hash.c | 129 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 133 insertions(+)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 092304a..55fa6e8 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -176,8 +176,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 23c4603..497746b 100644
--- a/drivers/crypto/marvell/cesa.h
+++ b/drivers/crypto/marvell/cesa.h
@@ -789,8 +789,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 644c97d..890607b 100644
--- a/drivers/crypto/marvell/hash.c
+++ b/drivers/crypto/marvell/hash.c
@@ -917,6 +917,67 @@ 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;
+}
+
+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,
+ .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;
@@ -1218,3 +1279,71 @@ 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;
+
+ ret = mv_cesa_ahmac_setkey("mv-sha256", key, keylen, &istate, &ostate);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < ARRAY_SIZE(istate.state); i++)
+ ctx->iv[i] = be32_to_cpu(istate.state[i]);
+
+ for (i = 0; i < ARRAY_SIZE(ostate.state); i++)
+ ctx->iv[i + 8] = be32_to_cpu(ostate.state[i]);
+
+ return 0;
+}
+
+static int mv_cesa_ahmac_sha256_init(struct ahash_request *req)
+{
+ struct mv_cesa_hmac_ctx *ctx = crypto_tfm_ctx(req->base.tfm);
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(&tmpl, CESA_SA_DESC_CFG_MACM_HMAC_SHA256);
+ memcpy(tmpl.ctx.hash.iv, ctx->iv, sizeof(ctx->iv));
+
+ mv_cesa_ahash_init(req, &tmpl);
+
+ return 0;
+}
+
+static int mv_cesa_ahmac_sha256_digest(struct ahash_request *req)
+{
+ int ret;
+
+ ret = mv_cesa_ahmac_sha256_init(req);
+ if (ret)
+ return ret;
+
+ return mv_cesa_ahash_finup(req);
+}
+
+struct ahash_alg mv_ahmac_sha256_alg = {
+ .init = mv_cesa_ahmac_sha256_init,
+ .update = mv_cesa_ahash_update,
+ .final = mv_cesa_ahash_final,
+ .finup = mv_cesa_ahash_finup,
+ .digest = mv_cesa_ahmac_sha256_digest,
+ .setkey = mv_cesa_ahmac_sha256_setkey,
+ .halg = {
+ .digestsize = SHA256_DIGEST_SIZE,
+ .statesize = sizeof(struct sha256_state),
+ .base = {
+ .cra_name = "hmac(sha256)",
+ .cra_driver_name = "mv-hmac-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_hmac_ctx),
+ .cra_init = mv_cesa_ahmac_cra_init,
+ .cra_module = THIS_MODULE,
+ }
+ }
+};
--
1.9.1
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 <[email protected]>
---
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 f763981..a7a7e0e 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -168,6 +168,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,
@@ -186,6 +202,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,
@@ -205,6 +230,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 },
@@ -330,7 +356,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;
@@ -345,14 +371,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
Add crypto related nodes to armada-xp.dtsi.
Signed-off-by: Boris Brezillon <[email protected]>
---
arch/arm/boot/dts/armada-xp.dtsi | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 013d63f..a12a81f 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -220,6 +220,19 @@
};
};
+ crypto@90000 {
+ compatible = "marvell,armada-xp-crypto";
+ reg = <0x90000 0x10000>;
+ 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";
+ };
+
xor@f0900 {
compatible = "marvell,orion-xor";
reg = <0xF0900 0x100
@@ -240,6 +253,24 @@
};
};
};
+
+ crypto_sram0: sa-sram0 {
+ compatible = "mmio-sram";
+ reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 MBUS_ID(0x09, 0x09) 0 0x800>;
+ status = "okay";
+ };
+
+ crypto_sram1: sa-sram1 {
+ compatible = "mmio-sram";
+ reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 MBUS_ID(0x09, 0x05) 0 0x800>;
+ status = "okay";
+ };
};
clocks {
--
1.9.1
From: Arnaud Ebalard <[email protected]>
Add the Kirkwood SoC description, 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 <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
---
drivers/crypto/marvell/cesa.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index a7a7e0e..16f9364 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -211,6 +211,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,
@@ -231,6 +240,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,kirkwood-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 },
@@ -379,7 +389,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
Enable the crypto IP on armada-xp-gp.
Signed-off-by: Boris Brezillon <[email protected]>
---
arch/arm/boot/dts/armada-xp-gp.dts | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 565227e..8a739f4 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -94,7 +94,9 @@
soc {
ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000
MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
- MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000>;
+ MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000
+ MBUS_ID(0x09, 0x09) 0 0 0xf1100000 0x10000
+ MBUS_ID(0x09, 0x05) 0 0 0xf1110000 0x10000>;
devbus-bootcs {
status = "okay";
--
1.9.1
+ Jason Gunthorpe, he may be interested in this.
On Fri, May 22, 2015 at 03:33:46PM +0200, Boris Brezillon wrote:
> 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
>
> In addition to this driver comes a bunch of DT updates adding crypto device
> nodes to several Marvell SoCs (those are only the tested ones, others might
> be added later).
>
> 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.
>
> Best Regards,
>
> Boris
>
> 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 (6):
> 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 SoCs
> ARM: marvell/dt: add crypto node to armada 370 dtsi
> ARM: marvell/dt: add crypto node to kirkwood dtsi
>
> Boris Brezillon (10):
> crypto: mv_cesa: request registers memory region
> 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: update DT bindings documentation
> ARM: marvell/dt: add crypto node to armada-xp.dtsi
> ARM: marvell/dt: enable crypto on armada-xp-gp
>
> .../devicetree/bindings/crypto/marvell-cesa.txt | 46 +
> arch/arm/boot/dts/armada-370.dtsi | 20 +
> arch/arm/boot/dts/armada-xp-gp.dts | 4 +-
> arch/arm/boot/dts/armada-xp.dtsi | 31 +
> arch/arm/boot/dts/kirkwood.dtsi | 2 +-
> drivers/crypto/Kconfig | 18 +
> drivers/crypto/Makefile | 1 +
> drivers/crypto/marvell/Makefile | 2 +
> drivers/crypto/marvell/cesa.c | 543 ++++++++
> drivers/crypto/marvell/cesa.h | 804 ++++++++++++
> drivers/crypto/marvell/cipher.c | 769 +++++++++++
> drivers/crypto/marvell/hash.c | 1349 ++++++++++++++++++++
> drivers/crypto/marvell/tdma.c | 224 ++++
> drivers/crypto/mv_cesa.c | 13 +-
> 14 files changed, 3816 insertions(+), 10 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
>
On Fri, May 22, 2015 at 03:33:47PM +0200, Boris Brezillon wrote:
> The mv_cesa driver does not request the CESA registers memory region.
> Since we're about to add a new CESA driver, we need to make sure only one
> of these drivers probe the CESA device, and requesting the registers memory
> region is a good way to achieve that.
>
> Signed-off-by: Boris Brezillon <[email protected]>
Patch applied.
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Hi Boris,
On 22/05/2015 15:34, Boris Brezillon wrote:
> Enable the crypto IP on armada-xp-gp.
>
> Signed-off-by: Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/[email protected]>
> ---
> arch/arm/boot/dts/armada-xp-gp.dts | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
> index 565227e..8a739f4 100644
> --- a/arch/arm/boot/dts/armada-xp-gp.dts
> +++ b/arch/arm/boot/dts/armada-xp-gp.dts
> @@ -94,7 +94,9 @@
> soc {
> ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000
> MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
> - MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000>;
> + MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000
> + MBUS_ID(0x09, 0x09) 0 0 0xf1100000 0x10000
> + MBUS_ID(0x09, 0x05) 0 0 0xf1110000 0x10000>;
As the crypto engine really depend on the SoC itself and not of the board,
what about updating the dts of the other board using an Armada XP?
Thanks,
Gregory
>
> devbus-bootcs {
> status = "okay";
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
Hi Boris,
On 22/05/2015 15:33, Boris Brezillon wrote:
> Add crypto related nodes to armada-xp.dtsi.
>
> Signed-off-by: Boris Brezillon <[email protected]>
>From the point of view of the mvebu it looks OK:
Acked-by: Gregory CLEMENT <[email protected]>
But of course, I will wait for that the driver will be merged before
applying it, or at least that the crypto maintainers validate the
binding.
Thanks,
Gregory
> ---
> arch/arm/boot/dts/armada-xp.dtsi | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
> index 013d63f..a12a81f 100644
> --- a/arch/arm/boot/dts/armada-xp.dtsi
> +++ b/arch/arm/boot/dts/armada-xp.dtsi
> @@ -220,6 +220,19 @@
> };
> };
>
> + crypto@90000 {
> + compatible = "marvell,armada-xp-crypto";
> + reg = <0x90000 0x10000>;
> + 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";
> + };
> +
> xor@f0900 {
> compatible = "marvell,orion-xor";
> reg = <0xF0900 0x100
> @@ -240,6 +253,24 @@
> };
> };
> };
> +
> + crypto_sram0: sa-sram0 {
> + compatible = "mmio-sram";
> + reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 MBUS_ID(0x09, 0x09) 0 0x800>;
> + status = "okay";
> + };
> +
> + crypto_sram1: sa-sram1 {
> + compatible = "mmio-sram";
> + reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 MBUS_ID(0x09, 0x05) 0 0x800>;
> + status = "okay";
> + };
> };
>
> clocks {
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
On Mon, 25 May 2015 17:10:37 +0200
Gregory CLEMENT <[email protected]> wrote:
> Hi Boris,
>
> On 22/05/2015 15:34, Boris Brezillon wrote:
> > Enable the crypto IP on armada-xp-gp.
> >
> > Signed-off-by: Boris Brezillon <[email protected]>
> > ---
> > arch/arm/boot/dts/armada-xp-gp.dts | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
> > index 565227e..8a739f4 100644
> > --- a/arch/arm/boot/dts/armada-xp-gp.dts
> > +++ b/arch/arm/boot/dts/armada-xp-gp.dts
> > @@ -94,7 +94,9 @@
> > soc {
> > ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000
> > MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
> > - MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000>;
> > + MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000
> > + MBUS_ID(0x09, 0x09) 0 0 0xf1100000 0x10000
> > + MBUS_ID(0x09, 0x05) 0 0 0xf1110000 0x10000>;
>
> As the crypto engine really depend on the SoC itself and not of the board,
> what about updating the dts of the other board using an Armada XP?
But that means introducing changes I haven't tested. Are you okay with
that ?
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
On Tue, 26 May 2015 10:59:36 +0200, Boris Brezillon
<[email protected]> wrote:
<snip>
>> As the crypto engine really depend on the SoC itself and not of the
>> board,
>> what about updating the dts of the other board using an Armada XP?
>
> But that means introducing changes I haven't tested. Are you okay with
> that ?
Well, worst case send it as a separate patch as RFC - I'm sure people will
test and report back.
Cheers,
Imre
On Tue, May 26, 2015 at 11:22:45AM +0200, Imre Kaloz wrote:
> On Tue, 26 May 2015 10:59:36 +0200, Boris Brezillon
> <[email protected]> wrote:
>
> <snip>
>
> >>As the crypto engine really depend on the SoC itself and not of
> >>the board,
> >>what about updating the dts of the other board using an Armada XP?
> >
> >But that means introducing changes I haven't tested. Are you okay with
> >that ?
>
> Well, worst case send it as a separate patch as RFC - I'm sure
> people will test and report back.
Yes, there are a few of us with diverse hardware that can perform
tests. It is best if you provide a git tree with all the patches
applied, and instructions how to test.
Andrew
On 26/05/2015 10:59, Boris Brezillon wrote:
> On Mon, 25 May 2015 17:10:37 +0200
> Gregory CLEMENT <[email protected]> wrote:
>
>> Hi Boris,
>>
>> On 22/05/2015 15:34, Boris Brezillon wrote:
>>> Enable the crypto IP on armada-xp-gp.
>>>
>>> Signed-off-by: Boris Brezillon <[email protected]>
>>> ---
>>> arch/arm/boot/dts/armada-xp-gp.dts | 4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
>>> index 565227e..8a739f4 100644
>>> --- a/arch/arm/boot/dts/armada-xp-gp.dts
>>> +++ b/arch/arm/boot/dts/armada-xp-gp.dts
>>> @@ -94,7 +94,9 @@
>>> soc {
>>> ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000
>>> MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
>>> - MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000>;
>>> + MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000
>>> + MBUS_ID(0x09, 0x09) 0 0 0xf1100000 0x10000
>>> + MBUS_ID(0x09, 0x05) 0 0 0xf1110000 0x10000>;
>>
>> As the crypto engine really depend on the SoC itself and not of the board,
>> what about updating the dts of the other board using an Armada XP?
>
> But that means introducing changes I haven't tested. Are you okay with
> that ?
Maybe I missed something but as the crypto is fully integrated in the SoC,
if for a given SoC it works on a board it would work on all the boards using
the same SoC.
The board specific part seems about setting memory address on the mbus.
By the way could you add a comment in front of the new line ? so next time
someone will copy and past one of the dts file, he will understand the
signification of these two lines.
But is it really depending of the board itself?
I see that the first lines are the same on all the dts, I just remember that
there was a reason why we could not put it in the dtsi. My point here, is as
the configuration is the same on all the boards, adding the crypto on all the
board should work without any issue.
Thanks,
Gregory
>
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
Dear Gregory CLEMENT,
On Wed, 27 May 2015 12:20:49 +0200, Gregory CLEMENT wrote:
> But is it really depending of the board itself?
> I see that the first lines are the same on all the dts, I just remember that
> there was a reason why we could not put it in the dtsi.
Yes, because the DT language doesn't have a += operator, basically.
Some of the MBus ranges are inherently board-specific: when you have a
NOR flash, you need a specific MBus range for it. And such a MBus range
is board-specific.
Since it's not possible to do:
ranges = <SoC level ranges>
in .dtsi, and:
ranges += <board level ranges>
in .dts, we simply decided to always put:
ranges = <SoC level and board level ranges>
in the .dts.
It does create some duplication, but that's the best we could do with
the existing DT infrastructure.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
Hi Thomas, Boris,
On 27/05/2015 13:23, Thomas Petazzoni wrote:
> Dear Gregory CLEMENT,
>
> On Wed, 27 May 2015 12:20:49 +0200, Gregory CLEMENT wrote:
>
>> But is it really depending of the board itself?
>> I see that the first lines are the same on all the dts, I just remember that
>> there was a reason why we could not put it in the dtsi.
>
> Yes, because the DT language doesn't have a += operator, basically.
>
> Some of the MBus ranges are inherently board-specific: when you have a
> NOR flash, you need a specific MBus range for it. And such a MBus range
> is board-specific.
>
> Since it's not possible to do:
>
> ranges = <SoC level ranges>
>
> in .dtsi, and:
>
> ranges += <board level ranges>
>
> in .dts, we simply decided to always put:
>
> ranges = <SoC level and board level ranges>
>
> in the .dts.
>
> It does create some duplication, but that's the best we could do with
> the existing DT infrastructure.
Thanks for the remainder.
So I think we should duplicate the crypto related part in all the dts
file which use an Armada XP SoC. And we don't have to test it again
as soon as it was tested on an Armada XP board (and it is the case
with the Armada XP one).
Gregory
>
> Best regards,
>
> Thomas
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
Dear Gregory CLEMENT,
On Wed, 27 May 2015 13:33:37 +0200, Gregory CLEMENT wrote:
> So I think we should duplicate the crypto related part in all the dts
> file which use an Armada XP SoC. And we don't have to test it again
> as soon as it was tested on an Armada XP board (and it is the case
> with the Armada XP one).
Yes, I also believe that the board-level changes are trivial enough
that if it's been tested to work on a given board using the Armada XP,
we can replicate to all Armada XP .dts files and have good confidence
that a review is sufficient to say it will work on the other boards.
Of course, we need at least one tested board for each SoC, however.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com