[PATCH v2 3/4] crypto: jz4780-rng: Add RNG node to jz4780.dtsi

Add RNG node to jz4780 dtsi. This driver uses registers that are part of the register set used by Ingenic CGU driver. Make RNG node as child of CGU node. Signed-off-by: PrasannaKumar Muralidharan --- Changes in v2: * Add "syscon" in CGU node's compatible section *

[PATCH v2 1/4] crypto: jz4780-rng: Add JZ4780 PRNG devicetree binding documentation

Add devicetree bindings for hardware pseudo random number generator present in Ingenic JZ4780 SoC. Signed-off-by: PrasannaKumar Muralidharan --- Changes in v2: * Add "syscon" in CGU node's compatible section * Make RNG child node of CGU.

[PATCH v2 2/4] crypto: jz4780-rng: Add Ingenic JZ4780 hardware PRNG driver

JZ4780 SoC pseudo random number generator driver using crypto framework. Adding a delay before reading RNG data and disabling RNG after reading data was suggested by Jeffery Walton. Tested-by: Mathieu Malaterre Suggested-by: Jeffrey Walton Signed-off-by:

[PATCH v2 0/4] crypto: Add driver for JZ4780 PRNG

This patch series adds support of pseudo random number generator found in Ingenic's JZ4780 and X1000 SoC. Based on Paul's review comments, add 'syscon' compatible in CGU node in jz4780.dtsi. jz4780-rng driver uses regmap exposed via syscon interface to access the RNG registers. CGU driver is not

[PATCH v2 4/4] crypto: jz4780-rng: Enable PRNG support in CI20 defconfig

Enable PRNG driver support in MIPS Creator CI20 default config. Signed-off-by: PrasannaKumar Muralidharan --- No changes in v2 arch/mips/configs/ci20_defconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/mips/configs/ci20_defconfig

Re: [PATCH] staging/ccree: Declare compiled out fuctions static inline

Try saving this email and then do `cat email.txt | git am`. It is corrupted. This is not how to send a v2 patch. Please read: https://kernelnewbies.org/FirstKernelPatch#head-5c81b3c517a1d0bbc24f92594cb734e155fcbbcb Look through the email archives for examples of other v2 patches. regards,

Re: [PATCH v7 5/7] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros

On Tue, Aug 22, 2017 at 8:02 PM, Logan Gunthorpe wrote: > This patch adds generic io{read|write}64[be]{_lo_hi|_hi_lo} macros if > they are not already defined by the architecture. (As they are provided > by the generic iomap library). > > The patch also points

Re: [PATCH] hw_random: timeriomem-rng: Remove 'max < 4' condition check

Hi Rick, On 22 August 2017 at 22:23, Rick Altherr wrote: > On Tue, Aug 22, 2017 at 9:22 AM, PrasannaKumar Muralidharan > wrote: >> >> In read routiene max is always >= 4. The check whether 'max < 4' is not >> necessary. Remove it. > > Missed that

Re: [PATCH] hw_random: timeriomem-rng: Remove 'max < 4' condition check

On Tue, Aug 22, 2017 at 9:22 AM, PrasannaKumar Muralidharan wrote: > > In read routiene max is always >= 4. The check whether 'max < 4' is not > necessary. Remove it. Missed that in the header. Acked-By: Rick Altherr > > Signed-off-by:

[PATCH v7 2/7] powerpc: io.h: move iomap.h include so that it can use readq/writeq defs

Subsequent patches in this series makes use of the readq and writeq defines in iomap.h. However, as is, they get missed on the powerpc platform seeing the include comes before the define. This patch moves the include down to fix this. Signed-off-by: Logan Gunthorpe Acked-By:

[PATCH v7 4/7] iomap: introduce io{read|write}64_{lo_hi|hi_lo}

In order to provide non-atomic functions for io{read|write}64 that will use readq and writeq when appropriate. We define a number of variants of these functions in the generic iomap that will do non-atomic operations on pio but atomic operations on mmio. These functions are only defined if readq

[PATCH v7 3/7] powerpc: iomap.c: introduce io{read|write}64_{lo_hi|hi_lo}

These functions will be introduced into the generic iomap.c so they can deal with PIO accesses in hi-lo/lo-hi variants. Thus, the powerpc version of iomap.c will need to provide the same functions even though, in this arch, they are identical to the regular io{read|write}64 functions.

[PATCH v7 6/7] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

