gmane.linux.kernel.cryptoapi

(unknown)

robothroli company — 2012-05-25T13:45:54

 i am robothroli, Purchase manager from roli Merchant Ltd. We are
Import/export Company based in taiwan. We are interested in purchasing
your product and I would like to make an inquiry. Please inform me on:

Sample availability and price
Minimum order quantity
FOB Prices

Sincerely
Purchase Manager
robothroli

RFC: support for MV_CESA with TDMA

Phil Sutter — 2012-05-25T16:08:26

Hi,

The following patch series adds support for the TDMA engine built into
Marvell's Kirkwood-based SoCs, and enhances mv_cesa.c in order to use it
for speeding up crypto operations. Kirkwood hardware contains a security
accelerator, which can control DMA as well as crypto engines. It allows
for operation with minimal software intervenience, which the following
patches implement: using a chain of DMA descriptors, data input,
configuration, engine startup and data output repeat fully automatically
until the whole input data has been handled.

The point for this being RFC is backwards-compatibility: earlier
hardware (Orion) ships a (slightly) different DMA engine (IDMA) along
with the same crypto engine, so in fact mv_cesa.c is in use on these
platforms, too. But since I don't possess hardware of this kind, I am
not able to make this code IDMA-compatible. Also, due to the quite
massive reorganisation of code flow, I don't really see how to make TDMA
support optional in mv_cesa.c.

Greetings, Phil

[PATCH 01/13] mv_cesa: do not use scatterlist iterators

Phil Sutter — 2012-05-25T16:08:27

The big problem is they cannot be used to iterate over DMA mapped
scatterlists, so get rid of them in order to add DMA functionality to
mv_cesa.

Signed-off-by: Phil Sutter <phil.sutter< at >viprinet.com>
---
 drivers/crypto/mv_cesa.c |   57 ++++++++++++++++++++++-----------------------
 1 files changed, 28 insertions(+), 29 deletions(-)

diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 3cc9237..c305350 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
< at >< at > -43,8 +43,8 < at >< at > enum engine_status {
 
 /**
  * struct req_progress - used for every crypt request
- * < at >src_sg_it:sg iterator for src
- * < at >dst_sg_it:sg iterator for dst
+ * < at >src_sg:sg list for src
+ * < at >dst_sg:sg list for dst
  * < at >sg_src_left:bytes left in src to process (scatter list)
  * < at >src_start:offset to add to src start position (scatter list)
  * < at >crypt_len:length of current hw crypt/hash process
< at >< at > -59,8 +59,8 < at >< at > enum engine_status {
  * track of progress within current scatterlist.
  */
 struct req_pr

[PATCH 03/13] mv_cesa: prepare the full sram config in dram

Phil Sutter — 2012-05-25T16:08:29

This way reconfiguring the cryptographic accelerator consists of a
single step (memcpy here), which in future can be done by the tdma
engine.

This patch introduces some ugly IV copying, necessary for input buffers
above 1920bytes. But this will go away later.

Signed-off-by: Phil Sutter <phil.sutter< at >viprinet.com>
---
 drivers/crypto/mv_cesa.c |   83 ++++++++++++++++++++++++++++-----------------
 1 files changed, 52 insertions(+), 31 deletions(-)

diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 3862a93..68b83d8 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
< at >< at > -76,6 +76,24 < at >< at > struct req_progress {
 int hw_processed_bytes;
 };
 
+struct sec_accel_sram {
+struct sec_accel_config op;
+union {
+struct {
+u32 key[8];
+u32 iv[4];
+} crypt;
+struct {
+u32 ivi[5];
+u32 ivo[5];
+} hash;
+} type;
+#define sa_keytype.crypt.key
+#define sa_ivtype.crypt.iv
+#define sa_ivitype.hash.ivi
+#define sa_ivotype.hash.ivo
+} __attribute__((packed));
+
 struc

[PATCH 05/13] add a driver for the Marvell TDMA engine

Phil Sutter — 2012-05-25T16:08:31

This is a DMA engine integrated into the Marvell Kirkwood SoC, designed
to offload data transfers from/to the CESA crypto engine.

Signed-off-by: Phil Sutter <phil.sutter< at >viprinet.com>
---
 arch/arm/mach-kirkwood/common.c            |   33 +++
 arch/arm/mach-kirkwood/include/mach/irqs.h |    1 +
 drivers/crypto/Kconfig                     |    5 +
 drivers/crypto/Makefile                    |    3 +-
 drivers/crypto/mv_tdma.c                   |  377 ++++++++++++++++++++++++++++
 drivers/crypto/mv_tdma.h                   |   50 ++++
 6 files changed, 468 insertions(+), 1 deletions(-)
 create mode 100644 drivers/crypto/mv_tdma.c
 create mode 100644 drivers/crypto/mv_tdma.h

diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
index 3ad0373..adc6eff 100644
--- a/arch/arm/mach-kirkwood/common.c
+++ b/arch/arm/mach-kirkwood/common.c
< at >< at > -269,9 +269,42 < at >< at > void __init kirkwood_uart1_init(void)
 /*****************************************************************************
  * Cryptographi

[PATCH 09/13] mv_cesa: implementing packet chain mode, only aes for now

Phil Sutter — 2012-05-25T16:08:35

This introduces a pool of four-byte DMA buffers for security
accelerator config updates.

Signed-off-by: Phil Sutter <phil.sutter< at >viprinet.com>
---
 drivers/crypto/mv_cesa.c |  134 ++++++++++++++++++++++++++++++++++++----------
 drivers/crypto/mv_cesa.h |    1 +
 2 files changed, 106 insertions(+), 29 deletions(-)

diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index bc2692e..8e66080 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
< at >< at > -10,6 +10,7 < at >< at >
 #include <crypto/algapi.h>
 #include <linux/crypto.h>
 #include <linux/dma-mapping.h>
+#include <linux/dmapool.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
 #include <linux/kthread.h>
< at >< at > -27,6 +28,9 < at >< at >
 #define MAX_HW_HASH_SIZE0xFFFF
 #define MV_CESA_EXPIRE500 /* msec */
 
+#define MV_DMA_INIT_POOLSIZE 16
+#define MV_DMA_ALIGN 16
+
 static int count_sgs(struct scatterlist *, unsigned int);
 
 /*
< at >< at > -96,6 +100,11 < at >< at > struct sec_accel_sram {
 #define sa_ivotype.hash.ivo
 } __attribute__((packed));
 
+struct u32_m

[PATCH 12/13] mv_cesa: drop the now unused process callback

Phil Sutter — 2012-05-25T16:08:38

And while here, simplify dequeue_complete_req() a bit.

Signed-off-by: Phil Sutter <phil.sutter< at >viprinet.com>
---
 drivers/crypto/mv_cesa.c |   21 ++++++---------------
 1 files changed, 6 insertions(+), 15 deletions(-)

diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 9afed2d..9a2f413 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
< at >< at > -69,7 +69,6 < at >< at > struct req_progress {
 struct scatterlist *src_sg;
 struct scatterlist *dst_sg;
 void (*complete) (void);
-void (*process) (void);
 
 /* src mostly */
 int sg_src_left;
< at >< at > -648,25 +647,17 < at >< at > static void mv_hash_algo_completion(void)
 static void dequeue_complete_req(void)
 {
 struct crypto_async_request *req = cpg->cur_req;
-cpg->p.hw_processed_bytes += cpg->p.crypt_len;
-cpg->p.crypt_len = 0;
 
 mv_tdma_clear();
 cpg->u32_usage = 0;
 
 BUG_ON(cpg->eng_st != ENGINE_W_DEQUEUE);
-if (cpg->p.hw_processed_bytes < cpg->p.hw_nbytes) {
-/* process next scatter list entry */
-cpg->eng_st = ENGINE_BUSY;
-setup

[PATCH 06/13] mv_cesa: use TDMA engine for data transfers

Phil Sutter — 2012-05-25T16:08:32

Simply chose the same DMA mask value as for mvsdio and ehci.

Signed-off-by: Phil Sutter <phil.sutter< at >viprinet.com>
---
 arch/arm/plat-orion/common.c |    6 +
 drivers/crypto/mv_cesa.c     |  214 +++++++++++++++++++++++++++++++++---------
 2 files changed, 175 insertions(+), 45 deletions(-)

diff --git a/arch/arm/plat-orion/common.c b/arch/arm/plat-orion/common.c
index 74daf5e..dd3a327 100644
--- a/arch/arm/plat-orion/common.c
+++ b/arch/arm/plat-orion/common.c
< at >< at > -916,9 +916,15 < at >< at > static struct resource orion_crypto_resources[] = {
 },
 };
 
+static u64 mv_crypto_dmamask = DMA_BIT_MASK(32);
+
 static struct platform_device orion_crypto = {
 .name           = "mv_crypto",
 .id             = -1,
+.dev= {
+.dma_mask = &mv_crypto_dmamask,
+.coherent_dma_mask = DMA_BIT_MASK(32),
+},
 };
 
 void __init orion_crypto_init(unsigned long mapbase,
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 4a989ea..e10da2b 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
< at >< at > -9

[PATCH 13/13] mv_cesa, mv_tdma: outsource common dma-pool handling code

Phil Sutter — 2012-05-25T16:08:39

Signed-off-by: Phil Sutter <phil.sutter< at >viprinet.com>
---
 drivers/crypto/dma_desclist.h |   79 +++++++++++++++++++++++++++++++++++
 drivers/crypto/mv_cesa.c      |   81 +++++++++----------------------------
 drivers/crypto/mv_tdma.c      |   91 ++++++++++++-----------------------------
 3 files changed, 125 insertions(+), 126 deletions(-)
 create mode 100644 drivers/crypto/dma_desclist.h

diff --git a/drivers/crypto/dma_desclist.h b/drivers/crypto/dma_desclist.h
new file mode 100644
index 0000000..c471ad6
--- /dev/null
+++ b/drivers/crypto/dma_desclist.h
< at >< at > -0,0 +1,79 < at >< at >
+#ifndef __DMA_DESCLIST__
+#define __DMA_DESCLIST__
+
+struct dma_desc {
+void *virt;
+dma_addr_t phys;
+};
+
+struct dma_desclist {
+struct dma_pool *itempool;
+struct dma_desc *desclist;
+unsigned long length;
+unsigned long usage;
+};
+
+#define DESCLIST_ITEM(dl, x)((dl).desclist[(x)].virt)
+#define DESCLIST_ITEM_DMA(dl, x)((dl).desclist[(x)].phys)
+#define DESCLIST_FULL(dl)((dl).length == (dl).usage)
+
+static inline int
+in

[PATCH 02/13] mv_cesa: minor formatting cleanup, will all make sense soon

Phil Sutter — 2012-05-25T16:08:28

This is just to keep formatting changes out of the following commit,
hopefully simplifying it a bit.

Signed-off-by: Phil Sutter <phil.sutter< at >viprinet.com>
---
 drivers/crypto/mv_cesa.c |   14 ++++++--------
 1 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index c305350..3862a93 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
< at >< at > -267,12 +267,10 < at >< at > static void mv_process_current_q(int first_block)
 }
 if (req_ctx->decrypt) {
 op.config |= CFG_DIR_DEC;
-memcpy(cpg->sram + SRAM_DATA_KEY_P, ctx->aes_dec_key,
-AES_KEY_LEN);
+memcpy(cpg->sram + SRAM_DATA_KEY_P, ctx->aes_dec_key, AES_KEY_LEN);
 } else {
 op.config |= CFG_DIR_ENC;
-memcpy(cpg->sram + SRAM_DATA_KEY_P, ctx->aes_enc_key,
-AES_KEY_LEN);
+memcpy(cpg->sram + SRAM_DATA_KEY_P, ctx->aes_enc_key, AES_KEY_LEN);
 }
 
 switch (ctx->key_len) {
< at >< at > -333,9 +331,8 < at >< at > static void mv_process_hash_current(int first_block)
 }
 
 op.mac_src_p =
-MAC_SRC_DAT

[PATCH 10/13] mv_cesa: reorganise mv_start_new_hash_req a bit

Phil Sutter — 2012-05-25T16:08:36

Check and exit early for whether CESA can be used at all.

Signed-off-by: Phil Sutter <phil.sutter< at >viprinet.com>
---
 drivers/crypto/mv_cesa.c |   61 +++++++++++++++++++++++++---------------------
 1 files changed, 33 insertions(+), 28 deletions(-)

diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 8e66080..5dba9df 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
< at >< at > -804,35 +804,13 < at >< at > static void mv_start_new_hash_req(struct ahash_request *req)
 else
 ctx->extra_bytes = 0;
 
-p->src_sg = req->src;
-if (req->nbytes) {
-BUG_ON(!req->src);
-p->sg_src_left = req->src->length;
-}
-
-if (hw_bytes) {
-p->hw_nbytes = hw_bytes;
-p->complete = mv_hash_algo_completion;
-p->process = mv_update_hash_config;
-
-if (unlikely(old_extra_bytes)) {
-dma_sync_single_for_device(cpg->dev, ctx->buffer_dma,
-SHA1_BLOCK_SIZE, DMA_TO_DEVICE);
-mv_tdma_memcpy(cpg->sram_phys + SRAM_DATA_IN_START,
-ctx->buffer_dma, old_extra_bytes);
-p->crypt_len = old_extra_

[PATCH 07/13] mv_cesa: have TDMA copy back the digest result

Phil Sutter — 2012-05-25T16:08:33

Signed-off-by: Phil Sutter <phil.sutter< at >viprinet.com>
---
 drivers/crypto/mv_cesa.c |   40 +++++++++++++++++++++++++++++-----------
 1 files changed, 29 insertions(+), 11 deletions(-)

diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index e10da2b..d099aa0 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
< at >< at > -159,8 +159,10 < at >< at > struct mv_req_hash_ctx {
 int first_hash;/* marks that we don't have previous state */
 int last_chunk;/* marks that this is the 'final' request */
 int extra_bytes;/* unprocessed bytes in buffer */
+int digestsize;/* size of the digest */
 enum hash_op op;
 int count_add;
+dma_addr_t result_dma;
 };
 
 static void mv_completion_timer_callback(unsigned long unused)
< at >< at > -497,9 +499,17 < at >< at > static void mv_init_hash_config(struct ahash_request *req)
 
 mv_tdma_separator();
 
-/* XXX: this fixes some ugly register fuckup bug in the tdma engine
- *      (no need to sync since the data is ignored anyway) */
-mv_tdma_memcpy(cpg->sa_sram_dma, c

[PATCH 08/13] mv_cesa: fetch extra_bytes via TDMA engine, too

Phil Sutter — 2012-05-25T16:08:34

Signed-off-by: Phil Sutter <phil.sutter< at >viprinet.com>
---
 drivers/crypto/mv_cesa.c |   12 ++++++++++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index d099aa0..bc2692e 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
< at >< at > -156,6 +156,7 < at >< at > struct mv_req_hash_ctx {
 u64 count;
 u32 state[SHA1_DIGEST_SIZE / 4];
 u8 buffer[SHA1_BLOCK_SIZE];
+dma_addr_t buffer_dma;
 int first_hash;/* marks that we don't have previous state */
 int last_chunk;/* marks that this is the 'final' request */
 int extra_bytes;/* unprocessed bytes in buffer */
< at >< at > -636,6 +637,9 < at >< at > static void mv_hash_algo_completion(void)
 dma_unmap_single(cpg->dev, ctx->result_dma,
 ctx->digestsize, DMA_FROM_DEVICE);
 
+dma_unmap_single(cpg->dev, ctx->buffer_dma,
+SHA1_BLOCK_SIZE, DMA_TO_DEVICE);
+
 if (unlikely(ctx->count > MAX_HW_HASH_SIZE)) {
 mv_save_digest_state(ctx);
 mv_hash_final_fallback(req);
< at >< at > -755,8 +759,10 < at >< at > static

[PATCH 04/13] mv_cesa: split up processing callbacks

Phil Sutter — 2012-05-25T16:08:30

Have a dedicated function initialising the full SRAM config, then use a
minimal callback for changing only relevant parts of it.

Signed-off-by: Phil Sutter <phil.sutter< at >viprinet.com>
---
 drivers/crypto/mv_cesa.c |   87 +++++++++++++++++++++++++++++++++------------
 1 files changed, 64 insertions(+), 23 deletions(-)

diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 68b83d8..4a989ea 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
< at >< at > -62,7 +62,7 < at >< at > struct req_progress {
 struct scatterlist *src_sg;
 struct scatterlist *dst_sg;
 void (*complete) (void);
-void (*process) (int is_first);
+void (*process) (void);
 
 /* src mostly */
 int sg_src_left;
< at >< at > -265,9 +265,8 < at >< at > static void setup_data_in(void)
 p->crypt_len = data_in_sram;
 }
 
-static void mv_process_current_q(int first_block)
+static void mv_init_crypt_config(struct ablkcipher_request *req)
 {
-struct ablkcipher_request *req = ablkcipher_request_cast(cpg->cur_req);
 struct mv_ctx *ctx = crypto_tfm_ctx

[PATCH 11/13] mv_cesa: implement descriptor chaining for hashes, too

Phil Sutter — 2012-05-25T16:08:37

Signed-off-by: Phil Sutter <phil.sutter< at >viprinet.com>
---
 drivers/crypto/mv_cesa.c |   89 ++++++++++++++++++----------------------------
 1 files changed, 35 insertions(+), 54 deletions(-)

diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 5dba9df..9afed2d 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
< at >< at > -536,34 +536,14 < at >< at > static void mv_init_hash_config(struct ahash_request *req)
 sizeof(struct sec_accel_sram), DMA_TO_DEVICE);
 mv_tdma_memcpy(cpg->sram_phys + SRAM_CONFIG, cpg->sa_sram_dma,
 sizeof(struct sec_accel_sram));
-
-mv_tdma_separator();
-
-if (req->result) {
-req_ctx->result_dma = dma_map_single(cpg->dev, req->result,
-req_ctx->digestsize, DMA_FROM_DEVICE);
-mv_tdma_memcpy(req_ctx->result_dma,
-cpg->sram_phys + SRAM_DIGEST_BUF, req_ctx->digestsize);
-} else {
-/* XXX: this fixes some ugly register fuckup bug in the tdma engine
- *      (no need to sync since the data is ignored anyway) */
-mv_tdma_memcpy(cpg->sa_sram_dma,
-

[PATCH 1/4] mv_cesa: add an expiry timer in case anything goes wrong

Phil Sutter — 2012-05-25T13:54:46

The timer triggers when 500ms have gone by after triggering the engine
and no completion interrupt was received. The callback then tries to
sanitise things as well as possible.

Signed-off-by: Phil Sutter <phil.sutter< at >viprinet.com>
---
 drivers/crypto/mv_cesa.c |   41 +++++++++++++++++++++++++++++++----------
 1 files changed, 31 insertions(+), 10 deletions(-)

diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index e6ecc5f..8327bed 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
< at >< at > -23,6 +23,7 < at >< at >
 
 #define MV_CESA"MV-CESA:"
 #define MAX_HW_HASH_SIZE0xFFFF
+#define MV_CESA_EXPIRE500 /* msec */
 
 /*
  * STM:
< at >< at > -85,6 +86,7 < at >< at > struct crypto_priv {
 spinlock_t lock;
 struct crypto_queue queue;
 enum engine_status eng_st;
+struct timer_list completion_timer;
 struct crypto_async_request *cur_req;
 struct req_progress p;
 int max_req_size;
< at >< at > -136,6 +138,29 < at >< at > struct mv_req_hash_ctx {
 int count_add;
 };
 
+static void mv_completion_timer_callback(unsigned long un

[PATCH 4/4] mv_cesa: fix for hash finalisation with data

Phil Sutter — 2012-05-25T13:54:49

Since mv_hash_final_fallback() uses ctx->state, read out the digest
state register before calling it.

Signed-off-by: Phil Sutter <phil.sutter< at >viprinet.com>
---
 drivers/crypto/mv_cesa.c |   19 +++++++++++++------
 1 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index d4763fb..3cc9237 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
< at >< at > -421,6 +421,15 < at >< at > out:
 return rc;
 }
 
+static void mv_save_digest_state(struct mv_req_hash_ctx *ctx)
+{
+ctx->state[0] = readl(cpg->reg + DIGEST_INITIAL_VAL_A);
+ctx->state[1] = readl(cpg->reg + DIGEST_INITIAL_VAL_B);
+ctx->state[2] = readl(cpg->reg + DIGEST_INITIAL_VAL_C);
+ctx->state[3] = readl(cpg->reg + DIGEST_INITIAL_VAL_D);
+ctx->state[4] = readl(cpg->reg + DIGEST_INITIAL_VAL_E);
+}
+
 static void mv_hash_algo_completion(void)
 {
 struct ahash_request *req = ahash_request_cast(cpg->cur_req);
< at >< at > -435,14 +444,12 < at >< at > static void mv_hash_algo_completion(void)
 memcpy(req->resul

[PATCH 2/4] mv_cesa: no need to write to that FPGA_INT_STATUS field

Phil Sutter — 2012-05-25T13:54:47

Also drop the whole definition, since it's unused otherwise.

Signed-off-by: Phil Sutter <phil.sutter< at >viprinet.com>
---
 drivers/crypto/mv_cesa.c |    1 -
 drivers/crypto/mv_cesa.h |    7 -------
 2 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 8327bed..4a1f872 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
< at >< at > -908,7 +908,6 < at >< at > irqreturn_t crypto_int(int irq, void *priv)
        "got an interrupt but no pending timer?\n");
 }
 val &= ~SEC_INT_ACCEL0_DONE;
-writel(val, cpg->reg + FPGA_INT_STATUS);
 writel(val, cpg->reg + SEC_ACCEL_INT_STATUS);
 BUG_ON(cpg->eng_st != ENGINE_BUSY);
 cpg->eng_st = ENGINE_W_DEQUEUE;
diff --git a/drivers/crypto/mv_cesa.h b/drivers/crypto/mv_cesa.h
index 08fcb11..81ce109 100644
--- a/drivers/crypto/mv_cesa.h
+++ b/drivers/crypto/mv_cesa.h
< at >< at > -29,13 +29,6 < at >< at >
 #define SEC_ST_ACT_0(1 << 0)
 #define SEC_ST_ACT_1(1 << 1)
 
-/*
- * FPGA_INT_STATUS looks like a FPGA leftover and is do

[PATCH 3/4] mv_cesa: initialise the interrupt status field to zero

Phil Sutter — 2012-05-25T13:54:48

Signed-off-by: Phil Sutter <phil.sutter< at >viprinet.com>
---
 drivers/crypto/mv_cesa.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 4a1f872..d4763fb 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
< at >< at > -1073,6 +1073,7 < at >< at > static int mv_probe(struct platform_device *pdev)
 if (ret)
 goto err_thread;
 
+writel(0, cpg->reg + SEC_ACCEL_INT_STATUS);
 writel(SEC_INT_ACCEL0_DONE, cpg->reg + SEC_ACCEL_INT_MASK);
 writel(SEC_CFG_STOP_DIG_ERR, cpg->reg + SEC_ACCEL_CFG);
 writel(SRAM_CONFIG, cpg->reg + SEC_ACCEL_DESC_P0);

[PATCH 2/2] crypto: bfin_crc: CRC hardware accelerator driver for BF60x family processors.

Sonic Zhang — 2012-05-25T09:54:14

From: Sonic Zhang <sonic.zhang< at >analog.com>

The CRC peripheral is a hardware block used to compute the CRC of the block
of data. This is based on a CRC32 engine which computes the CRC value of 32b
data words presented to it. For data words of < 32b in size, this driver
pack 0 automatically into 32b data units. This driver implements the async
hash crypto framework API.

Signed-off-by: Sonic Zhang <sonic.zhang< at >analog.com>
---
 drivers/crypto/Kconfig    |    7 +
 drivers/crypto/Makefile   |    3 +-
 drivers/crypto/bfin_crc.c |  789 +++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 798 insertions(+), 1 deletions(-)
 create mode 100644 drivers/crypto/bfin_crc.c

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 69fdf18..a520b93 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
< at >< at > -306,4 +306,11 < at >< at > if CRYPTO_DEV_UX500
 source "drivers/crypto/ux500/Kconfig"
 endif # if CRYPTO_DEV_UX500
 
+config CRYPTO_DEV_BFIN_CRC
+tristate "Support for Blackfin CRC hareware acceler

[PATCH] crypto: sha1 - use Kbuild supplied flags for AVX test

Mathias Krause — 2012-05-24T09:13:42

Commit ea4d26ae ("raid5: add AVX optimized RAID5 checksumming")
introduced x86/ arch wide defines for AFLAGS and CFLAGS indicating AVX
support in binutils based on the same test we have in x86/crypto/ right
now. To minimize duplication drop our implementation in favour to the
one in x86/.

Signed-off-by: Mathias Krause <minipli< at >googlemail.com>
---

This should be applied to cryptodev-2.6.git after it contains the above
mentioned commit, e.g. after cryptodev-2.6.git rebased to/merged v3.5-rc1.

 arch/x86/crypto/Makefile          |    7 -------
 arch/x86/crypto/sha1_ssse3_asm.S  |    2 +-
 arch/x86/crypto/sha1_ssse3_glue.c |    6 +++---
 3 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/arch/x86/crypto/Makefile b/arch/x86/crypto/Makefile
index e191ac0..479f95a 100644
--- a/arch/x86/crypto/Makefile
+++ b/arch/x86/crypto/Makefile
< at >< at > -34,12 +34,5 < at >< at > salsa20-x86_64-y := salsa20-x86_64-asm_64.o salsa20_glue.o
 serpent-sse2-x86_64-y := serpent-sse2-x86_64-asm_64.o serpent_sse2_glue.o
 
 aesni-intel-y :