[PATCH] crypto: aesni-intel: fix crypto_fpu_exit() section mismatch

2015-06-12 Thread Jeremiah Mahler
The '__init aesni_init()' function calls the '__exit crypto_fpu_exit()'
function directly.  Since they are in different sections, this generates
a warning.

  make CONFIG_DEBUG_SECTION_MISMATCH=y
  ...
  WARNING: arch/x86/crypto/aesni-intel.o(.init.text+0x12b): Section
  mismatch in reference from the function init_module() to the function
  .exit.text:crypto_fpu_exit()
  The function __init init_module() references
  a function __exit crypto_fpu_exit().
  This is often seen when error handling in the init function
  uses functionality in the exit path.
  The fix is often to remove the __exit annotation of
  crypto_fpu_exit() so it may be used outside an exit section.

Fix the warning by removing the __exit annotation.

Signed-off-by: Jeremiah Mahler 
---
 arch/x86/crypto/fpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/crypto/fpu.c b/arch/x86/crypto/fpu.c
index 5a2f30f..e7d679e 100644
--- a/arch/x86/crypto/fpu.c
+++ b/arch/x86/crypto/fpu.c
@@ -156,7 +156,7 @@ int __init crypto_fpu_init(void)
return crypto_register_template(&crypto_fpu_tmpl);
 }
 
-void __exit crypto_fpu_exit(void)
+void crypto_fpu_exit(void)
 {
crypto_unregister_template(&crypto_fpu_tmpl);
 }
-- 
2.1.4

--
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 v4 1/4] MPILIB: add mpi_read_buf(), mpi_copy() and mpi_get_size() helpers

2015-06-12 Thread Tadeusz Struk
On 06/12/2015 09:21 AM, Stephan Mueller wrote:
>> +void *mpi_get_buffer(MPI a, unsigned *nbytes, int *sign)
>> >+{
>> >+   uint8_t *buf, *p;
>> >+   int n, ret;
>> >+
>> >+   if (!nbytes)
>> >+   return NULL;
>> >+
>> >+   n = mpi_get_size(a);
> Shouldn't n be unsigned int?

You are right, thanks.
--
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 v4 1/4] MPILIB: add mpi_read_buf(), mpi_copy() and mpi_get_size() helpers

2015-06-12 Thread Stephan Mueller
Am Donnerstag, 11. Juni 2015, 12:05:38 schrieb Tadeusz Struk:

Hi Tadeusz,

>+ */
>+void *mpi_get_buffer(MPI a, unsigned *nbytes, int *sign)
>+{
>+   uint8_t *buf, *p;
>+   int n, ret;
>+
>+   if (!nbytes)
>+   return NULL;
>+
>+   n = mpi_get_size(a);

Shouldn't n be unsigned int?


Ciao
Stephan
--
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 2/2] crypto: replace NX842_MEM_COMPRESS with function

2015-06-12 Thread Dan Streetman
Replace the NX842_MEM_COMPRESS define with a function that returns the
specific platform driver's required working memory size.

The common nx-842.c driver refuses to load if there is no platform
driver present, so instead of defining an approximate working memory
size that's the maximum approximate size of both platform driver's
size requirements, the platform driver can directly provide its
specific, i.e. sizeof(struct nx842_workmem), size requirements which
the 842-nx crypto compression driver will use.

This saves memory by both reducing the required size of each driver
to the specific sizeof() amount, as well as using the specific loaded
platform driver's required amount, instead of the maximum of both.

Signed-off-by: Dan Streetman 
---
 drivers/crypto/nx/nx-842-crypto.c  |  2 +-
 drivers/crypto/nx/nx-842-powernv.c | 11 +++
 drivers/crypto/nx/nx-842-pseries.c |  7 +++
 drivers/crypto/nx/nx-842.c | 11 +++
 drivers/crypto/nx/nx-842.h |  9 +++--
 5 files changed, 25 insertions(+), 15 deletions(-)