Now that ioread64 and iowrite64 are available in io-64-nonatomic, we can remove the hack at the top of ntb_hw_intel.c and replace it with an include. Signed-off-by: Logan Gunthorpe Acked-by: Dave Jiang Acked-by: Allen Hubbe

[PATCH v7 0/7] make io{read|write}64 globally usable

This is just a resend seeing I've gotten no feedback in a couple weeks. Changes since v6: ** none ** Changes since v5: - Added a fix to the tilcdc driver to ensure it doesn't use the non-atomic operation. (This includes adding io{read|write}64[be]_is_nonatomic defines). Changes since v4:

[PATCH v7 1/7] drm/tilcdc: ensure nonatomic iowrite64 is not used

Add a check to ensure iowrite64 is only used if it is atomic. It was decided in [1] that the tilcdc driver should not be using an atomic operation (so it was left out of this patchset). However, it turns out that through the drm code, a nonatomic header is actually included:

Re: Re: [PATCH 0/6] Add support for ECDSA algorithm

Hi, Herbert, On 02/02/2017 03:57 PM, Herbert Xu wrote: Yes but RSA had an in-kernel user in the form of module signature verification. We don't add algorithms to the kernel without actual users. So this patch-set needs to come with an actual in-kernel user of ECDSA. ECDSA can be used by the

[PATCH] Documentation: hw_random: Fix issue related to feeding entropy pool

There is no need to use rng-tools for feeding random data into kernel entropy pool as hw_random core handles it. Documentation suggested that rng-tools is required which is incorrect. So remove it. Signed-off-by: PrasannaKumar Muralidharan ---

[PATCH v7 7/7] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

From: Horia Geantă We can now make use of the io-64-nonatomic-lo-hi header to always provide 64 bit IO operations. So this patch cleans up the extra CONFIG_64BIT ifdefs. To be consistent with CAAM engine HW spec: in case of 64-bit registers, irrespective of device

[PATCH v7 5/7] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros

This patch adds generic io{read|write}64[be]{_lo_hi|_hi_lo} macros if they are not already defined by the architecture. (As they are provided by the generic iomap library). The patch also points io{read|write}64[be] to the variant specified by the header name. This is because new drivers are

[PATCH] hw_random: timeriomem-rng: Remove 'max < 4' condition check

In read routiene max is always >= 4. The check whether 'max < 4' is not necessary. Remove it. Signed-off-by: PrasannaKumar Muralidharan --- drivers/char/hw_random/timeriomem-rng.c | 7 --- 1 file changed, 7 deletions(-) diff --git

Re: [PATCH v7 6/7] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

On Tue, Aug 22, 2017 at 8:02 PM, Logan Gunthorpe wrote: > Now that ioread64 and iowrite64 are available in io-64-nonatomic, > we can remove the hack at the top of ntb_hw_intel.c and replace it > with an include. > @@ -59,6 +59,7 @@ > #include > #include > #include >

Re: [PATCH v7 0/7] make io{read|write}64 globally usable

On 22/08/17 11:43 AM, Andy Shevchenko wrote: Overall quite a good clean up! Thanks! After addressing my comments you may take my Reviewed-by: Andy Shevchenko Great, Thanks! Logan

Re: Re: [PATCH 0/6] Add support for ECDSA algorithm

On Tue, Aug 22, 2017 at 12:14 PM, Tudor Ambarus wrote: > Hi, Herbert, > > On 02/02/2017 03:57 PM, Herbert Xu wrote: >> >> Yes but RSA had an in-kernel user in the form of module signature >> verification. We don't add algorithms to the kernel without >> actual users.

Re: [PATCH v7 5/7] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros

On 22/08/17 11:40 AM, Andy Shevchenko wrote: ldd -> LDD Ok. Recomendation is kinda arguable. I doubt modern architectures make difference between IO operations and MMIO. Does, for example, PCI requires some special signal (message / wire) handling when pio_*() accessors used vs. mmio_*()

Re: [PATCH v7 6/7] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

On Tue, Aug 22, 2017 at 8:56 PM, Logan Gunthorpe wrote: > > > On 22/08/17 11:41 AM, Andy Shevchenko wrote: >>> >>> @@ -59,6 +59,7 @@ >>> #include >>> #include >>> #include >>> +#include >> >> >> I would rather try to squeeze to most alpabetiacelly ordered part of

Re: [PATCH v7 0/7] make io{read|write}64 globally usable

On Tue, Aug 22, 2017 at 8:02 PM, Logan Gunthorpe wrote: > This is just a resend seeing I've gotten no feedback in a couple weeks. Overall quite a good clean up! Thanks! After addressing my comments you may take my Reviewed-by: Andy Shevchenko >

