Re: [PATCH v2 2/3] hwrng: exynos - add Samsung Exynos True RNG driver

Hi Lukasz, On 27 November 2017 at 15:28, Łukasz Stelmach wrote: > Add support for True Random Number Generator found in Samsung Exynos > 5250+ SoCs. > > Signed-off-by: Łukasz Stelmach > --- > MAINTAINERS | 7 + >

[PATCH] lib/mpi: Fix umul_ppmm() for MIPS64r6

From: James Hogan Current MIPS64r6 toolchains aren't able to generate efficient DMULU/DMUHU based code for the C implementation of umul_ppmm(), which performs an unsigned 64 x 64 bit multiply and returns the upper and lower 64-bit halves of the 128-bit result. Instead it

[PATCH v9 8/8] ntb: ntb_hw_switchtec: Cleanup 64bit IO defines to use the common header

Clean up the ifdefs which conditionally defined the io{read|write}64 functions in favour of the new common io-64-nonatomic-lo-hi header. Signed-off-by: Logan Gunthorpe Cc: Jon Mason --- drivers/ntb/hw/mscc/ntb_hw_switchtec.c | 30

[PATCH v9 2/8] 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 v9 6/8] 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 Reviewed-by: Andy Shevchenko Acked-by: Dave Jiang

[PATCH v9 3/8] 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 v9 4/8] 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 v9 7/8] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

Clean up the extra ifdefs which defined the wr_reg64 and rd_reg64 functions in non-64bit cases in favour of the new common io-64-nonatomic-lo-hi header. Signed-off-by: Logan Gunthorpe Cc: Andy Shevchenko Cc: Horia Geantă Cc:

[PATCH v9 0/8] Add io{read|write}64 to io-64-atomic headers

This is v9 of my cleanup series to push a number of instances of people defining their own io{read|write}64 functions when they don't exist in non-64bit systems. This series adds inline functions to the io-64-nonatomic headers and then cleans up the drivers that defined their own. Changes since

[PATCH v9 1/8] 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:

[PATCH v9 5/8] 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

Re: [PATCH 2/3] crypto: exynos - Improve performance of PRNG

On Tue, Dec 5, 2017 at 6:53 PM, Krzysztof Kozlowski wrote: > On Tue, Dec 05, 2017 at 05:43:10PM +0100, Łukasz Stelmach wrote: >> It was <2017-12-05 wto 14:54>, when Stephan Mueller wrote: >> > Am Dienstag, 5. Dezember 2017, 13:35:57 CET schrieb Łukasz Stelmach: >> > >> > Hi

Re: [PATCH v2 11/19] arm64: assembler: add macro to conditionally yield the NEON under PREEMPT

On 5 December 2017 at 12:45, Ard Biesheuvel wrote: > > >> On 5 Dec 2017, at 12:28, Dave Martin wrote: >> >>> On Mon, Dec 04, 2017 at 12:26:37PM +, Ard Biesheuvel wrote: >>> Add a support macro to conditionally yield the NEON (and thus the CPU)

Re: [PATCH] crypto: exynos - Icrease the priority of the driver

On Tue, Dec 05, 2017 at 05:20:46PM +0100, Łukasz Stelmach wrote: > exynos-rng is one of many implementations of stdrng. With priority as > low as 100 it isn't selected, if software implementations (DRBG) are > available. The value 300 was selected to give the PRNG priority before > software

Re: [PATCH 2/3] crypto: exynos - Improve performance of PRNG

On Tue, Dec 05, 2017 at 05:43:10PM +0100, Łukasz Stelmach wrote: > It was <2017-12-05 wto 14:54>, when Stephan Mueller wrote: > > Am Dienstag, 5. Dezember 2017, 13:35:57 CET schrieb Łukasz Stelmach: > > > > Hi Łukasz, > > > >> Use memcpy_fromio() instead of custom exynos_rng_copy_random() function

