3.6+
Fixes: 357fb60502ede ("crypto: talitos - add sha224, sha384 and sha512 to
existing AEAD algorithms")
Signed-off-by: Martin Hicks
---
drivers/crypto/talitos.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
in
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
---
drivers/crypto/talitos.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers
orked. Should tcrypt just set the IV bytes to 0 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
--
Mart
On Mon, Mar 9, 2015 at 6:16 AM, Horia Geantă wrote:
> On 3/3/2015 7:44 PM, Martin Hicks wrote:
>> On Tue, Mar 3, 2015 at 10:44 AM, Horia Geantă
>> wrote:
>>>
>>> For talitos, there are two cases:
>>>
>>> 1. request data size is <= data un
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.
>>
&g
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
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 wrote:
> On Tue, 3 Mar 2015 08:21:35 -0500
> Martin Hicks wrote:
>
>> The submission count was off by one.
>
On Tue, Mar 3, 2015 at 10:44 AM, Horia Geantă
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 int
SY is returned. The queued
requests are dispatched to the hardware in received order as hardware FIFO
slots become available.
Signed-off-by: Martin Hicks
---
drivers/crypto/talitos.c | 135 --
drivers/crypto/talitos.h |3 ++
2 files changed, 110 inser
: Martin Hicks
---
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..b0c85ce 100644
The submission count was off by one.
Signed-off-by: Martin Hicks
---
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
+++ b/drivers
This is properly defined in the md5 header file.
Signed-off-by: Martin Hicks
---
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
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
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
---
drivers/crypto/talitos.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto/talitos.c b
rypt CBC mode, it is not so simple...)
Speaking again 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 swi
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 backward
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 en
Hi Horia,
On Tue, Feb 24, 2015 at 1:21 PM, Horia Geantă
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) {
>
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 wrote:
> I was testing dm-crypt performance with a Freescale P1022 board with
> a recent kernel and was getting IO errors while do
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 wrote:
>
> I've just noticed that performance is pretty terrible with maxcpus=1, so
> I'll investigate that.
> mh
>
> On Fri, Feb
The newer talitos hardware has support for AES in XTS mode.
Signed-off-by: Martin Hicks
---
drivers/crypto/talitos.c | 33 +
drivers/crypto/talitos.h |1 +
2 files changed, 34 insertions(+)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
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
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 than sector size, but that
also requires that that the sector size be passed into the crypto engine
as an XTS cip
SY is returned. The queued
requests are dispatched to the hardware in received order as hardware FIFO
slots become available.
Signed-off-by: Martin Hicks
---
drivers/crypto/talitos.c | 92 +++---
drivers/crypto/talitos.h |3 ++
2 files changed, 74 inser
: Martin Hicks
---
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..d3472be 100644
The submission count was off by one.
Signed-off-by: Martin Hicks
---
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
+++ b/drivers
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
+++ b/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
---
drivers/crypto/talitos.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto/talitos.c b
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
(SStatus 123 SControl 310)
Signed-off-by: Martin Hicks
---
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
---
drivers/mmc/host/sdhci-of-esdhc.c | 10 +-
1
Perfect. I'm glad there's a patch.
mh
On Mon, Jan 12, 2015 at 4:31 PM, Scott Wood 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 Freesc
@ffe0:ethernet@b failed with error -12
Signed-off-by: Martin Hicks
---
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 a/arch/powerpc
On Wed, Oct 16, 2013 at 2:42 PM, Benjamin Herrenschmidt
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
OOK3S_32=y
CONFIG_PPC_BOOK3S=y
more below...
On Tue, Oct 15, 2013 at 4:39 PM, Benjamin Herrenschmidt
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 Tue, Oct 15, 2013 at 11:30 AM, Benjamin Herrenschmidt
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 75382aa72f06823
d_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 wrote:
> Hi,
>
> I've been trying to
300c4)
Gcc-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.or
38 matches
Mail list logo
