[PATCH] crypto: powerpc - move files to fix build error

2015-03-06 Thread Kim Phillips
The current cryptodev-2.6 tree commits:

d9850fc529ef (crypto: powerpc/sha1 - kernel config)
50ba29aaa7b0 (crypto: powerpc/sha1 - glue)

failed to properly place files under arch/powerpc/crypto, which
leads to build errors:

make[1]: *** No rule to make target 'arch/powerpc/crypto/sha1-spe-asm.o', 
needed by 'arch/powerpc/crypto/sha1-ppc-spe.o'.  Stop.
make[1]: *** No rule to make target 'arch/powerpc/crypto/sha1_spe_glue.o', 
needed by 'arch/powerpc/crypto/sha1-ppc-spe.o'.  Stop.
Makefile:947: recipe for target 'arch/powerpc/crypto' failed

Move the two sha1 spe files under crypto/, and whilst there, rename
other powerpc crypto files with underscores to use dashes for
consistency.

Cc: Markus Stockhausen stockhau...@collogia.de
Signed-off-by: Kim Phillips kim.phill...@freescale.com
---
applies to today's cryptodev-2.6.

 arch/powerpc/crypto/Makefile | 8 
 arch/powerpc/crypto/{aes_spe_glue.c = aes-spe-glue.c}   | 0
 arch/powerpc/crypto/{md5_glue.c = md5-glue.c}   | 0
 arch/powerpc/{ = crypto}/sha1-spe-asm.S | 0
 arch/powerpc/{sha1_spe_glue.c = crypto/sha1-spe-glue.c} | 0
 arch/powerpc/crypto/{sha256_spe_glue.c = sha256-spe-glue.c} | 0
 6 files changed, 4 insertions(+), 4 deletions(-)
 rename arch/powerpc/crypto/{aes_spe_glue.c = aes-spe-glue.c} (100%)
 rename arch/powerpc/crypto/{md5_glue.c = md5-glue.c} (100%)
 rename arch/powerpc/{ = crypto}/sha1-spe-asm.S (100%)
 rename arch/powerpc/{sha1_spe_glue.c = crypto/sha1-spe-glue.c} (100%)
 rename arch/powerpc/crypto/{sha256_spe_glue.c = sha256-spe-glue.c} (100%)

diff --git a/arch/powerpc/crypto/Makefile b/arch/powerpc/crypto/Makefile
index c6b25cba..9c221b6 100644
--- a/arch/powerpc/crypto/Makefile
+++ b/arch/powerpc/crypto/Makefile
@@ -10,8 +10,8 @@ obj-$(CONFIG_CRYPTO_SHA1_PPC) += sha1-powerpc.o
 obj-$(CONFIG_CRYPTO_SHA1_PPC_SPE) += sha1-ppc-spe.o
 obj-$(CONFIG_CRYPTO_SHA256_PPC_SPE) += sha256-ppc-spe.o
 
-aes-ppc-spe-y := aes-spe-core.o aes-spe-keys.o aes-tab-4k.o aes-spe-modes.o 
aes_spe_glue.o
-md5-ppc-y := md5-asm.o md5_glue.o
+aes-ppc-spe-y := aes-spe-core.o aes-spe-keys.o aes-tab-4k.o aes-spe-modes.o 
aes-spe-glue.o
+md5-ppc-y := md5-asm.o md5-glue.o
 sha1-powerpc-y := sha1-powerpc-asm.o sha1.o
-sha1-ppc-spe-y := sha1-spe-asm.o sha1_spe_glue.o
-sha256-ppc-spe-y := sha256-spe-asm.o sha256_spe_glue.o
+sha1-ppc-spe-y := sha1-spe-asm.o sha1-spe-glue.o
+sha256-ppc-spe-y := sha256-spe-asm.o sha256-spe-glue.o
diff --git a/arch/powerpc/crypto/aes_spe_glue.c 
b/arch/powerpc/crypto/aes-spe-glue.c
similarity index 100%
rename from arch/powerpc/crypto/aes_spe_glue.c
rename to arch/powerpc/crypto/aes-spe-glue.c
diff --git a/arch/powerpc/crypto/md5_glue.c b/arch/powerpc/crypto/md5-glue.c
similarity index 100%
rename from arch/powerpc/crypto/md5_glue.c
rename to arch/powerpc/crypto/md5-glue.c
diff --git a/arch/powerpc/sha1-spe-asm.S b/arch/powerpc/crypto/sha1-spe-asm.S
similarity index 100%
rename from arch/powerpc/sha1-spe-asm.S
rename to arch/powerpc/crypto/sha1-spe-asm.S
diff --git a/arch/powerpc/sha1_spe_glue.c b/arch/powerpc/crypto/sha1-spe-glue.c
similarity index 100%
rename from arch/powerpc/sha1_spe_glue.c
rename to arch/powerpc/crypto/sha1-spe-glue.c
diff --git a/arch/powerpc/crypto/sha256_spe_glue.c 
b/arch/powerpc/crypto/sha256-spe-glue.c
similarity index 100%
rename from arch/powerpc/crypto/sha256_spe_glue.c
rename to arch/powerpc/crypto/sha256-spe-glue.c
-- 
2.3.1

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/2] crypto: talitos: Add AES-XTS Support

2015-03-06 Thread Kim Phillips
On Fri, 6 Mar 2015 11:49:43 -0500
Martin Hicks m...@bork.org wrote:

 On Thu, Mar 5, 2015 at 7:16 PM, Kim Phillips kim.phill...@freescale.com 
 wrote:
  On Fri, 20 Feb 2015 12:00:10 -0500
  Martin Hicks m...@bork.org wrote:
 
  The newer talitos hardware has support for AES in XTS mode.
 
  Assuming it's the same thing, AES-XCBC gets added with SEC v3.0
  h/w.  Assuming hw_supports() doesn't already support this algorithm
 
 AES-XCBC isn't the same thing as AES-XTS.

Thanks.

  combination (technically via the mode bit), this needs to be
  reflected in the patch so the driver doesn't think SEC 2.x devices
  can do XTS, too.
 
 Right.  I hadn't looked into how exactly hw_supports() works.  It only
 indicates which execution units are present (in this case the AES
 unit).  I actually think XTS gets introduced in SEC v3.3.2.  I also
 have an MPC8379 (sec3.3) and it does not have XTS.
 
 Can you look internally to find out in which hardware it was
 introduced?  Is there a SEC 3.3.1 that also has XTS?

later MPC8315Es had a SEC v3.3.1, but AFAICT, it doesn't support
XTS, so, yes, it's likely v3.3.2 and above (if any).

 I guess I just need a -features flag to conditionally register the
 XTS algorithm for 3.3.x and newer.  Adding anything more complicated
 doesn't seem warranted at this time, although that could change if
 someone came along and needed to add a whole whack more of the AES
 modes that were introduced at various times in the different SEC
 revisions.

OK.  Note: there's some SEC node fixup code in u-boot that could be
used for this job, too.

  + .desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU |
  + DESC_HDR_SEL0_AESU |
  + DESC_HDR_MODE0_AESU_XTS,
 
  ...
 
   /* primary execution unit mode (MODE0) and derivatives */
   #define  DESC_HDR_MODE0_ENCRYPT  cpu_to_be32(0x0010)
   #define  DESC_HDR_MODE0_AESU_CBC cpu_to_be32(0x0020)
  +#define  DESC_HDR_MODE0_AESU_XTS cpu_to_be32(0x0420)
 
  I'd prefer these defines be kept as single bit definitions, and keep
  their names from the manual.  An XTS-specific definition can be
  composed from them either after this, or manually in the
  desc_hdr_template assignment above.
 
 It doesn't look like there are divisible single-bit definitions for
 the MODE0 bits. The AES Cipher modes are composed of 5 bits called
 CipherMode, Extended CipherMode and Aux2.  Individually they don't
 seem to mean anything.  Unless you want something like:
 
 #define AES_MODE(cm, ecm, aux2)   cpu_to_be32(((ecm6) | (aux25) |
 (cm1))  20)
 
 #define DESC_HDR_MODE0_AESU_CBC  AES_MODE(1, 0, 0)
 #define DESC_HDR_MODE0_AESU_XTS   AES_MODE(1, 1, 0)

the way you had it seems to be ok for now.

Kim
--
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 1/2] crypto: caamhash: - fix uninitialized edesc-sec4_sg_bytes field

2015-03-06 Thread Kim Phillips
On Fri, 6 Mar 2015 10:34:41 +0800
yanjiang@windriver.com wrote:

 From: Yanjiang Jin yanjiang@windriver.com
 
 sec4_sg_bytes not being properly initialized causes ahash_done
 to try to free unallocated DMA memory:
 
 caam_jr ffe301000.jr: DMA-API: device driver tries to free DMA memory it has 
 not allocated [device address=0xdeadbeefdeadbeef] [size=3735928559 bytes]
 [ cut here ]
 WARNING: at lib/dma-debug.c:1093
 Modules linked in:
 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.0.0-rc1+ #6
 task: e9598c00 ti: effca000 task.ti: e95a2000
 NIP: c04ef24c LR: c04ef24c CTR: c0549730
 REGS: effcbd40 TRAP: 0700   Not tainted  (4.0.0-rc1+)
 MSR: 00029002 CE,EE,ME  CR: 22008084  XER: 2000
 
 GPR00: c04ef24c effcbdf0 e9598c00 0096 c08f7424 c00ab2b0  0001
 GPR08: c0fe7510 effca000  01c3 22008082  c1048e77 c105
 GPR16: c0c36700 493c0040 002c e690e4a0 c1054fb4 c18bac40 00029002 c18b0788
 GPR24: 0014 e690e480 effcbe48  c0fde128 e6ffac10 deadbeef deadbeef
 NIP [c04ef24c] check_unmap+0x93c/0xb40
 LR [c04ef24c] check_unmap+0x93c/0xb40
 Call Trace:
 [effcbdf0] [c04ef24c] check_unmap+0x93c/0xb40 (unreliable)
 [effcbe40] [c04ef4f4] debug_dma_unmap_page+0xa4/0xc0
 [effcbec0] [c070cda8] ahash_done+0x128/0x1a0
 [effcbef0] [c0700070] caam_jr_dequeue+0x1d0/0x290
 [effcbf40] [c0045f40] tasklet_action+0x110/0x1f0
 [effcbf80] [c0044bc8] __do_softirq+0x188/0x700
 [effcbfe0] [c00455d8] irq_exit+0x108/0x120
 [effcbff0] [c000f520] call_do_irq+0x24/0x3c
 [e95a3e20] [c00059b8] do_IRQ+0xc8/0x170
 [e95a3e50] [c0011bc8] ret_from_except+0x0/0x18
 
 Signed-off-by: Yanjiang Jin yanjiang@windriver.com
 ---

Acked-by: Kim Phillips kim.phill...@freescale.com

Thanks,

Kim
--
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] rng: xgene-rng: add ACPI support for APM X-Gene RNG unit

2015-03-06 Thread Feng Kan
This adds ACPI support for APM X-Gene RNG unit.

Signed-off-by: Feng Kan f...@apm.com
---
 drivers/char/hw_random/xgene-rng.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/char/hw_random/xgene-rng.c 
b/drivers/char/hw_random/xgene-rng.c
index 23caa05..c37cf75 100644
--- a/drivers/char/hw_random/xgene-rng.c
+++ b/drivers/char/hw_random/xgene-rng.c
@@ -21,6 +21,7 @@
  *
  */
 
+#include linux/acpi.h
 #include linux/clk.h
 #include linux/delay.h
 #include linux/hw_random.h
