Re: [PATCH 4/4] mtd: provide helper to prepare buffers for DMA operations

Hi Boris, [auto build test ERROR on spi/for-next] [also build test ERROR on v4.6-rc1 next-20160331] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Boris-Brezillon/scatterlist-sg_table-from

[PATCH v4 2/7] crypto: AF_ALG -- add setpubkey setsockopt call

From: Stephan Mueller For supporting asymmetric ciphers, user space must be able to set the public key. The patch adds a new setsockopt call for setting the public key. Signed-off-by: Stephan Mueller Signed-off-by: Tadeusz Struk

[PATCH v4 6/7] crypto: KEYS - add generic handlers to symmetric key type

This adds generic sign, verify, encrypt, decrypt accessor functions to the asymmetric key type. These will be defined by asymmetric subtypes, similarly to how public_key currently defines the verify_signature function. Signed-off-by: Tadeusz Struk ---

[PATCH v4 5/7] crypto: algif_akcipher - add ops_nokey

Similar to algif_skcipher and algif_hash, algif_akcipher needs to prevent user space from using the interface in an improper way. This patch adds nokey ops handlers, which do just that. Signed-off-by: Tadeusz Struk --- crypto/algif_akcipher.c | 159

[PATCH v4 7/7] crypto: AF_ALG - add support for key_id

This patch adds support for asymmetric key type to AF_ALG. It will work as follows: A new PF_ALG socket options are added on top of existing ALG_SET_KEY and ALG_SET_PUBKEY, namely ALG_SET_KEY_ID and ALG_SET_PUBKEY_ID for setting public and private keys respectively. When these new options will be

[PATCH v4 3/7] crypto: AF_ALG -- add asymmetric cipher interface

From: Stephan Mueller This patch adds the user space interface for asymmetric ciphers. The interface allows the use of sendmsg as well as vmsplice to provide data. This version has been rebased on top of 4.6 and a few chackpatch issues have been fixed. Signed-off-by:

[PATCH v4 4/7] crypto: algif_akcipher - enable compilation

From: Stephan Mueller Add the Makefile and Kconfig updates to allow algif_akcipher to be compiled. Signed-off-by: Stephan Mueller Signed-off-by: Tadeusz Struk --- crypto/Kconfig |9 + crypto/Makefile |1 + 2

[PATCH v4 1/7] crypto: AF_ALG -- add sign/verify API

From: Stephan Mueller Add the flags for handling signature generation and signature verification. Also, the patch adds the interface for setting a public key. Signed-off-by: Stephan Mueller Signed-off-by: Tadeusz Struk ---

[PATCH v4 0/7] crypto: algif - add akcipher

First four patches are a resend of the v3 algif_akcipher from Stephan Mueller, with minor changes after rebase on top of 4.6-rc1. The next three patches add support for keys stored in system keyring subsystem. First patch adds algif_akcipher nokey hadlers. Second patch adds generic sign,

[PATCH 1/2] dt/bindings: Add bindings for hisilicon random number generator

Document the devicetree bindings for the random number generator found on Hisilicon Hip04 and Hip05 soc. Signed-off-by: Kefeng Wang --- Documentation/devicetree/bindings/rng/hisi-rng.txt | 12 1 file changed, 12 insertions(+) create mode 100644

[PATCH 2/2] hwrng: hisi: Add support for Hisilicon RNG support

This adds the Hisilicon Random Number Generator(RNG) support, which is found on Hip04 and Hip05 soc. Signed-off-by: Kefeng Wang --- drivers/char/hw_random/Kconfig| 13 drivers/char/hw_random/Makefile | 1 + drivers/char/hw_random/hisi-rng.c | 121

Re: [PATCH 3/4] spi: use sg_alloc_table_from_buf()

On Thu, Mar 31, 2016 at 02:29:43PM +0200, Boris Brezillon wrote: > Replace custom implementation of sg_alloc_table_from_buf() by a call to > sg_alloc_table_from_buf(). Acked-by: Mark Brown signature.asc Description: PGP signature

Re: [PATCH 2/4] scatterlist: add sg_alloc_table_from_buf() helper

On Thu, Mar 31, 2016 at 04:45:57PM +0200, Boris Brezillon wrote: > Hi Russell, > > On Thu, 31 Mar 2016 15:14:13 +0100 > Russell King - ARM Linux wrote: > > > On Thu, Mar 31, 2016 at 02:29:42PM +0200, Boris Brezillon wrote: > > > sg_alloc_table_from_buf() provides an easy

Re: [PATCH 2/4] scatterlist: add sg_alloc_table_from_buf() helper

