Re: [PATCH 2/2] hwrng: thunderx: Add Cavium HWRNG driver for ThunderX SoC.

Hello I have some minor comments below On 20/08/2016 00:32, Omer Khaliq wrote: > The Cavium ThunderX SoC has a hardware random number generator. > This driver provides support using the HWRNG framework. > > Signed-off-by: Omer Khaliq > Signed-off-by: Ananth Jasty

[PATCH 0/2] hwrng/PCI/IOV: Add driver for Cavium Thunder RNG

There is a hardware error rendering the FDL field incorrect for the some Thunder RNG devices. The first patch adds infrastructure to fix the problem. The second patch adds the driver. David Daney (1): PCI/IOV: Add function to allow Function Dependency Link override. Omer Khaliq (1):

[PATCH 2/2] hwrng: thunderx: Add Cavium HWRNG driver for ThunderX SoC.

The Cavium ThunderX SoC has a hardware random number generator. This driver provides support using the HWRNG framework. Signed-off-by: Omer Khaliq Signed-off-by: Ananth Jasty Acked-by: David Daney ---

[PATCH 1/2] PCI/IOV: Add function to allow Function Dependency Link override.

From: David Daney Some hardware presents an incorrect SR-IOV Function Dependency Link, add a function to allow this to be overridden in the PF driver for such devices. Signed-off-by: David Daney Signed-off-by: Omer Khaliq

Git bisected regression for ipsec/aead

Hi Herbert, In the process of testing ipsec I ran into panics (details below) with the algorithm "aead rfc4106(gcm(aes)) 0x1234567890123456789012345678901234567890 64" git-bisect analyzed this down to 7271b33cb87e80f3a416fb031ad3ca87f0bea80a is the first bad commit commit

[PATCH v5] DH support: add KDF handling support

Hi, this patch changes the documentation, the naming of the variables and the test case to refer to the variable name of a hashname instead of kdfname to match the current kernel implementation. Ciao Stephan ---8<--- Add the interface logic to support DH with KDF handling support. The

[PATCH v5] KEYS: add SP800-56A KDF support for DH

Hi, This patch now folds the KDF into the keys support as requested by Herbert. The caller can only supply the hash name used for the KDF. Note, the KDF implementation is identical to the kdf_ctr() support in the now unneeded KDF patches to the kernel crypto API. The new patch also changes the

Re: [PATCH v6 0/5] /dev/random - a new approach

On 08/18/16 22:56, Herbert Xu wrote: > On Thu, Aug 18, 2016 at 10:49:47PM -0400, Theodore Ts'o wrote: >> >> That really depends on the system. We can't assume that people are >> using systems with a 100Hz clock interrupt. More often than not >> people are using tickless kernels these days.

[PATCH 1/5] hwrng: amd: Fix style problem with blank line

Some blank line are unncessary, and one is missing after declaration. This patch fix thoses style problems. Signed-off-by: LABBE Corentin --- drivers/char/hw_random/amd-rng.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git

[PATCH 4/5] hwrng: amd: Remove asm/io.h

checkpatch complains about used instead of linux/io.h. In fact it is not needed. This patch remove it, and in the process, alphabetize the other headers. Signed-off-by: LABBE Corentin --- drivers/char/hw_random/amd-rng.c | 7 +++ 1 file changed, 3 insertions(+),

[PATCH 2/5] hwrng: amd: use the BIT macro

This patch add usage of the BIT() macro Signed-off-by: LABBE Corentin --- drivers/char/hw_random/amd-rng.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c index

[PATCH 5/5] hwrng: amd: Rework of the amd768-hwrng driver

This patch convert the hwrng interface used by amd768-rng to its new API by replacing data_read()/data_present() by read(). Furthermore, Instead of having two global variable, it's better to use a private struct. This will permit to remove amd_pdev variable. Finally, Instead of accessing hw

[PATCH 3/5] hwrng: amd: Be consitent with the driver name