Re: [PATCH 2/3] crypto: exynos - Improve performance of PRNG

It was <2017-12-05 wto 14:54>, when Stephan Mueller wrote: > Am Dienstag, 5. Dezember 2017, 13:35:57 CET schrieb Łukasz Stelmach: > > Hi Łukasz, > >> Use memcpy_fromio() instead of custom exynos_rng_copy_random() function >> to retrieve generated numbers from the registers of PRNG. >> >> Remove

Re: [PATCH] crypto: exynos - Icrease the priority of the driver

Am Dienstag, 5. Dezember 2017, 17:20:46 CET schrieb Łukasz Stelmach: Hi Łukasz, > exynos-rng is one of many implementations of stdrng. With priority as > low as 100 it isn't selected, if software implementations (DRBG) are > available. The value 300 was selected to give the PRNG priority before

[PATCH] crypto: exynos - Icrease the priority of the driver

exynos-rng is one of many implementations of stdrng. With priority as low as 100 it isn't selected, if software implementations (DRBG) are available. The value 300 was selected to give the PRNG priority before software implementations, but allow them to be selected in FIPS-mode (fips=1 in the

Re: [crypto 4/8] chtls: CPL handler definition

Hello, On Tue, Dec 5, 2017, at 12:40, Atul Gupta wrote: > CPL handlers for TLS session, record transmit and receive This does very much looks like full TCP offload with TLS on top? It would be nice if you could give a few more details in the patch descriptions. Bye, Hannes

Re: [PATCH 4.9-stable] Revert "crypto: caam - get rid of tasklet"

On Tue, Dec 05, 2017 at 05:37:44PM +0200, Horia Geantă wrote: > commit 2b163b5bce04546da72617bfb6c8bf07a45c4b17 upstream. Now queued up, thanks! greg k-h

[PATCH 4.9-stable] Revert "crypto: caam - get rid of tasklet"

commit 2b163b5bce04546da72617bfb6c8bf07a45c4b17 upstream. This reverts commit 66d2e2028091a074aa1290d2eeda5ddb1a6c329c. Quoting from Russell's findings: https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg21136.html [quote] Okay, I've re-tested, using a different way of measuring,

Re: [crypto 4/8] chtls: CPL handler definition

On Tue, 5 Dec 2017 17:10:00 +0530 Atul Gupta wrote: > CPL handlers for TLS session, record transmit and receive > > Signed-off-by: Atul Gupta > --- > drivers/crypto/chelsio/chtls/chtls_cm.c | 2048 > +++ > 1 file

Announce loop-AES-v3.7m file/swap crypto package

loop-AES changes since previous release: - Worked around kernel interface changes on 4.14 and 4.15-rc kernels. - Fixed possible timer delete race condition at loop detach time when key scrubbing was enabled. bzip2 compressed tarball is here:

Re: [PATCH 3/3] crypto: exynos - Reseed PRNG after generating 2^16 random bytes

On Tue, Dec 5, 2017 at 1:35 PM, Łukasz Stelmach wrote: > Reseed PRNG after reading 65 kB of randomness. Although this may reduce > performance, in most casese the loss is not noticable. s/casese/cases/ s/noticable/noticeable/ Please explain why you want to reseed after 65

Re: [PATCH 2/3] crypto: exynos - Improve performance of PRNG

Am Dienstag, 5. Dezember 2017, 13:35:57 CET schrieb Łukasz Stelmach: Hi Łukasz, > Use memcpy_fromio() instead of custom exynos_rng_copy_random() function > to retrieve generated numbers from the registers of PRNG. > > Remove unnecessary invocation of cpu_relax(). > > Signed-off-by: Łukasz

Re: [PATCH 3/3] crypto: exynos - Reseed PRNG after generating 2^16 random bytes

