Re: [PATCH 01/10] staging: ccree: remove inline qualifiers

On Mon, Dec 4, 2017 at 11:36 AM, Dan Carpenter wrote: > On Sun, Dec 03, 2017 at 01:58:12PM +, Gilad Ben-Yossef wrote: >> The ccree drivers was marking a lot of big functions in C file as >> static inline for no good reason. Remove the inline qualifier from >> any but

Re: [PATCH] staging: ccree: ssi_aead: fixed all coding style warnings.

Hi Sunil, On Thu, Dec 7, 2017 at 12:08 AM, SUNIL KALLUR RAMEGOWDA wrote: > My first kernel patch, fixed warnings. > Congratulations and may there be many more! :-) Please note that in addition to what Greg's patch-bot already mentioned I'm pretty sure you are looking at

Re: [PATCH] staging: ccree: ssi_aead: fixed all coding style warnings.

On Wed, Dec 06, 2017 at 11:08:09PM +0100, SUNIL KALLUR RAMEGOWDA wrote: > My first kernel patch, fixed warnings. > > Signed-off-by: SUNIL KALLUR RAMEGOWDA > --- > drivers/staging/ccree/ssi_aead.c | 179 > +++ > 1 file changed, 123

[PATCH] staging: ccree: ssi_aead: fixed all coding style warnings.

My first kernel patch, fixed warnings. Signed-off-by: SUNIL KALLUR RAMEGOWDA --- drivers/staging/ccree/ssi_aead.c | 179 +++ 1 file changed, 123 insertions(+), 56 deletions(-) diff --git a/drivers/staging/ccree/ssi_aead.c

Re: [Part2 PATCH v9 12/38] crypto: ccp: Add Platform Security Processor (PSP) device support

On Tue, Dec 5, 2017 at 2:04 AM, Brijesh Singh wrote: > The Platform Security Processor (PSP) is part of the AMD Secure > Processor (AMD-SP) functionality. The PSP is a dedicated processor > that provides support for key management commands in Secure Encrypted >

[PATCH v3 19/20] crypto: arm64/crct10dif-ce - yield NEON after every block of input

Avoid excessive scheduling delays under a preemptible kernel by yielding the NEON after every block of input. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/crct10dif-ce-core.S | 32 +--- 1 file changed, 28 insertions(+), 4 deletions(-) diff

[PATCH v3 20/20] DO NOT MERGE

Test code to force a kernel_neon_end+begin sequence at every yield point, and wipe the entire NEON state before resuming the algorithm. --- arch/arm64/include/asm/assembler.h | 33 1 file changed, 33 insertions(+) diff --git a/arch/arm64/include/asm/assembler.h

[PATCH v3 18/20] crypto: arm64/crc32-ce - yield NEON after every block of input

Avoid excessive scheduling delays under a preemptible kernel by yielding the NEON after every block of input. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/crc32-ce-core.S | 44 ++-- 1 file changed, 32 insertions(+), 12 deletions(-) diff --git

[PATCH v3 17/20] crypto: arm64/aes-ghash - yield NEON after every block of input

Avoid excessive scheduling delays under a preemptible kernel by yielding the NEON after every block of input. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/ghash-ce-core.S | 113 ++-- arch/arm64/crypto/ghash-ce-glue.c | 28 +++-- 2 files

[PATCH v3 13/20] crypto: arm64/sha2-ce - yield NEON after every block of input

Avoid excessive scheduling delays under a preemptible kernel by yielding the NEON after every block of input. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/sha2-ce-core.S | 37 ++-- 1 file changed, 26 insertions(+), 11 deletions(-) diff --git

[PATCH v3 11/20] arm64: assembler: add macros to conditionally yield the NEON under PREEMPT

Add support macros to conditionally yield the NEON (and thus the CPU) that may be called from the assembler code. In some cases, yielding the NEON involves saving and restoring a non trivial amount of context (especially in the CRC folding algorithms), and so the macro is split into three, and

[PATCH v3 12/20] crypto: arm64/sha1-ce - yield NEON after every block of input

