> 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: [PATC
On Fri, 6 Mar 2015 11:49:43 -0500
Martin Hicks wrote:
> On Thu, Mar 5, 2015 at 7:16 PM, Kim Phillips
> wrote:
> > On Fri, 20 Feb 2015 12:00:10 -0500
> > Martin Hicks wrote:
> >
> >> The newer talitos hardware has support for AES in XTS mode.
> >
> > Assuming it's the same thing, AES-XCBC gets
On Fri, 6 Mar 2015 10:34:42 +0800
wrote:
> From: Yanjiang Jin
>
> Fix rng_unmap_ctx's DMA_UNMAP size problem for caam_rng, else system would
> report the below calltrace during cleanup caam_rng.
> Since rng_create_sh_desc() creates a fixed descriptor of exactly 4
> command-lengths now, also upd
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.
On Fri, 6 Mar 2015 10:34:41 +0800
wrote:
> From: Yanjiang Jin
>
> 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=0xdeadbeef
This adds ACPI support for APM X-Gene RNG unit.
Signed-off-by: Feng Kan
---
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
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
Hi James,
On Thu, Mar 5, 2015 at 7:01 PM, James Hartley wrote:
> This adds the binding documentation for the Imagination Technologies
> hash accelerator that provides hardware acceleration for
> SHA1/SHA224/SHA256/MD5 hashes. This hardware will be present in
> the upcoming pistachio SoC.
>
> Sig
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
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 / R
The file Documentation/DocBook/crypto-API.tmpl documents the kernel
crypto API and is maintained.
Signed-off-by: Stephan Mueller
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ddc5a8c..c10814e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -280
* Pali Rohár [150306 11:16]:
> On Friday 06 March 2015 19:36:32 Tony Lindgren wrote:
> > * Pali Rohár [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
Hi Kim,
On Fri, Mar 6, 2015 at 11:49 AM, Martin Hicks wrote:
> On Thu, Mar 5, 2015 at 7:16 PM, Kim Phillips
> wrote:
>> On Fri, 20 Feb 2015 12:00:10 -0500
>> Martin Hicks wrote:
>>
>>> The newer talitos hardware has support for AES in XTS mode.
>>
>> Assuming it's the same thing, AES-XCBC gets
On Friday 06 March 2015 19:36:32 Tony Lindgren wrote:
> * Pali Rohár [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: O
* Pali Rohár [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:
On Thu, Mar 5, 2015 at 7:16 PM, Kim Phillips wrote:
> On Fri, 20 Feb 2015 12:00:10 -0500
> Martin Hicks 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 suppor
Move reset/init helpers init talitos2.h as they are specific to SEC2
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 19 ---
drivers/crypto/talitos2.h | 20
2 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/crypto/talit
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
* tal
Do use zero_entry value to init the descriptors ptrs to zero instead of
writing 0 in each field
Signed-off-by: Christophe Leroy
---
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 103b
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
---
drivers/crypto/talitos.c | 103 +-
drivers/crypto/talitos.h | 8
drivers/crypto/t
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
---
drivers/crypto/talitos.c | 29 +++--
1 file changed, 19 insertions(+), 1
This patch updates the documentation by including SEC1 into SEC2/3 doc
Signed-off-by: Christophe Leroy
---
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/Docu
SEC1 bugs on 0 data hash, so we submit an already padded block representing 0
data
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 3 +++
drivers/crypto/talitos1.c | 21 +
drivers/crypto/talitos1.h | 4
drivers/crypto/talitos2.h | 6 ++
4 files c
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 sca
Move interrupt related macros in talitos2.h as they are specific to SEC2
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 58 -
drivers/crypto/talitos2.h | 60 +++
2 files changed, 60 insertio
move sg_count() helper into talitos.h as it will be needed by SEC1 specific
functions
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 20
drivers/crypto/talitos.h | 21 +
2 files changed, 21 insertions(+), 20 deletions(-)
diff --git a/dr
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
---
drivers/crypto/talitos.h | 163 +---
driver
Move hash chain handling into talitos2.h as only SEC2 has sg chaining
capatibility
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 34 --
drivers/crypto/talitos2.h | 34 ++
2 files changed, 34 insertions(+), 34 del
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 ad
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
---
drivers/crypto/talitos.c | 2 +-
drivers/crypto/talitos2.h | 5 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/driv
Signed-off-by: Christophe Leroy
---
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/
This patch refactors the handling of the input and output data that is quite
similar in several functions
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 163 ---
1 file changed, 85 insertions(+), 78 deletions(-)
diff --git a/drivers/c
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
---
drivers/crypto/talitos.h | 85 ++--
1 fi
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
---
drivers/crypto/talitos.c | 20
1 file changed, 16 insertions(+), 4 deleti
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
>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:
Ac
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
Home Page: http://gondor.apana.org.a
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,
Tade
Kim Phillips wrote:
> On Tue, 3 Mar 2015 08:21:34 -0500
> Martin Hicks wrote:
>
>> This is properly defined in the md5 header file.
>>
>> Signed-off-by: Martin Hicks
>> ---
>
> Acked-by: Kim Phillips
Patches 1-2 applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au
On Wed, Mar 04, 2015 at 10:19:30AM +0100, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven
>
> 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
> C
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 hw
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
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 wrote:
[15/17] crypto: talitos - Implementation of SEC1
...
[16/17] crypto: talitos - SEC1 bugs on 0 data hash
[17/17] crypto: talitos
43 matches
Mail list logo
