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

On Tue, Nov 7, 2017 at 12:43 PM, Dan Carpenter wrote: > 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

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

Hi Dan, Thank you for reviewing the patch set. On Tue, Nov 7, 2017 at 12:30 PM, Dan Carpenter wrote: > > 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( > >

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

On Wed, 8 Nov 2017, Eric Biggers wrote: On Wed, Nov 08, 2017 at 08:17:12PM +, David Howells wrote: Eric Biggers wrote: This probably should be grouped with my series "crypto: dh - input validation fixes", as this is also a fix for Diffie-Hellman. I was actually

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

Stefan Wahren writes: > Hi Florian, > >> Florian Fainelli hat am 8. November 2017 um 01:44 >> geschrieben: >> >> >> The interrupt masking done for Northstart Plus and Northstar (BCM5301X) >> is moved from being a function pointer mapped to

Re: general protection fault in asn1_ber_decoder

On Mon, Nov 06, 2017 at 10:36:00AM -0800, syzbot wrote: > > syzbot will keep track of this bug report. > Once a fix for this bug is committed, please reply to this email with: > #syz fix: exact-commit-title > To mark this as a duplicate of another syzbot report, please reply with: > #syz dup:

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

On Wed, Nov 08, 2017 at 08:17:12PM +, David Howells wrote: > Eric Biggers wrote: > > > This probably should be grouped with my series "crypto: dh - input > > validation > > fixes", as this is also a fix for Diffie-Hellman. I was actually expecting > > Herbert Xu to

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

Eric Biggers wrote: > This probably should be grouped with my series "crypto: dh - input validation > fixes", as this is also a fix for Diffie-Hellman. I was actually expecting > Herbert Xu to take these patches, as Diffie-Hellman is now part of the crypto > API

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

Hi Florian, > Florian Fainelli hat am 8. November 2017 um 01:44 > geschrieben: > > > 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

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

Florian Fainelli writes: > bcm2835-rng is now capable of supporting the BCM63xx hardware, so remove > the driver which duplicates the same functionality. > > Signed-off-by: Florian Fainelli Assuming Stefan's testing says that the .name handling you

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

Florian Fainelli writes: > In preparation for allowing BCM63xx to use this driver, we abstract I/O > accessors such that we can easily change those later on. This may even be a fix on rpi, since i/o from different devices can get reordered and you're using the barrier

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

Florian Fainelli writes: > 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: [PATCH v2 06/12] hwrng: bcm2835-rng: Rework interrupt masking

Florian Fainelli writes: > 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

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

Florian Fainelli writes: > 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. 3-5 are: Reviewed-by: Eric Anholt

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

Florian Fainelli writes: > 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 > --- >

Re: [PATCH RESEND 4/4] dma: caam: add dma memcpy driver

On 10/31/2017 2:01 PM, Vinod Koul wrote: > On Mon, Oct 30, 2017 at 03:46:54PM +0200, Horia Geantă wrote: > >> @@ -600,6 +600,23 @@ config ZX_DMA >> help >>Support the DMA engine for ZTE ZX family platform devices. >> >> +config CRYPTO_DEV_FSL_CAAM_DMA > > File is sorted

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

Eric Biggers wrote: > 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

Re: [PATCH v2 1/3] staging: ccree: copy IV to DMAable memory

On Wed, Nov 08, 2017 at 01:54:03PM +0200, Gilad Ben-Yossef wrote: > > As a HW based crypto driver maintainer I sympathize, but let's play > devil's advocate for a second here: > > In the current state, HW based crypto drivers need to allocate a buffer > and copy the IV, because they don't know if

Re: [PATCH v2 1/3] staging: ccree: copy IV to DMAable memory

Hi, On Wed, Nov 8, 2017 at 12:26 PM, Horia Geantă wrote: > On 11/2/2017 10:14 AM, Gilad Ben-Yossef wrote: >> We are being passed an IV buffer from unknown origin, which may be >> stack allocated and thus not safe for DMA. Allocate a DMA safe >> buffer for the IV and use

Re: [PATCH v2 1/3] staging: ccree: copy IV to DMAable memory

On 11/2/2017 10:14 AM, Gilad Ben-Yossef wrote: > We are being passed an IV buffer from unknown origin, which may be > stack allocated and thus not safe for DMA. Allocate a DMA safe > buffer for the IV and use that instead. > IIUC this fixes only the (a)blkcipher / skcipher algorithms. What about

[bug report] crypto: chelsio - Move DMA un/mapping to chcr from lld cxgb4 driver

Hello Harsh Jain, This is a semi-automatic email about new static checker warnings. The patch 2f47d5804311: "crypto: chelsio - Move DMA un/mapping to chcr from lld cxgb4 driver" from Oct 8, 2017, leads to the following Smatch complaint: drivers/crypto/chelsio/chcr_algo.c:562