@@ -310,6 +311,14 @@ static int xgene_rng_init(struct hwrng *rng)
return 0;
 }
 
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id xgene_rng_acpi_match[] = {
+   { APMC0D18, },
+   { }
+};
+MODULE_DEVICE_TABLE(acpi, xgene_rng_acpi_match);
+#endif
+
 static struct hwrng xgene_rng_func = {
.name   = xgene-rng,
.init   = xgene_rng_init,
@@ -415,6 +424,7 @@ static struct platform_driver xgene_rng_driver = {
.driver = {
.name   = xgene-rng,
.of_match_table = xgene_rng_of_match,
+   .acpi_match_table = ACPI_PTR(xgene_rng_acpi_match),
},
 };
 
-- 
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


Reply back to me

2015-03-06 Thread Catherine Peng



I have business finance proposition for you. Reply for details
--
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 RESEND 2/2] crypto: algif - change algif_skcipher to be asynchronous

2015-03-06 Thread Herbert Xu
On Fri, Feb 27, 2015 at 11:35:49AM -0800, Tadeusz Struk wrote:

 +static int skcipher_mempool_create(struct sock *sk)
 +{
 + struct alg_sock *ask = alg_sk(sk);
 + struct skcipher_ctx *ctx = ask-private;
 + unsigned int len = sizeof(struct skcipher_async_req) +
 + GET_REQ_SIZE(ctx) + GET_IV_SIZE(ctx);
 + char buf[32];
 +
 + snprintf(buf, sizeof(buf), skcipher_%p, ctx);
 + ctx-cache = kmem_cache_create(buf, len, 0, SLAB_HWCACHE_ALIGN |
 +SLAB_TEMPORARY,
 +skcipher_cache_constructor);

Are these separate caches really necessary? It looks like an
overkill.  What's wrong with just kmalloc?

Cheers,
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 0/2] Add support for Broadcom RNG200

2015-03-06 Thread Herbert Xu
On Wed, Mar 04, 2015 at 12:42:12PM -0800, Scott Branden wrote:
 This series of patchsets contains the Broadcom Random Number Generator
 driver and device tree binding documentation.
 
 Changes from v2:
  added usleep_range instead of cpu_relax
  add init and cleanup functions following new hwrng model

All applied.  Thanks!
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH trivial/resend 4/9] crypto: ux500: Update error message for dmaengine_prep_slave_sg() API

2015-03-06 Thread Herbert Xu
On Wed, Mar 04, 2015 at 10:19:30AM +0100, Geert Uytterhoeven wrote:
 From: Geert Uytterhoeven geert+rene...@glider.be
 
 Commit 7e933d3b1e25b250 (crypto: ux500: use dmaengine_prep_slave_sg
 API) changed the code to use the new API, but forgot to update an error
 message.
 
 Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
 Cc: Herbert Xu herb...@gondor.apana.org.au

Applied.
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH RESEND 2/2] crypto: algif - change algif_skcipher to be asynchronous

2015-03-06 Thread Tadeusz Struk
On 03/06/2015 11:44 AM, Herbert Xu wrote:
 Are these separate caches really necessary? It looks like an
 overkill.  What's wrong with just kmalloc?

Hi Herbert,
It helps to make it faster.
This way I can do some of the request setup beforehand and minimize overhead on 
the data path.
Thanks,
Tadeusz
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] crypto: RNGs must return 0 in success case

2015-03-06 Thread Neil Horman

Change the RNGs to always return 0 in success case.

This patch ensures that seqiv.c works with RNGs other than krng. seqiv
expects that any return code other than 0 is an error. Without the
patch, rfc4106(gcm(aes)) will not work when using a DRBG or an ANSI
X9.31 RNG.

For the X9.31 bits:
Acked-by: Neil Horman nhor...@tuxdriver.com
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH RESEND 2/2] crypto: algif - change algif_skcipher to be asynchronous

2015-03-06 Thread Herbert Xu
On Fri, Mar 06, 2015 at 12:04:49PM +, Tadeusz Struk wrote:
 It helps to make it faster.
 This way I can do some of the request setup beforehand and minimize overhead 
 on the data path.

Do you have numbers to back this up?

Cheers,
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/2] crypto: talitos: Add AES-XTS Support

2015-03-06 Thread Martin Hicks
On Thu, Mar 5, 2015 at 7:16 PM, Kim Phillips kim.phill...@freescale.com wrote:
 On Fri, 20 Feb 2015 12:00:10 -0500
 Martin Hicks m...@bork.org wrote:

 The newer talitos hardware has support for AES in XTS mode.

 Assuming it's the same thing, AES-XCBC gets added with SEC v3.0
 h/w.  Assuming hw_supports() doesn't already support this algorithm

AES-XCBC isn't the same thing as AES-XTS.

 combination (technically via the mode bit), this needs to be
 reflected in the patch so the driver doesn't think SEC 2.x devices
 can do XTS, too.

Right.  I hadn't looked into how exactly hw_supports() works.  It only
indicates which execution units are present (in this case the AES
unit).  I actually think XTS gets introduced in SEC v3.3.2.  I also
have an MPC8379 (sec3.3) and it does not have XTS.

Can you look internally to find out in which hardware it was
introduced?  Is there a SEC 3.3.1 that also has XTS?

I guess I just need a -features flag to conditionally register the
XTS algorithm for 3.3.x and newer.  Adding anything more complicated
doesn't seem warranted at this time, although that could change if
someone came along and needed to add a whole whack more of the AES
modes that were introduced at various times in the different SEC
revisions.


 + .desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU |
 + DESC_HDR_SEL0_AESU |
 + DESC_HDR_MODE0_AESU_XTS,

 ...

  /* primary execution unit mode (MODE0) and derivatives */
  #define  DESC_HDR_MODE0_ENCRYPT  cpu_to_be32(0x0010)
  #define  DESC_HDR_MODE0_AESU_CBC cpu_to_be32(0x0020)
 +#define  DESC_HDR_MODE0_AESU_XTS cpu_to_be32(0x0420)

 I'd prefer these defines be kept as single bit definitions, and keep
 their names from the manual.  An XTS-specific definition can be
 composed from them either after this, or manually in the
 desc_hdr_template assignment above.

It doesn't look like there are divisible single-bit definitions for
the MODE0 bits. The AES Cipher modes are composed of 5 bits called
CipherMode, Extended CipherMode and Aux2.  Individually they don't
seem to mean anything.  Unless you want something like:

#define AES_MODE(cm, ecm, aux2)   cpu_to_be32(((ecm6) | (aux25) |
(cm1))  20)

#define DESC_HDR_MODE0_AESU_CBC  AES_MODE(1, 0, 0)
#define DESC_HDR_MODE0_AESU_XTS   AES_MODE(1, 1, 0)

Thanks,
mh

-- 
Martin Hicks P.Eng.  | m...@bork.org
Bork Consulting Inc. |   +1 (613) 266-2296
--
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 v2 02/17] crypto: talitos - Externalise specific SEC2 reset actions

2015-03-06 Thread Christophe Leroy
During init and reset, some actions are different between SEC1 and SEC2
This patch isolates them in small helper functions that we will be able
to redefine for SEC1

Signed-off-by: Christophe Leroy christophe.le...@c-s.fr

---
 drivers/crypto/talitos.c | 20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 857414a..103bfcf 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -88,9 +88,8 @@ static void unmap_single_talitos_ptr(struct device *dev,
 be16_to_cpu(talitos_ptr-len), dir);
 }
 
-static int reset_channel(struct device *dev, int ch)
+static unsigned int do_reset_channel(struct talitos_private *priv, int ch)
 {
-   struct talitos_private *priv = dev_get_drvdata(dev);
unsigned int timeout = TALITOS_TIMEOUT;
 
setbits32(priv-chan[ch].reg + TALITOS_CCCR, TALITOS_CCCR_RESET);
@@ -99,6 +98,14 @@ static int reset_channel(struct device *dev, int ch)
--timeout)
cpu_relax();
 
+   return timeout;
+}
+
+static int reset_channel(struct device *dev, int ch)
+{
+   struct talitos_private *priv = dev_get_drvdata(dev);
+   unsigned int timeout = do_reset_channel(priv, ch);
+
if (timeout == 0) {
dev_err(dev, failed to reset channel %d\n, ch);
return -EIO;
@@ -144,6 +151,12 @@ static int reset_device(struct device *dev)
 /*
  * Reset and initialize the device
  */
+static void do_init_device(struct talitos_private *priv)
+{
+   setbits32(priv-reg + TALITOS_IMR, TALITOS_IMR_INIT);
+   setbits32(priv-reg + TALITOS_IMR_LO, TALITOS_IMR_LO_INIT);
+}
+
 static int init_device(struct device *dev)
 {
struct talitos_private *priv = dev_get_drvdata(dev);
@@ -171,8 +184,7 @@ static int init_device(struct device *dev)
}
 
/* enable channel done and error interrupts */
-   setbits32(priv-reg + TALITOS_IMR, TALITOS_IMR_INIT);
-   setbits32(priv-reg + TALITOS_IMR_LO, TALITOS_IMR_LO_INIT);
+   do_init_device(priv);
 
/* disable integrity check error interrupts (use writeback instead) */
if (priv-features  TALITOS_FTR_HW_AUTH_CHECK)
-- 
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 v2 10/17] crypto: talitos - Move interrupt related macros in talitos2.h

2015-03-06 Thread Christophe Leroy
Move interrupt related macros in talitos2.h as they are specific to SEC2

Signed-off-by: Christophe Leroy christophe.le...@c-s.fr

---
 drivers/crypto/talitos.c  | 58 -
 drivers/crypto/talitos2.h | 60 +++
 2 files changed, 60 insertions(+), 58 deletions(-)

diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index ffa103b..b1ba98b 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -262,32 +262,6 @@ void talitos_flush_channel(struct device *dev, int ch, int 
error, int reset_ch)
 /*
  * process completed requests for channels that have done status
  */
-#define DEF_TALITOS_DONE(name, ch_done_mask)   \
-static void talitos_done_##name(unsigned long data)\
-{  \
-   struct device *dev = (struct device *)data; \
-   struct talitos_private *priv = dev_get_drvdata(dev);\
-   unsigned long flags;\
-   \
-   if (ch_done_mask  1)   \
-   talitos_flush_channel(dev, 0, 0, 0);\
-   if (priv-num_channels == 1)\
-   goto out;   \
-   if (ch_done_mask  (1  2))\
-   talitos_flush_channel(dev, 1, 0, 0);\
-   if (ch_done_mask  (1  4))\
-   talitos_flush_channel(dev, 2, 0, 0);\
-   if (ch_done_mask  (1  6))\
-   talitos_flush_channel(dev, 3, 0, 0);\
-   \
-out:   \
-   /* At this point, all completed channels have been processed */ \
-   /* Unmask done interrupts for channels completed later on. */   \
-   spin_lock_irqsave(priv-reg_lock, flags);  \
-   setbits32(priv-reg + TALITOS_IMR, ch_done_mask);   \
-   setbits32(priv-reg + TALITOS_IMR_LO, TALITOS_IMR_LO_INIT); \
-   spin_unlock_irqrestore(priv-reg_lock, flags); \
-}
 DEF_TALITOS_DONE(4ch, TALITOS_ISR_4CHDONE)
 DEF_TALITOS_DONE(ch0_2, TALITOS_ISR_CH_0_2_DONE)
 DEF_TALITOS_DONE(ch1_3, TALITOS_ISR_CH_1_3_DONE)
@@ -399,38 +373,6 @@ void talitos_report_eu_error(struct device *dev, int ch)
in_be32(priv-chan[ch].reg + TALITOS_DESCBUF_LO + 8*i));
 }
 
