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.
Signed-off-by: Stephan Muell
Le 06/03/2015 01:21, Kim Phillips a écrit :
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 - Update DT bindings with SEC1
This patchseries doesn't ap
On Thu, Mar 05, 2015 at 11:35:23AM +0200, Horia Geantă wrote:
>
> > Only potential problem is getting the crypto API to set the GFP_DMA
> > flag in the allocation request, but presumably a
> > CRYPTO_TFM_REQ_DMA crt_flag can be made to handle that.
>
> Right. And this flag would apply only to req
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.
Signed-off-by: James Hartley
---
.../devicetree/bindings/crypto/img-hash.txt
This adds support for the Imagination Technologies hash
accelerator which provides hardware acceleration for
SHA1 SHA244 SHA256 and MD5 hashes.
Tested on silicon, using testmgr.
Changes from V2:
* This hardware does not support importing a partial hash state,
so the init, updat
This adds support for the Imagination Technologies hash
accelerator which provides hardware acceleration for
SHA1 SHA224 SHA256 and MD5 hashes.
Signed-off-by: James Hartley
---
drivers/crypto/Kconfig| 14 +
drivers/crypto/Makefile |2 +
drivers/crypto/img-hash.c | 1037 ++
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 update DESC_RNG_LEN to (4 * CAAM_CMD_SZ).
caam_jr ffe3010
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=0xdeadbeefdeadbeef] [size=3735928559 bytes]
[ cut here
From: Yanjiang Jin
Hi,
This patch series fix some CAAM compile and runtime warnings.
I have tested this on fsl-p5020ds board using upstream 4.0.0-rc2 with the below
configs:
CONFIG_DMA_API_DEBUG=y
# CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
Change log:
v3:
0001-crypto-caamhash-fix-unin
On Thu, 5 Mar 2015 09:12:13 +0200
Cristian Stoica wrote:
> On 03/04/2015 08:34 PM, Kim Phillips wrote:
>
> > I don't see how, e.g., for one, dma_map_sg is I/O TLB
> > implementation-dependent.
>
> I'll need some remedial classes on this topic, but for the moment I
> don't see how this matters f
On Thu, 5 Mar 2015 11:35:23 +0200
Horia Geantă wrote:
> On 3/4/2015 2:23 AM, Kim Phillips wrote:
> > On Tue, 3 Mar 2015 08:21:37 -0500
> > Martin Hicks wrote:
> >
> >> @@ -1170,6 +1237,8 @@ static struct talitos_edesc
> >> *talitos_edesc_alloc(struct device *dev,
> >>
On Thu, 5 Mar 2015 10:52:37 +0800
yjin wrote:
> On 2015年03月05日 02:36, Kim Phillips wrote:
> > On Wed, 4 Mar 2015 13:33:22 +0800
> > yjin wrote:
> >
> >> On 2015年03月04日 03:31, Kim Phillips wrote:
> >>> On Tue, 3 Mar 2015 14:50:52 +0800
> >>> wrote:
> >>>
> -dma_unmap_single(
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 - Update DT bindings wi
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 - Update DT bindings with SEC1
This patchseries doesn't apply, at least on top of Herbert's
cryptodev-
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 support this algorithm
combination (technically via the mode bit), thi
On Tue, 3 Mar 2015 08:21:33 -0500
Martin Hicks wrote:
> There were multiple loops in a row, for each separate step of the
> initialization of the channels. Simplify to a single loop.
>
> Signed-off-by: Martin Hicks
> ---
Acked-by: Kim Phillips
Kim
--
To unsubscribe from this list: send the
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
Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.ker
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
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
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 6c1f6f1..9f75ec9 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/
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 scat
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
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
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
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
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/drive
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
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
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
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 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
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
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
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
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 e3a2
On 3/4/2015 2:23 AM, Kim Phillips wrote:
> On Tue, 3 Mar 2015 08:21:37 -0500
> Martin Hicks wrote:
>
>> @@ -1170,6 +1237,8 @@ static struct talitos_edesc
>> *talitos_edesc_alloc(struct device *dev,
>> edesc->dma_len,
>>
36 matches
Mail list logo