[PATCH 2/8] staging: ccree: use more readable func names

The driver was using a function naming scheme including common prefixes for driver global functions based on the code module they came from. The combination of long names with long common prefixes made the whole thing hard for a human to parse. Make the semantic change of switching to simple

[PATCH 7/8] staging: ccree: remove compare to none zero

The driver was full of code checking "if (x != 0)". Replace by "if (x)" for better readability. Signed-off-by: Gilad Ben-Yossef --- drivers/staging/ccree/ssi_aead.c| 34 +++--- drivers/staging/ccree/ssi_buffer_mgr.c | 74 ++---

[PATCH 4/8] staging: ccree: simplify buf mgr using local vars

Make the code more readable by using a local variables for commonly use expressions in the buffer manager part of the driver. Signed-off-by: Gilad Ben-Yossef --- drivers/staging/ccree/ssi_buffer_mgr.c | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-)

[PATCH 6/8] staging: ccree: simplify pm manager using local var

Make the code more readable by using a local variable. Signed-off-by: Gilad Ben-Yossef --- drivers/staging/ccree/ssi_pm.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/staging/ccree/ssi_pm.c b/drivers/staging/ccree/ssi_pm.c index

[PATCH 0/8] staging: ccree: fixes and cleanups

This is another batch of ccree fixes & cleanups. The first patch is a bug fix. All others are pure readability and coding style fixes. Gilad Ben-Yossef (8): staging: ccree: fix leak of import() after init() staging: ccree: use more readable func names staging: ccree: simplify AEAD using

[PATCH 8/8] staging: ccree: remove braces for single statement

Remove necessary braces for single statement blocks to improve code readabilty. Signed-off-by: Gilad Ben-Yossef --- drivers/staging/ccree/ssi_buffer_mgr.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c

[PATCH 3/8] staging: ccree: simplify AEAD using local var

Make the code more readable by using a local variable for commonly use expression in the AEAD part of the driver. Signed-off-by: Gilad Ben-Yossef --- drivers/staging/ccree/ssi_aead.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git

[PATCH v2] crypto: AF_ALG - remove locking in async callback

The code paths protected by the socket-lock do not use or modify the socket in a non-atomic fashion. The actions pertaining the socket do not even need to be handled as an atomic operation. Thus, the socket-lock can be safely ignored. This fixes a bug regarding scheduling in atomic as the

Re: [PATCH 11/12] hwrng: bcm2835-rng: Enable BCM2835 RNG to work on BCM63xx platforms

> Stefan Wahren hat am 7. November 2017 um 07:45 > geschrieben: > > > > Florian Fainelli hat am 6. November 2017 um 21:16 > > geschrieben: > > > > > > On 11/04/2017 11:27 AM, Stefan Wahren wrote: > > > Hi Florian > > > > > >> Florian Fainelli

[PATCH v2 00/12] bcm63xx-rng conversion to bcm2835-rng

Hi, As it usually happens when there is a fair amount of HW IP block re-use, competing implementations show up. In that case the BCM2835 HWRNG driver and the BCM63xx RNG driver have exactly the same register offsets and this is indeed the same piece of HW. This patch series first prepares the

[PATCH v2 12/12] hwrng: bcm63xx-rng: Remove since bcm2835-rng takes over

bcm2835-rng is now capable of supporting the BCM63xx hardware, so remove the driver which duplicates the same functionality. Signed-off-by: Florian Fainelli --- drivers/char/hw_random/Kconfig | 13 --- drivers/char/hw_random/Makefile | 1 -

[PATCH v2 03/12] hwrng: bcm2835-rng: Move enabling to hwrng::init

We should be moving the enabling of the HWRNG into a hwrng::init callback since we can be disabled and enabled every time a different hwrng is selected in the system. Signed-off-by: Florian Fainelli --- drivers/char/hw_random/bcm2835-rng.c | 16 1 file

[PATCH v2 10/12] dt-bindings: rng: Incorporate brcm,bcm6368.txt binding

Since the same block is used on BCM2835 and BCM6368, merge the bindings and remove the brcm,bcm6368.txt binding document. Acked-by: Rob Herring Signed-off-by: Florian Fainelli --- .../devicetree/bindings/rng/brcm,bcm2835.txt | 22

Re: [PATCH 7/8] staging: ccree: remove compare to none zero