diff --git a/drivers/crypto/nx/nx-842-crypto.c 
b/drivers/crypto/nx/nx-842-crypto.c
index 95066f3..d53a1dc 100644
--- a/drivers/crypto/nx/nx-842-crypto.c
+++ b/drivers/crypto/nx/nx-842-crypto.c
@@ -136,7 +136,7 @@ static int nx842_crypto_init(struct crypto_tfm *tfm)
 {
struct nx842_crypto_ctx *ctx = crypto_tfm_ctx(tfm);
 
-   ctx->wmem = kmalloc(NX842_MEM_COMPRESS, GFP_KERNEL);
+   ctx->wmem = kmalloc(nx842_workmem_size(), GFP_KERNEL);
ctx->sbounce = (u8 *)__get_free_pages(GFP_KERNEL, BOUNCE_BUFFER_ORDER);
ctx->dbounce = (u8 *)__get_free_pages(GFP_KERNEL, BOUNCE_BUFFER_ORDER);
if (!ctx->wmem || !ctx->sbounce || !ctx->dbounce) {
diff --git a/drivers/crypto/nx/nx-842-powernv.c 
b/drivers/crypto/nx/nx-842-powernv.c
index c388dba..33b3b0a 100644
--- a/drivers/crypto/nx/nx-842-powernv.c
+++ b/drivers/crypto/nx/nx-842-powernv.c
@@ -367,7 +367,8 @@ static int wait_for_csb(struct nx842_workmem *wmem,
  * @inlen: input buffer size
  * @out: output buffer pointer
  * @outlenp: output buffer size pointer
- * @workmem: working memory buffer pointer, must be at least NX842_MEM_COMPRESS
+ * @workmem: working memory buffer pointer, size determined by
+ *   nx842_powernv_driver.workmem_size
  * @fc: function code, see CCW Function Codes in nx-842.h
  *
  * Returns:
@@ -477,7 +478,8 @@ static int nx842_powernv_function(const unsigned char *in, 
unsigned int inlen,
  * @inlen: input buffer size
  * @out: output buffer pointer
  * @outlenp: output buffer size pointer
- * @workmem: working memory buffer pointer, must be at least NX842_MEM_COMPRESS
+ * @workmem: working memory buffer pointer, size determined by
+ *   nx842_powernv_driver.workmem_size
  *
  * Returns: see @nx842_powernv_function()
  */
@@ -504,7 +506,8 @@ static int nx842_powernv_compress(const unsigned char *in, 
unsigned int inlen,
  * @inlen: input buffer size
  * @out: output buffer pointer
  * @outlenp: output buffer size pointer
- * @workmem: working memory buffer pointer, must be at least NX842_MEM_COMPRESS
+ * @workmem: working memory buffer pointer, size determined by
+ *   nx842_powernv_driver.workmem_size
  *
  * Returns: see @nx842_powernv_function()
  */
@@ -572,6 +575,7 @@ static struct nx842_constraints nx842_powernv_constraints = 
{
 static struct nx842_driver nx842_powernv_driver = {
.name = KBUILD_MODNAME,
.owner =THIS_MODULE,
+   .workmem_size = sizeof(struct nx842_workmem),
.constraints =  &nx842_powernv_constraints,
.compress = nx842_powernv_compress,
.decompress =   nx842_powernv_decompress,
@@ -582,7 +586,6 @@ static __init int nx842_powernv_init(void)
struct device_node *dn;
 
/* verify workmem size/align restrictions */
-   BUILD_BUG_ON(sizeof(struct nx842_workmem) > NX842_MEM_COMPRESS);
BUILD_BUG_ON(WORKMEM_ALIGN % CRB_ALIGN);
BUILD_BUG_ON(CRB_ALIGN % DDE_ALIGN);
BUILD_BUG_ON(CRB_SIZE % DDE_ALIGN);
diff --git a/drivers/crypto/nx/nx-842-pseries.c 
b/drivers/crypto/nx/nx-842-pseries.c
index 41bc551..da52d8e 100644
--- a/drivers/crypto/nx/nx-842-pseries.c
+++ b/drivers/crypto/nx/nx-842-pseries.c
@@ -284,7 +284,7 @@ static int nx842_validate_result(struct device *dev,
  * @out: Pointer to output buffer
  * @outlen: Length of output buffer
  * @wrkmem: ptr to buffer for working memory, size determined by
- *  NX842_MEM_COMPRESS
+ *  nx842_pseries_driver.workmem_size
  *
  * Returns:
  *   0 Success, output of length @outlen stored in the buffer at @out
@@ -411,7 +411,7 @@ unlock:
  * @out: Pointer to output buffer
  * @outlen: Length of output buffer
  * @wrkmem: ptr to buffer for working memory, size determined by
- *  NX842_MEM_COMPRESS
+ *  nx842_pseries_driver.workmem_size
  *
  * Returns:
  *   0 Success, output of length @outlen stored in the buffer at @out
@@ -963,6 +963,7 @@ static

[PATCH 1/2] crypto: move include/linux/nx842.h into drivers/crypto/nx/nx-842.h

2015-06-12 Thread Dan Streetman
Move the contents of the include/linux/nx842.h header file into the
drivers/crypto/nx/nx-842.h header file.  Remove the nx842.h header
file and its entry in the MAINTAINERS file.

The include/linux/nx842.h header originally was there because the
crypto/842.c driver needed it to communicate with the nx-842 hw
driver.  However, that crypto compression driver was moved into
the drivers/crypto/nx/ directory, and now can directly include the
nx-842.h header.  Nothing else needs the public include/linux/nx842.h
header file, as all use of the nx-842 hardware driver will be through
the "842-nx" crypto compression driver, since the direct nx-842 api is
very limited in the buffer alignments and sizes that it will accept,
and the crypto compression interface handles those limitations and
allows any alignment and size buffers.

Signed-off-by: Dan Streetman 
---
 MAINTAINERS   |  1 -
 drivers/crypto/nx/nx-842-crypto.c |  3 ++-
 drivers/crypto/nx/nx-842.h| 21 -
 include/linux/nx842.h | 24 
 4 files changed, 22 insertions(+), 27 deletions(-)
 delete mode 100644 include/linux/nx842.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 912c9d9..fb06e1e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4862,7 +4862,6 @@ IBM Power 842 compression accelerator
 M: Dan Streetman 
 S: Supported
 F: drivers/crypto/nx/nx-842*
-F: include/linux/nx842.h
 F: include/linux/sw842.h
 F: crypto/842.c
 F: lib/842/
diff --git a/drivers/crypto/nx/nx-842-crypto.c 
b/drivers/crypto/nx/nx-842-crypto.c
index 2ffa103..95066f3 100644
--- a/drivers/crypto/nx/nx-842-crypto.c
+++ b/drivers/crypto/nx/nx-842-crypto.c
@@ -58,10 +58,11 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
+#include "nx-842.h"
+
 /* The first 5 bits of this magic are 0x1f, which is an invalid 842 5-bit
  * template (see lib/842/842.h), so this magic number will never appear at
  * the start of a raw 842 compressed buffer.  That is important, as any buffer
diff --git a/drivers/crypto/nx/nx-842.h b/drivers/crypto/nx/nx-842.h
index 1730f4da..4dbac11 100644
--- a/drivers/crypto/nx/nx-842.h
+++ b/drivers/crypto/nx/nx-842.h
@@ -4,7 +4,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -12,6 +11,12 @@
 #include 
 #include 
 
+#define __NX842_PSERIES_MEM_COMPRESS   (10240)
+#define __NX842_POWERNV_MEM_COMPRESS   (1024)
+
+#define NX842_MEM_COMPRESS (max_t(unsigned int,\
+   __NX842_PSERIES_MEM_COMPRESS, __NX842_POWERNV_MEM_COMPRESS))
+
 /* Restrictions on Data Descriptor List (DDL) and Entry (DDE) buffers
  *
  * From NX P8 workbook, sec 4.9.1 "842 details"
@@ -104,6 +109,13 @@ static inline unsigned long nx842_get_pa(void *addr)
 #define GET_FIELD(v, m)(((v) & (m)) >> MASK_LSH(m))
 #define SET_FIELD(v, m, val)   (((v) & ~(m)) | (((val) << MASK_LSH(m)) & (m)))
 
+struct nx842_constraints {
+   int alignment;
+   int multiple;
+   int minimum;
+   int maximum;
+};
+
 struct nx842_driver {
char *name;
struct module *owner;
@@ -124,4 +136,11 @@ void nx842_platform_driver_unset(struct nx842_driver 
*driver);
 bool nx842_platform_driver_get(void);
 void nx842_platform_driver_put(void);
 
+int nx842_constraints(struct nx842_constraints *constraints);
+
+int nx842_compress(const unsigned char *in, unsigned int in_len,
+  unsigned char *out, unsigned int *out_len, void *wrkmem);
+int nx842_decompress(const unsigned char *in, unsigned int in_len,
+unsigned char *out, unsigned int *out_len, void *wrkmem);
+
 #endif /* __NX_842_H__ */
diff --git a/include/linux/nx842.h b/include/linux/nx842.h
deleted file mode 100644
index 4ddf68d..000
--- a/include/linux/nx842.h
+++ /dev/null
@@ -1,24 +0,0 @@
-#ifndef __NX842_H__
-#define __NX842_H__
-
-#define __NX842_PSERIES_MEM_COMPRESS   (10240)
-#define __NX842_POWERNV_MEM_COMPRESS   (1024)
-
-#define NX842_MEM_COMPRESS (max_t(unsigned int,\
-   __NX842_PSERIES_MEM_COMPRESS, __NX842_POWERNV_MEM_COMPRESS))
-
-struct nx842_constraints {
-   int alignment;
-   int multiple;
-   int minimum;
-   int maximum;
-};
-
-int nx842_constraints(struct nx842_constraints *constraints);
-
-int nx842_compress(const unsigned char *in, unsigned int in_len,
-  unsigned char *out, unsigned int *out_len, void *wrkmem);
-int nx842_decompress(const unsigned char *in, unsigned int in_len,
-unsigned char *out, unsigned int *out_len, void *wrkmem);
-
-#endif
-- 
2.1.0

--
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 0/2] remove nx842.h from include/linux

2015-06-12 Thread Dan Streetman
Now that the crypto/842.c driver does only software 842 comp/decomp,
and the hardware crypto compressor for 842-nx is located in
drivers/crypto/nx with the NX 842 hw driver, there's no reason for
the nx842.h header to be located in include/linux/ anymore; nobody
should use the NX 842 hw driver directly, everyone should use the
crypto compression API.

The first patch moves the contents of include/linux/nx842.h into the
existing drivers/crypto/nx/nx-842.h header file.  The second patch
replaces the use of the NX842_MEM_COMPRESS define, since the 842-nx
crypto compression driver can directly get the required working
memory size from the NX 842 hw driver.

This cleans up include/linux/ by 1 file, and it saves some memory
by reducing the 842-nx working memory size down to exactly what the
NX 842 platform driver requires.

Dan Streetman (2):
  crypto: move include/linux/nx842.h into drivers/crypto/nx/nx-842.h
  crypto: replace NX842_MEM_COMPRESS with function

 MAINTAINERS|  1 -
 drivers/crypto/nx/nx-842-crypto.c  |  5 +++--
 drivers/crypto/nx/nx-842-powernv.c | 11 +++
 drivers/crypto/nx/nx-842-pseries.c |  7 +++
 drivers/crypto/nx/nx-842.c | 11 +++
 drivers/crypto/nx/nx-842.h | 18 +-
 include/linux/nx842.h  | 24 
 7 files changed, 41 insertions(+), 36 deletions(-)
 delete mode 100644 include/linux/nx842.h

-- 
2.1.0

--
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 v4 2/4] crypto: add PKE API

2015-06-12 Thread Tadeusz Struk
On 06/11/2015 07:42 PM, Herbert Xu wrote:
>> The testmgr code can mark an entire cipher implementation as fips_allowed=1 
>> as 
>> > already done for RSA. However, unlike with the other ciphers, that flag 
>> > must 
>> > go in conjunction with the used key sizes.
>> > 
>> > For FIPS mode, the following restrictions apply:
>> > 
>> > - RSA: 2048/3072
>> > 
>> > - DSA: L 2048 / N 224; L 2048 / N 256; L 3072 / N 256
>> > 
>> > - ECDSA: only the NIST curves
>> > 
>> > Any other key sizes for the given ciphers is not allowed in FIPS mode.
>> > 
>> > Should that constraint be considered here?
> Yes.  However it should be placed into a helper that everybody
> can call so that future hardware implementations can also make
> the same checks.

I will make the algorithm marked as fips allowed always and then fail in setkey 
if fips is enabled
and the given key doesn't meet the fips requirement.
Thanks
--
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 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

2015-06-12 Thread Vinod Koul
On Thu, Jun 04, 2015 at 06:58:06PM +0300, Peter Ujfalusi wrote:
> Vinod,
> 
> On 06/02/2015 03:55 PM, Vinod Koul wrote:
> > On Fri, May 29, 2015 at 05:32:50PM +0300, Peter Ujfalusi wrote:
> >> On 05/29/2015 01:18 PM, Vinod Koul wrote:
> >>> On Fri, May 29, 2015 at 11:42:27AM +0200, Geert Uytterhoeven wrote:
>  On Fri, May 29, 2015 at 11:33 AM, Vinod Koul  
>  wrote:
> > On Tue, May 26, 2015 at 04:25:57PM +0300, Peter Ujfalusi wrote:
> >> dma_request_slave_channel_compat() 'eats' up the returned error codes 
> >> which
> >> prevents drivers using the compat call to be able to do deferred 
> >> probing.
> >>
> >> The new wrapper is identical in functionality but it will return with 
> >> error
> >> code in case of failure and will pass the -EPROBE_DEFER to the caller 
> >> in
> >> case dma_request_slave_channel_reason() returned with it.
> > This is okay but am worried about one more warpper, how about fixing
> > dma_request_slave_channel_compat()
> 
>  Then all callers of dma_request_slave_channel_compat() have to be
>  modified to handle ERR_PTR first.
> 
>  The same is true for (the existing) dma_request_slave_channel_reason()
>  vs. dma_request_slave_channel().
> >>> Good point, looking again, I think we should rather fix
> >>> dma_request_slave_channel_reason() as it was expected to return err code 
> >>> and
> >>> add new users. Anyway users of this API do expect the reason...
> >>
> >> Hrm, they are for different use.dma_request_slave_channel()/_reason() is 
> >> for
> >> drivers only working via DT or ACPI while
> >> dma_request_slave_channel_compat()/_reason() is for drivers expected to 
> >> run in
> >> DT/ACPI or legacy mode as well.
> >>
> >> I added the dma_request_slave_channel_compat_reason() because OMAP/daVinci
> >> drivers are using this to request channels - they need to support DT and
> >> legacy mode.
> > I think we should hide these things behind the API and do this behind the
> > hood for ACPI/DT systems.
> > 
> > Also it makes sense to use right API and mark rest as depricated
> 
> So to convert the dma_request_slave_channel_compat() and not to create _reason
> variant?
> 
> Or to have single API to request channel? The problem with that is that we
> need different parameters for legacy and DT for example.
Sorry this slipped thru

Thinking about it again, I think we should coverge to two APIs and mark the
legacy depracuated and look to convert folks and phase that out


-- 
~Vinod
--
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: [V6 PATCH 6/7] megaraid_sas: fix TRUE and FALSE re-define build error

2015-06-12 Thread Sumit Saxena
>-Original Message-
>From: Suravee Suthikulpanit [mailto:suravee.suthikulpa...@amd.com]
>Sent: Wednesday, June 10, 2015 9:39 PM
>To: r...@rjwysocki.net; l...@kernel.org; catalin.mari...@arm.com;
>will.dea...@arm.com; thomas.lenda...@amd.com;
>herb...@gondor.apana.org.au; da...@davemloft.net; a...@arndb.de;
>kashyap.de...@avagotech.com; sumit.sax...@avagotech.com;
>uday.ling...@avagotech.com; vinholika...@gmail.com
>Cc: msal...@redhat.com; hanjun@linaro.org; al.st...@linaro.org;
>grant.lik...@linaro.org; leo.du...@amd.com; linux-arm-
>ker...@lists.infradead.org; linux-a...@vger.kernel.org; linux-
>ker...@vger.kernel.org; linaro-a...@lists.linaro.org;
net...@vger.kernel.org;
>linux-crypto@vger.kernel.org; Suravee Suthikulpanit
>Subject: [V6 PATCH 6/7] megaraid_sas: fix TRUE and FALSE re-define build
>error
>
>Signed-off-by: Suravee Suthikulpanit 
>Cc: Kashyap Desai 
>Cc: Sumit Saxena 
>Cc: Uday Lingala 
>---
> drivers/scsi/megaraid/megaraid_sas_fp.c | 8 
> 1 file changed, 8 insertions(+)
>
>diff --git a/drivers/scsi/megaraid/megaraid_sas_fp.c
>b/drivers/scsi/megaraid/megaraid_sas_fp.c
>index 4f72287..e8b7a69 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_fp.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_fp.c
>@@ -66,7 +66,15 @@ MODULE_PARM_DESC(lb_pending_cmds, "Change
>raid-1 load balancing outstanding "
>
> #define ABS_DIFF(a, b)   (((a) > (b)) ? ((a) - (b)) : ((b) - (a)))
> #define MR_LD_STATE_OPTIMAL 3
>+
>+#ifdef FALSE
>+#undef FALSE
>+#endif
> #define FALSE 0
>+
>+#ifdef TRUE
>+#undef TRUE
>+#endif
> #define TRUE 1
>
> #define SPAN_DEBUG 0
Acked-by: Sumit Saxena 

>--
>2.1.0
--
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


[RESEND PATCH v4 10/14] crypto: marvell/CESA: add support for all armada SoCs

2015-06-12 Thread Boris Brezillon
Add CESA IP description for all the missing armada SoCs (XP, 375 and 38x).

Signed-off-by: Boris Brezillon 
---
 drivers/crypto/marvell/cesa.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index e4dfee0..087370e 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -191,8 +191,20 @@ static const struct mv_cesa_caps armada_370_caps = {
.has_tdma = true,
 };
 
+static const struct mv_cesa_caps armada_xp_caps = {
+   .nengines = 2,
+   .cipher_algs = armada_370_cipher_algs,
+   .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[] = {
{ .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 },
+   { .compatible = "marvell,armada-38x-crypto", .data = &armada_xp_caps },
{}
 };
 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


[RESEND PATCH v4 03/14] crypto: mv_cesa: explicitly define kirkwood and dove compatible strings

2015-06-12 Thread Boris Brezillon
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 
---
 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


[RESEND PATCH v4 02/14] crypto: mv_cesa: use gen_pool to reserve the SRAM memory region

2015-06-12 Thread Boris Brezillon
The mv_cesa driver currently expects the SRAM memory region to be passed
as a platform device resource.

This approach implies two drawbacks:
- the DT representation is wrong
- the only one that can access the SRAM is the crypto engine

The last point is particularly annoying in some cases: for example on
armada 370, a small region of the crypto SRAM is used to implement the
cpuidle, which means you would not be able to enable both cpuidle and the
CESA driver.

To address that problem, we explicitly define the SRAM device in the DT
and then reference the sram node from the crypto engine node.

Also note that the old way of retrieving the SRAM memory region is still
supported, or in other words, backward compatibility is preserved.

Signed-off-by: Boris Brezillon 
---
 .../devicetree/bindings/crypto/mv_cesa.txt | 24 ++---
 drivers/crypto/Kconfig |  1 +
 drivers/crypto/mv_cesa.c   | 58 --
 3 files changed, 60 insertions(+), 23 deletions(-)

diff --git a/Documentation/devicetree/bindings/crypto/mv_cesa.txt 
b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
index eaa2873..13b8fc5 100644
--- a/Documentation/devicetree/bindings/crypto/mv_cesa.txt
+++ b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
@@ -2,21 +2,29 @@ Marvell Cryptographic Engines And Security Accelerator
 
 Required properties:
 - compatible : should be "marvell,orion-crypto"
-- reg : base physical address of the engine and length of memory mapped
-region, followed by base physical address of sram and its memory
-length
-- reg-names : "regs" , "sram";
-- interrupts : interrupt number
+- 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 only
  required for Dove 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@3 {
compatible = "marvell,orion-crypto";
-   reg = <0x3 0x1>,
- <0x400 0x800>;
-   reg-names = "regs" , "sram";
+   reg = <0x3 0x1>;
+   reg-names = "regs";
interrupts = <22>;
+   marvell,crypto-srams = <&crypto_sram>;
+   marvell,crypto-sram-size = <0x600>;
status = "okay";
};
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 033c0c8..a6bbea8 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -166,6 +166,7 @@ config CRYPTO_DEV_MV_CESA
select CRYPTO_AES
select CRYPTO_BLKCIPHER2
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 Marvell Orion
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 27b2373..a4c8637 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -29,6 +30,8 @@
 #define MAX_HW_HASH_SIZE   0x
 #define MV_CESA_EXPIRE 500 /* msec */
 
+#define MV_CESA_DEFAULT_SRAM_SIZE  2048
+
 /*
  * STM:
  *   /---\
@@ -83,6 +86,8 @@ struct req_progress {
 struct crypto_priv {
void __iomem *reg;
void __iomem *sram;
+   struct gen_pool *sram_pool;
+   dma_addr_t sram_dma;
int irq;
struct clk *clk;
struct task_struct *queue_th;
@@ -1019,6 +1024,39 @@ static struct ahash_alg mv_hmac_sha1_alg = {
 }
 };
 
+static int mv_cesa_get_sram(struct platform_device *pdev,
+   struct crypto_priv *cp)
+{
+   struct resource *res;
+   u32 sram_size = MV_CESA_DEFAULT_SRAM_SIZE;
+
+   of_property_read_u32(pdev->dev.of_node, "marvell,crypto-sram-size",
+&sram_size);
+
+   cp->sram_size = sram_size;
+   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,
+ &cp->sram_dma);
+   if (cp->sram)
+   return 0;
+
+   return -ENOMEM;
+   }
+
+   res = 

[RESEND PATCH v4 00/14] crypto: add a new driver for Marvell's CESA

2015-06-12 Thread Boris Brezillon
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-v4 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-v4

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 |   18 +
 drivers/crypto/Makefile|1 +
 drivers/crypto/marvell/Makefile|2 +
 drivers/crypto/marvell/cesa.c  |  544 
 drivers/crypto/marvell/cesa.h  |  804 +++
 drivers/crypto/marvell/cipher.c|  774 +++
 drivers/crypto/marvell/hash.c  | 1433 
 drivers/crypto/marvell/tdma.c  |  224 +++
 drivers/crypto/mv_cesa.c   |   60 +-
 11 files changed, 3912 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


[RESEND PATCH v4 09/14] crypto: marvell/CESA: add SHA256 support

2015-06-12 Thread Boris Brezillon
From: Arnaud Ebalard 

Add support for SHA256 operations.

Signed-off-by: Arnaud Ebalard 
Signed-off-by: Boris Brezillon 
---
 drivers/crypto/marvell/cesa.c |   2 +
 drivers/crypto/marvell/cesa.h |   2 +
 drivers/crypto/marvell/hash.c | 157 ++
 3 files changed, 161 insertions(+)

diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index b9da0df..e4dfee0 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 63fa493..8292bb7 100644
--- a/drivers/crypto/marvell/hash.c
+++ b/drivers/crypto/marvell/hash.c
@@ -973,6 +973,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;
@@ -1274,3 +1363,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-sh

[RESEND PATCH v4 05/14] crypto: marvell/CESA: add TDMA support

2015-06-12 Thread Boris Brezillon
The CESA IP supports CPU offload through a dedicated DMA engine (TDMA)
which can control the crypto block.
When you use this mode, all the required data (operation metadata and
payload data) are transferred using DMA, and the results are retrieved
through DMA when possible (hash results are not retrieved through DMA yet),
thus reducing the involvement of the CPU and providing better performances
in most cases (for small requests, the cost of DMA preparation might
exceed the performance gain).

Note that some CESA IPs do not embed this dedicated DMA, hence the
activation of this feature on a per platform basis.

Signed-off-by: Boris Brezillon 
Signed-off-by: Arnaud Ebalard 
---
 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 | 167 +++-
 drivers/crypto/marvell/hash.c   | 412 +++-
 drivers/crypto/marvell/tdma.c   | 224 ++
 7 files changed, 1087 insertions(+), 16 deletions(-)
 create mode 100644 drivers/crypto/marvell/tdma.c

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index c15c5a5..cbf2957 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -186,6 +186,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 8d90e28..5a226c4 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -180,6 +180,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[] = {
@@ -188,6 +189,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);
@@ -295,6 +356,10 @@ static int mv_cesa_probe(struct platform_device *pdev)
if (IS_ERR(cesa->regs))
return -ENOMEM;
 
+   ret = mv_cesa_de

[RESEND PATCH v4 12/14] crypto: marvell/CESA: add support for Orion SoCs

2015-06-12 Thread Boris Brezillon
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 
---
 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 c7e25a0..bd54973 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

--
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


[RESEND PATCH v4 11/14] crypto: marvell/CESA: add allhwsupport module parameter

2015-06-12 Thread Boris Brezillon
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 
---
 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 087370e..c7e25a0 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


[RESEND PATCH v4 06/14] crypto: marvell/CESA: add DES support

2015-06-12 Thread Boris Brezillon
Add support for DES operations.

Signed-off-by: Boris Brezillon 
Signed-off-by: Arnaud Ebalard 
---
 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 5a226c4..47c9ef8 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -165,6 +165,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 fcacc70..5d91da3 100644
--- a/drivers/crypto/marvell/cesa.h
+++ b/drivers/crypto/marvell/cesa.h
@@ -790,6 +790,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 8188fc2..2094a9e 100644
--- a/drivers/crypto/marvell/cipher.c
+++ b/drivers/crypto/marvell/cipher.c
@@ -13,9 +13,15 @@
  */
 
 #include 
+#include 
 
 #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;
@@ -223,6 +229,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)
 {
@@ -341,6 +371,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 = mv_cesa_ecb_des_decrypt,
+   },
+   

[RESEND PATCH v4 14/14] crypto: marvell/CESA: add DT bindings documentation

2015-06-12 Thread Boris Brezillon
Add DT bindings documentation for the new marvell-cesa driver.

Signed-off-by: Boris Brezillon 
---
 .../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


[RESEND PATCH v4 07/14] crypto: marvell/CESA: add Triple-DES support

2015-06-12 Thread Boris Brezillon
From: Arnaud Ebalard 

Add support for Triple-DES operations.

Signed-off-by: Arnaud Ebalard 
Signed-off-by: Boris Brezillon 
---
 drivers/crypto/marvell/cesa.c   |   2 +
 drivers/crypto/marvell/cesa.h   |   2 +
 drivers/crypto/marvell/cipher.c | 147 
 3 files changed, 151 insertions(+)

diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 47c9ef8..b9f4d26 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -167,6 +167,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_des3_ede_alg,
+   &mv_cesa_cbc_des3_ede_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 5d91da3..d886280 100644
--- a/drivers/crypto/marvell/cesa.h
+++ b/drivers/crypto/marvell/cesa.h
@@ -792,6 +792,8 @@ 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_des3_ede_alg;
+extern struct crypto_alg mv_cesa_cbc_des3_ede_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 2094a9e..d71262d 100644
--- a/drivers/crypto/marvell/cipher.c
+++ b/drivers/crypto/marvell/cipher.c
@@ -22,6 +22,11 @@ struct mv_cesa_des_ctx {
u8 key[DES_KEY_SIZE];
 };
 
+struct mv_cesa_des3_ctx {
+   struct mv_cesa_ctx base;
+   u8 key[DES3_EDE_KEY_SIZE];
+};
+
 struct mv_cesa_aes_ctx {
struct mv_cesa_ctx base;
struct crypto_aes_ctx aes;
@@ -253,6 +258,22 @@ static int mv_cesa_des_setkey(struct crypto_ablkcipher 
*cipher, const u8 *key,
return 0;
 }
 
+static int mv_cesa_des3_ede_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);
+
+   if (len != DES3_EDE_KEY_SIZE) {
+   crypto_ablkcipher_set_flags(cipher, CRYPTO_TFM_RES_BAD_KEY_LEN);
+   return -EINVAL;
+   }
+
+   memcpy(ctx->key, key, DES3_EDE_KEY_SIZE);
+
+   return 0;
+}
+
 static int mv_cesa_ablkcipher_dma_req_init(struct ablkcipher_request *req,
const struct mv_cesa_op_ctx *op_templ)
 {
@@ -491,6 +512,132 @@ struct crypto_alg mv_cesa_cbc_des_alg = {
},
 };
 
+static int mv_cesa_des3_op(struct ablkcipher_request *req,
+  struct mv_cesa_op_ctx *tmpl)
+{
+   struct mv_cesa_des3_ctx *ctx = crypto_tfm_ctx(req->base.tfm);
+   int ret;
+
+   mv_cesa_update_op_cfg(tmpl, CESA_SA_DESC_CFG_CRYPTM_3DES,
+ CESA_SA_DESC_CFG_CRYPTM_MSK);
+
+   memcpy(tmpl->ctx.blkcipher.key, ctx->key, DES3_EDE_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_des3_ede_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_3DES_EDE |
+  CESA_SA_DESC_CFG_DIR_ENC);
+
+   return mv_cesa_des3_op(req, &tmpl);
+}
+
+static int mv_cesa_ecb_des3_ede_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_3DES_EDE |
+  CESA_SA_DESC_CFG_DIR_DEC);
+
+   return mv_cesa_des3_op(req, &tmpl);
+}
+
+struct crypto_alg mv_cesa_ecb_des3_ede_alg = {
+   .cra_name = "ecb(des3_ede)",
+   .cra_driver_name = "mv-ecb-des3-ede",
+   .cra_priority = 300,
+   .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+CRYPTO_ALG_KERN_DRIVER_ONLY | CRYPTO_ALG_ASYNC,
+   .cra_blocksize = DES3_EDE_BLOCK_SIZE,
+   .cra_ctxsize = sizeof(struct mv_cesa_des3_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 = DES3_EDE_KEY_SIZE,
+   .max_keysize = DES3_EDE_KEY_SIZE,
+   .ivsize  = DES3_EDE_BLOCK_SIZE,
+   .setkey = mv_cesa_des3_ede_setkey,
+   .encrypt = mv_cesa_ecb_des3_ede_encrypt,
+

[RESEND PATCH v4 13/14] crypto: marvell/CESA: add support for Kirkwood and Dove SoCs

2015-06-12 Thread Boris Brezillon
From: Arnaud Ebalard 

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 
Signed-off-by: Boris Brezillon 
---
 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 bd54973..3546ee7 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,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 },
@@ -379,7 +390,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


[RESEND PATCH v4 08/14] crypto: marvell/CESA: add MD5 support

2015-06-12 Thread Boris Brezillon
From: Arnaud Ebalard 

Add support for MD5 operations.

Signed-off-by: Arnaud Ebalard 
Signed-off-by: Boris Brezillon 
---
 drivers/crypto/marvell/cesa.c |   2 +
 drivers/crypto/marvell/cesa.h |   2 +
 drivers/crypto/marvell/hash.c | 170 +-
 3 files changed, 172 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index b9f4d26..b9da0df 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 f9c6d47..63fa493 100644
--- a/drivers/crypto/marvell/hash.c
+++ b/drivers/crypto/marvell/hash.c
@@ -12,6 +12,7 @@
  * by the Free Software Foundation.
  */
 
+#include 
 #include 
 
 #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,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,
+   .cra_flags = CRYPTO_ALG_ASYNC |
+  

[RESEND PATCH v4 01/14] crypto: mv_cesa: document the clocks property

2015-06-12 Thread Boris Brezillon
On Dove platforms, the crypto engine requires a clock. Document this
clocks property in the mv_cesa bindings doc.

Signed-off-by: Boris Brezillon 
---
 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


[RESEND PATCH v4 04/14] crypto: add a new driver for Marvell's CESA

2015-06-12 Thread Boris Brezillon
The existing mv_cesa driver supports some features of the CESA IP but is
quite limited, and reworking it to support new features (like involving the
TDMA engine to offload the CPU) is almost impossible.
This driver has been rewritten from scratch to take those new features into
account.

This commit introduce the base infrastructure allowing us to add support
for DMA optimization.
It also includes support for one hash (SHA1) and one cipher (AES)
algorithm, and enable those features on the Armada 370 SoC.

Other algorithms and platforms will be added later on.

Signed-off-by: Boris Brezillon 
Signed-off-by: Arnaud Ebalard 
---
 drivers/crypto/Kconfig  |  16 +
 drivers/crypto/Makefile |   1 +
 drivers/crypto/marvell/Makefile |   2 +
 drivers/crypto/marvell/cesa.c   | 413 +++
 drivers/crypto/marvell/cesa.h   | 567 +++
 drivers/crypto/marvell/cipher.c | 320 ++
 drivers/crypto/marvell/hash.c   | 718 
 7 files changed, 2037 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..c15c5a5 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -174,6 +174,22 @@ 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_ALGAPI
+   select CRYPTO_AES
+   select CRYPTO_DES
+   select CRYPTO_BLKCIPHER2
+   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..8d90e28
--- /dev/null
+++ b/drivers/crypto/marvell/cesa.c
@@ -0,0 +1,413 @@
+/*
+ * 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 
+ * Author: Arnaud Ebalard 
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#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;
+   struct mv_cesa_ctx *ctx;
+
+   spin_lock_bh(&cesa_dev->lock);
+   req = crypto_dequeue_request(&cesa_dev->queue);
+   engine->req = req;
+   spin_unlock_bh(&cesa_dev->lock);
+
+   if (!req)
+   return;
+
+   ctx = crypto_tfm_ctx(req->tfm);
+   ctx->ops->prepare(req, engine);
+   ctx->ops->step(req);
+}
+
+static irqreturn_t mv_cesa_int(int irq, void *priv)
+{
+   struct mv_cesa_engine *engine = priv;
+   struct crypto_async_request *req;
+   struct mv_cesa_ctx *ctx;
+   u32 status, mask;
+   irqreturn_t ret = IRQ_NONE;
+
+   while (true) {
+   int res;
+
+