Re: [PATCH v7 6/7] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

On 22/08/17 11:41 AM, Andy Shevchenko wrote: @@ -59,6 +59,7 @@ #include #include #include +#include I would rather try to squeeze to most alpabetiacelly ordered part of this block. Otherwise it's a pretty nice clean up! I don't understand. The includes were not alphabetically in

Re: [PATCH] crypto: ccp - Fix XTS-AES-128 support on v5 CCPs

On 08/18/2017 11:02 PM, Herbert Xu wrote: On Fri, Aug 18, 2017 at 11:41:04AM -0500, Gary R Hook wrote: On Tue, Jul 25, 2017 at 02:12:11PM -0500, Gary R Hook wrote: Version 5 CCPs have some new requirements for XTS-AES: the type field must be specified, and the key requires 512 bits, with each

★beijing--“JEC world 2018 世界复合材料展览及会议”将于“3月06-08日”在“法国巴黎”举行 （地右P1-L-Me）

尊敬的 beij...@cpahkltd.com 企业领导/公司负责人/业界专家，您好： 　　 　　 新材料为21世纪三大共性关键技术之一，已成为全球经济迅速增长的源动力和提升核心竞争力的战略焦点。材料作为制造业的基础，特别是新材料研究和产业发展的水平与规模，已经成为衡量一个国家科技进步和综合实力的重要标志。在新材料发展与应用中，复合材料占有相当重要的地位，特别广泛的应用在汽车、交通、风能、航空、航天、兵器、船舶、国防、机械、电子、化工、建筑、农业、渔业、纺织、运动器材等领域，一直是世界各国优先发展和竞争激烈的重要行业。 　　 　　“JEC世界复合材料展览及会议”（JEC world

Re: [PATCH v7 5/7] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros

On Tue, Aug 22, 2017 at 8:55 PM, Logan Gunthorpe wrote: > On 22/08/17 11:40 AM, Andy Shevchenko wrote: >> Recomendation is kinda arguable. I doubt modern architectures make >> difference between IO operations and MMIO. >> Does, for example, PCI requires some special signal

[PATCH 04/11] crypto: nx - Use GCM IV size constant

This patch replace GCM IV size value by their constant name. Signed-off-by: Corentin Labbe --- drivers/crypto/nx/nx-aes-gcm.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/crypto/nx/nx-aes-gcm.c b/drivers/crypto/nx/nx-aes-gcm.c

[PATCH 07/11] crypto: mediatek - Use GCM IV size constant

This patch replace GCM IV size value by their constant name. Signed-off-by: Corentin Labbe --- drivers/crypto/mediatek/mtk-aes.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/crypto/mediatek/mtk-aes.c

[PATCH 08/11] crypto: chelsio - Use GCM IV size constant

This patch replace GCM IV size value by their constant name. Signed-off-by: Corentin Labbe --- drivers/crypto/chelsio/chcr_algo.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/crypto/chelsio/chcr_algo.c

[PATCH 06/11] crypto: bcm - Use GCM IV size constant

This patch replace GCM IV size value by their constant name. Signed-off-by: Corentin Labbe --- drivers/crypto/bcm/cipher.c | 8 drivers/crypto/bcm/cipher.h | 3 +-- 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/crypto/bcm/cipher.c

[PATCH 02/11] crypto: caam - Use GCM IV size constant

This patch replace GCM IV size value by their constant name. Signed-off-by: Corentin Labbe --- drivers/crypto/caam/caamalg.c | 10 +- drivers/crypto/caam/compat.h | 1 + 2 files changed, 6 insertions(+), 5 deletions(-) diff --git

[PATCH 01/11] crypto: gcm - add GCM IV size constant

Many GCM users use directly GCM IV size instead of using some constant. This patch add all IV size constant used by GCM. Signed-off-by: Corentin Labbe --- include/crypto/gcm.h | 8 1 file changed, 8 insertions(+) create mode 100644 include/crypto/gcm.h

[PATCH 03/11] crypto: ccp - Use GCM IV size constant

This patch replace GCM IV size value by their constant name. Signed-off-by: Corentin Labbe --- drivers/crypto/ccp/ccp-crypto-aes-galois.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/crypto/ccp/ccp-crypto-aes-galois.c

[PATCH 09/11] crypto: omap - Use GCM IV size constant

