Re: [PATCH v3 0/7] crypto: aes - allow generic AES to be omitted

On Tue, Jul 18, 2017 at 07:32:41AM +0100, Ard Biesheuvel wrote: > > Because it is slower, and how much slower is architecture dependent > (if your arch has slow multiplication, aes-ti decryption will be dog > slow compared to aes-generic) Right, but does anybody actually care? My guess is that on

[RFC PATCH v12 4/4] LRNG - enable compile

Add LRNG compilation support. CC: Greg Kroah-Hartman CC: Arnd Bergmann CC: Jason A. Donenfeld Signed-off-by: Stephan Mueller --- drivers/char/Kconfig | 10 ++ drivers/char/Makefile | 10 +- 2

[RFC PATCH v12 2/4] random: conditionally compile code depending on LRNG

When selecting the LRNG for compilation, disable add_disk_randomness and its supporting function. CC: Greg Kroah-Hartman CC: Arnd Bergmann CC: Jason A. Donenfeld Signed-off-by: Stephan Mueller ---

Re: [RFC PATCH v12 2/4] random: conditionally compile code depending on LRNG

Am Dienstag, 18. Juli 2017, 10:13:55 CEST schrieb Arnd Bergmann: Hi Arnd, > On Tue, Jul 18, 2017 at 9:58 AM, Stephan Müller wrote: > > When selecting the LRNG for compilation, disable add_disk_randomness and > > its supporting function. > > > > CC: Greg Kroah-Hartman

Re: [PATCH 2/2] crypto/algapi - make crypto_xor() take separate dst and src arguments

