Am Samstag, 21. Februar 2015, 08:39:05 schrieb sri sowj:
Hi sri,
> Hi Stephen,
>
> Thank you very much for the information provided.
>
> I will try to explore more on AF_ALG , in between please can you also
> provide information regarding below ?
> #1: how openssl communicates to crypto h/w usi
Hi Stephen,
Thank you very much for the information provided.
I will try to explore more on AF_ALG , in between please can you also
provide information regarding below ?
#1: how openssl communicates to crypto h/w using PF_ALG
#2: How man algorithms are supported?
#3: are there any samples to get
Am Samstag, 21. Februar 2015, 01:27:04 schrieb sri sowj:
Hi sri,
> Hi ,
>
> I want to interact with Crypto Hardware from user space using openssl
> like libraries based applications through cryptodev-linux interface.
>
> it looks like openssl comes with cryptodev-linux support(through
> eng_cry
Am Samstag, 21. Februar 2015, 01:39:23 schrieb sri sowj:
Hi sri,
> Hi Muller ,
>
> Thanks for the information provided.
>
> I am little confused between current scenario (multiple threads will
> send multiple requests to crypto H/W) and export/import.
>
> Please can you let me know when export
Hi Muller ,
Thanks for the information provided.
I am little confused between current scenario (multiple threads will
send multiple requests to crypto H/W) and export/import.
Please can you let me know when export/imports can be used in real time?
I Have seen many references of these method(exp
Hi ,
I want to interact with Crypto Hardware from user space using openssl
like libraries based applications through cryptodev-linux interface.
it looks like openssl comes with cryptodev-linux support(through
eng_cryptodev.c) .
When I downloaded openssl,eng_cryptodev.c file is available by defaul
Am Donnerstag, 19. Februar 2015, 21:48:30 schrieb sri sowj:
Hi sri,
> Hi ,
>
> I am trying to understand Hashing Algorithms implementation in linux kernel
> .
>
> I am really not sure on how to deal with following scenario.
>
> assume when App1 is in middle of
> execution(crypto_ahash_init/upd
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 20, 2015 at 11:21 AM, Martin Hick
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
in
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
I was running into situations where the hardware FIFO was filling up, and
the code was returning EAGAIN to dm-crypt and just dropping the submitted
crypto request.
This adds support in talitos for a software backlog queue. When requests
can't be queued to the hardware immediately EBUSY is returne
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/cr
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
This is preparatory work for moving to using the crypto async queue
handling code. A talitos_request structure is buried into each
talitos_edesc so that when talitos_submit() is called, everything required
to defer the submission to the hardware is contained within talitos_edesc.
Signed-off-by: M
I was testing dm-crypt performance with a Freescale P1022 board with
a recent kernel and was getting IO errors while doing testing with LUKS.
Investigation showed that all hardware FIFO slots were filling and
the driver was returning EAGAIN to the block layer, which is not an
expected response for
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/driv
On 20 February 2015 at 15:55, Will Deacon wrote:
> On Thu, Feb 19, 2015 at 05:25:16PM +, Ard Biesheuvel wrote:
>> This patch increases the interleave factor for parallel AES modes
>> to 4x. This improves performance on Cortex-A57 by ~35%. This is
>> due to the 3-cycle latency of AES instructio
On Thu, Feb 19, 2015 at 05:25:16PM +, Ard Biesheuvel wrote:
> This patch increases the interleave factor for parallel AES modes
> to 4x. This improves performance on Cortex-A57 by ~35%. This is
> due to the 3-cycle latency of AES instructions on the A57's
> relatively deep pipeline (compared to
Hi Markus,
Thanks for the information provided .
But I am still not really sure how does crypto driver keeps track of
the context (intermediate Hash) ,when another application/thread sends
a request ? I think export/import methods are used to export this
intermediate hash to upper layers ,then t
20 matches
Mail list logo