Hi Russell, On Thu, 31 Mar 2016 15:14:13 +0100 Russell King - ARM Linux wrote: > On Thu, Mar 31, 2016 at 02:29:42PM +0200, Boris Brezillon wrote: > > sg_alloc_table_from_buf() provides an easy solution to create an sg_table > > from a virtual address pointer. This

Re: [PATCH 2/4] scatterlist: add sg_alloc_table_from_buf() helper

On Thu, Mar 31, 2016 at 02:29:42PM +0200, Boris Brezillon wrote: > sg_alloc_table_from_buf() provides an easy solution to create an sg_table > from a virtual address pointer. This function takes care of dealing with > vmallocated buffers, buffer alignment, or DMA engine limitations (maximum > DMA

[PATCH RFC] padata: Removed unused code.

By accident I stumbled across code that has never been used. This driver has EXPORT_SYMBOL functions, and the only user of the code is pcrypt.c, but this only uses a subset of the exported symbols. According to 'git log -G', the functions, padata_set_cpumasks, padata_add_cpu, and

Re: cipher implementations allowed to sleep?

Am Donnerstag, 31. März 2016, 20:58:25 schrieb Herbert Xu: Hi Herbert, > On Thu, Mar 31, 2016 at 01:47:50PM +0200, Stephan Mueller wrote: > > Considering the implementation in ansi_cprng.c, is it allowed to use > > spin_lock_bh with the sync operations assuming that a cipher > > implementation >

Re: cipher implementations allowed to sleep?

On Thu, Mar 31, 2016 at 01:47:50PM +0200, Stephan Mueller wrote: > > Considering the implementation in ansi_cprng.c, is it allowed to use > spin_lock_bh with the sync operations assuming that a cipher implementation > may sleep? As I said, it's only allowed to sleep if you set the MAY_SLEEP

[PATCH 4/4] mtd: provide helper to prepare buffers for DMA operations

Some NAND controller drivers are making use of DMA to transfer data from the controller to the buffer passed by the MTD user. Provide a generic mtd_map/unmap_buf() implementation to avoid open coded (and sometime erroneous) implementations. Signed-off-by: Boris Brezillon

[PATCH 1/4] mm: add is_highmem_addr() helper

Add an helper to check if a virtual address is in the highmem region. Signed-off-by: Boris Brezillon --- include/linux/highmem.h | 13 + 1 file changed, 13 insertions(+) diff --git a/include/linux/highmem.h b/include/linux/highmem.h index

[PATCH 2/4] scatterlist: add sg_alloc_table_from_buf() helper

sg_alloc_table_from_buf() provides an easy solution to create an sg_table from a virtual address pointer. This function takes care of dealing with vmallocated buffers, buffer alignment, or DMA engine limitations (maximum DMA transfer size). Signed-off-by: Boris Brezillon

[PATCH 3/4] spi: use sg_alloc_table_from_buf()

Replace custom implementation of sg_alloc_table_from_buf() by a call to sg_alloc_table_from_buf(). Signed-off-by: Boris Brezillon --- drivers/spi/spi.c | 45 + 1 file changed, 5 insertions(+), 40 deletions(-) diff

[PATCH 0/4] scatterlist: sg_table from virtual pointer

Hello, This series has been extracted from another series [1] adding support for DMA operations in a NAND driver. The reason I decided to post those patches separately is because they are touching core stuff, and I'd like to have feedback on these specific aspects. The idea is to provide a

Re: cipher implementations allowed to sleep?

Am Donnerstag, 31. März 2016, 17:21:06 schrieb Herbert Xu: Hi Herbert, > On Thu, Mar 31, 2016 at 11:18:48AM +0200, Stephan Mueller wrote: > > Hi Herbert, > > > > is it allowed that cipher implementations sleep? The driver of my question > > is whether I can use spin_lock_irqsave() as a lock

Re: cipher implementations allowed to sleep?

Am Donnerstag, 31. März 2016, 17:21:06 schrieb Herbert Xu: Hi Herbert, > On Thu, Mar 31, 2016 at 11:18:48AM +0200, Stephan Mueller wrote: > > Hi Herbert, > > > > is it allowed that cipher implementations sleep? The driver of my question > > is whether I can use spin_lock_irqsave() as a lock

Re: cipher implementations allowed to sleep?

On Thu, Mar 31, 2016 at 11:18:48AM +0200, Stephan Mueller wrote: > Hi Herbert, > > is it allowed that cipher implementations sleep? The driver of my question is > whether I can use spin_lock_irqsave() as a lock around a cipher operation. > > The cipher operations in question are hashing,

cipher implementations allowed to sleep?

Hi Herbert, is it allowed that cipher implementations sleep? The driver of my question is whether I can use spin_lock_irqsave() as a lock around a cipher operation. The cipher operations in question are hashing, HMACing and symmetric ciphers. Thank you Stephan -- To unsubscribe from this list: