> See Documentation/DocBook/crypto-API.tmpl in the cryptodev-2.6 tree.
> There you will find tons of documentation (which will be merged during
> 3.19-rc1)
Yes, I've been reading that. It certainly helps a great deal, but
still leaves me with some significant questions.
I started researching t
>> The other one, which I have to think *very* hard about, is whether
>> using the same seed material as /dev/random in this much weaker
>> cryptographic construction will introduce a flaw in *it*.
> I have no idea what you are referring to here. The caller is requred to
> seed the DRNG. Typicall
On 12/01/2014 07:00 AM, Herbert Xu wrote:
> As I said the two are arbitrary and we don't place any restrictions
> on them at all (apart from the fact that the TX length in bytes must
> obviously be longer than the RX bytes).
>
> So you can have a 1-element TX list with a multi-element RX list.
Ok
On Mon, Dec 01, 2014 at 06:53:41AM -0800, Tadeusz Struk wrote:
> Hi Herbert,
> On 12/01/2014 06:40 AM, Herbert Xu wrote:
> >> + nents = sg_nents(ctx->rsgl.sg);
> >> > +sg_mark_end(&sg[nents - 1]);
> > Huh? You're getting nents from the RX side and using it t
Hi Herbert,
On 12/01/2014 06:40 AM, Herbert Xu wrote:
>> +nents = sg_nents(ctx->rsgl.sg);
>> > + sg_mark_end(&sg[nents - 1]);
> Huh? You're getting nents from the RX side and using it to mark
> the TX side? This makes no sense because RX may have no relationship
On Fri, Nov 28, 2014 at 10:40:45AM -0800, Tadeusz Struk wrote:
> Remover unneeded code.
>
> Signed-off-by: Tadeusz Struk
Patch applied. Thanks!
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from t
On Fri, Nov 28, 2014 at 10:40:36AM -0800, Tadeusz Struk wrote:
>
> @@ -468,6 +470,9 @@ static int skcipher_recvmsg(struct kiocb *unused, struct
> socket *sock,
> if (!used)
> goto free;
>
> + nents = sg_nents(ctx->rsgl.sg);
Hi all!
I have a question regarding the use of the backlog in a driver
using the crypto API.
In my driver ("crypto: sahara - SHA support") I had a problem with
using the backlog when I am using more than one thread to enqueue
the requests and have a queue depth of 1. What happens is, that I
run in
The Sahara on the i.MX53 is of version 4. Add support for probing the
device.
Signed-off-by: Steffen Trumtrar
---
.../devicetree/bindings/crypto/fsl-imx-sahara.txt| 2 +-
drivers/crypto/sahara.c | 20 +---
2 files changed, 18 insertions(+), 4 del
The driver uses a spinlock, but never initializes it.
Fix this.
Signed-off-by: Steffen Trumtrar
---
drivers/crypto/sahara.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index 164e1ec624e3..6fb16fe7eea5 100644
--- a/drivers/crypto/sahara.
In preparation for SHA support, replace the tasklets with a kthread that
manages one crypto_queue for the core.
As the Sahara can only process one AES or SHA request at a time, we make
sure that the queue serializes all requests from userspace. Instead of a
watchdog timer we now use a completion m
Add support for the MDHA unit in the SAHARA core.
The MDHA can generate hash digests for MD5 and SHA1 in version 3 and
additionally SHA224 and SHA256 in version 4.
Add the SHA1 and SHA256 algorithms to the driver.
The implementation was tested with the in-kernel testmgr and a userspace
testprogra
Hi!
This series adds support for
- i.MX53 support
- SHA1/256
to the SAHARA driver.
- Version 4 is a major overhaul of the previous versions.
The tasklet/watchdog implementation of the driver is replaced by a kthread
and completions. This makes sure, that only one request is qu
13 matches
Mail list logo
