Re: [PATCH 1/2] crypto: Make hwrng choose rng source by quality.

Hi Harald, Can you split this patch into two? One patch to choose rng based on the quality and another for not overriding user decided rng. Some more minor comments below. On 29 June 2017 at 15:33, Harald Freudenberger wrote: > The hwrng core implementation currently

[PATCH] crypto: arm64/gcm - implement native driver using v8 Crypto Extensions

Currently, the AES-GCM implementation for arm64 systems that support the ARMv8 Crypto Extensions is based on the generic GCM module, which combines the AES-CTR implementation using AES instructions with the PMULL based GHASH driver. This is suboptimal, given the fact that the input data needs to

[PATCH v2] staging: ccree: Use __func__ instead of function name

From: Karthik Tummala Fixed following checkpatch.pl warning: WARNING: Prefer using '"%s...", __func__' to using the function's name, in a string It is prefered to use '%s & __func__' instead of function name for logging. Signed-off-by: Karthik Tummala

[PATCH v3 RESEND 5/5] crypto: ccp - remove ccp_present() check from device initialize

Since SP device driver supports multiples devices (e.g CCP, PSP), we should not fail the driver init just because CCP device is not found. Signed-off-by: Brijesh Singh --- drivers/crypto/ccp/sp-dev.c | 12 1 file changed, 12 deletions(-) diff --git

[PATCH v3 RESEND 4/5] crypto: ccp - rename ccp driver initialize files as sp device

CCP device initializes is now integerated into higher level SP device, to avoid the confusion lets rename the ccp driver initialization files (ccp-platform.c->sp-platform.c, ccp-pci.c->sp-pci.c). The patch does not make any functional changes other than renaming file and structures Signed-off-by:

[PATCH v3 RESEND 3/5] crypto: cpp - Abstract interrupt registeration

The CCP and PSP devices part of AMD Secure Procesor may share the same interrupt. Hence we expand the SP device to register a common interrupt handler and provide functions to CCP and PSP devices to register their interrupt callback which will be invoked upon interrupt. Signed-off-by: Brijesh

[PATCH v3 RESEND 2/5] crypto: ccp - Introduce the AMD Secure Processor device

The CCP device is part of the AMD Secure Processor. In order to expand the usage of the AMD Secure Processor, create a framework that allows functional components of the AMD Secure Processor to be initialized and handled appropriately. Signed-off-by: Brijesh Singh ---

[PATCH v3 RESEND 1/5] crypto: ccp - Use devres interface to allocate PCI/iomap and cleanup

Update pci and platform files to use devres interface to allocate the PCI and iomap resources. Also add helper functions to consolicate module init, exit and power mangagement code duplication. Signed-off-by: Brijesh Singh --- drivers/crypto/ccp/ccp-dev-v3.c | 7 +++

[PATCH v3 RESEND 0/5] Introduce AMD Secure Processor device

(Copying Tom Lendacky) CCP device (drivers/crypto/ccp/ccp.ko) is part of AMD Secure Processor, which is not dedicated solely to crypto. The AMD Secure Processor includes CCP and PSP (Platform Secure Processor) devices. This patch series adds a framework that allows functional component of the

[PATCH v3 5/5] crypto: ccp - remove ccp_present() check from device initialize

Since SP device driver supports multiples devices (e.g CCP, PSP), we should not fail the driver init just because CCP device is not found. Signed-off-by: Brijesh Singh --- drivers/crypto/ccp/sp-dev.c | 12 1 file changed, 12 deletions(-) diff --git

[PATCH v3 3/5] crypto: cpp - Abstract interrupt registeration

The CCP and PSP devices part of AMD Secure Procesor may share the same interrupt. Hence we expand the SP device to register a common interrupt handler and provide functions to CCP and PSP devices to register their interrupt callback which will be invoked upon interrupt. Signed-off-by: Brijesh

[PATCH v3 0/5] Introduce AMD Secure Processor device

CCP device (drivers/crypto/ccp/ccp.ko) is part of AMD Secure Processor, which is not dedicated solely to crypto. The AMD Secure Processor includes CCP and PSP (Platform Secure Processor) devices. This patch series adds a framework that allows functional component of the AMD Secure Processor to be

[PATCH v3 2/5] crypto: ccp - Introduce the AMD Secure Processor device

The CCP device is part of the AMD Secure Processor. In order to expand the usage of the AMD Secure Processor, create a framework that allows functional components of the AMD Secure Processor to be initialized and handled appropriately. Signed-off-by: Brijesh Singh ---

[PATCH v3 4/5] crypto: ccp - rename ccp driver initialize files as sp device