Avoid excessive scheduling delays under a preemptible kernel by yielding the NEON after every block of input. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/sha1-ce-core.S | 42 ++-- 1 file changed, 29 insertions(+), 13 deletions(-) diff --git

[PATCH v3 15/20] crypto: arm64/aes-blk - yield NEON after every block of input

Avoid excessive scheduling delays under a preemptible kernel by yielding the NEON after every block of input. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/aes-ce.S| 15 +- arch/arm64/crypto/aes-modes.S | 331 2 files changed, 216

[PATCH v3 14/20] crypto: arm64/aes-ccm - yield NEON after every block of input

Avoid excessive scheduling delays under a preemptible kernel by yielding the NEON after every block of input. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/aes-ce-ccm-core.S | 150 +--- 1 file changed, 95 insertions(+), 55 deletions(-) diff

[PATCH v3 16/20] crypto: arm64/aes-bs - yield NEON after every block of input

Avoid excessive scheduling delays under a preemptible kernel by yielding the NEON after every block of input. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/aes-neonbs-core.S | 305 +++- 1 file changed, 170 insertions(+), 135 deletions(-) diff

[PATCH v3 10/20] arm64: assembler: add utility macros to push/pop stack frames

We are going to add code to all the NEON crypto routines that will turn them into non-leaf functions, so we need to manage the stack frames. To make this less tedious and error prone, add some macros that take the number of callee saved registers to preserve and the extra size to allocate in the

[PATCH v3 07/20] crypto: arm64/aes-blk - add 4 way interleave to CBC encrypt path