On Tue, Nov 07, 2017 at 09:40:03AM +, Gilad Ben-Yossef wrote: > diff --git a/drivers/staging/ccree/ssi_aead.c > b/drivers/staging/ccree/ssi_aead.c > index f1a3976..e9d03ee 100644 > --- a/drivers/staging/ccree/ssi_aead.c > +++ b/drivers/staging/ccree/ssi_aead.c > @@ -240,7 +240,7 @@ static

Re: [PATCH 3/8] staging: ccree: simplify AEAD using local var

On Tue, Nov 07, 2017 at 09:39:59AM +, Gilad Ben-Yossef wrote: > Make the code more readable by using a local variable > for commonly use expression in the AEAD part of the driver. > > Signed-off-by: Gilad Ben-Yossef > --- > drivers/staging/ccree/ssi_aead.c | 10

Re: [PATCH 6/8] staging: ccree: simplify pm manager using local var

On Tue, Nov 07, 2017 at 09:40:02AM +, Gilad Ben-Yossef wrote: > --- a/drivers/staging/ccree/ssi_pm.c > +++ b/drivers/staging/ccree/ssi_pm.c > @@ -90,20 +90,24 @@ int cc_pm_resume(struct device *dev) > int cc_pm_get(struct device *dev) > { > int rc = 0; > + struct ssi_drvdata

Re: [PATCH 5/8] staging: ccree: fold common code into function

On Tue, Nov 07, 2017 at 09:40:01AM +, Gilad Ben-Yossef wrote: > @@ -669,21 +690,12 @@ void cc_unmap_aead_request(struct device *dev, struct > aead_request *req) > } > if (drvdata->coherent && > (areq_ctx->gen_ctx.op_type == DRV_CRYPTO_DIRECTION_DECRYPT) && > -

Re: [PATCH 2/8] staging: ccree: use more readable func names

On Tue, Nov 07, 2017 at 09:39:58AM +, Gilad Ben-Yossef wrote: > @@ -780,11 +766,10 @@ static inline int ssi_buffer_mgr_aead_chain_iv( > unsigned int iv_size_to_authenc = crypto_aead_ivsize(tfm); > unsigned int iv_ofs = GCM_BLOCK_RFC4_IV_OFFSET; > /*

Re: [PATCH] lib/mpi: call cond_resched() from mpi_powm() loop

On Tue, Nov 07, 2017 at 10:38:30AM -0800, Mat Martineau wrote: > > Eric, > > On Mon, 6 Nov 2017, Eric Biggers wrote: > > >From: Eric Biggers > > > >On a non-preemptible kernel, if KEYCTL_DH_COMPUTE is called with the > >largest permitted inputs (16384 bits), the kernel

[PATCH v2] lib/mpi: call cond_resched() from mpi_powm() loop

From: Eric Biggers On a non-preemptible kernel, if KEYCTL_DH_COMPUTE is called with the largest permitted inputs (16384 bits), the kernel spends 10+ seconds doing modular exponentiation in mpi_powm() without rescheduling. If all threads do it, it locks up the system.

Re: general protection fault in asn1_ber_decoder

Eric Biggers wrote: > Hi David, you just beat me to it, but I don't think this is the best way to > fix the problem. The length check just needs to be rewritten to not > overflow. Also it seems there is another broken length check later in the > function. How about this:

[PATCH 1/8] staging: ccree: fix leak of import() after init()

crypto_ahash_import() may be called either after crypto_ahash_init() or without such call. Right now we always internally call init() as part of import(), thus leaking memory and mappings if the user has already called init() herself. Fix this by only calling init() internally if the state is not

[PATCH v2 06/12] hwrng: bcm2835-rng: Rework interrupt masking

The interrupt masking done for Northstart Plus and Northstar (BCM5301X) is moved from being a function pointer mapped to of_device_id::data into a proper part of the hwrng::init callback. While at it, we also make the of_data be a proper structure indicating the platform specifics, since the day

[PATCH v2 05/12] hwrng: bcm2835-rng: Use device managed helpers

Now that we have moved the RNG disabling into a hwrng::cleanup callback, we can use the device managed registration operation and remove our remove callback since it won't do anything necessary. Signed-off-by: Florian Fainelli --- drivers/char/hw_random/bcm2835-rng.c | 13

[PATCH v2 09/12] hwrng: bcm2835-rng: Add Broadcom MIPS I/O accessors

Broadcom MIPS HW is always strapped to match the system-wide endian such that all I/O access to this RNG block is done with the native CPU endian, account for that. Signed-off-by: Florian Fainelli --- drivers/char/hw_random/bcm2835-rng.c | 13 +++-- 1 file changed,

[PATCH v2 08/12] hwrng: bcm2835-rng: Abstract I/O accessors

In preparation for allowing BCM63xx to use this driver, we abstract I/O accessors such that we can easily change those later on. Signed-off-by: Florian Fainelli --- drivers/char/hw_random/bcm2835-rng.c | 27 +++ 1 file changed, 19 insertions(+), 8

[PATCH v2 11/12] hwrng: bcm2835-rng: Enable BCM2835 RNG to work on BCM63xx platforms

We have now incorporated all necessary functionality for the BCM63xx platforms to successfully migrate over bcm2835-rng, so add the final bits: Kconfig selection and proper platform_device device type matching to keep the same platform device name for registration to work. Signed-off-by: Florian

[PATCH v2 02/12] hwrng: bcm2835-rng: Define a driver private context

Instead of making hwrng::priv host the base register address, define a driver private context, make it per platform device instance and pass it down the different functions. Signed-off-by: Florian Fainelli --- drivers/char/hw_random/bcm2835-rng.c | 55

[PATCH v2 01/12] hwrng: bcm2835-rng: Obtain base register via resource

In preparation for consolidating bcm63xx-rng into bcm2835-rng, make sure that we obtain the base register via platform_get_resource() since we need to support the non-DT enabled MIPS-based BCM63xx DSL SoCs. Signed-off-by: Florian Fainelli ---

[PATCH v2 04/12] hwrng: bcm2835-rng: Implementation cleanup callback

We should be disabling the RNG in a hwrng::cleanup callback if we are not longer the system selected RNG, not wait until the device driver is removed. Signed-off-by: Florian Fainelli --- drivers/char/hw_random/bcm2835-rng.c | 12 +--- 1 file changed, 9

[PATCH v2 07/12] hwrng: bcm2835-rng: Manage an optional clock

One of the last steps before bcm63xx-rng can be eliminated is to manage a clock during hwrng::init and hwrng::cleanup, so fetch it in the probe function, and manage it during these two steps when valid. Signed-off-by: Florian Fainelli ---

Re: [Part2 PATCH v8 12/38] crypto: ccp: Add Platform Security Processor (PSP) device support

On 11/06/2017 12:11 PM, Brijesh Singh wrote: The Platform Security Processor (PSP) is part of the AMD Secure Processor (AMD-SP) functionality. The PSP is a dedicated processor that provides support for key management commands in Secure Encrypted Virtualization (SEV) mode, along with

Re: [Part2 PATCH v8 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support

On 11/06/2017 12:11 PM, Brijesh Singh wrote: AMD's new Secure Encrypted Virtualization (SEV) feature allows the memory contents of virtual machines to be transparently encrypted with a key unique to the VM. The programming and management of the encryption keys are handled by the AMD Secure

Re: [PATCH v2] tpm: Move Linux RNG connection to hwrng

On Tue, Nov 07, 2017 at 08:50:44AM +0530, PrasannaKumar Muralidharan wrote: > I am assuming you are talking about the following patches - using > struct tpm_chip instead of chip number and this patch. yes > I won't be able to test if struct tpm_chip usage as I don't have > multiple tpm hw in

Re: [PATCH] lib/mpi: call cond_resched() from mpi_powm() loop

Eric, On Mon, 6 Nov 2017, Eric Biggers wrote: From: Eric Biggers On a non-preemptible kernel, if KEYCTL_DH_COMPUTE is called with the largest permitted inputs (16384 bits), the kernel spends 10+ seconds doing modular exponentiation in mpi_powm() without rescheduling.

Re: [PATCH v5 2/2] crypto: stm32 - Support for STM32 CRYP crypto module

On 22/10/17 09:26, Corentin Labbe wrote: > On Thu, Oct 19, 2017 at 05:10:30PM +0200, Fabien Dessenne wrote: >> This module registers block cipher algorithms that make use of the >> STMicroelectronics STM32 crypto "CRYP1" hardware. >> The following algorithms are supported: >> - aes: ecb, cbc,

Re: [PATCH v2] tpm: Move Linux RNG connection to hwrng

On Sun, Nov 05, 2017 at 07:27:04PM -0700, Jason Gunthorpe wrote: > On Sun, Nov 05, 2017 at 01:05:06PM +0200, Jarkko Sakkinen wrote: > > > I asked to create a series for a reason. Now this doesn't apply because I > > don't have an ancestor in my git history. > > It would be unusual for me to put