[PATCH v2 08/10] 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| 28 +-- drivers/staging/ccree/ssi_buffer_mgr.c | 74 ++---

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

[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 v3 2/6] staging: ccree: register setkey for none hash macs

The original ccree driver was registering a useless setkey method even for non-MAC hash transformations. Somewhere around v4.9 a check was added that failed hash operations if a setkey method was registered but was not called, so during the initial upstream port code was added to only register the

Re: [PATCH v2 2/7] staging: ccree: register setkey for none hash macs

On Fri, Jun 23, 2017 at 7:29 PM, Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote: > On Thu, Jun 22, 2017 at 04:36:56PM +0300, Gilad Ben-Yossef wrote: >> Fix a bug where the transformation init code did >> not register a setkey method for none hash based MACs. >

Re: [PATCH v2 2/7] staging: ccree: register setkey for none hash macs

On Thu, Jun 22, 2017 at 04:36:56PM +0300, Gilad Ben-Yossef wrote: > Fix a bug where the transformation init code did > not register a setkey method for none hash based MACs. "none hash based MACs"? Is that the correct language, I don't understand it, sorry, can you expand on it

[PATCH v2 2/7] staging: ccree: register setkey for none hash macs

Fix a bug where the transformation init code did not register a setkey method for none hash based MACs. Fixes commit 50cfbbb7e627 ("staging: ccree: add ahash support"). Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com> --- drivers/staging/ccree

[PATCH 2/7] staging: ccree: register setkey for none hash macs

Fix a bug where the transformation init code did not register a setkey method for none hash based MACs. Fixes commit 50cfbbb7e627 ("staging: ccree: add ahash support"). Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com> --- drivers/staging/ccree

[PATCH v2 4/4] crypto: Documentation: fix none signal safe sample

The sample code was showing use of wait_for_completion_interruptible() for waiting for an async. crypto op to finish. However, if a signal arrived it would free the buffers used even while crypto HW might still DMA from/into the buffers. Resolve this by using wait_for_completion() instead.

[PATCH v2 4/4] crypto: Documentation: fix none signal safe sample

The sample code was showing use of wait_for_completion_interruptible() for waiting for an async. crypto op to finish. However, if a signal arrived it would free the buffers used even while crypto HW might still DMA from/into the buffers. Resolve this by using wait_for_completion() instead.

Re: [PATCH 4/4] crypto: Documentation: fix none signal safe sample

On Thu, May 11, 2017 at 02:53:45PM +0300, Gilad Ben-Yossef wrote: > The sample code was showing use of wait_for_completion_interruptible() > for waiting for an async. crypto op to finish. However, if a signal > arrived it would free the buffers used even while crypto HW might > still DMA from/into

[PATCH 4/4] crypto: Documentation: fix none signal safe sample

The sample code was showing use of wait_for_completion_interruptible() for waiting for an async. crypto op to finish. However, if a signal arrived it would free the buffers used even while crypto HW might still DMA from/into the buffers. Resolve this by using wait_for_completion() instead.

Re: (none)

On Wed, Jun 01, 2016 at 02:59:21AM -0400, Jeffrey Walton wrote: > > $ cat /proc/modules | egrep -i '(via|padlock|rng)' > padlock_sha 16384 0 - Live 0x > padlock_aes 16384 0 - Live 0x > via_cputemp 16384 0 - Live 0x > hwmon_vid 16384 1 via_cputemp, Live 0x > via_rng

Re: (none)

Am Mittwoch, 1. Juni 2016, 02:59:21 schrieb Jeffrey Walton: Hi Jeffrey, > On Wed, Jun 1, 2016 at 2:19 AM, Herbert Xu wrote: > > On Wed, Jun 01, 2016 at 07:53:38AM +0200, Stephan Mueller wrote: > >> I thought via-rng.c covers the VIA Padlock RNG? > > > > Indeed,

Re: (none)

On Wed, Jun 1, 2016 at 2:19 AM, Herbert Xu wrote: > On Wed, Jun 01, 2016 at 07:53:38AM +0200, Stephan Mueller wrote: >> >> I thought via-rng.c covers the VIA Padlock RNG? > > Indeed, you're quite right. In that case Jeffrey was the via-rng > driver loaded? $ cat

Re: (none)

On Wed, Jun 01, 2016 at 07:53:38AM +0200, Stephan Mueller wrote: > > I thought via-rng.c covers the VIA Padlock RNG? Indeed, you're quite right. In that case Jeffrey was the via-rng driver loaded? Thanks, -- Email: Herbert Xu Home Page:

Re: (none)

Am Mittwoch, 1. Juni 2016, 12:59:43 schrieb Herbert Xu: Hi Herbert, > Jeffrey Walton wrote: > > Please forgive my ignorance here... > > > > I have test system with a VIA C7-M processor and PM-400 chipset. This > > is one of those Thin Client/Internet of Things processor and

Re: (none)

Jeffrey Walton wrote: > Please forgive my ignorance here... > > I have test system with a VIA C7-M processor and PM-400 chipset. This > is one of those Thin Client/Internet of Things processor and chipsets > I test security libraries on (like OpenSSL, Cryptlib and Crypto++).