On 18 July 2017 at 09:39, Herbert Xu wrote: > On Mon, Jul 10, 2017 at 02:45:48PM +0100, Ard Biesheuvel wrote: >> There are quite a number of occurrences in the kernel of the pattern >> >> if (dst != src) >> memcpy(dst, src, walk.total %

Re: [RFC PATCH v12 2/4] random: conditionally compile code depending on LRNG

Am Dienstag, 18. Juli 2017, 10:47:00 CEST schrieb Arnd Bergmann: Hi Arnd, > On Tue, Jul 18, 2017 at 10:37 AM, Stephan Müller wrote: > > Am Dienstag, 18. Juli 2017, 10:13:55 CEST schrieb Arnd Bergmann: > >> On Tue, Jul 18, 2017 at 9:58 AM, Stephan Müller

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

On Tue, Jul 18, 2017 at 10:45:12AM +0200, Stephan Müller wrote: > Am Dienstag, 18. Juli 2017, 10:32:10 CEST schrieb Greg Kroah-Hartman: > > Hi Greg, > > > external references do not last as long as the kernel change log does :( > > What would be the best way to cite a 50+ page document? I got a

Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

On Tue, Jul 18, 2017 at 11:10 AM, Stephan Müller wrote: > Am Dienstag, 18. Juli 2017, 11:02:02 CEST schrieb Arnd Bergmann: > > Hi Arnd, >> >> I can see why the jitterentropy implementation avoids using kernel headers, >> the problem now is that part of it gets moved into a

Re: [RFC PATCH v12 2/4] random: conditionally compile code depending on LRNG

On Tue, Jul 18, 2017 at 9:58 AM, Stephan Müller wrote: > When selecting the LRNG for compilation, disable add_disk_randomness and > its supporting function. > > CC: Greg Kroah-Hartman > CC: Arnd Bergmann > CC: Jason A. Donenfeld

Re: [PATCH v3 0/7] crypto: aes - allow generic AES to be omitted

On 18 July 2017 at 09:30, Herbert Xu wrote: > On Tue, Jul 18, 2017 at 08:57:28AM +0100, Ard Biesheuvel wrote: >> >> So if you care about security and/or the cache/memory footprint more >> than about speed, you can disable the table based implementations that >> exist

Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

On Tue, Jul 18, 2017 at 10:40:07AM +0200, Stephan Müller wrote: > Am Dienstag, 18. Juli 2017, 10:30:14 CEST schrieb Greg Kroah-Hartman: > > Hi Greg, > > > > +typedef unsigned long long __u64; > > > +typedef long long __s64; > > > > types.h already has these defines, don't

Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

Am Dienstag, 18. Juli 2017, 11:16:10 CEST schrieb Arnd Bergmann: Hi Arnd, > I guess ideally you just move the inner half of lrng_get_jent(), > i.e. everything inside of the spinlock, plus the buffer, into that file. > That should keep the low-level side separate from the caller. Yes, I concur.

Re: [PATCH v3 0/7] crypto: aes - allow generic AES to be omitted

On 18 July 2017 at 08:18, Herbert Xu wrote: > On Tue, Jul 18, 2017 at 07:32:41AM +0100, Ard Biesheuvel wrote: >> >> Because it is slower, and how much slower is architecture dependent >> (if your arch has slow multiplication, aes-ti decryption will be dog >> slow

[RFC PATCH v12 3/4] Linux Random Number Generator

The LRNG with the following properties: * noise source: interrupts timing with fast boot time seeding * lockless LFSR to collect raw entropy * use of standalone ChaCha20 based RNG with the option to use a different DRNG selectable at compile time * "atomic" seeding of secondary DRBG to

[RFC PATCH v12 0/4] /dev/random - a new approach

Hi, after distributing patches for the Linux-RNG - a new approach for the last half year, I would like to submit this RFC for inclusion into the kernel. The following patch set provides a different approach to /dev/random which I call Linux Random Number Generator (LRNG) to collect entropy

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

On Tue, Jul 18, 2017 at 09:59:09AM +0200, Stephan Müller wrote: > The LRNG with the following properties: > > * noise source: interrupts timing with fast boot time seeding > > * lockless LFSR to collect raw entropy > > * use of standalone ChaCha20 based RNG with the option to use a >

Re: [PATCH 2/2] crypto/algapi - make crypto_xor() take separate dst and src arguments

On Mon, Jul 10, 2017 at 02:45:48PM +0100, Ard Biesheuvel wrote: > There are quite a number of occurrences in the kernel of the pattern > > if (dst != src) > memcpy(dst, src, walk.total % AES_BLOCK_SIZE); > crypto_xor(dst, final, walk.total % AES_BLOCK_SIZE); > > or > >

Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

Am Dienstag, 18. Juli 2017, 10:30:14 CEST schrieb Greg Kroah-Hartman: Hi Greg, > > +typedefunsigned long long __u64; > > +typedeflong long __s64; > > types.h already has these defines, don't re-typedef them again... The issue is that the C code is compiled without

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

Am Dienstag, 18. Juli 2017, 10:32:10 CEST schrieb Greg Kroah-Hartman: Hi Greg, > external references do not last as long as the kernel change log does :( What would be the best way to cite a 50+ page document? I got a suggestion to include the ASCII version of the document into Documentation/

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

On Tue, Jul 18, 2017 at 10:45:12AM +0200, Stephan Müller wrote: > Am Dienstag, 18. Juli 2017, 10:32:10 CEST schrieb Greg Kroah-Hartman: > > Hi Greg, > > > external references do not last as long as the kernel change log does :( > > What would be the best way to cite a 50+ page document? I got a

Re: [RFC PATCH v12 4/4] LRNG - enable compile

On Tue, Jul 18, 2017 at 9:59 AM, Stephan Müller wrote: > Add LRNG compilation support. > > diff --git a/drivers/char/Makefile b/drivers/char/Makefile > index 53e3372..87e06ec 100644 > --- a/drivers/char/Makefile > +++ b/drivers/char/Makefile > @@ -2,7 +2,15 @@ > # Makefile

Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

Am Dienstag, 18. Juli 2017, 10:49:59 CEST schrieb Greg Kroah-Hartman: Hi Greg, > > > This issue was discussed during the inclusion of the Jitter RNG C code > > into > > the kernel. > > Ok, that was then, this is now, why not change it now? How does > including types.h change anything? At the

Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

On Tue, Jul 18, 2017 at 10:49 AM, Greg Kroah-Hartman wrote: > On Tue, Jul 18, 2017 at 10:40:07AM +0200, Stephan Müller wrote: >> Am Dienstag, 18. Juli 2017, 10:30:14 CEST schrieb Greg Kroah-Hartman: >> >> Hi Greg, >> >> > > +typedef unsigned long long __u64; >> >

Re: [RFC PATCH v12 2/4] random: conditionally compile code depending on LRNG

On Tue, Jul 18, 2017 at 10:37 AM, Stephan Müller wrote: > Am Dienstag, 18. Juli 2017, 10:13:55 CEST schrieb Arnd Bergmann: >> On Tue, Jul 18, 2017 at 9:58 AM, Stephan Müller wrote: >> > When selecting the LRNG for compilation, disable add_disk_randomness

Re: [RFC PATCH v12 4/4] LRNG - enable compile

Am Dienstag, 18. Juli 2017, 10:51:41 CEST schrieb Arnd Bergmann: Hi Arnd, > On Tue, Jul 18, 2017 at 9:59 AM, Stephan Müller wrote: > > Add LRNG compilation support. > > > > diff --git a/drivers/char/Makefile b/drivers/char/Makefile > > index 53e3372..87e06ec 100644 > > ---

[RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

To support the LRNG operation which allocates the Jitter RNG separately from the kernel crypto API, extract the relevant information into a separate header file. CC: Greg Kroah-Hartman CC: Arnd Bergmann CC: Jason A. Donenfeld

Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

On Tue, Jul 18, 2017 at 09:57:55AM +0200, Stephan Müller wrote: > --- /dev/null > +++ b/include/crypto/jitterentropy.h > @@ -0,0 +1,80 @@ > +/* > + * Copyright (C) 2017, Stephan Mueller > + * > + * Redistribution and use in source and binary forms, with or without > + *

Re: [PATCH v3 0/7] crypto: aes - allow generic AES to be omitted

On Tue, Jul 18, 2017 at 08:57:28AM +0100, Ard Biesheuvel wrote: > > So if you care about security and/or the cache/memory footprint more > than about speed, you can disable the table based implementations that > exist for i586, x86, ARM and arm64 (all of which have faster and time > invariant

Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

Am Dienstag, 18. Juli 2017, 11:02:02 CEST schrieb Arnd Bergmann: Hi Arnd, > > I can see why the jitterentropy implementation avoids using kernel headers, > the problem now is that part of it gets moved into a new header, and that > already violates the original principle. > > From my reading of

[PATCH v2 2/2] crypto/algapi - make crypto_xor() take separate dst and src arguments

There are quite a number of occurrences in the kernel of the pattern if (dst != src) memcpy(dst, src, walk.total % AES_BLOCK_SIZE); crypto_xor(dst, final, walk.total % AES_BLOCK_SIZE); or crypto_xor(keystream, src, nbytes); memcpy(dst, keystream, nbytes); where crypto_xor() is

[PATCH v2 1/2] crypto/algapi - use separate dst and src operands for __crypto_xor()

In preparation of introducing crypto_xor_cpy(), which will use separate operands for input and output, modify the __crypto_xor() implementation, which it will share with the existing crypto_xor(), which provides the actual functionality when not using the inline version. Signed-off-by: Ard

[PATCH v2 0/2] crypto/algapi - refactor crypto_xor() to avoid memcpy()s

>From 2/2: """ There are quite a number of occurrences in the kernel of the pattern if (dst != src) memcpy(dst, src, walk.total % AES_BLOCK_SIZE); crypto_xor(dst, final, walk.total % AES_BLOCK_SIZE); or crypto_xor(keystream, src, nbytes); memcpy(dst, keystream,

Re: [PATCH V2 6/6] crypto/nx: Add P9 NX support for 842 compression engine

On Mon, Jul 17, 2017 at 04:50:38PM -0700, Haren Myneni wrote: > > This patch adds P9 NX support for 842 compression engine. Virtual > Accelerator Switchboard (VAS) is used to access 842 engine on P9. > > For each NX engine per chip, setup receive window using > vas_rx_win_open() which configures

Re: [PATCH V2 0/6] Enable NX 842 compression engine on Power9

On Mon, 17 Jul 2017 16:43:19 -0700 Haren Myneni wrote: > [PATCH V2 0/6] Enable NX 842 compression engine on Power9 > > P9 introduces Virtual Accelerator Switchboard (VAS) to communicate > with NX 842 engine. icswx function is used to access NX before. > On powerNV

Re: [PATCH v3 0/7] crypto: aes - allow generic AES to be omitted

On 18 July 2017 at 06:25, Herbert Xu wrote: > On Tue, Jun 20, 2017 at 11:28:53AM +0200, Ard Biesheuvel wrote: >> The generic AES driver uses 16 lookup tables of 1 KB each, and has >> encryption and decryption routines that are fully unrolled. Given how >> the

Re: [PATCH] crypto: ccp - Fix XTS-AES support on a version 5 CCP

Am Montag, 17. Juli 2017, 22:08:27 CEST schrieb Gary R Hook: Hi Gary, > Version 5 CCPs have differing requirements for XTS-AES: key components > are stored in a 512-bit vector. The context must be little-endian > justified. AES-256 is supported now, so propagate the cipher size to > the command

[PATCH v4 3/8] crypto: aes - retire table based generic AES in favor of fixed time driver

Rework the fixed time AES code so that it can fulfil dependencies of other drivers on the shared AES key expansion routines. This way, we can remove the table based generic AES code altogether, and use the much smaller and time invariant fixed time driver as the global default for systems that

[PATCH v4 5/8] crypto: arm/aes - avoid expanded lookup tables in the final round

For the final round, avoid the expanded and padded lookup tables exported by the generic AES driver. Instead, for encryption, we can perform byte loads from the same table we used for the inner rounds, which will still be hot in the caches. For decryption, use the inverse AES Sbox exported by the

[PATCH v4 7/8] crypto: arm64/aes-neon - reuse Sboxes from AES core module

The newly introduced AES core module exposes its Sboxes for the benefit of the fixed time AES driver. Since the arm64 NEON based implementation already depends on the same core module for its key expansion routines, let's use its Sboxes as well, and remove the local copy. Signed-off-by: Ard

[PATCH v4 4/8] crypto: x86/aes-ni - switch to generic fallback

The time invariant AES-NI implementation is SIMD based, and so it needs a fallback in case the code is called from a context where SIMD is not allowed. On x86, this is really only when executing in the context of an interrupt taken while in kernel mode, since SIMD is allowed in all other cases.

[PATCH v4 2/8] crypto - aes: use dedicated lookup tables for table based asm routines

Instead of linking against the table based AES generic C code to reuse the lookup tables, add an assembler file that defines a couple of macros that instantiate the tables in-place. This allows us to replace AES in a subsequent patch. Signed-off-by: Ard Biesheuvel ---

[PATCH v4 6/8] crypto: arm64/aes - avoid expanded lookup tables in the final round

For the final round, avoid the expanded and padded lookup tables exported by the generic AES driver. Instead, for encryption, we can perform byte loads from the same table we used for the inner rounds, which will still be hot in the caches. For decryption, use the inverse AES Sbox exported by the

[PATCH v4 0/8] crypto: aes - retire table based generic AES

The generic AES driver uses 16 lookup tables of 1 KB each, and has encryption and decryption routines that are fully unrolled. Given how the dependencies between this code and other drivers are declared in Kconfig files, this code is always pulled into the core kernel, even if it is usually

[PATCH v4 1/8] drivers/crypto/Kconfig: drop bogus CRYPTO_AES dependencies

In preparation of fine tuning the dependency relations between the accelerated AES drivers and the core support code, let's remove the dependency declarations that are false. None of these modules have link time dependencies on the generic AES code, nor do they declare any AES algos with

[PATCH v4 8/8] crypto: aes - add meaningful help text to the various AES drivers

Remove the duplicated boilerplate help text and add a bit of explanation about the nature of the various AES implementations that exist for various architectures. In particular, highlight the time variant nature of some implementations, and the fact that they can be omitted if required.

Re: [PATCH v2 2/2] crypto: arm64/ghash - add NEON accelerated fallback for 64-bit PMULL

On 18 July 2017 at 10:49, Herbert Xu wrote: > On Wed, Jul 05, 2017 at 12:43:19AM +0100, Ard Biesheuvel wrote: >> Implement a NEON fallback for systems that do support NEON but have >> no support for the optional 64x64->128 polynomial multiplication >> instruction that

[PATCH v2 2/3] staging: ccree: Convert to devm_ioremap_resource for map, unmap

source() releases and unmaps mem region on driver detach. (d) adjust log messages accordingly and remove any blank lines. Signed-off-by: Suniel Mahesh <suni...@techveda.org> --- Changes for v2: - format specifiers changed in log messages. - Rebased on top of next-20170718. --- Note: - Patch was test

[PATCH v2 3/3] staging: ccree: Use platform_get_irq and devm_request_irq

top of next-20170718. --- Note: - Patch was tested and built(ARCH=arm) on next-20170718. No build issues reported, however it was not tested on real hardware. --- drivers/staging/ccree/ssi_driver.c | 30 +- drivers/staging/ccree/ssi_driver.h | 3 +-- 2 files changed, 1

Re: [PATCH] crypto: inside-secure - do not parse the dma mask from dt

On Fri, Jun 23, 2017 at 04:05:25PM +0200, Antoine Tenart wrote: > Remove the dma mask parsing from dt as this should not be encoded into > the engine device tree node. Keep the fallback value for now, which > should work for the boards already supported upstream. > > Signed-off-by: Antoine Tenart

Re: [PATCH][crypto-next] crypto: cavium/nitrox - Change in firmware path.

Srikanth Jampala wrote: > Moved the firmware to "cavium" subdirectory as suggested by > Kyle McMartin. > > Signed-off-by: Srikanth Jampala Patch applied. Thanks. -- Email: Herbert Xu Home Page:

Re: [PATCH v1] crypto: brcm - Fix SHA3-512 algorithm failure

Raveendra Padasalagi wrote: > In Broadcom SPU driver, due to missing break statement > in spu2_hash_xlate() while mapping SPU2 equivalent > SHA3-512 value, -EINVAL is chosen and hence leading to > failure of SHA3-512 algorithm. This patch fixes the same. > >

Re: [PATCH] crypto: ccp - Change all references to use the JOB ID macro

On Tue, Jun 27, 2017 at 08:58:16AM -0500, Gary R Hook wrote: > Use the CCP_NEW_JOBID() macro when assigning an identifier > > Signed-off-by: Gary R Hook Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/

Re: [PATCH] crypto: sahara : make of_device_ids const.

On Tue, Jun 27, 2017 at 05:11:23PM +0530, Arvind Yadav wrote: > of_device_ids are not supposed to change at runtime. All functions > working with of_device_ids provided by work with const > of_device_ids. So mark the non-const structs as const. > > File size before: >text data

Re: [PATCH] crypto: ccp - Fix some line spacing

On Tue, Jun 27, 2017 at 08:58:04AM -0500, Gary R Hook wrote: > Add/remove blank lines as appropriate. > > Signed-off-by: Gary R Hook Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key:

Re: [PATCH] crypto: qat: fix spelling mistake: "runing" -> "running"

On Mon, Jun 26, 2017 at 08:41:03PM +0100, Colin King wrote: > From: Colin Ian King > > trivial fix to spelling mistake in dev_info message > > Signed-off-by: Colin Ian King Patch applied. Thanks. -- Email: Herbert Xu

Re: [PATCH] crypto: virtio - Refacotor virtio_crypto driver for new virito crypto services

On Fri, Jun 23, 2017 at 11:31:19AM -0400, Xin Zeng wrote: > In current virtio crypto device driver, some common data structures and > implementations that should be used by other virtio crypto algorithms > (e.g. asymmetric crypto algorithms) introduce symmetric crypto algorithms > specific

Re: [PATCH] crypto: mxc-scc: fix error code in mxc_scc_probe()

On Fri, Jun 30, 2017 at 01:42:12AM -0500, Gustavo A. R. Silva wrote: > Print and propagate the return value of platform_get_irq on failure. > > Signed-off-by: Gustavo A. R. Silva Patch applied. Thanks. -- Email: Herbert Xu Home Page:

Re: [PATCH] crypto: ccp-platform: print error message on platform_get_irq failure

On Fri, Jun 30, 2017 at 12:59:52AM -0500, Gustavo A. R. Silva wrote: > Print error message on platform_get_irq failure before return. > > Signed-off-by: Gustavo A. R. Silva Patch applied. Thanks. -- Email: Herbert Xu Home Page:

Re: [PATCH] crypto: mediatek: fix error return code in mtk_crypto_probe()

On Fri, Jun 30, 2017 at 01:24:54AM -0500, Gustavo A. R. Silva wrote: > Propagate the return value of platform_get_irq on failure. > > Signed-off-by: Gustavo A. R. Silva Patch applied. Thanks. -- Email: Herbert Xu Home Page:

Re: [PATCH v2 0/2] crypto hwrng consider quality value, remember user choice

On Tue, Jul 11, 2017 at 09:36:21AM +0200, Harald Freudenberger wrote: > The hwrng core implementation currently doesn't consider the > quality field of the struct hwrng. So the first registered rng > is the winner and further rng sources even with much better > quality are ignored. > > The

Re: [PATCH] crypto: brcm - remove BCM_PDC_MBOX dependency in Kconfig

On Tue, Jul 11, 2017 at 03:50:06PM +0530, Raveendra Padasalagi wrote: > SPU driver is dependent on generic MAILBOX API's to > communicate with underlying DMA engine driver. > > So this patch removes BCM_PDC_MBOX "depends on" for SPU driver > in Kconfig and adds MAILBOX as dependent module. > >

Re: [PATCH v3] crypto: ccp - Provide an error path for debugfs setup failure

On Wed, Jun 28, 2017 at 11:56:47AM -0500, Gary R Hook wrote: > Changes since v2: > - On failure remove only the DebugFS heirarchy for this device > Changes since v1: > - Remove unneeded local variable > > Signed-off-by: Gary R Hook Patch applied. Thanks. -- Email:

Re: [PATCH v4 0/5] Introduce AMD Secure Processor device

On Thu, Jul 06, 2017 at 09:59:12AM -0500, Brijesh Singh wrote: > CCP device (drivers/crypto/ccp/ccp.ko) is part of AMD Secure Processor, > which is not dedicated solely to crypto. The AMD Secure Processor includes > CCP and PSP (Platform Secure Processor) devices. > > This patch series adds a

Re: [PATCH 0/3] crypto: introduce Microchip / Atmel ECC driver

On Wed, Jul 05, 2017 at 01:07:57PM +0300, Tudor Ambarus wrote: > Hi, > > This patch set introduces Microchip / Atmel ECC driver. > > The first patch adds some helpers that will be used by fallbacks to > kpp software implementations. > > The second patch adds ECDH support for the ATECC508A (I2C)

Re: [PATCH v5] crypto: sun4i-ss: support the Security System PRNG

On Mon, Jul 03, 2017 at 08:48:48PM +0200, Corentin Labbe wrote: > The Security System has a PRNG, this patch adds support for it via > crypto_rng. > > Signed-off-by: Corentin Labbe Patch applied. Thanks. -- Email: Herbert Xu Home Page:

Re: [PATCH v2 2/2] crypto: arm64/ghash - add NEON accelerated fallback for 64-bit PMULL

On Wed, Jul 05, 2017 at 12:43:19AM +0100, Ard Biesheuvel wrote: > Implement a NEON fallback for systems that do support NEON but have > no support for the optional 64x64->128 polynomial multiplication > instruction that is part of the ARMv8 Crypto Extensions. It is based > on the paper "Fast

Re: [PATCH] Documentation/bindings: crypto: remove the dma-mask property

On Fri, Jun 23, 2017 at 04:52:18PM +0200, Antoine Tenart wrote: > The dma-mask property is broken and was removed in the device trees > having a safexcel-eip197 node and in the safexcel cryptographic > driver. This patch removes the dma-mask property from the documentation > as well. > >

Re: [PATCH] crypto: omap-des: fix error return code in omap_des_probe()

On Fri, Jun 30, 2017 at 02:07:04AM -0500, Gustavo A. R. Silva wrote: > Print and propagate the return value of platform_get_irq on failure. > > Signed-off-by: Gustavo A. R. Silva Patch applied. Thanks. -- Email: Herbert Xu Home Page:

Re: [PATCH] crypto: omap-aes: fix error return code in omap_aes_probe()

On Fri, Jun 30, 2017 at 02:00:54AM -0500, Gustavo A. R. Silva wrote: > Propagate the return value of platform_get_irq on failure. > > Signed-off-by: Gustavo A. R. Silva Patch applied. Thanks. -- Email: Herbert Xu Home Page:

Re: [PATCH] crypto: brcm: add NULL check on of_match_device() return value

On Fri, Jul 07, 2017 at 01:33:33AM -0500, Gustavo A. R. Silva wrote: > Check return value from call to of_match_device() > in order to prevent a NULL pointer dereference. > > In case of NULL print error message and return -ENODEV > > Signed-off-by: Gustavo A. R. Silva

Re: [PATCH v2 00/13] crypto: caam - fixes, clean-up

On Mon, Jul 10, 2017 at 08:40:26AM +0300, Horia Geantă wrote: > [ > Change log: > v1 -> v2 > -patch 05/13 - add missing check in ablkcipher_giv_edesc_alloc(), > to make sure number of reserved S/G entries is not overflown > -patch 12/13 - fix author - replace my Freescale address with >

Re: [PATCH] drivers: crypto: geode-aes: fixed coding style warnings and error

On Thu, Jul 06, 2017 at 02:44:56PM -0400, Chris Gorman wrote: > fixed WARNING: Block comments should align the * on each line > fixed WARNINGs: Missing a blank line after declarations > fixed ERROR: space prohibited before that ',' (ctx:WxE) > > Signed-off-by: Chris Gorman

Re: [PATCH] crypto: mxs-dcp: print error message on platform_get_irq failure

On Fri, Jun 30, 2017 at 01:54:16AM -0500, Gustavo A. R. Silva wrote: > Print error message on platform_get_irq failure before return. > > Signed-off-by: Gustavo A. R. Silva Patch applied. Thanks. -- Email: Herbert Xu Home Page:

[PATCH v2 1/3] staging: ccree: Replace kzalloc with devm_kzalloc

zalloc() is automatically freed on driver detach, otherwise it leads to a double free. (c) remove unnecessary blank lines. Signed-off-by: Suniel Mahesh <suni...@techveda.org> --- Changes for v2: - Changes done as suggested by Greg-KH. - Rebased on top of next-20170718. --- Note: - Patch was tested an

Re: [PATCH v2 2/2] crypto: arm64/ghash - add NEON accelerated fallback for 64-bit PMULL

On 18 July 2017 at 10:56, Ard Biesheuvel wrote: > On 18 July 2017 at 10:49, Herbert Xu wrote: >> On Wed, Jul 05, 2017 at 12:43:19AM +0100, Ard Biesheuvel wrote: >>> Implement a NEON fallback for systems that do support NEON but have >>> no

Re: [PATCH 1/2] crypto: inside-secure - fix invalidation check in hmac_sha1_setkey

Hi, On Mon, Jul 17, 2017 at 11:45:19AM +0200, Antoine Tenart wrote: > The safexcel_hmac_sha1_setkey function checks if an invalidation command > should be issued, i.e. when the context ipad/opad change. This checks is > done after filling the ipad/opad which and it can't be true. The patch >

Re: [v3 RFC PATCH 2/2] crypto: ecc: use caller's GFP flags

Hi, Herbert, On 07/18/2017 08:52 AM, Herbert Xu wrote: On Wed, Jun 28, 2017 at 05:08:36PM +0300, Tudor Ambarus wrote: Using GFP_KERNEL when allocating data and implicitly assuming that we can sleep was wrong because the caller could be in atomic context. Let the caller decide whether sleeping

Re: [v3 RFC PATCH 1/2] crypto: ecdh: fix concurrency on ecdh_ctx

Hi, Herbert, On 07/18/2017 08:50 AM, Herbert Xu wrote: On Wed, Jun 28, 2017 at 05:08:35PM +0300, Tudor Ambarus wrote: ecdh_ctx contained static allocated data for the shared secret, for the public and private key. When talking about shared secret and public key, they were doomed to

[PATCH 3/4] arm64: dts: freescale: ls208xa: add crypto node

LS208xA has a SEC v5.1 security engine. Signed-off-by: Horia Geantă --- arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 41 ++ 1 file changed, 41 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi

[PATCH 1/4] crypto: caam/jr - add support for DPAA2 parts

Add support for using the caam/jr backend on DPAA2-based SoCs. These have some particularities we have to account for: -HW S/G format is different -Management Complex (MC) firmware initializes / manages (partially) the CAAM block: MCFGR, QI enablement in QICTL, RNG Signed-off-by: Horia Geantă

[PATCH 0/4] crypto: caam - add Job Ring support for DPAA2 parts

This patch set adds support for CAAM's legacy Job Ring backend / interface on platforms having DPAA2 (Datapath Acceleration Architecture v2), like LS1088A or LS2088A. I would like to get the DT patches through the crypto list (to make sure they don't end up merged before driver support). Thanks,

[PATCH 2/4] arm64: dts: freescale: ls208xa: share aliases node

aliases node is identical for all boards, thus move it to the common file ls208xa.dtsi. Signed-off-by: Horia Geantă --- arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts | 5 - arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts | 5 -

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

Am Dienstag, 18. Juli 2017, 10:52:12 CEST schrieb Greg Kroah-Hartman: Hi Greg, > > > I have stated the core concerns I have with random.c in [1]. To remedy > > these core concerns, major changes to random.c are needed. With the past > > experience, I would doubt that I get the changes into

[PATCH 4/4] arm64: dts: freescale: ls1088a: add crypto node

LS1088A has a SEC v5.3 security engine. Signed-off-by: Horia Geantă --- arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 43 ++ 1 file changed, 43 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi

[PATCH v4 2/5] iomap: introduce io{read|write}64_{lo_hi|hi_lo}

In order to provide non-atomic functions for io{read|write}64 that will use readq and writeq when appropriate. We define a number of variants of these functions in the generic iomap that will do non-atomic operations on pio but atomic operations on mmio. These functions are only defined if readq

[PATCH v4 1/5] powerpc: io.h: move iomap.h include so that it can use readq/writeq defs

Subsequent patches in this series makes use of the readq and writeq defines in iomap.h. However, as is, they get missed on the powerpc platform seeing the include comes before the define. This patch moves the include down to fix this. Signed-off-by: Logan Gunthorpe Cc:

[PATCH v4 3/5] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros

This patch adds generic io{read|write}64[be]{_lo_hi|_hi_lo} macros if they are not already defined by the architecture. (As they are provided by the generic iomap library). The patch also points io{read|write}64[be] to the variant specified by the header name. This is because new drivers are

[PATCH v4 0/5] make io{read|write}64 globally usable

This is version four of my patchset to enable drivers to use io{read|write}64 on all arches. Changes since v3: - I noticed powerpc didn't use the appropriate functions seeing readq/writeq were not defined when iomap.h was included. Thus I've included a patch to adjust this - Fixed some mistakes

[PATCH v4 4/5] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

Now that ioread64 and iowrite64 are available in io-64-nonatomic, we can remove the hack at the top of ntb_hw_intel.c and replace it with an include. Signed-off-by: Logan Gunthorpe Cc: Jon Mason Cc: Allen Hubbe Acked-by: Dave Jiang

[PATCH v4 5/5] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

From: Horia Geantă We can now make use of the io-64-nonatomic-lo-hi header to always provide 64 bit IO operations. So this patch cleans up the extra CONFIG_64BIT ifdefs. To be consistent with CAAM engine HW spec: in case of 64-bit registers, irrespective of device

Re: [PATCH] crypto: ccp - Fix XTS-AES support on a version 5 CCP

On 07/18/2017 01:28 AM, Stephan Müller wrote: Am Montag, 17. Juli 2017, 22:08:27 CEST schrieb Gary R Hook: Hi Gary, Version 5 CCPs have differing requirements for XTS-AES: key components are stored in a 512-bit vector. The context must be little-endian justified. AES-256 is supported now, so

RE: [PATCH v4 4/5] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

From: Logan Gunthorpe > Now that ioread64 and iowrite64 are available in io-64-nonatomic, > we can remove the hack at the top of ntb_hw_intel.c and replace it > with an include. > > Signed-off-by: Logan Gunthorpe > Cc: Jon Mason > Cc: Allen Hubbe

Re: [PATCH V2 0/6] Enable NX 842 compression engine on Power9

Nicholas Piggin [nicholas.pig...@gmail.com] wrote: > On Mon, 17 Jul 2017 16:43:19 -0700 > Haren Myneni wrote: > > > [PATCH V2 0/6] Enable NX 842 compression engine on Power9 > > This patchset depends on VAS kernel changes: > >

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

On Tue, Jul 18, 2017 at 04:37:11PM +0200, Stephan Müller wrote: > > > > > I have stated the core concerns I have with random.c in [1]. To remedy > > > these core concerns, major changes to random.c are needed. With the past > > > experience, I would doubt that I get the changes into random.c. > >

Re: [PATCH V2 0/6] Enable NX 842 compression engine on Power9

On 07/18/2017 11:06 AM, Sukadev Bhattiprolu wrote: > Nicholas Piggin [nicholas.pig...@gmail.com] wrote: >> On Mon, 17 Jul 2017 16:43:19 -0700 >> Haren Myneni wrote: >> >>> [PATCH V2 0/6] Enable NX 842 compression engine on Power9 >>> This patchset depends on VAS kernel

[PATCH 5/6] staging: ccree: Fix alignment issues in ssi_ivgen.c

Fixes checkpatch.pl alignment warnings. Signed-off-by: Simon Sandström --- drivers/staging/ccree/ssi_ivgen.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/ccree/ssi_ivgen.c b/drivers/staging/ccree/ssi_ivgen.c index

[PATCH 2/6] staging: ccree: Fix alignment issues in ssi_hash.c

Fixes checkpatch.pl alignment warnings. Signed-off-by: Simon Sandström --- drivers/staging/ccree/ssi_hash.c | 105 +-- 1 file changed, 56 insertions(+), 49 deletions(-) diff --git a/drivers/staging/ccree/ssi_hash.c

[PATCH 6/6] staging: ccree: Fix alignment issues in ssi_request_mgr.c

Fixes checkpatch.pl alignment warnings. Signed-off-by: Simon Sandström --- drivers/staging/ccree/ssi_request_mgr.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/staging/ccree/ssi_request_mgr.c b/drivers/staging/ccree/ssi_request_mgr.c index

[PATCH 4/6] staging: ccree: Fix alignment issues in ssi_cipher.c

Fixes checkpatch.pl alignment warnings. Signed-off-by: Simon Sandström --- drivers/staging/ccree/ssi_cipher.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/ccree/ssi_cipher.c b/drivers/staging/ccree/ssi_cipher.c index

[PATCH 1/6] staging: ccree: Fix alignment issues in ssi_aead.c

Fixes checkpatch.pl alignment warnings. Signed-off-by: Simon Sandström --- drivers/staging/ccree/ssi_aead.c | 47 +--- 1 file changed, 25 insertions(+), 22 deletions(-) diff --git a/drivers/staging/ccree/ssi_aead.c

  1   2   >