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
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
> +++--
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 +++---
> 1 file changed, 15 insertions(+), 7 deletions(-)
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. Dezember 2017, 13:35:5
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:
It was <2017-12-05 wto 14:54>, when Step
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:
> >>> Add a support macro to conditionally yield
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 wrote:
>> >>
>> >>> On Mon, Dec 04, 2017 at 12:26:37PM +, Ard Biesh
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:
> >> >
> >> >
> >> >> On 5 Dec 2017, at 12:28, Dave M
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 December 2017 at 12:45, Ard Biesheuvel
>> >> wro
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 u
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:
On Tue, Dec 05, 2017 at 05:43:10PM +010
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
>> ---
>> .../bindings/crypto/samsung,exynos-rng4.txt| 4 ++-
>> drivers/crypto/ex
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.
>>>
>>> Signed-off-by: Łukasz Stelmach
>>> ---
>>> .../bindings/cry
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, Dec 05, 2017 at 06:04:34PM +, Ard Biesheu
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
>>> wrote:
Add support for PRNG in Exynos5250+ SoC
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:
On Tue, Dec 5, 2017 at 1:35 PM, Łukasz Stel
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
> > > wrote:
> > > > Add support for PRNG in Exynos52
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 tha
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
---
crypto/tes
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 tha
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 tha
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 t
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 tha
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 co
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
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 INTERL
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 routines
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 st
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 --git a/arch/arm64/crypto/aes-
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 the
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 a/arch/arm64/crypto/sha1-ce-co
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 insertions(+), 130 deletions(-)
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 --git a/arch/arm64/crypto/aes-ce
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 a/arch/arm64/crypto/sha2-ce-co
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 changed, 97 insertions(+), 44 delet
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 a/arch/arm64/crypto/crc32-ce-
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
b/arch/arm64/
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 --git a/arch/arm64/crypto/crct10
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
> Virtualization (SEV) mode, along wit
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 b/drivers/staging/ccree/ssi_aead.c
in
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 insertions(+), 56 deletions(
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 Linus's tree and not Gre
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 the few truly single line
43 matches
Mail list logo
