[RFC PATCH crypto -v3 2/2] AES-NI: Add support to Intel AES-NI instructions for x86_64 platform

This is not intented to be merged, just for reviewing. If no other issues, I will pre-assemble AES-NI instructions in aesni-intel_asm.S, because they are not supported by some binutils until now. ---> Add support to Intel AES-NI instr

[RFC PATCH crypto -v3 1/2] AES-NI: Add support to access underlying blkcipher under cryptd ablkcipher

cryptd_alloc_ablkcipher() will allocate a cryptd-ed ablkcipher for specified algorithm name. The new allocated one is guaranteed to be cryptd-ed ablkcipher, so the blkcipher underlying can be gotten via cryptd_ablkcipher_child(). Signed-off-by: Huang Ying --- crypto/cryptd.c | 19

Re: Use cryptd(%s) as cryptd-ed algorithm name instead of %s

On Wed, 2009-01-14 at 14:53 +0800, Herbert Xu wrote: > On Wed, Jan 14, 2009 at 02:44:08PM +0800, Huang Ying wrote: > > Because: > > > > 1. if use %s, you can only request cryptd(), not > >cryptd(), because generated new algorithm instance has > >algorithm name: and driver name cryptd(). >

Re: Use cryptd(%s) as cryptd-ed algorithm name instead of %s

On Wed, Jan 14, 2009 at 02:44:08PM +0800, Huang Ying wrote: > Because: > > 1. if use %s, you can only request cryptd(), not >cryptd(), because generated new algorithm instance has >algorithm name: and driver name cryptd(). This is intentional. For the purposes we talked about we should

Use cryptd(%s) as cryptd-ed algorithm name instead of %s

Because: 1. if use %s, you can only request cryptd(), not cryptd(), because generated new algorithm instance has algorithm name: and driver name cryptd(). 2. Generated cryptd-ed algorithm will have the same algorithm name and higher priority, but some user may not want to use cryptd-ed

crypto: shash - Remove superfluous check in init_tfm

Hi: I'll added this to cryptodev-2.6. commit 1f4cfc229e0e8c3b48cfada9aecfc72ff438fa61 Author: Herbert Xu Date: Wed Jan 14 13:34:48 2009 +1100 crypto: shash - Remove superfluous check in init_tfm We're currently checking the frontend type in init_tfm. This is completely point

Re: [PATCH] crypto: compress - Add pcomp interface

Hi Geert: On Tue, Jan 13, 2009 at 04:59:40PM +0100, Geert Uytterhoeven wrote: > The current "comp" crypto interface supports one-shot (de)compression only, > i.e. the whole data buffer to be (de)compressed must be passed at once, and > the whole (de)compressed data buffer will be received at once.

[PATCH] crypto: deflate - switch to pcomp

Change the "deflate" crypto module from the "comp" to the "pcomp" interface. Signed-off-by: Geert Uytterhoeven Cc: James Morris --- crypto/Kconfig|2 +- crypto/deflate.c | 350 include/crypto/compress.h | 12 ++ 3 files ch

[PATCH] squashfs: Make SquashFS 4 use the new pcomp crypto interface

Modify SquashFS 4 to use the new "pcomp" crypto interface for decompression, instead of calling the underlying zlib library directly. This simplifies e.g. the addition of support for hardware decompression and different decompression algorithms. Signed-off-by: Geert Uytterhoeven Cc: Phillip Lough

[PATCH] crypto: compress - Add pcomp interface

The current "comp" crypto interface supports one-shot (de)compression only, i.e. the whole data buffer to be (de)compressed must be passed at once, and the whole (de)compressed data buffer will be received at once. In several use-cases (e.g. compressed file systems that store files in big compresse

[PATCH] crypto: api - Export pcomp through comp

Allow "pcomp" algorithms to be used through the old "comp" interface, by implementing one-shot (de)compression on top of the partial (de)compression interface. As the old "comp" interface doesn't support the configuration of (de)compression parameters by the user, each algorithm must provide a set

[PATCH/RFC 0/7] Partial (de)compression API

The following patch series adds support for partial (de)compression to the CRYPTO API, and modifies SquashFS 4 to use this: [1] crypto: compress - Add pcomp interface [2] crypto: testmgr - Add support for the pcomp interface [3] crypto: api - Add type init function to crypto_tfm [4] crypto

[PATCH] crypto: testmgr - swith deflate test to pcomp

Change the tests for the "deflate" crypto module from the "comp" to the "pcomp" test framework. Signed-off-by: Geert Uytterhoeven --- crypto/testmgr.c |4 ++-- crypto/testmgr.h | 24 ++-- 2 files changed, 24 insertions(+), 4 deletions(-) diff --git a/crypto/testmgr.c b

[PATCH] crypto: api - Add type init function to crypto_tfm

Add a type init function to crypto_tfm, so transforms can override the default action of calling the algorithm's cra_init() method. This will be used by the "comp" compatibility layer for the "pcomp" type, which needs to call the algorithm's setup() method, in addition to the cra_init() method. S

[PATCH] crypto: testmgr - Add support for the pcomp interface

Signed-off-by: Geert Uytterhoeven --- crypto/testmgr.c | 181 ++ crypto/testmgr.h |9 +++ 2 files changed, 190 insertions(+), 0 deletions(-) diff --git a/crypto/testmgr.c b/crypto/testmgr.c index a75f11f..aad718f 100644 --- a/crypto/testmg

Re: kernel BUG at crypto/scatterwalk.c:37! when using modified tcrypt for HMAC testing

Hi Herbert, Many thanks that fixed it. Regards, Dean Jenkins MontaVista Software --- Begin Message --- Dean Jenkins wrote: > > I'm using a 2.6.27.4 kernel on an armv5te platform. > > I hit a BUG() at crypto/scatterwalk.c:37 that indicates that the scatterlist > length is zero. > > I've trace