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

'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 --- drivers/crypto/cavium/nitrox/nitrox_main.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/crypto/cavium/nitrox/nitro

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

'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 --- drivers/crypto/inside-secure/safexcel.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) di

Re: random.c: LFSR polynomials are not irreducible/primitive

On Tue, Aug 15, 2017 at 10:45:17AM +0200, Stephan Mueller wrote: > Am Dienstag, 15. August 2017, 00:21:05 CEST schrieb Theodore Ts'o: > > Hi Theodore, > > > Have you looked at section 3.1.1 of the above cited paper? > > > > http://eprint.iacr.org/2012/251.pdf > > Thanks for the hint, but th

Re: random.c: LFSR polynomials are not irreducible/primitive

Am Dienstag, 15. August 2017, 00:21:05 CEST schrieb Theodore Ts'o: Hi Theodore, > Have you looked at section 3.1.1 of the above cited paper? > > http://eprint.iacr.org/2012/251.pdf Thanks for the hint, but that does not seem to solve the mystery either. When I use magma with GF(2^32), I

Re: [PATCH v5 04/19] crypto: marvell/cesa: remove redundant backlog checks on EBUSY

Le Mon, 14 Aug 2017 18:21:14 +0300, Gilad Ben-Yossef a écrit : > Now that -EBUSY return code only indicates backlog queueing > we can safely remove the now redundant check for the > CRYPTO_TFM_REQ_MAY_BACKLOG flag when -EBUSY is returned. > > Signed-off-by: Gilad Ben-Yossef Acked-by: Boris Bre

RE: [PATCH 2/3] crypto: engine - find request type with cra_type

Hi Corentin, Since I have just sent a patch to add the support of "aead_request" to crypto engine, I am wondering if your proposed change (checking cra_type instead of crypto_tfm_alg_type) and mine are compatible. It looks like they are (assuming we export crypto_aead_type): can you confirm? BR

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

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 --- drivers/crypto/rockchip/rk3288_crypto.c| 46 ++- drivers/crypto/rockchip

[PATCH v2 1/3] crypto: engine - permit to enqueue aead_request

The current crypto engine allows ablkcipher_request and ahash_request to be enqueued. Extend this to aead_request. Signed-off-by: Fabien Dessenne --- crypto/crypto_engine.c | 101 include/crypto/engine.h | 16 2 files changed, 117 inser

[PATCH v2 3/3] crypto: stm32 - Support for STM32 CRYP crypto module

This module registers block and AEAD cipher algorithms that make use of the STMicroelectronics STM32 crypto "CRYP1" hardware. The following algorithms are supported: - aes: ecb, cbc, ctr, gcm, ccm - des: ecb, cbc - tdes: ecb, cbc Signed-off-by: Fabien Dessenne --- drivers/crypto/stm32/Kconfig

[PATCH v2 2/3] dt-bindings: Document STM32 CRYP bindings

Document device tree bindings for the STM32 CRYP. Signed-off-by: Fabien Dessenne --- .../devicetree/bindings/crypto/st,stm32-cryp.txt | 20 1 file changed, 20 insertions(+) create mode 100644 Documentation/devicetree/bindings/crypto/st,stm32-cryp.txt diff --git a/Docum

[PATCH v2 0/3] STM32 CRYP crypto driver

This set of patches adds a new crypto driver for STMicroelectronics stm32 HW. This drivers uses the crypto API and provides with HW-enabled AEAD and block cipher algorithms. It makes use of the crypto engine which is upgraded in order to support AEAD requests. This driver was successfully tested w