CCP device initializes is now integerated into higher level SP device, to avoid the confusion lets rename the ccp driver initialization files (ccp-platform.c->sp-platform.c, ccp-pci.c->sp-pci.c). The patch does not make any functional changes other than renaming file and structures Signed-off-by:

[PATCH v3 1/5] crypto: ccp - Use devres interface to allocate PCI/iomap and cleanup

Update pci and platform files to use devres interface to allocate the PCI and iomap resources. Also add helper functions to consolicate module init, exit and power mangagement code duplication. Signed-off-by: Brijesh Singh --- drivers/crypto/ccp/ccp-dev-v3.c | 7 +++

Re: wait in atomic context for an i2c crypto device to finish its execution

On 29.06.2017 13:12, Gilad Ben-Yossef wrote: Perhaps I missed something but it sounds like a classic case to use a work queue: Makes sense, thanks! ta

[PATCH v3 0/4] make io{read|write}64 more globally usable

Hi, Here's my third attempt. This time we add functions to io-64-nonatomic-* which call io{read|write}32 twice so that the pio is done correctly. I've also included a patch that adds these functions to the generic iomap library so that readq/writeq can be used while still splitting pio

[PATCH v3 1/4] 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 v3 2/4] 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 v3 3/4] 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 Cc: Jon Mason Cc: Allen Hubbe Acked-by: Dave Jiang

[PATCH v3 4/4] 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-hi-lo 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

Re: [PATCH 14/14] staging: ccree: fix block comment style

On Tue, Jun 27, 2017 at 9:27 AM, Gilad Ben-Yossef wrote: > Align block comments according to coding style. > > Signed-off-by: Gilad Ben-Yossef > --- > drivers/staging/ccree/cc_hw_queue_defs.h | 8 > 1 file changed, 4 insertions(+), 4

Re: [PATCH] Stagingdriver cctree: Fix for checkpatch warning

On Tue, Jun 27, 2017 at 11:47:56AM +0530, bincy_k_phi...@yahoo.co.in wrote: > From: Bincy K Philip > > Trivial fix for Line over 80 characters > > Moved the comment to top of the definition > --- > drivers/staging/ccree/cc_hw_queue_defs.h | 3 ++- > 1 file changed,

Re: [PATCH 0/2] staging: ccree: Fix coding style and remove warnings

On Thu, Jun 29, 2017 at 04:13:38PM +0530, karthik wrote: > On Wednesday 28 June 2017 03:15 PM, Gilad Ben-Yossef wrote: > > Thank you Karthik, > > > > On Wed, Jun 28, 2017 at 12:37 PM, wrote: > > > From: Karthik Tummala > > > > > > This patch series

Re: [PATCH 0/2] staging: ccree: Fix coding style and remove warnings

On Wednesday 28 June 2017 03:15 PM, Gilad Ben-Yossef wrote: Thank you Karthik, On Wed, Jun 28, 2017 at 12:37 PM, wrote: From: Karthik Tummala This patch series fixes coding style and removes the following checkpatch.pl warnings: Prefer using

Re: [PATCH] crypto: caam - properly set IV after {en,de}crypt

On 6/28/2017 4:42 PM, Horia Geantă wrote: > On 6/28/2017 4:27 PM, David Gstir wrote: >> Certain cipher modes like CTS expect the IV (req->info) of >> ablkcipher_request (or equivalently req->iv of skcipher_request) to >> contain the last ciphertext block when the {en,de}crypt operation is done. >>

Re: wait in atomic context for an i2c crypto device to finish its execution

On Thu, Jun 29, 2017 at 1:05 PM, Tudor Ambarus wrote: > Hi, Herbert, all, > > I need an advice. I'm writing a driver for a crypto device that > communicates over I2C. Reads and writes from/to the i2c device are > sequential, I use a lock to synchronize the requests. >

wait in atomic context for an i2c crypto device to finish its execution

Hi, Herbert, all, I need an advice. I'm writing a driver for a crypto device that communicates over I2C. Reads and writes from/to the i2c device are sequential, I use a lock to synchronize the requests. There are no interrupts for the i2c client. Each request has to send a command, to wait for

[PATCH 1/2] crypto: Make hwrng choose rng source by quality.

The hwrng core implementation currently doesn't consider the quality field of the struct hwrng. So the first registered rng is the winner and further rng sources even with much better quality are ignored. The behavior should be that always the best rng with the highest quality rate should be used

Re: [PATCH v2 3/3] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

On 6/28/2017 7:51 PM, Logan Gunthorpe wrote: > > > On 28/06/17 04:20 AM, Arnd Bergmann wrote: >> On Wed, Jun 28, 2017 at 1:02 AM, Logan Gunthorpe wrote: >>> #include >>> #include >>> -#include >>> +#include >> >> Here you include the hi-lo variant unconditionally. >>