This patch replace GCM IV size value by their constant name. Signed-off-by: Corentin Labbe --- drivers/crypto/omap-aes-gcm.c | 7 --- drivers/crypto/omap-aes.c | 5 +++-- 2 files changed, 7 insertions(+), 5 deletions(-) diff --git

[PATCH 05/11] crypto: atmel - Use GCM IV size constant

This patch replace GCM IV size value by their constant name. Signed-off-by: Corentin Labbe --- drivers/crypto/atmel-aes.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/atmel-aes.c b/drivers/crypto/atmel-aes.c index

[PATCH 10/11] crypto: gcm - Use GCM IV size constant

This patch replace GCM IV size value by their constant name. Signed-off-by: Corentin Labbe --- crypto/gcm.c | 23 --- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/crypto/gcm.c b/crypto/gcm.c index 3841b5eafa7e..80cf6cfe082b

[PATCH 11/11] crypto: aesni - Use GCM IV size constant

This patch replace GCM IV size value by their constant name. Signed-off-by: Corentin Labbe --- arch/x86/crypto/aesni-intel_glue.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/x86/crypto/aesni-intel_glue.c

[PATCH 00/11] crypto: gcm - add GCM IV size constant

Many GCM users use directly GCM IV size instead of using some constant. This patch add all IV size constant used by GCM and convert drivers for using them.. Corentin Labbe (11): crypto: gcm - add GCM iv size constant crypto: caam - Use GCM IV size constant crypto: ccp - Use GCM IV size

Re: [PATCH] staging/ccree: Declare compiled out fuctions static inline

On Wed, Aug 16, 2017 at 03:09:09PM -0700, Greg KH wrote: > On Mon, Jul 31, 2017 at 02:47:23PM +0530, RishabhHardas wrote: > > From: RishabhHardas > > > > Sparse was giving out a warning for symbols 'cc_set_ree_fips_status' and > > 'fips_handler' > > that they were not

Re: [PATCH] crypto: rockchip: Don't dequeue the request when device is busy

On Tue, Aug 15, 2017 at 03:48:15PM +0800, zain wang wrote: > The device can only process one request at a time. So if multiple > requests came at the same time, we can enqueue them first, and > dequeue them one by one when the device is idle. > > Signed-off-by: zain wang

Re: [PATCH] crypto: inside-secure - fix an error handling path in safexcel_probe()

On Tue, Aug 15, 2017 at 09:33:24PM +0200, Christophe JAILLET wrote: > 'ret' is known to be 0 at this point. > If 'safexcel_request_ring_irq()' fails, it returns an error code. > Return this value instead of 0 which means success. > > Signed-off-by: Christophe JAILLET

Re: [PATCH 1/2] crypto/chacha20: fix handling of chunked input

On Mon, Aug 14, 2017 at 02:28:14PM +0100, Ard Biesheuvel wrote: > Commit 9ae433bc79f9 ("crypto: chacha20 - convert generic and x86 versions > to skcipher") ported the existing chacha20 code to use the new skcipher > API, and introduced a bug along the way. Unfortunately, the tcrypt tests > did not

Re: [PATCH 2/2] crypto: testmgr - add chunked test cases for chacha20

On Mon, Aug 14, 2017 at 02:28:15PM +0100, Ard Biesheuvel wrote: > We failed to catch a bug in the chacha20 code after porting it to the > skcipher API. We would have caught it if any chunked tests had been > defined, so define some now so we will catch future regressions. > > Signed-off-by: Ard

Re: [PATCH v4] crypto: only call put_page on referenced and used pages

On Wed, Aug 16, 2017 at 11:56:24AM +0200, Stephan Müller wrote: > Hi Herbert, > > This patch was created against the current Linus development tree. > > The functional test was conducted at the time v3 was aired. The patch > v4 is compile-tested. > > Ciao > Stephan > > ---8<--- > For

Re: [PATCH] crypto: cavium - add release_firmware to all return case

On Mon, Aug 14, 2017 at 01:58:54PM +0200, Corentin Labbe wrote: > Two return case misses to call release_firmware() and so leak some > memory. > > This patch create a fw_release label (and so a common error path) > and use it on all return case. > > Detected by CoverityScan, CID#1416422

Re: [PATCH] crypto: mediatek - Add empty messages check in GCM mode

On Wed, Aug 16, 2017 at 07:19:48PM +0800, Ryder Lee wrote: > Currently, empty messages are not supported in GCM mode, hence add > a check to prevent producing incorrect results. > > Signed-off-by: Ryder Lee > --- > drivers/crypto/mediatek/mtk-aes.c | 5 + > 1 file

