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
Kim
--
To unsubscribe from this list: send the line unsubscribe linux-crypto
On Tue, 3 Mar 2015 08:21:33 -0500
Martin Hicks m...@bork.org 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 m...@bork.org
---
Acked-by: Kim Phillips kim.phill...@freescale.com
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
combination (technically via the
Le 06/03/2015 01:21, Kim Phillips a écrit :
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
On Thu, 5 Mar 2015 10:52:37 +0800
yjin yanjiang@windriver.com wrote:
On 2015年03月05日 02:36, Kim Phillips wrote:
On Wed, 4 Mar 2015 13:33:22 +0800
yjin yanjiang@windriver.com wrote:
On 2015年03月04日 03:31, Kim Phillips wrote:
On Tue, 3 Mar 2015 14:50:52 +0800
On Thu, 5 Mar 2015 09:12:13 +0200
Cristian Stoica cristian.sto...@freescale.com 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
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
From: Yanjiang Jin yanjiang@windriver.com
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:
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 james.hart...@imgtec.com
---
drivers/crypto/Kconfig| 14 +
drivers/crypto/Makefile |2 +
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,
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 james.hart...@imgtec.com
---
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
On Thu, 5 Mar 2015 11:35:23 +0200
Horia Geantă horia.gea...@freescale.com wrote:
On 3/4/2015 2:23 AM, Kim Phillips wrote:
On Tue, 3 Mar 2015 08:21:37 -0500
Martin Hicks m...@bork.org wrote:
@@ -1170,6 +1237,8 @@ static struct talitos_edesc
*talitos_edesc_alloc(struct device *dev,
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
From: Yanjiang Jin yanjiang@windriver.com
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 *
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
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
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
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
*
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
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
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
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,
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
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
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(-)
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
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
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 6c1f6f1..9f75ec9 100644
---
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
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
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
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 |
On 3/4/2015 2:23 AM, Kim Phillips wrote:
On Tue, 3 Mar 2015 08:21:37 -0500
Martin Hicks m...@bork.org wrote:
@@ -1170,6 +1237,8 @@ static struct talitos_edesc
*talitos_edesc_alloc(struct device *dev,
edesc-dma_len,
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
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 request
36 matches
Mail list logo
