org> # 3.6+
Fixes: 357fb60502ede ("crypto: talitos - add sha224, sha384 and sha512 to
existing AEAD algorithms")
Signed-off-by: Martin Hicks <m...@bork.org>
---
drivers/crypto/talitos.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/cryp
The max keysize for both of these is 128, not 96. Before, with keysizes
over 96, the memcpy in ahash_setkey() would overwrite memory beyond the
key field.
Signed-off-by: Martin Hicks <m...@bork.org>
---
drivers/crypto/talitos.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
instead of 0xff?
Isn't one IV just as good as another? I think adding exceptions to
the tcrypt code would be ugly, but maybe one should be made for XTS
since the standard dictates that the IV should be plain or plain64?
Thanks,
mh
--
Martin Hicks P.Eng. | m...@bork.org
Bork
On Mon, Mar 9, 2015 at 6:16 AM, Horia Geantă horia.gea...@freescale.com wrote:
On 3/3/2015 7:44 PM, Martin Hicks wrote:
On Tue, Mar 3, 2015 at 10:44 AM, Horia Geantă
horia.gea...@freescale.com wrote:
For talitos, there are two cases:
1. request data size is = data unit / sector size
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
Hi Kim,
On Fri, Mar 6, 2015 at 11:49 AM, 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
Ok, I'm fine dropping this patch. I'm sure it doesn't affect
performance in a measurable way.
mh
On Tue, Mar 3, 2015 at 7:35 PM, Kim Phillips kim.phill...@freescale.com wrote:
On Tue, 3 Mar 2015 08:21:35 -0500
Martin Hicks m...@bork.org wrote:
The submission count was off by one.
Signed
requests.
- Avoid enqueuing a submitted request to the crypto queue unnecessarily.
- Fix return paths where CRYPTO_TFM_REQ_MAY_BACKLOG is not set.
Martin Hicks (5):
crypto: talitos: Simplify per-channel initialization
crypto: talitos: Remove MD5_BLOCK_SIZE
crypto: talitos: Fix off-by-one and use
The submission count was off by one.
Signed-off-by: Martin Hicks m...@bork.org
---
drivers/crypto/talitos.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 89cf4d5..7709805 100644
--- a/drivers/crypto/talitos.c
This is properly defined in the md5 header file.
Signed-off-by: Martin Hicks m...@bork.org
---
drivers/crypto/talitos.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index c49d977..89cf4d5 100644
--- a/drivers
is returned. The queued
requests are dispatched to the hardware in received order as hardware FIFO
slots become available.
Signed-off-by: Martin Hicks m...@bork.org
---
drivers/crypto/talitos.c | 135 --
drivers/crypto/talitos.h |3 ++
2 files changed, 110
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
---
drivers/crypto/talitos.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto
-by: Martin Hicks m...@bork.org
---
drivers/crypto/talitos.c | 95 +++---
drivers/crypto/talitos.h | 41 +---
2 files changed, 66 insertions(+), 70 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 7709805
On Tue, Mar 3, 2015 at 10:44 AM, Horia Geantă
horia.gea...@freescale.com wrote:
On 3/3/2015 12:09 AM, Martin Hicks wrote:
On Mon, Mar 02, 2015 at 03:37:28PM +0100, Milan Broz wrote:
If crypto API allows to encrypt more sectors in one run
(handling IV internally) dmcrypt can be modified
with talitos in mind, there would be no advantage for this
hardware. Although larger requests are possible only a single IV can be
provided per request, so for algorithms like AES-CBC and dm-crypt 512byte IOs
are the only option (short of switching to 4kB block size).
mh
--
Martin Hicks P.Eng
On Mon, Mar 02, 2015 at 04:44:19PM -0500, Martin Hicks wrote:
Write (MB/s)Read (MB/s)
Unencrypted 140 176
aes-xts-plain64 512b 113 115
aes-xts-plain64 4kB 71 56
I got the two AES lines backwards. Sorry about
On Mon, Mar 02, 2015 at 03:25:56PM +0200, Horia Geantă wrote:
On 2/20/2015 7:00 PM, Martin Hicks wrote:
This adds the AES-XTS mode, supported by the Freescale SEC 3.3.2.
One of the nice things about this hardware is that it knows how to deal
with encrypt/decrypt requests that are larger
Hi Horia,
On Tue, Feb 24, 2015 at 1:21 PM, Horia Geantă
horia.gea...@freescale.com wrote:
On 2/20/2015 6:21 PM, Martin Hicks wrote:
+ int ret = -EINPROGRESS;
spin_lock_irqsave(priv-chan[ch].head_lock, flags);
+ if (edesc) {
+ orig_request = edesc-req
I've just noticed that performance is pretty terrible with maxcpus=1, so
I'll investigate that.
mh
On Fri, Feb 20, 2015 at 11:21 AM, Martin Hicks m...@bork.org wrote:
I was testing dm-crypt performance with a Freescale P1022 board with
a recent kernel and was getting IO errors while doing
for an async crypto implementation.
The following patch series adds a few small fixes, and reworks the
submission path to use the crypto_queue mechanism to handle the
request backlog.
Martin Hicks (5):
crypto: talitos: Simplify per-channel initialization
crypto: talitos: Remove MD5_BLOCK_SIZE
This is properly defined in the md5 header file.
---
drivers/crypto/talitos.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index c49d977..89cf4d5 100644
--- a/drivers/crypto/talitos.c
+++
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
---
drivers/crypto/talitos.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto
-by: Martin Hicks m...@bork.org
---
drivers/crypto/talitos.c | 93 +++---
drivers/crypto/talitos.h | 41 +---
2 files changed, 65 insertions(+), 69 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 7709805
The submission count was off by one.
Signed-off-by: Martin Hicks m...@bork.org
---
drivers/crypto/talitos.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 89cf4d5..7709805 100644
--- a/drivers/crypto/talitos.c
is returned. The queued
requests are dispatched to the hardware in received order as hardware FIFO
slots become available.
Signed-off-by: Martin Hicks m...@bork.org
---
drivers/crypto/talitos.c | 92 +++---
drivers/crypto/talitos.h |3 ++
2 files changed, 74
?
Martin Hicks (2):
crypto: talitos: Clean ups and comment fixes for ablkcipher commands
crypto: talitos: Add AES-XTS Support
drivers/crypto/talitos.c | 45 +
drivers/crypto/talitos.h |1 +
2 files changed, 38 insertions(+), 8 deletions
This just cleans up some of the initializers, and improves the comments
should any other ablkcipher modes be added in the future. The header
words 1 and 5 have more possibilities than just passing an IV. These
are pointers to the Cipher Context in/out registers.
Signed-off-by: Martin Hicks m
The newer talitos hardware has support for AES in XTS mode.
Signed-off-by: Martin Hicks m...@bork.org
---
drivers/crypto/talitos.c | 33 +
drivers/crypto/talitos.h |1 +
2 files changed, 34 insertions(+)
diff --git a/drivers/crypto/talitos.c b/drivers
Resending to linux-crypto in plain text.
Sorry to everyone else for the duplication.
mh
On Fri, Feb 20, 2015 at 1:23 PM, Martin Hicks m...@bork.org wrote:
I've just noticed that performance is pretty terrible with maxcpus=1, so
I'll investigate that.
mh
On Fri, Feb 20, 2015 at 11:21 AM
(SStatus 123 SControl 310)
Signed-off-by: Martin Hicks m...@bork.org
---
drivers/ata/sata_fsl.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index f9054cd..a9b5508 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -868,6 +868,8
The reset code was pushed into the esdhc-imx driver, but missed being
pushed into the FSL OF driver at the same time. The commit that broke
the OF ESDHC driver was 0718e59ae259f7c48155b4e852d8b0632d59028e
Signed-off-by: Martin Hicks m...@bork.org
---
drivers/mmc/host/sdhci-of-esdhc.c | 10
Perfect. I'm glad there's a patch.
mh
On Mon, Jan 12, 2015 at 4:31 PM, Scott Wood scottw...@freescale.com wrote:
On Mon, 2015-01-12 at 10:27 -0500, Martin Hicks wrote:
With an earlier change (746c9e9f - Fix PowerPC address parsing hack),
ethernet
has broken on Freescale boards
@ffe0:ethernet@b failed with error -12
Signed-off-by: Martin Hicks m...@bork.org
---
arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi |1 +
arch/powerpc/boot/dts/fsl/pq3-etsec2-1.dtsi |1 +
arch/powerpc/boot/dts/fsl/pq3-etsec2-2.dtsi |1 +
3 files changed, 3 insertions(+)
diff --git
CONFIG_PPC_BOOK3S=y
more below...
On Tue, Oct 15, 2013 at 4:39 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Tue, 2013-10-15 at 15:22 -0500, Scott Wood wrote:
On Tue, 2013-10-15 at 14:53 -0500, Benjamin Herrenschmidt wrote:
On Tue, 2013-10-15 at 14:44 -0400, Martin Hicks wrote
On Wed, Oct 16, 2013 at 2:42 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Wed, 2013-10-16 at 11:05 -0400, Martin Hicks wrote:
Actually, I was wrong, the mpc8379 is an e300c4.
So it seems clear to me that we compile in the book3s code because
this is an 83xx CPU part. I also
into perf_read_regs
I don't know enough about PPC to know what's going on, but reverting
the changes to perf_instruction_pointer() gets me reasonable 'perf
report' output with 3.11.
Thanks,
mh
On Thu, Oct 3, 2013 at 10:21 AM, Martin Hicks m...@bork.org wrote:
Hi,
I've been trying to track down a performance
On Tue, Oct 15, 2013 at 11:30 AM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Tue, 2013-10-15 at 09:59 -0400, Martin Hicks wrote:
I've tracked the start of the strange instruction pointers in 'perf
report' to a commit by Anton:
commit 75382aa72f06823db7312ad069c3bae2eb3f8548
-4.7.2 uClibC built with ct-ng 1.18.0
binutils 2.22
Thanks,
mh
--
Martin Hicks P.Eng. | m...@bork.org
Bork Consulting Inc. | +1 (613) 266-2296
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo
38 matches
Mail list logo