-#define DEF_TALITOS_INTERRUPT(name, ch_done_mask, ch_err_mask, tlet)  \
-static irqreturn_t talitos_interrupt_##name(int irq, void *data)  \
-{ \
-   struct device *dev = data; \
-   struct talitos_private *priv = dev_get_drvdata(dev);   \
-   u32 isr, isr_lo;   \
-   unsigned long flags;   \
-  \
-   spin_lock_irqsave(priv-reg_lock, flags); \
-   isr = in_be32(priv-reg + TALITOS_ISR);\
-   isr_lo = in_be32(priv-reg + TALITOS_ISR_LO);  \
-   /* Acknowledge interrupt */\
-   out_be32(priv-reg + TALITOS_ICR, isr  (ch_done_mask | ch_err_mask)); \
-   out_be32(priv-reg + TALITOS_ICR_LO, isr_lo);  \
-  \
-   if (unlikely(isr  ch_err_mask || isr_lo)) {   \
-   spin_unlock_irqrestore(priv-reg_lock, flags);\
-   talitos_error(dev, isr  ch_err_mask, isr_lo); \
-   }  \
-   else { \
-   if (likely(isr  ch_done_mask)) {  \
-   /* mask further done interrupts. */\
-   clrbits32(priv-reg + TALITOS_IMR, ch_done_mask);  \
-   /* done_task will unmask done interrupts at exit */\
-   tasklet_schedule(priv-done_task[tlet]);  \
-   }  \
-   spin_unlock_irqrestore(priv-reg_lock, flags);\
- 

[PATCH v2 06/17] crypto: talitos - Add talitos2.c to isolate SEC2 specific functions

2015-03-06 Thread Christophe Leroy
SEC1 doesn't have IPSec descriptor, so all functions using that descriptor
are specific to SEC2. This patch moves them in a new talitos2.c file
dedicated to SEC2

We also move to talitos2.c all the functions that will be different for
SEC1, like the handling of mapping/unmapping of input/output scatterlists

We move to talitos.h some of the helpers that are used by both talitos.c
and talitos2.c

Signed-off-by: Christophe Leroy christophe.le...@c-s.fr

---
 drivers/crypto/Kconfig|   4 +
 drivers/crypto/Makefile   |   1 +
 drivers/crypto/talitos.c  | 666 +-
 drivers/crypto/talitos.h  | 133 +
 drivers/crypto/talitos2.c | 614 ++
 5 files changed, 758 insertions(+), 660 deletions(-)
 create mode 100644 drivers/crypto/talitos2.c

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 2fb0fdf..4fd6d7e 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -211,6 +211,7 @@ config CRYPTO_DEV_TALITOS
select CRYPTO_ALGAPI
select CRYPTO_AUTHENC
select HW_RANDOM
+   select CRYPTO_DEV_TALITOS2
depends on FSL_SOC
help
  Say 'Y' here to use the Freescale Security Engine (SEC)
@@ -222,6 +223,9 @@ config CRYPTO_DEV_TALITOS
  To compile this driver as a module, choose M here: the module
  will be called talitos.
 
+config CRYPTO_DEV_TALITOS2
+   bool
+
 config CRYPTO_DEV_IXP4XX
tristate Driver for IXP4xx crypto hardware acceleration
depends on ARCH_IXP4XX  IXP4XX_QMGR  IXP4XX_NPE
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 3924f93..f26159f 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_CRYPTO_DEV_PPC4XX) += amcc/
 obj-$(CONFIG_CRYPTO_DEV_S5P) += s5p-sss.o
 obj-$(CONFIG_CRYPTO_DEV_SAHARA) += sahara.o
 obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o
+obj-$(CONFIG_CRYPTO_DEV_TALITOS2) += talitos2.o
 obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/
 obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
 obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 76e636b..114c5e5 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -55,39 +55,6 @@
 
 #include talitos.h
 
-static void to_talitos_ptr(struct talitos_ptr *talitos_ptr, dma_addr_t 
dma_addr)
-{
-   talitos_ptr-ptr = cpu_to_be32(lower_32_bits(dma_addr));
-   talitos_ptr-eptr = upper_32_bits(dma_addr);
-}
-
-/*
- * map virtual single (contiguous) pointer to h/w descriptor pointer
- */
-static void map_single_talitos_ptr(struct device *dev,
-  struct talitos_ptr *talitos_ptr,
-  unsigned short len, void *data,
-  unsigned char extent,
-  enum dma_data_direction dir)
-{
-   dma_addr_t dma_addr = dma_map_single(dev, data, len, dir);
-
-   talitos_ptr-len = cpu_to_be16(len);
-   to_talitos_ptr(talitos_ptr, dma_addr);
-   talitos_ptr-j_extent = extent;
-}
-
-/*
- * unmap bus single (contiguous) h/w descriptor pointer
- */
-static void unmap_single_talitos_ptr(struct device *dev,
-struct talitos_ptr *talitos_ptr,
-enum dma_data_direction dir)
-{
-   dma_unmap_single(dev, be32_to_cpu(talitos_ptr-ptr),
-be16_to_cpu(talitos_ptr-len), dir);
-}
-
 static unsigned int do_reset_channel(struct talitos_private *priv, int ch)
 {
unsigned int timeout = TALITOS_TIMEOUT;
@@ -646,20 +613,6 @@ static void talitos_unregister_rng(struct device *dev)
  * crypto alg
  */
 #define TALITOS_CRA_PRIORITY   3000
-#define TALITOS_MAX_KEY_SIZE   96
-#define TALITOS_MAX_IV_LENGTH  16 /* max of AES_BLOCK_SIZE, 
DES3_EDE_BLOCK_SIZE */
-
-struct talitos_ctx {
-   struct device *dev;
-   int ch;
-   __be32 desc_hdr_template;
-   u8 key[TALITOS_MAX_KEY_SIZE];
-   u8 iv[TALITOS_MAX_IV_LENGTH];
-   unsigned int keylen;
-   unsigned int enckeylen;
-   unsigned int authkeylen;
-   unsigned int authsize;
-};
 
 #define HASH_MAX_BLOCK_SIZESHA512_BLOCK_SIZE
 #define TALITOS_MDEU_MAX_CONTEXT_SIZE  TALITOS_MDEU_CONTEXT_SIZE_SHA384_SHA512
@@ -678,426 +631,6 @@ struct talitos_ahash_req_ctx {
struct scatterlist *psrc;
 };
 
-static int aead_setauthsize(struct crypto_aead *authenc,
-   unsigned int authsize)
-{
-   struct talitos_ctx *ctx = crypto_aead_ctx(authenc);
-
-   ctx-authsize = authsize;
-
-   return 0;
-}
-
-static int aead_setkey(struct crypto_aead *authenc,
-  const u8 *key, unsigned int keylen)
-{
-   struct talitos_ctx *ctx = crypto_aead_ctx(authenc);
-   struct crypto_authenc_keys keys;
-
-   if (crypto_authenc_extractkeys(keys, key, keylen) != 0)
-   goto badkey;
-
-   

[PATCH v2 13/17] crypto: talitos - move sg_count() helper into talitos.h

2015-03-06 Thread Christophe Leroy
move sg_count() helper into talitos.h as it will be needed by SEC1 specific 
functions

Signed-off-by: Christophe Leroy christophe.le...@c-s.fr

---
 drivers/crypto/talitos.c | 20 
 drivers/crypto/talitos.h | 21 +
 2 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 0262e75..76209e8 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -457,26 +457,6 @@ static void talitos_unregister_rng(struct device *dev)
 #define TALITOS_CRA_PRIORITY   3000
 
 /*
- * derive number of elements in scatterlist
- */
-static int sg_count(struct scatterlist *sg_list, int nbytes, bool *chained)
-{
-   struct scatterlist *sg = sg_list;
-   int sg_nents = 0;
-
-   *chained = false;
-   while (nbytes  0) {
-   sg_nents++;
-   nbytes -= sg-length;
-   if (!sg_is_last(sg)  (sg + 1)-length == 0)
-   *chained = true;
-   sg = sg_next(sg);
-   }
-
-   return sg_nents;
-}
-
-/*
  * allocate and map the extended descriptor
  */
 struct talitos_edesc *talitos_edesc_alloc(struct device *dev,
diff --git a/drivers/crypto/talitos.h b/drivers/crypto/talitos.h
index f5e8013..f0ffbb0 100644
--- a/drivers/crypto/talitos.h
+++ b/drivers/crypto/talitos.h
@@ -153,6 +153,27 @@ extern void talitos_error(struct device *dev, u32 isr, u32 
isr_lo);
 
 extern int talitos_cra_init(struct crypto_tfm *tfm);
 
+/*
+ * derive number of elements in scatterlist
+ */
+static inline int sg_count(struct scatterlist *sg_list, int nbytes,
+  bool *chained)
+{
+   struct scatterlist *sg = sg_list;
+   int sg_nents = 0;
+
+   *chained = false;
+   while (nbytes  0) {
+   sg_nents++;
+   nbytes -= sg-length;
+   if (!sg_is_last(sg)  (sg + 1)-length == 0)
+   *chained = true;
+   sg = sg_next(sg);
+   }
+
+   return sg_nents;
+}
+
 /* .features flag */
 #define TALITOS_FTR_SRC_LINK_TBL_LEN_INCLUDES_EXTENT 0x0001
 #define TALITOS_FTR_HW_AUTH_CHECK 0x0002
-- 
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 v2 16/17] crypto: talitos - SEC1 bugs on 0 data hash

2015-03-06 Thread Christophe Leroy
SEC1 bugs on 0 data hash, so we submit an already padded block representing 0 
data

Signed-off-by: Christophe Leroy christophe.le...@c-s.fr

---
 drivers/crypto/talitos.c  |  3 +++
 drivers/crypto/talitos1.c | 21 +
 drivers/crypto/talitos1.h |  4 
 drivers/crypto/talitos2.h |  6 ++
 4 files changed, 34 insertions(+)

diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 82a5181..0cb8ab4 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -815,6 +815,9 @@ static int common_nonsnoop_hash(struct talitos_edesc *edesc,
 
to_talitos_next_desc_clear(desc);
 
+   if (desc-ptr[3].len == 0)
+   talitos_handle_buggy_hash(ctx, edesc, desc-ptr[3]);
+
ret = talitos_submit(dev, ctx-ch, desc, callback, areq);
if (ret != -EINPROGRESS) {
common_nonsnoop_hash_unmap(dev, edesc, areq);
diff --git a/drivers/crypto/talitos1.c b/drivers/crypto/talitos1.c
index c1a8e9e..1edaa68 100644
--- a/drivers/crypto/talitos1.c
+++ b/drivers/crypto/talitos1.c
@@ -174,3 +174,24 @@ void talitos_error(struct device *dev, u32 isr, u32 isr_lo)
talitos_init_device(dev);
}
 }
+
+/*
+ * SEC1 doesn't like hashing of 0 sized message, so we do the padding
+ * ourself and submit a padded block
+ */
+void talitos_handle_buggy_hash(struct talitos_ctx *ctx,
+  struct talitos_edesc *edesc,
+  struct talitos_ptr *ptr)
+{
+   static u8 padded_hash[64] = {
+   0x80, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+   0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+   0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+   0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+   };
+
+   pr_err_once(Bug in SEC1, padding ourself\n);
+   edesc-desc.hdr = ~DESC_HDR_MODE0_MDEU_PAD;
+   map_single_talitos_ptr(ctx-dev, ptr, sizeof(padded_hash),
+  (char *)padded_hash, 0, DMA_TO_DEVICE);
+}
diff --git a/drivers/crypto/talitos1.h b/drivers/crypto/talitos1.h
index f78d89d..a9e0619 100644
--- a/drivers/crypto/talitos1.h
+++ b/drivers/crypto/talitos1.h
@@ -277,6 +277,10 @@ static inline void ahash_process_chain(struct scatterlist 
*src, int nbytes,
}
 }
 
+extern void talitos_handle_buggy_hash(struct talitos_ctx *ctx,
+  struct talitos_edesc *edesc,
+  struct talitos_ptr *ptr);
+
 #define DEF_TALITOS_DONE(name, ch_done_mask)   \
 static void talitos_done_##name(unsigned long data)\
 {  \
diff --git a/drivers/crypto/talitos2.h b/drivers/crypto/talitos2.h
index 2715c72..de0c8f4 100644
--- a/drivers/crypto/talitos2.h
+++ b/drivers/crypto/talitos2.h
@@ -266,6 +266,12 @@ static inline void ahash_process_chain(struct scatterlist 
*src, int nbytes,
req_ctx-psrc = src;
 }
 
+static inline void talitos_handle_buggy_hash(struct talitos_ctx *ctx,
+  struct talitos_edesc *edesc,
+  struct talitos_ptr *ptr)
+{
+}
+
 #define DEF_TALITOS_DONE(name, ch_done_mask)   \
 static void talitos_done_##name(unsigned long data)\
 {  \
-- 
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 v2 05/17] crypto: talitos - isolate scatter/gather handling for ahash

2015-03-06 Thread Christophe Leroy
SEC1 doesn't support scatter/gather, therefore this part of the code will
have to be implemented differently for SEC1, so we isolate it in a small
helper function

Signed-off-by: Christophe Leroy christophe.le...@c-s.fr

---
 drivers/crypto/talitos.c | 29 +++--
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 3165364..76e636b 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -1707,6 +1707,23 @@ static int ahash_init_sha224_swinit(struct ahash_request 
*areq)
return 0;
 }
 
+static void ahash_process_chain(struct scatterlist *src, int nbytes,
+   bool *chained,
+   struct talitos_ahash_req_ctx *req_ctx,
+   int nbytes_to_hash)
+{
+   if (req_ctx-nbuf) {
+   unsigned int nsg = (req_ctx-nbuf  nbytes_to_hash) ? 2 : 1;
+
+   sg_init_table(req_ctx-bufsl, nsg);
+   sg_set_buf(req_ctx-bufsl, req_ctx-buf, req_ctx-nbuf);
+   if (nsg  1)
+   scatterwalk_sg_chain(req_ctx-bufsl, 2, src);
+   req_ctx-psrc = req_ctx-bufsl;
+   } else
+   req_ctx-psrc = src;
+}
+
 static int ahash_process_req(struct ahash_request *areq, unsigned int nbytes)
 {
struct crypto_ahash *tfm = crypto_ahash_reqtfm(areq);
@@ -1717,7 +1734,6 @@ static int ahash_process_req(struct ahash_request *areq, 
unsigned int nbytes)
crypto_tfm_alg_blocksize(crypto_ahash_tfm(tfm));
unsigned int nbytes_to_hash;
unsigned int to_hash_later;
-   unsigned int nsg;
bool chained;
 
if (!req_ctx-last  (nbytes + req_ctx-nbuf = blocksize)) {
@@ -1745,15 +1761,8 @@ static int ahash_process_req(struct ahash_request *areq, 
unsigned int nbytes)
}
 
/* Chain in any previously buffered data */
-   if (req_ctx-nbuf) {
-   nsg = (req_ctx-nbuf  nbytes_to_hash) ? 2 : 1;
-   sg_init_table(req_ctx-bufsl, nsg);
-   sg_set_buf(req_ctx-bufsl, req_ctx-buf, req_ctx-nbuf);
-   if (nsg  1)
-   scatterwalk_sg_chain(req_ctx-bufsl, 2, areq-src);
-   req_ctx-psrc = req_ctx-bufsl;
-   } else
-   req_ctx-psrc = areq-src;
+   ahash_process_chain(areq-src, nbytes, chained, req_ctx,
+   nbytes_to_hash);
 
if (to_hash_later) {
int nents = sg_count(areq-src, nbytes, chained);
-- 
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 v2 17/17] crypto: talitos - Update DT bindings with SEC1

2015-03-06 Thread Christophe Leroy
This patch updates the documentation by including SEC1 into SEC2/3 doc

Signed-off-by: Christophe Leroy christophe.le...@c-s.fr

---
 Documentation/devicetree/bindings/crypto/fsl-sec2.txt | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec2.txt 
b/Documentation/devicetree/bindings/crypto/fsl-sec2.txt
index 38988ef..570d6a2 100644
--- a/Documentation/devicetree/bindings/crypto/fsl-sec2.txt
+++ b/Documentation/devicetree/bindings/crypto/fsl-sec2.txt
@@ -1,9 +1,10 @@
-Freescale SoC SEC Security Engines versions 2.x-3.x
+Freescale SoC SEC Security Engines versions 1.x-2.x-3.x
 
 Required properties:
 
 - compatible : Should contain entries for this and backward compatible
-  SEC versions, high to low, e.g., fsl,sec2.1, fsl,sec2.0
+  SEC versions, high to low, e.g., fsl,sec2.1, fsl,sec2.0 (SEC2/3)
+ e.g., fsl,sec1.2, fsl,sec1.0 (SEC1)
 - reg : Offset and length of the register set for the device
 - interrupts : the SEC's interrupt number
 - fsl,num-channels : An integer representing the number of channels
-- 
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 v2 08/17] crypto: talitos - Deport SEC2 error handling

2015-03-06 Thread Christophe Leroy
SEC2 and SEC1 error handling will be different because so many bits are
different. So we move error handling into talitos2.c

Signed-off-by: Christophe Leroy christophe.le...@c-s.fr

---
 drivers/crypto/talitos.c  | 103 +-
 drivers/crypto/talitos.h  |   8 
 drivers/crypto/talitos2.c |  82 
 3 files changed, 101 insertions(+), 92 deletions(-)

diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 114c5e5..81a6e47 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -68,7 +68,7 @@ static unsigned int do_reset_channel(struct talitos_private 
*priv, int ch)
return timeout;
 }
 
-static int reset_channel(struct device *dev, int ch)
+int talitos_reset_channel(struct device *dev, int ch)
 {
struct talitos_private *priv = dev_get_drvdata(dev);
unsigned int timeout = do_reset_channel(priv, ch);
@@ -124,7 +124,7 @@ static void do_init_device(struct talitos_private *priv)
setbits32(priv-reg + TALITOS_IMR_LO, TALITOS_IMR_LO_INIT);
 }
 
-static int init_device(struct device *dev)
+int talitos_init_device(struct device *dev)
 {
struct talitos_private *priv = dev_get_drvdata(dev);
int ch, err;
@@ -145,7 +145,7 @@ static int init_device(struct device *dev)
 
/* reset channels */
for (ch = 0; ch  priv-num_channels; ch++) {
-   err = reset_channel(dev, ch);
+   err = talitos_reset_channel(dev, ch);
if (err)
return err;
}
@@ -223,7 +223,7 @@ EXPORT_SYMBOL(talitos_submit);
 /*
  * process what was done, notify callback of error if not
  */
-static void flush_channel(struct device *dev, int ch, int error, int reset_ch)
+void talitos_flush_channel(struct device *dev, int ch, int error, int reset_ch)
 {
struct talitos_private *priv = dev_get_drvdata(dev);
struct talitos_request *request, saved_req;
@@ -289,15 +289,15 @@ static void talitos_done_##name(unsigned long data)   
\
unsigned long flags;\
\
if (ch_done_mask  1)   \
-   flush_channel(dev, 0, 0, 0);\
+   talitos_flush_channel(dev, 0, 0, 0);\
if (priv-num_channels == 1)\
goto out;   \
if (ch_done_mask  (1  2))\
-   flush_channel(dev, 1, 0, 0);\
+   talitos_flush_channel(dev, 1, 0, 0);\
if (ch_done_mask  (1  4))\
-   flush_channel(dev, 2, 0, 0);\
+   talitos_flush_channel(dev, 2, 0, 0);\
if (ch_done_mask  (1  6))\
-   flush_channel(dev, 3, 0, 0);\
+   talitos_flush_channel(dev, 3, 0, 0);\
\
 out:   \
/* At this point, all completed channels have been processed */ \
@@ -345,10 +345,11 @@ static u32 current_desc_hdr(struct device *dev, int ch)
 /*
  * user diagnostics; report root cause of error based on execution unit status
  */
-static void report_eu_error(struct device *dev, int ch, u32 desc_hdr)
+void talitos_report_eu_error(struct device *dev, int ch)
 {
struct talitos_private *priv = dev_get_drvdata(dev);
int i;
+   u32 desc_hdr = current_desc_hdr(dev, ch);
 
if (!desc_hdr)
desc_hdr = in_be32(priv-chan[ch].reg + TALITOS_DESCBUF);
@@ -417,88 +418,6 @@ static void report_eu_error(struct device *dev, int ch, 
u32 desc_hdr)
in_be32(priv-chan[ch].reg + TALITOS_DESCBUF_LO + 8*i));
 }
 
-/*
- * recover from error interrupts
- */
-static void talitos_error(struct device *dev, u32 isr, u32 isr_lo)
-{
-   struct talitos_private *priv = dev_get_drvdata(dev);
-   unsigned int timeout = TALITOS_TIMEOUT;
-   int ch, error, reset_dev = 0, reset_ch = 0;
-   u32 v, v_lo;
-
-   for (ch = 0; ch  priv-num_channels; ch++) {
-   /* skip channels without errors */
-   if (!(isr  (1  (ch * 2 + 1
-   continue;
-
-   error = -EINVAL;
-
-   v = in_be32(priv-chan[ch].reg + TALITOS_CCPSR);
-   v_lo = in_be32(priv-chan[ch].reg + TALITOS_CCPSR_LO);
-
-   if (v_lo  TALITOS_CCPSR_LO_DOF) {
-   dev_err(dev, double fetch fifo overflow error\n);
-   error = -EAGAIN;
-   

[PATCH v2 07/17] crypto: talitos - Split talitos.h into 2 parts

2015-03-06 Thread Christophe Leroy
In order to be able to manage differences between SEC1 and SEC2, we split
talitos.h into two parts.
talitos2.h will contain all parts that are specific to SEC2 and different on 
SEC1

Signed-off-by: Christophe Leroy christophe.le...@c-s.fr

---
 drivers/crypto/talitos.h  | 163 +---
 drivers/crypto/talitos2.h | 204 ++
 2 files changed, 205 insertions(+), 162 deletions(-)
 create mode 100644 drivers/crypto/talitos2.h

diff --git a/drivers/crypto/talitos.h b/drivers/crypto/talitos.h
index 566dc92..09c97ad 100644
--- a/drivers/crypto/talitos.h
+++ b/drivers/crypto/talitos.h
@@ -29,34 +29,11 @@
  */
 
 #define TALITOS_TIMEOUT 10
-#define TALITOS_MAX_DATA_LEN 65535
 
 #define DESC_TYPE(desc_hdr) ((be32_to_cpu(desc_hdr)  3)  0x1f)
 #define PRIMARY_EU(desc_hdr) ((be32_to_cpu(desc_hdr)  28)  0xf)
 #define SECONDARY_EU(desc_hdr) ((be32_to_cpu(desc_hdr)  16)  0xf)
 
-/* descriptor pointer entry */
-struct talitos_ptr {
-   __be16 len; /* length */
-   u8 j_extent;/* jump to sg link table and/or extent */
-   u8 eptr;/* extended address */
-   __be32 ptr; /* address */
-};
-
-static const struct talitos_ptr zero_entry = {
-   .len = 0,
-   .j_extent = 0,
-   .eptr = 0,
-   .ptr = 0
-};
-
-/* descriptor */
-struct talitos_desc {
-   __be32 hdr; /* header high bits */
-   __be32 hdr_lo;  /* header low bits */
-   struct talitos_ptr ptr[7];  /* ptr/len pair array */
-};
-
 /**
  * talitos_request - descriptor submission request
  * @desc: descriptor pointer (kernel virtual)
@@ -133,38 +110,6 @@ struct talitos_private {
struct hwrng rng;
 };
 
-/*
- * talitos_edesc - s/w-extended descriptor
- * @assoc_nents: number of segments in associated data scatterlist
- * @src_nents: number of segments in input scatterlist
- * @dst_nents: number of segments in output scatterlist
- * @assoc_chained: whether assoc is chained or not
- * @src_chained: whether src is chained or not
- * @dst_chained: whether dst is chained or not
- * @iv_dma: dma address of iv for checking continuity and link table
- * @dma_len: length of dma mapped link_tbl space
- * @dma_link_tbl: bus physical address of link_tbl
- * @desc: h/w descriptor
- * @link_tbl: input and output h/w link tables (if {src,dst}_nents  1)
- *
- * if decrypting (with authcheck), or either one of src_nents or dst_nents
- * is greater than 1, an integrity check value is concatenated to the end
- * of link_tbl data
- */
-struct talitos_edesc {
-   int assoc_nents;
-   int src_nents;
-   int dst_nents;
-   bool assoc_chained;
-   bool src_chained;
-   bool dst_chained;
-   dma_addr_t iv_dma;
-   int dma_len;
-   dma_addr_t dma_link_tbl;
-   struct talitos_desc desc;
-   struct talitos_ptr link_tbl[0];
-};
-
 #define TALITOS_MAX_KEY_SIZE   96
 /* max of AES_BLOCK_SIZE, DES3_EDE_BLOCK_SIZE */
 #define TALITOS_MAX_IV_LENGTH  16
@@ -181,77 +126,6 @@ struct talitos_ctx {
unsigned int authsize;
 };
 
-static inline void to_talitos_ptr(struct talitos_ptr *ptr, dma_addr_t dma_addr)
-{
-   ptr-ptr = cpu_to_be32(lower_32_bits(dma_addr));
-   ptr-eptr = upper_32_bits(dma_addr);
-}
-
-/*
- * map virtual single (contiguous) pointer to h/w descriptor pointer
- */
-static inline void map_single_talitos_ptr(struct device *dev,
-  struct talitos_ptr *talitos_ptr,
-  unsigned short len, void *data,
-  unsigned char extent,
-  enum dma_data_direction dir)
-{
-   dma_addr_t dma_addr = dma_map_single(dev, data, len, dir);
-
-   talitos_ptr-len = cpu_to_be16(len);
-   to_talitos_ptr(talitos_ptr, dma_addr);
-   talitos_ptr-j_extent = extent;
-}
-
-/*
- * unmap bus single (contiguous) h/w descriptor pointer
- */
-static inline void unmap_single_talitos_ptr(struct device *dev,
-struct talitos_ptr *talitos_ptr,
-enum dma_data_direction dir)
-{
-   dma_unmap_single(dev, be32_to_cpu(talitos_ptr-ptr),
-be16_to_cpu(talitos_ptr-len), dir);
-}
-
-static inline int talitos_map_sg(struct device *dev, struct scatterlist *sg,
- unsigned int nents, enum dma_data_direction dir,
- bool chained)
-{
-   if (unlikely(chained))
-   while (sg) {
-   dma_map_sg(dev, sg, 1, dir);
-   sg = sg_next(sg);
-   }
-   else
-   dma_map_sg(dev, sg, nents, dir);
-   return nents;
-}
-
-static inline void talitos_unmap_sg_chain(struct device *dev,
- struct scatterlist *sg,
- enum dma_data_direction dir)
-{
-   while (sg) {
- 

[PATCH v2 11/17] crypto: talitos - Move hash chain handling into talitos2.h

2015-03-06 Thread Christophe Leroy
Move hash chain handling into talitos2.h as only SEC2 has sg chaining 
capatibility

Signed-off-by: Christophe Leroy christophe.le...@c-s.fr

---
 drivers/crypto/talitos.c  | 34 --
 drivers/crypto/talitos2.h | 34 ++
 2 files changed, 34 insertions(+), 34 deletions(-)

diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index b1ba98b..8b627d0 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -456,23 +456,6 @@ static void talitos_unregister_rng(struct device *dev)
  */
 #define TALITOS_CRA_PRIORITY   3000
 
-#define HASH_MAX_BLOCK_SIZESHA512_BLOCK_SIZE
-#define TALITOS_MDEU_MAX_CONTEXT_SIZE  TALITOS_MDEU_CONTEXT_SIZE_SHA384_SHA512
-
-struct talitos_ahash_req_ctx {
-   u32 hw_context[TALITOS_MDEU_MAX_CONTEXT_SIZE / sizeof(u32)];
-   unsigned int hw_context_size;
-   u8 buf[HASH_MAX_BLOCK_SIZE];
-   u8 bufnext[HASH_MAX_BLOCK_SIZE];
-   unsigned int swinit;
-   unsigned int first;
-   unsigned int last;
-   unsigned int to_hash_later;
-   u64 nbuf;
-   struct scatterlist bufsl[2];
-   struct scatterlist *psrc;
-};
-
 /*
  * derive number of elements in scatterlist
  */
@@ -911,23 +894,6 @@ static int ahash_init_sha224_swinit(struct ahash_request 
*areq)
return 0;
 }
 
-static void ahash_process_chain(struct scatterlist *src, int nbytes,
-   bool *chained,
-   struct talitos_ahash_req_ctx *req_ctx,
-   int nbytes_to_hash)
-{
-   if (req_ctx-nbuf) {
-   unsigned int nsg = (req_ctx-nbuf  nbytes_to_hash) ? 2 : 1;
-
-   sg_init_table(req_ctx-bufsl, nsg);
-   sg_set_buf(req_ctx-bufsl, req_ctx-buf, req_ctx-nbuf);
-   if (nsg  1)
-   scatterwalk_sg_chain(req_ctx-bufsl, 2, src);
-   req_ctx-psrc = req_ctx-bufsl;
-   } else
-   req_ctx-psrc = src;
-}
-
 static int ahash_process_req(struct ahash_request *areq, unsigned int nbytes)
 {
struct crypto_ahash *tfm = crypto_ahash_reqtfm(areq);
diff --git a/drivers/crypto/talitos2.h b/drivers/crypto/talitos2.h
index 10c7313..7edc563 100644
--- a/drivers/crypto/talitos2.h
+++ b/drivers/crypto/talitos2.h
@@ -223,6 +223,40 @@ static inline void do_init_device(struct talitos_private 
*priv)
setbits32(priv-reg + TALITOS_IMR_LO, TALITOS_IMR_LO_INIT);
 }
 
+#define HASH_MAX_BLOCK_SIZESHA512_BLOCK_SIZE
+#define TALITOS_MDEU_MAX_CONTEXT_SIZE  TALITOS_MDEU_CONTEXT_SIZE_SHA384_SHA512
+
+struct talitos_ahash_req_ctx {
+   u32 hw_context[TALITOS_MDEU_MAX_CONTEXT_SIZE / sizeof(u32)];
+   unsigned int hw_context_size;
+   u8 buf[HASH_MAX_BLOCK_SIZE];
+   u8 bufnext[HASH_MAX_BLOCK_SIZE];
+   unsigned int swinit;
+   unsigned int first;
+   unsigned int last;
+   unsigned int to_hash_later;
+   u64 nbuf;
+   struct scatterlist bufsl[2];
+   struct scatterlist *psrc;
+};
+
+static inline void ahash_process_chain(struct scatterlist *src, int nbytes,
+   bool *chained,
+   struct talitos_ahash_req_ctx *req_ctx,
+   int nbytes_to_hash)
+{
+   if (req_ctx-nbuf) {
+   unsigned int nsg = (req_ctx-nbuf  nbytes_to_hash) ? 2 : 1;
+
+   sg_init_table(req_ctx-bufsl, nsg);
+   sg_set_buf(req_ctx-bufsl, req_ctx-buf, req_ctx-nbuf);
+   if (nsg  1)
+   scatterwalk_sg_chain(req_ctx-bufsl, 2, src);
+   req_ctx-psrc = req_ctx-bufsl;
+   } else
+   req_ctx-psrc = src;
+}
+
 #define DEF_TALITOS_DONE(name, ch_done_mask)   \
 static void talitos_done_##name(unsigned long data)\
 {  \
-- 
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 v2 01/17] crypto: talitos - base address for Execution Units and macro for ISR masks

2015-03-06 Thread Christophe Leroy
SEC1 and SEC2 have different EU base addresses, so define base addresses
as #define
SEC1 and SEC2 have different bit masks for ISR registers, so create a
macro to define them

Signed-off-by: Christophe Leroy christophe.le...@c-s.fr

---
 drivers/crypto/talitos.h | 85 ++--
 1 file changed, 53 insertions(+), 32 deletions(-)

diff --git a/drivers/crypto/talitos.h b/drivers/crypto/talitos.h
index 61a1405..102dc99 100644
--- a/drivers/crypto/talitos.h
+++ b/drivers/crypto/talitos.h
@@ -149,6 +149,8 @@ extern int talitos_submit(struct device *dev, int ch, 
struct talitos_desc *desc,
  * TALITOS_xxx_LO addresses point to the low data bits (32-63) of the register
  */
 
+#define ISR_FORMAT(x)  (((x)  4) | (x))
+
 /* global register offset addresses */
 #define TALITOS_MCR0x1030  /* master control register */
 #define   TALITOS_MCR_RCA0 (1  15) /* remap channel 0 */
@@ -163,12 +165,12 @@ extern int talitos_submit(struct device *dev, int ch, 
struct talitos_desc *desc,
 #define TALITOS_IMR_LO 0x100C
 #define   TALITOS_IMR_LO_INIT  0x2 /* allow RNGU error IRQs */
 #define TALITOS_ISR0x1010  /* interrupt status register */
-#define   TALITOS_ISR_4CHERR   0xaa/* 4 channel errors mask */
-#define   TALITOS_ISR_4CHDONE  0x55/* 4 channel done mask */
-#define   TALITOS_ISR_CH_0_2_ERR   0x22/* channels 0, 2 errors mask */
-#define   TALITOS_ISR_CH_0_2_DONE  0x11/* channels 0, 2 done mask */
-#define   TALITOS_ISR_CH_1_3_ERR   0x88/* channels 1, 3 errors mask */
-#define   TALITOS_ISR_CH_1_3_DONE  0x44/* channels 1, 3 done mask */
+#define   TALITOS_ISR_4CHERR   ISR_FORMAT(0xa) /* 4 ch errors mask */
+#define   TALITOS_ISR_4CHDONE  ISR_FORMAT(0x5) /* 4 ch done mask */
+#define   TALITOS_ISR_CH_0_2_ERR   ISR_FORMAT(0x2) /* ch 0, 2 err mask */
+#define   TALITOS_ISR_CH_0_2_DONE  ISR_FORMAT(0x1) /* ch 0, 2 done mask */
+#define   TALITOS_ISR_CH_1_3_ERR   ISR_FORMAT(0x8) /* ch 1, 3 err mask */
+#define   TALITOS_ISR_CH_1_3_DONE  ISR_FORMAT(0x4) /* ch 1, 3 done mask */
 #define TALITOS_ISR_LO 0x1014
 #define TALITOS_ICR0x1018  /* interrupt clear register */
 #define TALITOS_ICR_LO 0x101C
@@ -224,37 +226,56 @@ extern int talitos_submit(struct device *dev, int ch, 
struct talitos_desc *desc,
 #define TALITOS_SCATTER0xe0
 #define TALITOS_SCATTER_LO 0xe4
 
+/* execution unit registers base */
+#define TALITOS_DEU0x2000
+#define TALITOS_AESU   0x4000
+#define TALITOS_MDEU   0x6000
+#define TALITOS_AFEU   0x8000
+#define TALITOS_RNGU   0xa000
+#define TALITOS_PKEU   0xc000
+#define TALITOS_KEU0xe000
+#define TALITOS_CRCU   0xf000
+
 /* execution unit interrupt status registers */
-#define TALITOS_DEUISR 0x2030 /* DES unit */
-#define TALITOS_DEUISR_LO  0x2034
-#define TALITOS_AESUISR0x4030 /* AES unit */
-#define TALITOS_AESUISR_LO 0x4034
-#define TALITOS_MDEUISR0x6030 /* message digest unit */
-#define TALITOS_MDEUISR_LO 0x6034
-#define TALITOS_MDEUICR0x6038 /* interrupt control */
-#define TALITOS_MDEUICR_LO 0x603c
+/* DES unit */
+#define TALITOS_DEUISR (TALITOS_DEU + 0x30)
+#define TALITOS_DEUISR_LO  (TALITOS_DEU + 0x34)
+#define TALITOS_DEUICR (TALITOS_DEU + 0x38) /* int. control */
+/* AES unit */
+#define TALITOS_AESUISR(TALITOS_AESU + 0x30)
+#define TALITOS_AESUISR_LO (TALITOS_AESU + 0x34)
+/* message digest unit */
+#define TALITOS_MDEUISR(TALITOS_MDEU + 0x30)
+#define TALITOS_MDEUISR_LO (TALITOS_MDEU + 0x34)
+#define TALITOS_MDEUICR(TALITOS_MDEU + 0x38) /* int. 
control */
+#define TALITOS_MDEUICR_LO (TALITOS_MDEU + 0x3c)
 #define   TALITOS_MDEUICR_LO_ICE   0x4000 /* integrity check IRQ enable */
-#define TALITOS_AFEUISR0x8030 /* arc4 unit */
-#define TALITOS_AFEUISR_LO 0x8034
-#define TALITOS_RNGUISR0xa030 /* random number unit */
-#define TALITOS_RNGUISR_LO 0xa034
-#define TALITOS_RNGUSR 0xa028 /* rng status */
-#define TALITOS_RNGUSR_LO  0xa02c
+/* arc4 unit */
+#define TALITOS_AFEUISR(TALITOS_AFEU + 0x30)
+#define TALITOS_AFEUISR_LO (TALITOS_AFEU + 0x34)
+/* random number unit */
+#define TALITOS_RNGUISR(TALITOS_RNGU + 0x30)
+#define TALITOS_RNGUISR_LO (TALITOS_RNGU + 0x34)
+#define TALITOS_RNGUSR 

[PATCH v2 04/17] crypto: talitos - Refactor the sg in/out chain allocation

2015-03-06 Thread Christophe Leroy
This patch refactors the handling of the input and output data that is quite
similar in several functions

Signed-off-by: Christophe Leroy christophe.le...@c-s.fr

---
 drivers/crypto/talitos.c | 163 ---
 1 file changed, 85 insertions(+), 78 deletions(-)

diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index de4d93b..3165364 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -1339,16 +1339,26 @@ static int ablkcipher_setkey(struct crypto_ablkcipher 
*cipher,
return 0;
 }
 
+static void unmap_sg_talitos_ptr(struct device *dev, struct scatterlist *src,
+struct scatterlist *dst, unsigned int len,
+struct talitos_edesc *edesc,
+struct talitos_ptr *ptr_in,
+struct talitos_ptr *ptr_out)
+{
+   talitos_sg_unmap(dev, edesc, src, dst);
+}
+
 static void common_nonsnoop_unmap(struct device *dev,
  struct talitos_edesc *edesc,
  struct ablkcipher_request *areq)
 {
unmap_single_talitos_ptr(dev, edesc-desc.ptr[5], DMA_FROM_DEVICE);
+
+   unmap_sg_talitos_ptr(dev, areq-src, areq-dst, areq-nbytes, edesc,
+edesc-desc.ptr[3], edesc-desc.ptr[4]);
unmap_single_talitos_ptr(dev, edesc-desc.ptr[2], DMA_TO_DEVICE);
unmap_single_talitos_ptr(dev, edesc-desc.ptr[1], DMA_TO_DEVICE);
 
-   talitos_sg_unmap(dev, edesc, areq-src, areq-dst);
-
if (edesc-dma_len)
dma_unmap_single(dev, edesc-dma_link_tbl, edesc-dma_len,
 DMA_BIDIRECTIONAL);
@@ -1370,6 +1380,65 @@ static void ablkcipher_done(struct device *dev,
areq-base.complete(areq-base, err);
 }
 
+int map_sg_in_talitos_ptr(struct device *dev, struct scatterlist *src,
+ unsigned int len, struct talitos_edesc *edesc,
+ enum dma_data_direction dir, struct talitos_ptr *ptr)
+{
+   int sg_count;
+
+   ptr-len = cpu_to_be16(len);
+   ptr-j_extent = 0;
+
+   sg_count = talitos_map_sg(dev, src, edesc-src_nents ? : 1, dir,
+ edesc-src_chained);
+
+   if (sg_count == 1) {
+   to_talitos_ptr(ptr, sg_dma_address(src));
+   } else {
+   sg_count = sg_to_link_tbl(src, sg_count, len,
+ edesc-link_tbl[0]);
+   if (sg_count  1) {
+   to_talitos_ptr(ptr, edesc-dma_link_tbl);
+   ptr-j_extent |= DESC_PTR_LNKTBL_JUMP;
+   dma_sync_single_for_device(dev, edesc-dma_link_tbl,
+  edesc-dma_len,
+  DMA_BIDIRECTIONAL);
+   } else {
+   /* Only one segment now, so no link tbl needed */
+   to_talitos_ptr(ptr, sg_dma_address(src));
+   }
+   }
+   return sg_count;
+}
+
+void map_sg_out_talitos_ptr(struct device *dev, struct scatterlist *dst,
+   unsigned int len, struct talitos_edesc *edesc,
+   enum dma_data_direction dir,
+   struct talitos_ptr *ptr, int sg_count)
+{
+   ptr-len = cpu_to_be16(len);
+   ptr-j_extent = 0;
+
+   if (dir != DMA_NONE)
+   sg_count = talitos_map_sg(dev, dst, edesc-dst_nents ? : 1,
+ dir, edesc-dst_chained);
+
+   if (sg_count == 1) {
+   to_talitos_ptr(ptr, sg_dma_address(dst));
+   } else {
+   struct talitos_ptr *link_tbl_ptr =
+   edesc-link_tbl[edesc-src_nents + 1];
+
+   to_talitos_ptr(ptr, edesc-dma_link_tbl +
+ (edesc-src_nents + 1) *
+ sizeof(struct talitos_ptr));
+   ptr-j_extent |= DESC_PTR_LNKTBL_JUMP;
+   sg_count = sg_to_link_tbl(dst, sg_count, len, link_tbl_ptr);
+   dma_sync_single_for_device(dev, edesc-dma_link_tbl,
+  edesc-dma_len, DMA_BIDIRECTIONAL);
+   }
+}
+
 static int common_nonsnoop(struct talitos_edesc *edesc,
   struct ablkcipher_request *areq,
   void (*callback) (struct device *dev,
@@ -1399,56 +1468,16 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
/*
 * cipher in
 */
-   desc-ptr[3].len = cpu_to_be16(cryptlen);
-   desc-ptr[3].j_extent = 0;
-
-   sg_count = talitos_map_sg(dev, areq-src, edesc-src_nents ? : 1,
- (areq-src == areq-dst) ? DMA_BIDIRECTIONAL
-  : DMA_TO_DEVICE,
- 

[PATCH v2 14/17] crypto: talitos - Add a helper function to clear j_extent field

2015-03-06 Thread Christophe Leroy
j_extent field is specific to SEC2 so we add a helper function to clear it
so that SEC1 can redefine that function as nop

Signed-off-by: Christophe Leroy christophe.le...@c-s.fr

---
 drivers/crypto/talitos.c  | 2 +-
 drivers/crypto/talitos2.h | 5 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 76209e8..c27051c 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -626,7 +626,7 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
/* cipher iv */
to_talitos_ptr(desc-ptr[1], edesc-iv_dma);
desc-ptr[1].len = cpu_to_be16(ivsize);
-   desc-ptr[1].j_extent = 0;
+   to_talitos_ptr_extent_clear(desc-ptr[1]);
 
/* cipher key */
map_single_talitos_ptr(dev, desc-ptr[2], ctx-keylen,
diff --git a/drivers/crypto/talitos2.h b/drivers/crypto/talitos2.h
index 7177088..6f98b12 100644
--- a/drivers/crypto/talitos2.h
+++ b/drivers/crypto/talitos2.h
@@ -90,6 +90,11 @@ static inline void to_talitos_ptr(struct talitos_ptr *ptr, 
dma_addr_t dma_addr)
ptr-eptr = upper_32_bits(dma_addr);
 }
 
+static inline void to_talitos_ptr_extent_clear(struct talitos_ptr *ptr)
+{
+   ptr-j_extent = 0;
+}
+
 /*
  * map virtual single (contiguous) pointer to h/w descriptor pointer
  */
-- 
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 v2 15/17] crypto: talitos - Implementation of SEC1

2015-03-06 Thread Christophe Leroy
This patch adds talitos1.c and talitos1.h with all specificities needed
to handle the SEC1 security engine found in MPC885 and MPC8272.

The SEC1 has several differences with its younger brother SEC2:
* Several bits in registers have different locations
* Many bits are missing
* Some bits are in addition
* SEC1 doesn't support scatter/gather
* SEC1 has a different descriptor structure

We add a helper function for clearing the desc field in the descriptor as that 
field needs to be cleared on SEC1 and doesn't exist on SEC2.

Signed-off-by: Christophe Leroy christophe.le...@c-s.fr

---
 drivers/crypto/Kconfig|   6 +-
 drivers/crypto/Makefile   |   1 +
 drivers/crypto/talitos.c  |   4 +
 drivers/crypto/talitos.h  |   5 +
 drivers/crypto/talitos1.c | 176 
 drivers/crypto/talitos1.h | 339 ++
 drivers/crypto/talitos2.h |   4 +
 7 files changed, 534 insertions(+), 1 deletion(-)
 create mode 100644 drivers/crypto/talitos1.c
 create mode 100644 drivers/crypto/talitos1.h

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 4fd6d7e..f863cac 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -211,7 +211,8 @@ config CRYPTO_DEV_TALITOS
select CRYPTO_ALGAPI
select CRYPTO_AUTHENC
select HW_RANDOM
-   select CRYPTO_DEV_TALITOS2
+   select CRYPTO_DEV_TALITOS1 if PPC_8xx || PPC_82xx
+   select CRYPTO_DEV_TALITOS2 if !CRYPTO_DEV_TALITOS1
depends on FSL_SOC
help
  Say 'Y' here to use the Freescale Security Engine (SEC)
@@ -223,6 +224,9 @@ config CRYPTO_DEV_TALITOS
  To compile this driver as a module, choose M here: the module
  will be called talitos.
 
+config CRYPTO_DEV_TALITOS1
+   bool
+
 config CRYPTO_DEV_TALITOS2
bool
 
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index f26159f..ef16f7b 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_CRYPTO_DEV_PPC4XX) += amcc/
 obj-$(CONFIG_CRYPTO_DEV_S5P) += s5p-sss.o
 obj-$(CONFIG_CRYPTO_DEV_SAHARA) += sahara.o
 obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o
+obj-$(CONFIG_CRYPTO_DEV_TALITOS1) += talitos1.o
 obj-$(CONFIG_CRYPTO_DEV_TALITOS2) += talitos2.o
 obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/
 obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index c27051c..82a5181 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -653,6 +653,8 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
/* last DWORD empty */
desc-ptr[6] = zero_entry;
 
+   to_talitos_next_desc_clear(desc);
+
ret = talitos_submit(dev, ctx-ch, desc, callback, areq);
if (ret != -EINPROGRESS) {
common_nonsnoop_unmap(dev, edesc, areq);
@@ -811,6 +813,8 @@ static int common_nonsnoop_hash(struct talitos_edesc *edesc,
/* last DWORD empty */
desc-ptr[6] = zero_entry;
 
+   to_talitos_next_desc_clear(desc);
+
ret = talitos_submit(dev, ctx-ch, desc, callback, areq);
if (ret != -EINPROGRESS) {
common_nonsnoop_hash_unmap(dev, edesc, areq);
diff --git a/drivers/crypto/talitos.h b/drivers/crypto/talitos.h
index f0ffbb0..e937c05 100644
--- a/drivers/crypto/talitos.h
+++ b/drivers/crypto/talitos.h
@@ -370,4 +370,9 @@ static inline int sg_count(struct scatterlist *sg_list, int 
nbytes,
 #define DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU  cpu_to_be32(2  3)
 #define DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU   cpu_to_be32(4  3)
 
+#ifdef CONFIG_CRYPTO_DEV_TALITOS1
+#include talitos1.h
+#endif
+#ifdef CONFIG_CRYPTO_DEV_TALITOS2
 #include talitos2.h
+#endif
diff --git a/drivers/crypto/talitos1.c b/drivers/crypto/talitos1.c
new file mode 100644
index 000..c1a8e9e
--- /dev/null
+++ b/drivers/crypto/talitos1.c
@@ -0,0 +1,176 @@
+/*
+ * talitos1 - Freescale Integrated Security Engine (SEC1) device driver
+ *
+ * Copyright (c) 2008-2011 Freescale Semiconductor, Inc.
+ *
+ * Copyright (c) 2014-2015 CS Systemes d'Information.
+ *
+ * Scatterlist Crypto API glue code copied from files with the following:
+ * Copyright (c) 2006-2007 Herbert Xu herb...@gondor.apana.org.au
+ *
+ * Crypto algorithm registration code copied from hifn driver:
+ * 2007+ Copyright (c) Evgeniy Polyakov john...@2ka.mipt.ru
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/mod_devicetable.h

[PATCH v2 12/17] crypto: talitos - Define compatible in talitos2.h instead of talitos.c

2015-03-06 Thread Christophe Leroy
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr

---
 drivers/crypto/talitos.c  | 4 +---
 drivers/crypto/talitos2.h | 2 ++
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 8b627d0..0262e75 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -1972,9 +1972,7 @@ err_out:
 }
 
 static const struct of_device_id talitos_match[] = {
-   {
-   .compatible = fsl,sec2.0,
-   },
+   TALITOS_OF_COMPATIBLE,
{},
 };
 MODULE_DEVICE_TABLE(of, talitos_match);
diff --git a/drivers/crypto/talitos2.h b/drivers/crypto/talitos2.h
index 7edc563..7177088 100644
--- a/drivers/crypto/talitos2.h
+++ b/drivers/crypto/talitos2.h
@@ -316,3 +316,5 @@ static irqreturn_t talitos_interrupt_##name(int irq, void 
*data)   \
return (isr  (ch_done_mask | ch_err_mask) || isr_lo) ? IRQ_HANDLED :  \
IRQ_NONE;  \
 }
+
+#define TALITOS_OF_COMPATIBLE  {.compatible = fsl,sec2.0,}
-- 
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 v2 0/17] crypto: talitos - Add support for SEC1

2015-03-06 Thread Christophe Leroy
The purpose of this set of patchs is to add to talitos crypto driver the
support for the SEC1 version of the security engine, which is found in
mpc885 and mpc8272 processors.

The approach has been to split the driver in two main parts:
* talitos.c and talitos.h contains parts that are common
* talitos2.c and talitos2.h contains specificities of SEC2

Then
* talitos1.c and talitos1.h has been created with SEC1 specificities

v2 applies cleanly on this afternoon's (06 March 2015) cryptodev-2.6 tree 
(commit c83d45d5)

Patchset:
[01/17] crypto: talitos - base address for Execution Units and macro for ISR 
masks
[02/17] crypto: talitos - Externalise specific SEC2 reset actions
[03/17] crypto: talitos - Use zero entry to init descriptors ptrs to zero
[04/17] crypto: talitos - Refactor the sg in/out chain allocation
[05/17] crypto: talitos - isolate scatter/gather handling for ahash
[06/17] crypto: talitos - Add talitos2.c to isolate SEC2 specific functions
[07/17] crypto: talitos - Split talitos.h into 2 parts
[08/17] crypto: talitos - Deport SEC2 error handling
[09/17] crypto: talitos - Move reset/init helpers into talitos2.h
[10/17] crypto: talitos - Move interrupt related macros in talitos2.h
[11/17] crypto: talitos - Move hash chain handling into talitos2.h
[12/17] crypto: talitos - Define compatible in talitos2.h instead of talitos.c
[13/17] crypto: talitos - move sg_count() helper into talitos.h
[14/17] crypto: talitos - Add a helper function to clear j_extent field
[15/17] crypto: talitos - Implementation of SEC1
[16/17] crypto: talitos - SEC1 bugs on 0 data hash
[17/17] crypto: talitos - Update DT bindings with SEC1

Signed-off-by: Christophe Leroy christophe.le...@c-s.fr

 .../devicetree/bindings/crypto/fsl-sec2.txt|   5 +-
 drivers/crypto/Kconfig |   8 +
 drivers/crypto/Makefile|   2 +
 drivers/crypto/talitos.c   | 927 +
 drivers/crypto/talitos.h   | 183 ++--
 drivers/crypto/talitos1.c  | 197 +
 drivers/crypto/talitos1.h  | 343 
 drivers/crypto/talitos2.c  | 696 
 drivers/crypto/talitos2.h  | 335 
 9 files changed, 1734 insertions(+), 962 deletions(-)
--
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 v2 09/17] crypto: talitos - Move reset/init helpers into talitos2.h

2015-03-06 Thread Christophe Leroy
Move reset/init helpers init talitos2.h as they are specific to SEC2

Signed-off-by: Christophe Leroy christophe.le...@c-s.fr

---
 drivers/crypto/talitos.c  | 19 ---
 drivers/crypto/talitos2.h | 20 
 2 files changed, 20 insertions(+), 19 deletions(-)

diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 81a6e47..ffa103b 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -55,19 +55,6 @@
 
 #include talitos.h
 
-static unsigned int do_reset_channel(struct talitos_private *priv, int ch)
-{
-   unsigned int timeout = TALITOS_TIMEOUT;
-
-   setbits32(priv-chan[ch].reg + TALITOS_CCCR, TALITOS_CCCR_RESET);
-
-   while ((in_be32(priv-chan[ch].reg + TALITOS_CCCR)  TALITOS_CCCR_RESET)
-   --timeout)
-   cpu_relax();
-
-   return timeout;
-}
-
 int talitos_reset_channel(struct device *dev, int ch)
 {
struct talitos_private *priv = dev_get_drvdata(dev);
@@ -118,12 +105,6 @@ static int reset_device(struct device *dev)
 /*
  * Reset and initialize the device
  */
-static void do_init_device(struct talitos_private *priv)
-{
-   setbits32(priv-reg + TALITOS_IMR, TALITOS_IMR_INIT);
-   setbits32(priv-reg + TALITOS_IMR_LO, TALITOS_IMR_LO_INIT);
-}
-
 int talitos_init_device(struct device *dev)
 {
struct talitos_private *priv = dev_get_drvdata(dev);
diff --git a/drivers/crypto/talitos2.h b/drivers/crypto/talitos2.h
index e7a91cf..f9da9f2 100644
--- a/drivers/crypto/talitos2.h
+++ b/drivers/crypto/talitos2.h
@@ -202,3 +202,23 @@ extern int talitos_alg_alloc_aead(struct crypto_alg *alg);
 #define DESC_PTR_LNKTBL_JUMP   0x80
 #define DESC_PTR_LNKTBL_RETURN 0x02
 #define DESC_PTR_LNKTBL_NEXT   0x01
+
+static inline unsigned int do_reset_channel(struct talitos_private *priv,
+   int ch)
+{
+   unsigned int timeout = TALITOS_TIMEOUT;
+
+   setbits32(priv-chan[ch].reg + TALITOS_CCCR, TALITOS_CCCR_RESET);
+
+   while ((in_be32(priv-chan[ch].reg + TALITOS_CCCR)  TALITOS_CCCR_RESET)
+   --timeout)
+   cpu_relax();
+
+   return timeout;
+}
+
+static inline void do_init_device(struct talitos_private *priv)
+{
+   setbits32(priv-reg + TALITOS_IMR, TALITOS_IMR_INIT);
+   setbits32(priv-reg + TALITOS_IMR_LO, TALITOS_IMR_LO_INIT);
+}
-- 
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 v2 03/17] crypto: talitos - Use zero entry to init descriptors ptrs to zero

2015-03-06 Thread Christophe Leroy
Do use zero_entry value to init the descriptors ptrs to zero instead of
writing 0 in each field

Signed-off-by: Christophe Leroy christophe.le...@c-s.fr

---
 drivers/crypto/talitos.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 103bfcf..de4d93b 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -1385,9 +1385,7 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
int sg_count, ret;
 
/* first DWORD empty */
-   desc-ptr[0].len = 0;
-   to_talitos_ptr(desc-ptr[0], 0);
-   desc-ptr[0].j_extent = 0;
+   desc-ptr[0] = zero_entry;
 
/* cipher iv */
to_talitos_ptr(desc-ptr[1], edesc-iv_dma);
@@ -1457,9 +1455,7 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
   DMA_FROM_DEVICE);
 
/* last DWORD empty */
-   desc-ptr[6].len = 0;
-   to_talitos_ptr(desc-ptr[6], 0);
-   desc-ptr[6].j_extent = 0;
+   desc-ptr[6] = zero_entry;
 
ret = talitos_submit(dev, ctx-ch, desc, callback, areq);
if (ret != -EINPROGRESS) {
-- 
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 v2 2/5] crypto: talitos: Remove MD5_BLOCK_SIZE

2015-03-06 Thread Herbert Xu
Kim Phillips kim.phill...@freescale.com wrote:
 On Tue,  3 Mar 2015 08:21:34 -0500
 Martin Hicks m...@bork.org wrote:
 
 This is properly defined in the md5 header file.
 
 Signed-off-by: Martin Hicks m...@bork.org
 ---
 
 Acked-by: Kim Phillips kim.phill...@freescale.com

Patches 1-2 applied.  Thanks.
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 00/10] omap3 crypto fixes

2015-03-06 Thread Tony Lindgren
* Pali Rohár pali.ro...@gmail.com [150306 11:16]:
 On Friday 06 March 2015 19:36:32 Tony Lindgren wrote:
  * Pali Rohár pali.ro...@gmail.com [150226 05:54]:
   This patch series fix crypto support for omap3 devices which
   use DT.
   
   It enables AES and SHAM on N9/N950 and SHAM on N900. AES is
   still disabled for N900.
   
   Pali Rohár (10):
 ARM: OMAP2+: Return correct error values from device and
 hwmod ARM: OMAP3: Fix crypto support for HS devices
 crypto: omap-sham: Add support for omap3 devices
 crypto: omap-sham: Check for return value from
 pm_runtime_get_sync ARM: dts: omap3 hs: Remove timer12
 ARM: dts: omap3: Add missing dmas for crypto
 ARM: dts: n9/n950: Enable omap crypto support
 ARM: dts: n900: Enable omap sham and include directly
 omap34xx.dtsi ARM: dts: omap3-tao3530: Include directly
 omap34xx.dtsi ARM: dts: Remove files omap34xx-hs.dtsi and
 omap36xx-hs.dtsi

arch/arm/boot/dts/omap3-n900.dts   |   16 +-
arch/arm/boot/dts/omap3-n950-n9.dtsi   |2 +-
arch/arm/boot/dts/omap3-tao3530.dtsi   |   11 +++-
arch/arm/boot/dts/omap3.dtsi   |4 ++
arch/arm/boot/dts/omap34xx-hs.dtsi |   16 --
arch/arm/boot/dts/omap36xx-hs.dtsi |   16 --
arch/arm/mach-omap2/omap_device.c  |   30
++- arch/arm/mach-omap2/omap_hwmod.c   |  
10 ++-- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   79
+++- drivers/crypto/omap-sham.c   
 |   13 - 10 files changed, 131
insertions(+), 66 deletions(-) delete mode 100644
arch/arm/boot/dts/omap34xx-hs.dtsi delete mode 100644
arch/arm/boot/dts/omap36xx-hs.dtsi
  
  Are there any fixes in this series that should go into
  v4.0-rc series, or can it all wait for v4.1?
  
  Regards,
  
  Tony
 
 I do not know which patches are you sending to 4.0-rc series, but 
 omap crypto is totally broken in linus tree for both GP  HS 
 omap3 devices when DT booting is used. This patch series fix that 
 problem.

OK so the whole series is needed then. It seems too intrusive for
the v4.0-rc series unless this fixes a regression with some earlier
commit.

Regards,

Tony
--
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] MAINTAINERS: add crypto-API.tmpl

2015-03-06 Thread Stephan Mueller
The file Documentation/DocBook/crypto-API.tmpl documents the kernel
crypto API and is maintained.

Signed-off-by: Stephan Mueller smuel...@chronox.de
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ddc5a8c..c10814e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2805,6 +2805,7 @@ L:linux-crypto@vger.kernel.org
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git
 S: Maintained
 F: Documentation/crypto/
+F: Documentation/DocBook/crypto-API.tmpl
 F: arch/*/crypto/
 F: crypto/
 F: drivers/crypto/
-- 
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 1/2] crypto: Documentation - AEAD / RNG AF_ALG interface

2015-03-06 Thread Stephan Mueller
The patch moves the information provided in
Documentation/crypto/crypto-API-userspace.txt into a separate chapter in
the kernel crypto API DocBook. Some corrections are applied (such as
removing a reference to Netlink when the AF_ALG socket is referred to).

In addition, the AEAD and RNG interface description is now added.

Also, a brief description of the zero-copy interface with an example
code snippet is provided.

Signed-off-by: Stephan Mueller smuel...@chronox.de
---
 Documentation/DocBook/crypto-API.tmpl | 596 ++
 Documentation/crypto/crypto-API-userspace.txt | 205 -
 2 files changed, 596 insertions(+), 205 deletions(-)
 delete mode 100644 Documentation/crypto/crypto-API-userspace.txt

diff --git a/Documentation/DocBook/crypto-API.tmpl 
b/Documentation/DocBook/crypto-API.tmpl
index 33f63cf..efc8d90 100644
--- a/Documentation/DocBook/crypto-API.tmpl
+++ b/Documentation/DocBook/crypto-API.tmpl
@@ -1072,6 +1072,602 @@ kernel crypto API|   Caller
/sect1
   /chapter
 
+  chapter id=UsertitleUser Space Interface/title
+   sect1titleIntroduction/title
+para
+ The concepts of the kernel crypto API visible to kernel space is fully
+ applicable to the user space interface as well. Therefore, the kernel
+ crypto API high level discussion for the in-kernel use cases applies
+ here as well.
+/para
+
+para
+ The major difference, however, is that user space can only act as a
+ consumer and never as a provider of a transformation or cipher algorithm.
+/para
+
+para
+ The following covers the user space interface exported by the kernel
+ crypto API. A working example of this description is libkcapi that
+ can be obtained from [1]. That library can be used by user space
+ applications that require cryptographic services from the kernel.
+/para
+
+para
+ Some details of the in-kernel kernel crypto API aspects do not
+ apply to user space, however. This includes the difference between
+ synchronous and asynchronous invocations. The user space API call
+ is fully synchronous.
+/para
+
+para
+ [1] http://www.chronox.de/libkcapi.html
+/para
+
+   /sect1
+
+   sect1titleUser Space API General Remarks/title
+para
+ The kernel crypto API is accessible from user space. Currently,
+ the following ciphers are accessible:
+/para
+
+itemizedlist
+ listitem
+  paraMessage digest including keyed message digest (HMAC, CMAC)/para
+ /listitem
+
+ listitem
+  paraSymmetric ciphers/para
+ /listitem
+
+ listitem
+  paraAEAD ciphers/para
+ /listitem
+
+ listitem
+  paraRandom Number Generators/para
+ /listitem
+/itemizedlist
+
+para
+ The interface is provided via socket type using the type AF_ALG.
+ In addition, the setsockopt option type is SOL_ALG. In case the
+ user space header files do not export these flags yet, use the
+ following macros:
+/para
+
+programlisting
+#ifndef AF_ALG
+#define AF_ALG 38
+#endif
+#ifndef SOL_ALG
+#define SOL_ALG 279
+#endif
+/programlisting
+
+para
+ A cipher is accessed with the same name as done for the in-kernel
+ API calls. This includes the generic vs. unique naming schema for
+ ciphers as well as the enforcement of priorities for generic names.
+/para
+
+para
+ To interact with the kernel crypto API, a socket must be
+ created by the user space application. User space invokes the cipher
+ operation with the send()/write() system call family. The result of the
+ cipher operation is obtained with the read()/recv() system call family.
+/para
+
+para
+ The following API calls assume that the socket descriptor
+ is already opened by the user space application and discusses only
+ the kernel crypto API specific invocations.
+/para
+
+para
+ To initialize the socket interface, the following sequence has to
+ be performed by the consumer:
+/para
+
+orderedlist
+ listitem
+  para
+   Create a socket of type AF_ALG with the struct sockaddr_alg
+   parameter specified below for the different cipher types.
+  /para
+ /listitem
+
+ listitem
+  para
+   Invoke bind with the socket descriptor
+  /para
+ /listitem
+
+ listitem
+  para
+   Invoke accept with the socket descriptor. The accept system call
+   returns a new file descriptor that is to be used to interact with
+   the particular cipher instance. When invoking send/write or recv/read
+   system calls to send data to the kernel or obtain data from the
+   kernel, the file descriptor returned by accept must be used.
+  /para
+ /listitem
+/orderedlist
+   /sect1
+
+   sect1titleIn-place Cipher operation/title
+para
+ Just like the in-kernel operation of the kernel crypto API, the user
+ space interface allows the cipher 

[PATCH 0/2] crypto: Documentation - add AF_ALG to DocBook

2015-03-06 Thread Stephan Mueller
Hi,

the AF_ALG interface description is added to the kernel crypto API
DocBook. It is extended by the newly added AEAD and RNG interfaces.

An example of the documentation can be viewed at [1].

[1] http://www.chronox.de/crypto-API/User.html

Stephan Mueller (2):
  crypto: Documentation - AEAD / RNG AF_ALG interface
  MAINTAINERS: add crypto-API.tmpl

 Documentation/DocBook/crypto-API.tmpl | 596 ++
 Documentation/crypto/crypto-API-userspace.txt | 205 -
 MAINTAINERS   |   1 +
 3 files changed, 597 insertions(+), 205 deletions(-)
 delete mode 100644 Documentation/crypto/crypto-API-userspace.txt

-- 
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 00/10] omap3 crypto fixes

2015-03-06 Thread Aaro Koskinen
Hi,

On Fri, Mar 06, 2015 at 10:36:32AM -0800, Tony Lindgren wrote:
 Are there any fixes in this series that should go into
 v4.0-rc series, or can it all wait for v4.1?

I think these all should wait for v4.1.

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


AW: [PATCH] crypto: powerpc - move files to fix build error

2015-03-06 Thread Markus Stockhausen
 Von: Kim Phillips [kim.phill...@freescale.com]
 Gesendet: Samstag, 7. März 2015 01:46
 An: Herbert Xu; Benjamin Herrenschmidt; Paul Mackerras; Michael Ellerman
 Cc: Markus Stockhausen; linux-crypto@vger.kernel.org; 
 linuxppc-...@lists.ozlabs.org; linux-ker...@vger.kernel.org
 Betreff: [PATCH] crypto: powerpc - move files to fix build error
 
 The current cryptodev-2.6 tree commits:
 
 d9850fc529ef (crypto: powerpc/sha1 - kernel config)
 50ba29aaa7b0 (crypto: powerpc/sha1 - glue)
 
 failed to properly place files under arch/powerpc/crypto, which
 leads to build errors:
 
 make[1]: *** No rule to make target 'arch/powerpc/crypto/sha1-spe-asm.o', 
 needed by 'arch/powerpc/crypto/sha1-ppc-spe.o'.  Stop.
 make[1]: *** No rule to make target 'arch/powerpc/crypto/sha1_spe_glue.o', 
 needed by 'arch/powerpc/crypto/sha1-ppc-spe.o'.  Stop.
 Makefile:947: recipe for target 'arch/powerpc/crypto' failed
 
 Move the two sha1 spe files under crypto/, and whilst there, rename
 other powerpc crypto files with underscores to use dashes for
 consistency.

Sorry for the glitches. Did not notice that I had the files in adjacent folders
and finally added the wrong ones to my git. Thanks a lot for fixing that. 

Markus
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser Mail ist nicht gestattet.

Über das Internet versandte E-Mails können unter fremden Namen erstellt oder
manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine
rechtsverbindliche Willenserklärung.

Collogia
Unternehmensberatung AG
Ubierring 11
D-50678 Köln

Vorstand:
Kadir Akin
Dr. Michael Höhnerbach

Vorsitzender des Aufsichtsrates:
Hans Kristian Langva

Registergericht: Amtsgericht Köln
Registernummer: HRB 52 497

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.

e-mails sent over the internet may have been written under a wrong name or
been manipulated. That is why this message sent as an e-mail is not a
legally binding declaration of intention.

Collogia
Unternehmensberatung AG
Ubierring 11
D-50678 Köln

executive board:
Kadir Akin
Dr. Michael Höhnerbach

President of the supervisory board:
Hans Kristian Langva

Registry office: district court Cologne
Register number: HRB 52 497




Re: [PATCH 0/17] crypto: talitos - Add support for SEC1

2015-03-06 Thread leroy christophe

Le 06/03/2015 01:28, Herbert Xu a écrit :

On Thu, Mar 05, 2015 at 06:21:01PM -0600, Kim Phillips wrote:

On Thu, 5 Mar 2015 17:46:05 +0100
Christophe Leroy christophe.le...@c-s.fr wrote:


[15/17] crypto: talitos - Implementation of SEC1

...


[16/17] crypto: talitos - SEC1 bugs on 0 data hash
[17/17] crypto: talitos - Update DT bindings with SEC1

This patchseries doesn't apply, at least on top of Herbert's
cryptodev-2.6 tree, as of today:

Applying: crypto: talitos - Implementation of SEC1
error: patch failed: drivers/crypto/talitos.c:655
error: drivers/crypto/talitos.c: patch does not apply

Also the patches are coming in a random order.  Please send them
one at a time to ensure proper ordering.

Thanks,
Kim, I have now tried on top of cryptodev-2.6 tree, and for me it works 
(see below).

Do I clone cryptodev-2.6 from the wrong place ?
On that clone, the latest commit on talitos.c is commit 
5be4d4c94b1f98b839344fda7a8752a4a09d0ef5 crypto: replace 
scatterwalk_sg_next with sg_next


[root@localhost ~]# git clone 
https://www.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git

Cloning into 'cryptodev-2.6'...
remote: Counting objects: 4043448, done.
remote: Compressing objects: 100% (682829/682829), done.
Receiving objects: 100% (4043448/4043448), 893.52 MiB | 258.00 KiB/s, done.
remote: Total 4043448 (delta 3330215), reused 4043104 (delta 3329977)
Resolving deltas: 100% (3330215/3330215), done.
Checking connectivity... done.
Checking out files: 100% (48971/48971), done.
[root@localhost ~]# cd cryptodev-2.6/
[root@localhost cryptodev-2.6]# git branch test
[root@localhost cryptodev-2.6]# git checkout test
Switched to branch 'test'
[root@localhost cryptodev-2.6]# git am 
/root/gen/trunk/submitted_patches/talitos/0*
Applying: crypto: talitos - base address for Execution Units and macro 
for ISR masks

Applying: crypto: talitos - Externalise specific SEC2 reset actions
Applying: crypto: talitos - Use zero entry to init descriptors ptrs to zero
Applying: crypto: talitos - Refactor the sg in/out chain allocation
Applying: crypto: talitos - isolate scatter/gather handling for ahash
Applying: crypto: talitos - Add talitos2.c to isolate SEC2 specific 
functions

Applying: crypto: talitos - Split talitos.h into 2 parts
Applying: crypto: talitos - Deport SEC2 error handling
Applying: crypto: talitos - Move reset/init helpers into talitos2.h
Applying: crypto: talitos - Move interrupt related macros in talitos2.h
Applying: crypto: talitos - Move hash chain handling into talitos2.h
Applying: crypto: talitos - Define compatible in talitos2.h instead of 
talitos.c

Applying: crypto: talitos - move sg_count() helper into talitos.h
Applying: crypto: talitos - Add a helper function to clear j_extent field
Applying: crypto: talitos - Implementation of SEC1
Applying: crypto: talitos - SEC1 bugs on 0 data hash
Applying: crypto: talitos - Update DT bindings with SEC1
[root@localhost cryptodev-2.6]#

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