The driver name is displayed each time differently. This patch make use of the same name everywhere. Signed-off-by: LABBE Corentin --- drivers/char/hw_random/amd-rng.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git

Re: [PATCH] Add Ingenic JZ4780 hardware RNG driver

> __ARM_FEATURE_UNALIGNED (cf., > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0774f/chr1383660321827.html) > . MIPSEL does not define such a macro. > > # MIPS ci20 creator with GCC 4.6 > $ gcc -march=native -dM -E - #define __BIGGEST_ALIGNMENT__ 8 > > If the MIPS

Re: [PATCH] Add Ingenic JZ4780 hardware RNG driver

> Please forgive my ignorance Prasanna... > > For the JZ4780 I have, there are two registers in play. The first is > the control register which enables/disables the RNG. The control > register is named ERNG. The second register is the data register, and > it produces the random stream. The data

[PATCH] crypto/xor: skip speed test if the xor function is selected automatically

If the architecture selected the xor function with XOR_SELECT_TEMPLATE the speed result of the do_xor_speed benchmark is of limited value. The speed measurement increases the bootup time a little, which can makes a difference for kernels used in container like virtual machines. Signed-off-by:

Re: [PATCH] Add Ingenic JZ4780 hardware RNG driver

On Wed, Aug 17, 2016 at 11:35 AM, PrasannaKumar Muralidharan wrote: > This patch adds support for hardware random number generator present in > JZ4780 SoC. > > Signed-off-by: PrasannaKumar Muralidharan > --- > ... > +static int

Re: [PATCH] Add Ingenic JZ4780 hardware RNG driver

On Wed, Aug 17, 2016 at 11:35 AM, PrasannaKumar Muralidharan wrote: > This patch adds support for hardware random number generator present in > JZ4780 SoC. > > Signed-off-by: PrasannaKumar Muralidharan > --- >

Re: [PATCH v6 0/5] /dev/random - a new approach

Hi! > > From my point of view, it would make sense to factor time from RTC and > > mac addresses into the initial hash. Situation in the paper was so bad > > some devices had _completely identical_ keys. We should be able to do > > better than that. > > We fixed that **years** ago. In fact, the

Re: [PATCHv3 net-next 0/4] crypto/chcr: Add support for Chelsio Crypto Driver

From: Herbert Xu Date: Fri, 19 Aug 2016 14:15:43 +0800 > On Thu, Aug 18, 2016 at 11:11:01PM -0700, David Miller wrote: >> From: Hariprasad Shenai >> Date: Wed, 17 Aug 2016 12:33:02 +0530 >> >> > This patch series adds support for Chelsio

Re: [PATCHv3 net-next 0/4] crypto/chcr: Add support for Chelsio Crypto Driver

On Thu, Aug 18, 2016 at 11:11:01PM -0700, David Miller wrote: > From: Hariprasad Shenai > Date: Wed, 17 Aug 2016 12:33:02 +0530 > > > This patch series adds support for Chelsio Crypto driver. > > Herbert, what do you want to do with this? I can push it via > net-next

Re: [PATCHv3 net-next 3/4] chcr: Support for Chelsio's Crypto Hardware

On Wed, Aug 17, 2016 at 12:33:05PM +0530, Hariprasad Shenai wrote: > The Chelsio's Crypto Hardware can perform the following operations: > SHA1, SHA224, SHA256, SHA384 and SHA512, HMAC(SHA1), HMAC(SHA224), > HMAC(SHA256), HMAC(SHA384), HAMC(SHA512), AES-128-CBC, AES-192-CBC, > AES-256-CBC,

Re: [PATCHv3 net-next 0/4] crypto/chcr: Add support for Chelsio Crypto Driver

From: Hariprasad Shenai Date: Wed, 17 Aug 2016 12:33:02 +0530 > This patch series adds support for Chelsio Crypto driver. Herbert, what do you want to do with this? I can push it via net-next if you like. -- To unsubscribe from this list: send the line "unsubscribe