[PATCH v2 2/2] Crypto: Add SHA-3 Test's in tcrypt

Added support for SHA-3 algorithm test's in tcrypt module and related test vectors. Signed-off-by: Raveendra Padasalagi --- crypto/tcrypt.c | 53 ++- crypto/testmgr.c | 40 ++ crypto/testmgr.h | 125

[PATCH v2 0/2] Add SHA-3 algorithm and test vectors.

This patchset adds the implementation of SHA-3 algorithm in software and it's based on original implementation pushed in patch https://lwn.net/Articles/518415/ with additional changes to match the padding rules specified in SHA-3 specification. This patchset also includes changes in tcrypt module

Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

Hi Stephan, On 16 June 2016 at 17:38, Stephan Mueller wrote: >> This isn't an issue with AF_ALG, I should have changed the subject >> line perhaps. In this case it's an inconsistency between some >> implementations and the documentation (header comment). It affects >>

Re: [PATCH 1/2] Crypto: Add SHA-3 hash algorithm

Am Donnerstag, 16. Juni 2016, 21:39:17 schrieb Raveendra Padasalagi: Hi Raveendra, > I need some clarification to address your comment > > "Shouldn't there be a priority here?" > > What I know regarding priority value for an algorithm > is higher the priority value it will be get selected for

Re: [PATCH 1/2] Crypto: Add SHA-3 hash algorithm

Hi Stephan, Yes, I was initially thinking of to put it as FIPS but looked at the existing "crypto/Kconfig" for other algorithms and found it to be using DFIPS. So kept this also the same :) I need some clarification to address your comment "Shouldn't there be a priority here?" What I know

Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

Am Donnerstag, 16. Juni 2016, 16:59:01 schrieb Andrew Zaborowski: Hi Andrew, > Hi Stephan, > > On 16 June 2016 at 10:05, Stephan Mueller wrote: > > Am Dienstag, 14. Juni 2016, 09:42:34 schrieb Andrew Zaborowski: > > > > Hi Andrew, > > > >> > I think we have agreed on

Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

Hi Stephan, On 16 June 2016 at 10:05, Stephan Mueller wrote: > Am Dienstag, 14. Juni 2016, 09:42:34 schrieb Andrew Zaborowski: > > Hi Andrew, > >> > >> > I think we have agreed on dropping the length enforcement at the interface >> > level. >> >> Separately from this there's

Re: [PATCH 6/7] crypto: marvell: Adding load balancing between engines

Hello, Le 15/06/2016 23:13, Boris Brezillon a écrit : On Wed, 15 Jun 2016 21:15:33 +0200 Romain Perier wrote: This commits adds support for fine grained load balancing on multi-engine IPs. The engine is pre-selected based on its current load and on the

Re: [PATCH 5/7] crypto: marvell: Adding a complete operation for async requests

Hello, Le 15/06/2016 22:55, Boris Brezillon a écrit : + Nit: not sure you should mix this cosmetic change with the other changes. Ok You already have ivsize initialized. + memcpy_fromio(ablkreq->info, basereq->chain.last->data, ivsize); Use memcpy() here. good catch,

[PATCH] crypto: caam - replace deprecated EXTRA_CFLAGS

EXTRA_CFLAGS is still supported but its usage is deprecated. Signed-off-by: Tudor Ambarus --- drivers/crypto/caam/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/caam/Makefile b/drivers/crypto/caam/Makefile index

Re: [PATCH 4/7] crypto: marvell: Moving the tdma chain out of mv_cesa_tdma_req

On Thu, 16 Jun 2016 14:02:42 +0200 Romain Perier wrote: > > Now that the dma specific fields are part of the base request there's no > > reason to keep this union. > > > > You can just put struct mv_cesa_req base; directly under struct > >

Re: [PATCH 4/7] crypto: marvell: Moving the tdma chain out of mv_cesa_tdma_req

On Thu, 16 Jun 2016 14:02:42 +0200 Romain Perier wrote: > > Now that the dma specific fields are part of the base request there's no > > reason to keep this union. > > > > You can just put struct mv_cesa_req base; directly under struct > >

Re: [PATCH 4/7] crypto: marvell: Moving the tdma chain out of mv_cesa_tdma_req

Hello, Le 15/06/2016 22:42, Boris Brezillon a écrit : On Wed, 15 Jun 2016 21:15:31 +0200 Romain Perier wrote: Actually the only way to access the tdma chain is to use the 'req' union Currently, ... ok Now that the dma specific fields are part of the

Re: [PATCH] crypto: caam: fix misspelled upper_32_bits

On 6/16/2016 12:04 PM, Arnd Bergmann wrote: > An endianess fix mistakenly used higher_32_bits() instead of > upper_32_bits(), and that doesn't exist: > > drivers/crypto/caam/desc_constr.h: In function 'append_ptr': > drivers/crypto/caam/desc_constr.h:84:75: error: implicit declaration of >

Re: [PATCH 1/2] Crypto: Add SHA-3 hash algorithm

Hi Stephan, Thanks for the review comments. I will address it in the next patch. Please look at my reply below against each comment. Regards, Raveendra On Wed, Jun 15, 2016 at 5:12 PM, Stephan Mueller wrote: > Am Mittwoch, 15. Juni 2016, 15:11:58 schrieb Raveendra

[PATCH] crypto: caam: fix misspelled upper_32_bits

An endianess fix mistakenly used higher_32_bits() instead of upper_32_bits(), and that doesn't exist: drivers/crypto/caam/desc_constr.h: In function 'append_ptr': drivers/crypto/caam/desc_constr.h:84:75: error: implicit declaration of function 'higher_32_bits'

Re: [PATCH 3/7] crypto: marvell: Copy IV vectors by DMA transfers for acipher requests

Hi Romain, On jeu., juin 16 2016, Romain Perier wrote: > >>> diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h >>> index 74071e4..74b84bd 100644 >>> --- a/drivers/crypto/marvell/cesa.h >>> +++ b/drivers/crypto/marvell/cesa.h >>> @@

Re: [PATCH 3/7] crypto: marvell: Copy IV vectors by DMA transfers for acipher requests

Hello, Le 15/06/2016 22:07, Boris Brezillon a écrit : On Wed, 15 Jun 2016 21:15:30 +0200 Romain Perier wrote: Adding a TDMA descriptor at the end of the request for copying the output IV vector via a DMA transfer. This is required for processing cipher

Re: [PATCH 2/7] crypto: marvell: Check engine is not already running when enabling a req

Hello, Le 15/06/2016 21:37, Boris Brezillon a écrit : " Add a BUG_ON() call when the driver tries to launch a crypto request while the engine is still processing the previous one. This replaces a silent system hang by a verbose kernel panic with the associated backtrace to let the user know

Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

Am Dienstag, 14. Juni 2016, 09:42:34 schrieb Andrew Zaborowski: Hi Andrew, > > > > I think we have agreed on dropping the length enforcement at the interface > > level. > > Separately from this there's a problem with the user being unable to > know if the algorithm is going to fail because of