Am Dienstag, 5. Dezember 2017, 13:35:58 CET schrieb Łukasz Stelmach: Hi Łukasz, > Reseed PRNG after reading 65 kB of randomness. Although this may reduce > performance, in most casese the loss is not noticable. Please add to the log that you also increase the timer-based reseed to 1 second?!

Re: [PATCH 2/3] crypto: exynos - Improve performance of PRNG

On Tue, Dec 5, 2017 at 1:35 PM, Łukasz Stelmach wrote: > Use memcpy_fromio() instead of custom exynos_rng_copy_random() function > to retrieve generated numbers from the registers of PRNG. > > Remove unnecessary invocation of cpu_relax(). > > Signed-off-by: Łukasz Stelmach

Re: [RFC] crypto: exynos - Icrease the priority of the driver

Am Dienstag, 5. Dezember 2017, 13:42:14 CET schrieb Łukasz Stelmach: Hi Łukasz, > exynos-rng is one of many implementations of stdrng. With priority as > low as 100 it isn't selected, if software implementations (DRBG) are > available. What about using 300? The reason is the following: in the

Re: [PATCH 1/3] crypto: exynos - Support Exynos5250+ SoCs

On Tue, Dec 5, 2017 at 1:35 PM, Łukasz Stelmach wrote: > Add support for PRNG in Exynos5250+ SoCs. > > Signed-off-by: Łukasz Stelmach > --- > .../bindings/crypto/samsung,exynos-rng4.txt| 4 ++- > drivers/crypto/exynos-rng.c

Re: [crypto 6/8] chtls: TCB and Key program

Am Dienstag, 5. Dezember 2017, 12:40:29 CET schrieb Atul Gupta: Hi Atul, > program the tx and rx key on chip. > > Signed-off-by: Atul Gupta > --- > drivers/crypto/chelsio/chtls/chtls_hw.c | 394 > 1 file changed, 394 insertions(+) >

Re: [PATCH v2 11/19] arm64: assembler: add macro to conditionally yield the NEON under PREEMPT

> On 5 Dec 2017, at 12:28, Dave Martin wrote: > >> On Mon, Dec 04, 2017 at 12:26:37PM +, Ard Biesheuvel wrote: >> Add a support macro to conditionally yield the NEON (and thus the CPU) >> that may be called from the assembler code. Given that especially the >>

[RFC] crypto: exynos - Icrease the priority of the driver

exynos-rng is one of many implementations of stdrng. With priority as low as 100 it isn't selected, if software implementations (DRBG) are available. Signed-off-by: Łukasz Stelmach --- If not 1000, what is the best value, what is the policy?

[PATCH 3/3] crypto: exynos - Reseed PRNG after generating 2^16 random bytes

Reseed PRNG after reading 65 kB of randomness. Although this may reduce performance, in most casese the loss is not noticable. Signed-off-by: Łukasz Stelmach --- drivers/crypto/exynos-rng.c | 18 ++ 1 file changed, 14 insertions(+), 4 deletions(-) diff

[PATCH 0/3] Assorted changes for Exynos PRNG driver

Hello, This is a series of patches for exynos-rng driver I've decided to create after adding support for Exynos5250+ chips. They do not strictly depend on each other, but I think it is better to send them as a single patch-set. Patch #1 Add support for PRNG in Exynos5250+ SoCs Patch #2 Improve

[PATCH 2/3] crypto: exynos - Improve performance of PRNG

Use memcpy_fromio() instead of custom exynos_rng_copy_random() function to retrieve generated numbers from the registers of PRNG. Remove unnecessary invocation of cpu_relax(). Signed-off-by: Łukasz Stelmach --- drivers/crypto/exynos-rng.c | 36

[PATCH 1/3] crypto: exynos - Support Exynos5250+ SoCs

Add support for PRNG in Exynos5250+ SoCs. Signed-off-by: Łukasz Stelmach --- .../bindings/crypto/samsung,exynos-rng4.txt| 4 ++- drivers/crypto/exynos-rng.c| 36 -- 2 files changed, 36 insertions(+), 4 deletions(-)

