Hi Sebastian,
On Thu, 09 Apr 2015 17:34:29 +0200
Sebastian Hesselbarth wrote:
>
> if you include a bunch of performance measurements, I guess it will help
> you to get an agreement of replacing the driver instead of reworking it.
Yep, I made some measurements using tcrypt a while ago, I'll pro
Am Donnerstag, 9. April 2015, 16:58:41 schrieb Boris Brezillon:
Hi Boris,
>Hello,
>
>This is an attempt to replace the mv_cesa driver by a new one to address
>some limitations of the existing driver.
>From a performance and CPU load point of view the most important
>limitation is the lack of DMA
On 09.04.2015 16:58, Boris Brezillon wrote:
This is an attempt to replace the mv_cesa driver by a new one to address
some limitations of the existing driver.
From a performance and CPU load point of view the most important
limitation is the lack of DMA support, thus preventing us from chaining
c
On Thu, Apr 09, 2015 at 04:58:41PM +0200, Boris Brezillon wrote:
> Hello,
>
> This is an attempt to replace the mv_cesa driver by a new one to address
> some limitations of the existing driver.
> >From a performance and CPU load point of view the most important
> limitation is the lack of DMA supp
Document new compatible strings, document the new method to reference the
crypto SRAM and deprecate the old one and document the the 'clocks' and
'clock-names' properties.
Signed-off-by: Boris Brezillon
---
.../devicetree/bindings/crypto/mv_cesa.txt | 50 --
1 file ch
Hello,
This is an attempt to replace the mv_cesa driver by a new one to address
some limitations of the existing driver.
>From a performance and CPU load point of view the most important
limitation is the lack of DMA support, thus preventing us from chaining
crypto operations.
I know we usually t
This removes all the boilerplate from the existing implementation,
and replaces it with calls into the base layer. It also changes the
prototypes of the core asm functions to be compatible with the base
prototype
void (sha512_block_fn)(struct sha256_state *sst, u8 const *src, int blocks)
so th
This removes all the boilerplate from the existing implementation,
and replaces it with calls into the base layer.
Signed-off-by: Ard Biesheuvel
---
arch/x86/crypto/sha1_ssse3_glue.c | 139 --
1 file changed, 28 insertions(+), 111 deletions(-)
diff --git a/ar
To reduce the number of copies of boilerplate code throughout
the tree, this patch implements generic glue for the SHA-1
algorithm. This allows a specific arch or hardware implementation
to only implement the special handling that it needs.
The users need to supply an implementation of
void (sh
To reduce the number of copies of boilerplate code throughout
the tree, this patch implements generic glue for the SHA-256
algorithm. This allows a specific arch or hardware implementation
to only implement the special handling that it needs.
The users need to supply an implementation of
void (
This removes all the boilerplate from the existing implementation,
and replaces it with calls into the base layer.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/sha1-ce-core.S | 33 -
arch/arm64/crypto/sha1-ce-glue.c | 151 ---
2 files changed,
This removes all the boilerplate from the existing implementation,
and replaces it with calls into the base layer.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/sha2-ce-core.S | 29 +++--
arch/arm64/crypto/sha2-ce-glue.c | 227 +--
2 files changed, 63 i
This removes all the boilerplate from the existing implementation,
and replaces it with calls into the base layer.
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/Kconfig| 2 +-
arch/arm/crypto/sha2-ce-core.S | 19 ++---
arch/arm/crypto/sha2-ce-glue.c | 155 +
Hello all,
This is v4 of what is now a complete glue code consolidation series
for generic, x86, arm and arm64 implementations of SHA-1, SHA-224/256
and SHA-384/512.
The purpose is to have a single, canonical implementation of the core
logic that gets reused by all versions of the algorithm. Note
This removes all the boilerplate from the existing implementation,
and replaces it with calls into the base layer. It also changes the
prototypes of the core asm functions to be compatible with the base
prototype
void (sha256_block_fn)(struct sha256_state *sst, u8 const *src, int blocks)
so tha
To reduce the number of copies of boilerplate code throughout
the tree, this patch implements generic glue for the SHA-512
algorithm. This allows a specific arch or hardware implementation
to only implement the special handling that it needs.
The users need to supply an implementation of
void (
This removes all the boilerplate from the existing implementation,
and replaces it with calls into the base layer.
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/sha256_glue.c | 170 ++---
arch/arm/crypto/sha256_glue.h | 17 +---
arch/arm/crypto/sha2
This updated the generic SHA-512 implementation to use the
generic shared SHA-512 glue code.
It also implements a .finup hook crypto_sha512_finup() and exports
it to other modules. The import and export() functions and the
.statesize member are dropped, since the default implementation
is perfectl
This removes all the boilerplate from the existing implementation,
and replaces it with calls into the base layer.
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/sha1_neon_glue.c | 135 +++
1 file changed, 24 insertions(+), 111 deletions(-)
diff --git a/ar
This removes all the boilerplate from the existing implementation,
and replaces it with calls into the base layer.
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/Kconfig| 1 -
arch/arm/crypto/sha1-ce-core.S | 23 +++--
arch/arm/crypto/sha1-ce-glue.c | 107 ++
This updated the generic SHA-1 implementation to use the generic
shared SHA-1 glue code.
It also implements a .finup hook crypto_sha1_finup() and exports
it to other modules. The import and export() functions and the
.statesize member are dropped, since the default implementation
is perfectly suit
This updates the generic SHA-256 implementation to use the
new shared SHA-256 glue code.
It also implements a .finup hook crypto_sha256_finup() and exports
it to other modules. The import and export() functions and the
.statesize member are dropped, since the default implementation
is perfectly su
This removes all the boilerplate from the existing implementation,
and replaces it with calls into the base layer.
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/sha1-ce-glue.c | 3 +-
arch/arm/{include/asm => }/crypto/sha1.h | 3 +
arch/arm/crypto/sha1_glue.c | 112
A cipher instance is added to the list of instances unconditionally
regardless of whether the associated test failed. However, a failed
test implies that during another lookup, the cipher instance will
be added to the list again as it will not be found by the lookup
code.
That means that the list
Am Donnerstag, 9. April 2015, 17:40:35 schrieb Herbert Xu:
Hi Herbert,
>On Thu, Apr 09, 2015 at 11:22:19AM +0200, Stephan Mueller wrote:
>> I tested it and this approach does not work.
>>
>> If I see that right, the reason for that is the following: The suggestion
>> is
>> to grab the ref count
On Thu, Apr 09, 2015 at 11:22:19AM +0200, Stephan Mueller wrote:
>
> I tested it and this approach does not work.
>
> If I see that right, the reason for that is the following: The suggestion is
> to grab the ref count at the start of the function followed by a
> __crypto_register_alg. __crypto_
Am Donnerstag, 9. April 2015, 15:41:41 schrieb Herbert Xu:
Hi Herbert,
>On Thu, Apr 09, 2015 at 09:36:03AM +0200, Stephan Mueller wrote:
>> diff --git a/crypto/algapi.c b/crypto/algapi.c
>> index f1d0307..cfca1de 100644
>> --- a/crypto/algapi.c
>> +++ b/crypto/algapi.c
>> @@ -533,6 +533,13 @@ int
On Thu, Apr 09, 2015 at 09:36:03AM +0200, Stephan Mueller wrote:
>
> diff --git a/crypto/algapi.c b/crypto/algapi.c
> index f1d0307..cfca1de 100644
> --- a/crypto/algapi.c
> +++ b/crypto/algapi.c
> @@ -533,6 +533,13 @@ int crypto_register_instance(struct crypto_template
> *tmpl,
> if (IS_ERR
A cipher instance is added to the list of instances unconditionally
regardless of whether the associated test failed. However, a failed
test implies that during another lookup, the cipher instance will
be added to the list again as it will not be found by the lookup
code.
That means that the list
29 matches
Mail list logo