Re: [PATCH] crypto: mediatek - Add empty messages check in GCM mode

Hi, On Tue, 2017-08-22 at 15:01 +0800, Herbert Xu wrote: > On Wed, Aug 16, 2017 at 07:19:48PM +0800, Ryder Lee wrote: > > Currently, empty messages are not supported in GCM mode, hence add > > a check to prevent producing incorrect results. > > > > Signed-off-by: Ryder Lee

[PATCH v1] crypto: mediatek - Add empty messages check in GCM mode

Currently, empty messages are not supported in GCM mode, hence add a check to prevent producing incorrect results. Signed-off-by: Ryder Lee --- changes since v1: - fix build erro: add a missing semicolon. drivers/crypto/mediatek/mtk-aes.c | 5 + 1 file changed, 5

Re: [PATCH] crypto: cavium/nitrox - Fix an error handling path in 'nitrox_probe()'

On Wed, Aug 16, 2017 at 07:16:06AM +0200, Christophe JAILLET wrote: > 'err' is known to be 0 at this point. > If 'kzalloc()' fails, returns -ENOMEM instead of 0 which means success. > > Signed-off-by: Christophe JAILLET Patch applied. Thanks. -- Email: Herbert

Re: [PATCH] crypto: MPI - kunmap after finishing accessing buffer

On Thu, Aug 10, 2017 at 08:06:18AM +0200, Stephan Müller wrote: > Hi Herbert, > > I found that issue while playing around with edge conditions in my > algif_akcipher implementation. This issue only manifests in a > segmentation violation on 32 bit machines and with an SGL where each > SG points

Re: [PATCH v4] crypto: only call put_page on referenced and used pages

On Wed, Aug 16, 2017 at 11:56:24AM +0200, Stephan Müller wrote: > Hi Herbert, > > This patch was created against the current Linus development tree. > > The functional test was conducted at the time v3 was aired. The patch > v4 is compile-tested. Thanks! Cc: -- Email:

Re: [PATCH] crypto: MPI - kunmap after finishing accessing buffer

On Thu, Aug 10, 2017 at 08:06:18AM +0200, Stephan Müller wrote: > Hi Herbert, > > I found that issue while playing around with edge conditions in my > algif_akcipher implementation. This issue only manifests in a > segmentation violation on 32 bit machines and with an SGL where each > SG points

Re: [PATCH] crypto: algif_aead - fix comment regarding memory layout

On Wed, Aug 09, 2017 at 04:20:00PM +0200, Stephan Müller wrote: > Signed-off-by: Stephan Mueller Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key:

Re: [PATCH v4 0/4] crypto: add driver for Axis ARTPEC crypto accelerator

On Thu, Aug 10, 2017 at 02:53:50PM +0200, Lars Persson wrote: > This series adds a driver for the crypto accelerator in the ARTPEC series of > SoCs from Axis Communications AB. > > Changelog v4: > - The skcipher conversion had a mistake where the algos were registered > instead of unregistered

Re: [PATCH] crypto: AF_ALG - get_page upon reassignment to TX SGL

On Thu, Aug 10, 2017 at 04:40:03PM +0200, Stephan Müller wrote: > Hi Herbert, > > The error can be triggered with the following test. Invoking that test > in a while [ 1 ] loop shows that no memory is leaked. Patch applied. Thanks. -- Email: Herbert Xu Home Page:

Re: [PATCH] crypto: sahara: constify platform_device_id

On Sun, Aug 13, 2017 at 02:34:00PM +0530, Arvind Yadav wrote: > platform_device_id are not supposed to change at runtime. All functions > working with platform_device_id provided by > work with const platform_device_id. So mark the non-const structs as > const. > > Signed-off-by: Arvind Yadav

Re: [PATCH] staging/ccree: Declare compiled out fuctions static inline

Google for how to send a v2 patch. https://www.google.com/search?q=how+to+send+a+v2+patch https://kernelnewbies.org/FirstKernelPatch regards, dan carpenter

Re: [PATCH] staging/ccree: Declare compiled out fuctions static inline

On Wed, Aug 16, 2017 at 03:09:09PM -0700, Greg KH wrote: > On Mon, Jul 31, 2017 at 02:47:23PM +0530, RishabhHardas wrote: > > From: RishabhHardas > > > > Sparse was giving out a warning for symbols 'cc_set_ree_fips_status' and > > 'fips_handler' > > that they were not