Re: [PATCH v2 11/19] arm64: assembler: add macro to conditionally yield the NEON under PREEMPT

On Mon, Dec 04, 2017 at 12:26:37PM +, Ard Biesheuvel wrote: > Add a support macro to conditionally yield the NEON (and thus the CPU) > that may be called from the assembler code. Given that especially the > instruction based accelerated crypto code may use very tight loops, add > some

[crypto 8/8] Kconfig Makefile

Entry for Inline TLS as another driver dependent on cxgb4 and chcr Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/Kconfig | 10 ++ drivers/crypto/chelsio/Makefile | 1 + 2 files changed, 11 insertions(+) diff --git a/drivers/crypto/chelsio/Kconfig

[crypto 6/8] chtls: TCB and Key program

program the tx and rx key on chip. Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chtls/chtls_hw.c | 394 1 file changed, 394 insertions(+) create mode 100644 drivers/crypto/chelsio/chtls/chtls_hw.c diff --git

[crypto 7/8] chtls: structure and macro definiton

Inline TLS state, connection management. Support macros definition. Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chtls/Makefile | 4 + drivers/crypto/chelsio/chtls/chtls.h| 481 drivers/crypto/chelsio/chtls/chtls_cm.h |

[crypto 4/8] chtls: CPL handler definition

CPL handlers for TLS session, record transmit and receive Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chtls/chtls_cm.c | 2048 +++ 1 file changed, 2048 insertions(+) create mode 100644 drivers/crypto/chelsio/chtls/chtls_cm.c diff

[crypto 5/8] chtls: Inline crypto request for Tx.

TLS handler for record transmit and receive. Create Inline TLS work request Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chtls/chtls_io.c | 1866 +++ 1 file changed, 1866 insertions(+) create mode 100644

[crypto 2/8] chcr: changes to chcr driver

Define the Macro for TLS Key context Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chcr_algo.h | 42 + drivers/crypto/chelsio/chcr_core.h | 55 +- include/uapi/linux/tls.h | 1 + 3 files

[crypto 3/8] chtls: ulp for Inline TLS processing

Register chtls as another tcp ULP, Based on a similar infrastructure in tcp_cong. proto_ops are defined to handle CPL to send/receive crypto request to hw. Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chtls/chtls_main.c | 585 ++ 1

[crypto 1/8] cxgb4: Inline TLS

Add new uld driver for Inline TLS support. WR is defined to submit crypto request to firmware. Key area size is configured in hw-config file. Signed-off-by: Atul Gupta --- drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 18 ++-

[crypto 0/8] Chelsio inline TLS

RFC series for Chelsio Inline TLS driver (chtls.ko) Chtls driver use the available ULP infrastructure to register chtls as another ULP. Chtls use the TCP Sockets to transmit and receive TLS record. TCP proto_ops is extended to offload TLS record. T6 adapter provide the following features:

[crypto] chcr: fix a type cast error

fix a type cast error for queue descriptor Reported-by: Dan Carpenter Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chcr_ipsec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/chelsio/chcr_ipsec.c

[PATCH] crypto: chcr: select CRYPTO_GF128MUL

Without the gf128mul library support, we can run into a link error: drivers/crypto/chelsio/chcr_algo.o: In function `chcr_update_tweak': chcr_algo.c:(.text+0x7e0): undefined reference to `gf128mul_x8_ble' This adds a Kconfig select statement for it, next to the ones we already have. Fixes:

Re: [PATCH v3 1/3] dt-bindings: hwrng: Add Samsung Exynos 5250+ True RNG bindings

On Tue, Dec 5, 2017 at 10:30 AM, Łukasz Stelmach wrote: > It was <2017-12-04 pon 14:13>, when Krzysztof Kozlowski wrote: >> On Mon, Dec 4, 2017 at 1:53 PM, Łukasz Stelmach >> wrote: >>> Add binding documentation for the True Random Number