On Fri, Jun 07, 2019 at 11:57:49AM -0700, Florian Fainelli wrote:
> On 5/10/19 10:31 AM, Florian Fainelli wrote:
> > BCM7211 features a RNG200 block, document its compatible string.
> >
> > Signed-off-by: Florian Fainelli
>
> Rob, does this look okay to you?
Yes, sorry, a bit behind on reviews.
On Fri, 10 May 2019 10:31:10 -0700, Florian Fainelli wrote:
> BCM7211 features a RNG200 block, document its compatible string.
>
> Signed-off-by: Florian Fainelli
> ---
> Documentation/devicetree/bindings/rng/brcm,iproc-rng200.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Rob Herr
On 6/13/2019 3:48 PM, Christophe Leroy wrote:
> On SEC1, hash provides wrong result when performing hashing in several
> steps with input data SG list has more than one element. This was
> detected with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS:
>
> [ 44.185947] alg: hash: md5-talitos test failed (wrong
On Wed, Jun 12, 2019 at 09:59:52PM +0800, Herbert Xu wrote:
> On Wed, Jun 12, 2019 at 09:26:02PM +0800, Shawn Guo wrote:
> >
> > Yes, it happens from time to time depending on maintainer's style. I'm
> > fine with the DT changes going through other subsystem tree, if the
> > subsystem maintainer wa
On Wed, Jun 12, 2019 at 05:08:50PM +0200, Heiko Carstens wrote:
> On Wed, Jun 12, 2019 at 03:33:02PM +0200, David Hildenbrand wrote:
> > s390x crypto is one of the rare modules that returns -EOPNOTSUPP instead of
> > -ENODEV in case HW support is not available.
> >
> > Convert to -ENODEV, so e.g.,
Le 12/06/2019 à 15:59, Horia Geanta a écrit :
On 6/12/2019 8:52 AM, Christophe Leroy wrote:
Le 11/06/2019 à 18:30, Horia Geanta a écrit :
On 6/11/2019 6:40 PM, Christophe Leroy wrote:
Le 11/06/2019 à 17:37, Horia Geanta a écrit :
On 6/11/2019 5:39 PM, Christophe Leroy wrote:
This seri
On Sun, Jun 09, 2019 at 03:57:10PM +0900, Masahiro Yamada wrote:
>
> diff --git a/include/crypto/internal/cryptouser.h
> b/include/crypto/internal/cryptouser.h
> index 8c602b187c58..2339cb06dbf8 100644
> --- a/include/crypto/internal/cryptouser.h
> +++ b/include/crypto/internal/cryptouser.h
> @@ -
On Tue, Jun 04, 2019 at 10:53:51PM +0800, YueHaibing wrote:
> Fix sparse warnings:
>
> drivers/crypto/bcm/cipher.c:99:6: warning: symbol 'BCMHEADER' was not
> declared. Should it be static?
> drivers/crypto/bcm/cipher.c:2096:6: warning: symbol 'spu_no_incr_hash' was
> not declared. Should it be
Eric Biggers wrote:
> From: Eric Biggers
>
> Rewrite the skcipher API example, changing it to encrypt a buffer with
> AES-256-XTS. This addresses various problems with the previous example:
>
> - It requests a specific driver "cbc-aes-aesni", which is unusual.
> Normally users ask for "cbc(ae
Eric Biggers wrote:
> From: Eric Biggers
>
> - Use sg_init_one() instead of sg_init_table() then sg_set_buf().
>
> - Remove unneeded calls to sg_init_table() prior to scatterwalk_ffwd().
>
> - Simplify initializing the poly tail block.
>
> - Simplify computing padlen.
>
> This doesn't change
On Thu, Jun 13, 2019 at 08:47:10AM +0800, Shawn Guo wrote:
> On Wed, Jun 12, 2019 at 09:59:52PM +0800, Herbert Xu wrote:
> > On Wed, Jun 12, 2019 at 09:26:02PM +0800, Shawn Guo wrote:
> > >
> > > Yes, it happens from time to time depending on maintainer's style. I'm
> > > fine with the DT changes g
Eric Biggers wrote:
> From: Eric Biggers
>
> Constify the ctx and iv arguments to crypto_chacha_init() and the
> various chacha*_stream_xor() functions. This makes it clear that they
> are not modified.
>
> Signed-off-by: Eric Biggers
> ---
> arch/arm/crypto/chacha-neon-glue.c | 2 +-
> arch
Eric Biggers wrote:
> From: Eric Biggers
>
> Since commit 944585a64f5e ("crypto: x86/aes-ni - remove special handling
> of AES in PCBC mode"), the "__aes-aesni" internal cipher algorithm is no
> longer used. So remove it too.
>
> Signed-off-by: Eric Biggers
> ---
> arch/x86/crypto/aesni-intel
Eric Biggers wrote:
> Most generic crypto algorithms declare a driver name ending in
> "-generic". The rest don't declare a driver name and instead rely on
> the crypto API automagically appending "-generic" upon registration.
>
> Having multiple conventions is unnecessarily confusing and makes
Eric Biggers wrote:
> From: Eric Biggers
>
> crypto_aead_encrypt() and crypto_aead_decrypt() have grown to be more
> than a single indirect function call. They now also check whether a key
> has been set, the decryption side checks whether the input is at least
> as long as the authentication t
Eric Biggers wrote:
> From: Eric Biggers
>
> The 'chunksize' and 'walksize' properties of skcipher algorithms are
> implementation details that users of the skcipher API should not be
> looking at. So move their accessor functions from
> to .
>
> Signed-off-by: Eric Biggers
> ---
> include/c
Eric Biggers wrote:
> From: Eric Biggers
>
> crypto_skcipher_encrypt() and crypto_skcipher_decrypt() have grown to be
> more than a single indirect function call. They now also check whether
> a key has been set, and with CONFIG_CRYPTO_STATS=y they also update the
> crypto statistics. That can
On Wed, Jun 05, 2019 at 06:51:53PM +0530, Nishad Kamdar wrote:
> This patch corrects the SPDX License Identifier style
> in header files related to Crypto Drivers for Cavium Nitrox
> family CNN55XX devices.
> For C header files Documentation/process/license-rules.rst
> mandates C-like comments (opp
Eric Biggers wrote:
> From: Eric Biggers
>
> Call cond_resched() after each fuzz test iteration. This avoids stall
> warnings if fuzz_iterations is set very high for testing purposes.
>
> While we're at it, also call cond_resched() after finishing testing each
> test vector.
>
> Signed-off-by
On Thu, Jun 06, 2019 at 01:13:48PM -0300, Fabio Estevam wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
>
> Signed-off-by: Fabio Estevam
> ---
> drivers/crypto/mxs-dcp.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
All applied. Thanks.
--
Email: Herber
On Thu, Jun 06, 2019 at 08:36:17PM +0530, Nishad Kamdar wrote:
> This patch corrects the SPDX License Identifier style
> in header file related to Crypto Drivers for Hisilicon
> SEC Engine in Hip06 and Hip07.
> For C header files Documentation/process/license-rules.rst
> mandates C-like comments (o
On Thu, Jun 06, 2019 at 09:57:13AM -0500, Gustavo A. R. Silva wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct q
On Thu, Jun 13, 2019 at 11:13:55AM +0800, Herbert Xu wrote:
> On Wed, Jun 12, 2019 at 05:08:50PM +0200, Heiko Carstens wrote:
> > On Wed, Jun 12, 2019 at 03:33:02PM +0200, David Hildenbrand wrote:
> > > s390x crypto is one of the rare modules that returns -EOPNOTSUPP instead
> > > of
> > > -ENODEV
On 6/11/2019 5:39 PM, Christophe Leroy wrote:
> Next patch will require struct talitos_edesc to be defined
> earlier in talitos.c
>
> This patch moves it into talitos.h so that it can be used
> from any place in talitos.c
>
> Fixes: 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahas
Le 13/06/2019 à 14:13, Horia Geanta a écrit :
On 6/11/2019 5:39 PM, Christophe Leroy wrote:
Next patch will require struct talitos_edesc to be defined
earlier in talitos.c
This patch moves it into talitos.h so that it can be used
from any place in talitos.c
Fixes: 37b5e8897eb5 ("crypto: tal
On 6/13/2019 3:16 PM, Christophe Leroy wrote:
>
>
> Le 13/06/2019 à 14:13, Horia Geanta a écrit :
>> On 6/11/2019 5:39 PM, Christophe Leroy wrote:
>>> Next patch will require struct talitos_edesc to be defined
>>> earlier in talitos.c
>>>
>>> This patch moves it into talitos.h so that it can be u
On 6/11/2019 5:39 PM, Christophe Leroy wrote:
> icv_ool is not used anymore, drop it.
>
> Fixes: 9cc87bc3613b ("crypto: talitos - fix AEAD processing")
I can't find this SHA1.
Are you referring to commit e345177ded17 ("crypto: talitos - fix AEAD
processing.")?
Horia
On 6/11/2019 5:39 PM, Christophe Leroy wrote:
> When building for SEC1 only, talitos2_done functions are unneeded
> and should go away.
>
> For this, use has_ftr_sec1() which will always return true when only
> SEC1 support is being built, allowing GCC to drop TALITOS2 functions.
>
> Signed-off-b
Le 13/06/2019 à 14:24, Horia Geanta a écrit :
On 6/13/2019 3:16 PM, Christophe Leroy wrote:
Le 13/06/2019 à 14:13, Horia Geanta a écrit :
On 6/11/2019 5:39 PM, Christophe Leroy wrote:
Next patch will require struct talitos_edesc to be defined
earlier in talitos.c
This patch moves it into
Le 13/06/2019 à 14:21, Horia Geanta a écrit :
On 6/11/2019 5:39 PM, Christophe Leroy wrote:
icv_ool is not used anymore, drop it.
Fixes: 9cc87bc3613b ("crypto: talitos - fix AEAD processing")
I can't find this SHA1.
Are you referring to commit e345177ded17 ("crypto: talitos - fix AEAD
pro
On 6/13/2019 3:32 PM, Christophe Leroy wrote:
>
>
> Le 13/06/2019 à 14:24, Horia Geanta a écrit :
>> On 6/13/2019 3:16 PM, Christophe Leroy wrote:
>>>
>>>
>>> Le 13/06/2019 à 14:13, Horia Geanta a écrit :
On 6/11/2019 5:39 PM, Christophe Leroy wrote:
> Next patch will require struct tali
This series is the last set of fixes for the Talitos driver.
We now get a fully clean boot on both SEC1 (SEC1.2 on mpc885) and
SEC2 (SEC2.2 on mpc8321E) with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS:
[3.385197] bus: 'platform': really_probe: probing driver talitos with
device ff02.crypto
[3
icv_ool is not used anymore, drop it.
Fixes: e345177ded17 ("crypto: talitos - fix AEAD processing.")
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 3 ---
drivers/crypto/talitos.h | 2 --
2 files changed, 5 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/tali
On SEC1, hash provides wrong result when performing hashing in several
steps with input data SG list has more than one element. This was
detected with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS:
[ 44.185947] alg: hash: md5-talitos test failed (wrong result) on test vector
6, cfg="random: may_sleep use_f
Moves it into talitos.h so that it can be used
from any place in talitos.c
This will be required for next
patch ("crypto: talitos - fix hash on SEC1")
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 30 --
drivers/crypto/talitos.h | 30
When building for SEC1 only, talitos2_done functions are unneeded
and should go away.
For this, use has_ftr_sec1() which will always return true when only
SEC1 support is being built, allowing GCC to drop TALITOS2 functions.
Signed-off-by: Christophe Leroy
Reviewed-by: Horia Geantă
---
drivers
Le 13/06/2019 à 14:39, Horia Geanta a écrit :
On 6/13/2019 3:32 PM, Christophe Leroy wrote:
Le 13/06/2019 à 14:24, Horia Geanta a écrit :
On 6/13/2019 3:16 PM, Christophe Leroy wrote:
Le 13/06/2019 à 14:13, Horia Geanta a écrit :
On 6/11/2019 5:39 PM, Christophe Leroy wrote:
Next patc
Le 13/06/2019 à 14:48, Christophe Leroy a écrit :
Moves it into talitos.h so that it can be used
from any place in talitos.c
This will be required for next
patch ("crypto: talitos - fix hash on SEC1")
Signed-off-by: Christophe Leroy
Cc: sta...@vger.kernel.org
---
drivers/crypto/talito
On Thu, Jun 13, 2019 at 02:28:51PM +0200, Christophe Leroy wrote:
>
>
> Le 13/06/2019 à 14:21, Horia Geanta a écrit :
> > On 6/11/2019 5:39 PM, Christophe Leroy wrote:
> > > icv_ool is not used anymore, drop it.
> > >
> > > Fixes: 9cc87bc3613b ("crypto: talitos - fix AEAD processing")
> > I can'
39 matches
Mail list logo