CBC encryption is strictly sequential, and so the current AES code simply processes the input one block at a time. However, we are about to add yield support, which adds a bit of overhead, and which we prefer to align with other modes in terms of granularity (i.e., it is better to have all

[PATCH v3 06/20] crypto: arm64/aes-blk - remove configurable interleave

The AES block mode implementation using Crypto Extensions or plain NEON was written before real hardware existed, and so its interleave factor was made build time configurable (as well as an option to instantiate all interleaved sequences inline rather than as subroutines) We ended up using

[PATCH v3 09/20] crypto: arm64/sha256-neon - play nice with CONFIG_PREEMPT kernels

Tweak the SHA256 update routines to invoke the SHA256 block transform block by block, to avoid excessive scheduling delays caused by the NEON algorithm running with preemption disabled. Also, remove a stale comment which no longer applies now that kernel mode NEON is actually disallowed in some

[PATCH v3 08/20] crypto: arm64/aes-blk - add 4 way interleave to CBC-MAC encrypt path

CBC MAC is strictly sequential, and so the current AES code simply processes the input one block at a time. However, we are about to add yield support, which adds a bit of overhead, and which we prefer to align with other modes in terms of granularity (i.e., it is better to have all routines yield

[PATCH v3 03/20] crypto: arm64/aes-blk - move kernel mode neon en/disable into loop

When kernel mode NEON was first introduced on arm64, the preserve and restore of the userland NEON state was completely unoptimized, and involved saving all registers on each call to kernel_neon_begin(), and restoring them on each call to kernel_neon_end(). For this reason, the NEON crypto code

[PATCH v3 00/20] crypto: arm64 - play nice with CONFIG_PREEMPT

This is the second followup 'crypto: arm64 - disable NEON across scatterwalk API calls' sent out last Friday. As reported by Sebastian, the way the arm64 NEON crypto code currently keeps kernel mode NEON enabled across calls into skcipher_walk_xxx() is causing problems with RT builds, given that

[PATCH v3 01/20] crypto: testmgr - add a new test case for CRC-T10DIF

In order to be able to test yield support under preempt, add a test vector for CRC-T10DIF that is long enough to take multiple iterations (and thus possible preemption between them) of the primary loop of the accelerated x86 and arm64 implementations. Signed-off-by: Ard Biesheuvel

[PATCH v3 04/20] crypto: arm64/aes-bs - move kernel mode neon en/disable into loop

When kernel mode NEON was first introduced on arm64, the preserve and restore of the userland NEON state was completely unoptimized, and involved saving all registers on each call to kernel_neon_begin(), and restoring them on each call to kernel_neon_end(). For this reason, the NEON crypto code

[PATCH v3 02/20] crypto: arm64/aes-ce-ccm - move kernel mode neon en/disable into loop

When kernel mode NEON was first introduced on arm64, the preserve and restore of the userland NEON state was completely unoptimized, and involved saving all registers on each call to kernel_neon_begin(), and restoring them on each call to kernel_neon_end(). For this reason, the NEON crypto code

[PATCH v3 05/20] crypto: arm64/chacha20 - move kernel mode neon en/disable into loop

When kernel mode NEON was first introduced on arm64, the preserve and restore of the userland NEON state was completely unoptimized, and involved saving all registers on each call to kernel_neon_begin(), and restoring them on each call to kernel_neon_end(). For this reason, the NEON crypto code

Re: [PATCH 1/3] crypto: exynos - Support Exynos5250+ SoCs

On Wed, 2017-12-06 at 15:05 +0100, Krzysztof Kozlowski wrote: > On Wed, Dec 6, 2017 at 2:42 PM, Łukasz Stelmach > wrote: > > It was <2017-12-05 wto 14:34>, when Krzysztof Kozlowski wrote: > > > On Tue, Dec 5, 2017 at 1:35 PM, Łukasz Stelmach > >

Re: [PATCH 1/3] crypto: exynos - Support Exynos5250+ SoCs

On Wed, Dec 6, 2017 at 3:53 PM, Łukasz Stelmach wrote: > It was <2017-12-06 śro 15:05>, when Krzysztof Kozlowski wrote: >> On Wed, Dec 6, 2017 at 2:42 PM, Łukasz Stelmach >> wrote: >>> It was <2017-12-05 wto 14:34>, when Krzysztof Kozlowski wrote:

Re: [PATCH 1/3] crypto: exynos - Support Exynos5250+ SoCs

It was <2017-12-06 śro 15:05>, when Krzysztof Kozlowski wrote: > On Wed, Dec 6, 2017 at 2:42 PM, Łukasz Stelmach > wrote: >> It was <2017-12-05 wto 14:34>, when Krzysztof Kozlowski wrote: >>> On Tue, Dec 5, 2017 at 1:35 PM, Łukasz Stelmach >>>

Re: [PATCH v2 11/19] arm64: assembler: add macro to conditionally yield the NEON under PREEMPT

On Wed, Dec 06, 2017 at 12:25:44PM +, Ard Biesheuvel wrote: > On 6 December 2017 at 12:12, Dave P Martin wrote: > > On Wed, Dec 06, 2017 at 11:57:12AM +, Ard Biesheuvel wrote: > >> On 6 December 2017 at 11:51, Dave Martin wrote: > >> > On Tue,

Re: [PATCH 1/3] crypto: exynos - Support Exynos5250+ SoCs

On Wed, Dec 6, 2017 at 2:42 PM, Łukasz Stelmach wrote: > It was <2017-12-05 wto 14:34>, when Krzysztof Kozlowski wrote: >> On Tue, Dec 5, 2017 at 1:35 PM, Łukasz Stelmach >> wrote: >>> Add support for PRNG in Exynos5250+ SoCs. >>> >>>

Re: [PATCH 1/3] crypto: exynos - Support Exynos5250+ SoCs

It was <2017-12-05 wto 14:34>, when Krzysztof Kozlowski wrote: > On Tue, Dec 5, 2017 at 1:35 PM, Łukasz Stelmach > wrote: >> Add support for PRNG in Exynos5250+ SoCs. >> >> Signed-off-by: Łukasz Stelmach >> --- >>

Re: [PATCH 2/3] crypto: exynos - Improve performance of PRNG

It was <2017-12-06 śro 12:37>, when Krzysztof Kozlowski wrote: > On Wed, Dec 6, 2017 at 12:32 PM, Łukasz Stelmach > wrote: >> It was <2017-12-05 wto 19:06>, when Krzysztof Kozlowski wrote: >>> On Tue, Dec 5, 2017 at 6:53 PM, Krzysztof Kozlowski wrote:

locking in prng

Hi, I am preparing some improvements for the exynos-rng PRNG driver. It is a driver for hardware PRNG in Exynos SoCs. The hardware should not be access simultaneously by more than one thread/processe or it may return the same data to all of them. Are there any locks betweend kernel consumers or

Re: [PATCH v2 11/19] arm64: assembler: add macro to conditionally yield the NEON under PREEMPT

On 6 December 2017 at 12:12, Dave P Martin wrote: > On Wed, Dec 06, 2017 at 11:57:12AM +, Ard Biesheuvel wrote: >> On 6 December 2017 at 11:51, Dave Martin wrote: >> > On Tue, Dec 05, 2017 at 06:04:34PM +, Ard Biesheuvel wrote: >> >> On 5

Re: [PATCH v2 11/19] arm64: assembler: add macro to conditionally yield the NEON under PREEMPT

On Wed, Dec 06, 2017 at 11:57:12AM +, Ard Biesheuvel wrote: > On 6 December 2017 at 11:51, Dave Martin wrote: > > On Tue, Dec 05, 2017 at 06:04:34PM +, Ard Biesheuvel wrote: > >> On 5 December 2017 at 12:45, Ard Biesheuvel > >> wrote: > >>

Re: [PATCH v2 11/19] arm64: assembler: add macro to conditionally yield the NEON under PREEMPT

On 6 December 2017 at 11:51, Dave Martin wrote: > On Tue, Dec 05, 2017 at 06:04:34PM +, Ard Biesheuvel wrote: >> On 5 December 2017 at 12:45, Ard Biesheuvel >> wrote: >> > >> > >> >> On 5 Dec 2017, at 12:28, Dave Martin

Re: [PATCH v2 11/19] arm64: assembler: add macro to conditionally yield the NEON under PREEMPT

On Tue, Dec 05, 2017 at 06:04:34PM +, Ard Biesheuvel wrote: > On 5 December 2017 at 12:45, Ard Biesheuvel wrote: > > > > > >> On 5 Dec 2017, at 12:28, Dave Martin wrote: > >> > >>> On Mon, Dec 04, 2017 at 12:26:37PM +, Ard Biesheuvel wrote:

Re: [PATCH 2/3] crypto: exynos - Improve performance of PRNG

On Wed, Dec 6, 2017 at 12:32 PM, Łukasz Stelmach wrote: > It was <2017-12-05 wto 19:06>, when Krzysztof Kozlowski wrote: >> On Tue, Dec 5, 2017 at 6:53 PM, Krzysztof Kozlowski wrote: >>> On Tue, Dec 05, 2017 at 05:43:10PM +0100, Łukasz Stelmach wrote:

Re: [PATCH 2/3] crypto: exynos - Improve performance of PRNG

It was <2017-12-05 wto 19:06>, when Krzysztof Kozlowski wrote: > On Tue, Dec 5, 2017 at 6:53 PM, Krzysztof Kozlowski wrote: >> On Tue, Dec 05, 2017 at 05:43:10PM +0100, Łukasz Stelmach wrote: >>> It was <2017-12-05 wto 14:54>, when Stephan Mueller wrote: Am Dienstag, 5.

Re: [PATCH RFC 4/4] crypto: stm32: convert to the new crypto engine API

Hi, On 29/11/17 09:41, Corentin Labbe wrote: > This patch convert the driver to the new crypto engine API. > > Signed-off-by: Corentin Labbe Tested-by: Fabien Dessenne > --- > drivers/crypto/stm32/stm32-hash.c | 22 +++--- >

Re: [PATCH RFC 1/4] crypto: engine - Permit to enqueue all async requests

On 29/11/17 09:41, Corentin Labbe wrote: > The crypto engine could actually only enqueue hash and ablkcipher request. > This patch permit it to enqueue any type of crypto_async_request. > > Signed-off-by: Corentin Labbe > --- > crypto/crypto_engine.c | 188 >

Re: [PATCH RFC 0/4] crypto: engine - Permit to enqueue all async requests

Hi Corentin, I am fine with this proposal: it is generic enough and I have been able to test and run the crypto engine with aead_request without changing any single line of code. This is what I need to be able to send the AEAD extension of the stm32-cryp driver (successfully tested with your