Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

On 11/18/2015 05:46 PM, Andy Shevchenko wrote: > On Wed, Nov 18, 2015 at 4:21 PM, Peter Ujfalusi wrote: >> Hi Vinod, >> >> bringing this old thread back to life as I just started to work on this. > > What I remember we need to convert drivers to use new API meanwhile it >

Re: [PATCH v2 1/5] crypto: Multi-buffer encryptioin infrastructure support

On Wed, Nov 18, 2015 at 06:39:30PM -0800, Tim Chen wrote: > > The __cbc-aes-aesni-mb algorithm is marked as internal algorithm > with flag CRYPTO_ALG_INTERNAL, so it should not be picked up by other > algorithms and should only be invoked from mcryptd. OK I guess that's fine then. > Anyway,

[PATCH] drivers/crypto/qat/qat_common/Makefile: fix typo in clean-files

A typo in the Makefile leaves qat_rsaprivkey-asn1.h hanging around. Signed-off-by: Jim Davis --- drivers/crypto/qat/qat_common/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/qat/qat_common/Makefile

[PATCH v3 4/5] crypto: AES CBC by8 encryption

This patch introduces the assembly routine to do a by8 AES CBC encryption in support of the AES CBC multi-buffer implementation. Encryption of 8 data streams of a key size are done simultaneously. Originally-by: Chandramouli Narayanan Signed-off-by: Tim Chen

[PATCH v3 5/5] crypto: AES CBC multi-buffer glue code

This patch introduces the multi-buffer job manager which is responsible for submitting scatter-gather buffers from several AES CBC jobs to the multi-buffer algorithm. The glue code interfaces with the underlying algorithm that handles 8 data streams of AES CBC encryption in parallel. AES key

[PATCH v3 0/5] crypto: x86 AES-CBC encryption with multibuffer

In this patch series, we introduce AES CBC encryption that is parallelized on x86_64 cpu with XMM registers. The multi-buffer technique encrypt 8 data streams in parallel with SIMD instructions. Decryption is handled as in the existing AESNI Intel CBC implementation which can already parallelize

[PATCH v3 1/5] crypto: Multi-buffer encryptioin infrastructure support

In this patch, the infrastructure needed to support multibuffer encryption implementation is added: a) Enhace mcryptd daemon to support blkcipher requests. b) Update configuration to include multi-buffer encryption build support. For an introduction to the multi-buffer implementation, please

[PATCH v3 2/5] crypto: AES CBC multi-buffer data structures

This patch introduces the data structures and prototypes of functions needed for doing AES CBC encryption using multi-buffer. Included are the structures of the multi-buffer AES CBC job, job scheduler in C and data structure defines in x86 assembly code. Originally-by: Chandramouli Narayanan

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

On Thursday 19 November 2015 12:34:22 Peter Ujfalusi wrote: > > I think we can go with a single API, but I don't really like that: > dma_request_channel(dev, name, *mask, fn, fn_param); > > This would cover all current uses being legacy, DT/ACPI, compat, etc: > dma_request_channel(NULL, NULL, ,

[PATCH 2/2] crypto: picoxcell: set [src|dst]_nents and nents as signed int

The unsigned int variables [src|dst]_nents and nents can be assigned signed value (-EINVAL) from sg_nents_for_len(). Furthermore they are used only by dma_map_sg and dma_unmap_sg which wait for an signed int, so they must be set as int. Fixes: f051f95eb47b ("crypto: picoxcell - check return value

[PATCH 1/2] crypto: sahara: set nb_[in|out]_sg as signed int

The two unsigned int variables nb_in_sg and nb_out_sg can be assigned signed value (-EINVAL) from sg_nents_for_len(). Furthermore they are used only by dma_map_sg and dma_unmap_sg which wait for an signed int, so they must be set as int. Fixes: 6c2b74d4774f ("crypto: sahara - check return value

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

On 11/18/2015 05:07 PM, Arnd Bergmann wrote: > On Wednesday 18 November 2015 16:41:35 Peter Ujfalusi wrote: >> On 11/18/2015 04:29 PM, Arnd Bergmann wrote: >>> On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote: 2. non slave channel requests, where only the functionality matters,

[PATCH v3 1/4] lib/mpi: only require buffers as big as needed for the integer

Since mpi_write_to_sgl and mpi_read_buffer explicitly left-align the integers being written it makes no sense to require a buffer big enough for the number + the leading zero bytes which are not written. The error returned also doesn't convey any information. So instead require only the size

[PATCH 4/4] crypto: RSA padding algorithm

This patch adds PKCS#1 v1.5 standard RSA padding as a separate template. This way an RSA cipher with padding can be obtained by instantiating "pkcs1pad(rsa)". The reason for adding this is that RSA is almost never used without this padding (or OAEP) so it will be needed for either certificate

[PATCH v3 2/4] crypto: rsa: only require output buffers as big as needed.

rhe RSA operations explicitly left-align the integers being written skipping any leading zero bytes, but still require the output buffers to include just enough space for the integer + the leading zero bytes. Since the size of integer + the leading zero bytes (i.e. the key modulus size) can now be

RE: [PATCH] crypto: add asynchronous compression support

Hello, Herbert. > -Original Message- > From: Herbert Xu [mailto:herb...@gondor.apana.org.au] > Sent: Thursday, November 19, 2015 6:43 PM > To: Li, Weigang > Cc: linux-crypto@vger.kernel.org; Struk, Tadeusz; Joonsoo Kim; Sergey > Senozhatsky > Subject: Re: [PATCH] crypto: add asynchronous

Re: [PATCH] crypto: add asynchronous compression support

On Fri, Nov 20, 2015 at 03:04:47PM +0900, Joonsoo Kim wrote: > > Linearization would be enough to use sg-list but it has a problem. > Linearization needs sleepable function such as vmap() and it makes > sync (de)compression in atomic context impossible. Currently, zram > did sync (de)compression

Re: [PATCH] crypto: add asynchronous compression support

On 11/20/2015 2:19 PM, Herbert Xu wrote: On Fri, Nov 20, 2015 at 03:04:47PM +0900, Joonsoo Kim wrote: Linearization would be enough to use sg-list but it has a problem. Linearization needs sleepable function such as vmap() and it makes sync (de)compression in atomic context impossible.

[PATCH v2 0/2] fix a possible NULL dereference

Hello The main goal of this patch series is to fix a possible NULL dereference. Even if the probability of this case is very low, fixing it made static analyzers happy. In the same time it permits to remove a "cast that drop const qualifiers. Regards Changes since v1 - Use