Re: What should be the algo priority

On Tue, Apr 4, 2017 at 6:07 PM, Stephan Müller wrote: > Am Dienstag, 4. April 2017, 09:53:17 CEST schrieb Harsh Jain: > > Hi Harsh, > >> Hi, >> >> Do we have any guidelines documented to decide what should be the >> algorithm priority. Specially for authenc

[PATCH v2 2/3] hw_random: timeriomem_rng: Shorten verbose type and variable names

No functional changes. Signed-off-by: Rick Altherr --- Changes in v2: - Split type and variable renames into separate patch drivers/char/hw_random/timeriomem-rng.c | 27 +-- 1 file changed, 13 insertions(+), 14 deletions(-) diff --git

[PATCH v2 1/3] hw_random: Migrate timeriomem_rng to new API

Preserves the existing behavior of only returning 32-bits per call. Signed-off-by: Rick Altherr --- Changes in v2: - Split API migration into separate patch drivers/char/hw_random/timeriomem-rng.c | 60 - 1 file changed, 30 insertions(+),

[PATCH v2 3/3] hw_random: timeriomem_rng: Improve performance for sub-jiffie update periods

Some hardware RNGs provide a single register for obtaining random data. Instead of signaling when new data is available, the reader must wait a fixed amount of time between reads for new data to be generated. timeriomem_rng implements this scheme with the period specified in platform data or

[PATCH v2 0/3] hw_random: timeriomem_rng: Migrate to new API and improve performance

AST2400 can generate 32-bits of random data every 1us. Original driver was limited to one 32-bit read every jiffie due to deprecated API and use of timers. Migrating to new hwrng API and switching to hrtimers improves read performance of /dev/hwrng to 13Mb/s. Changes in v2: - Split API

Re: [PATCH 4/5] crypto/nx: Add P9 NX support for 842 compression engine.

Michael, Thanks for the review and comments. On 04/04/2017 03:55 AM, Michael Ellerman wrote: > Hi Haren, > > A few comments ... > > Haren Myneni writes: > >> diff --git a/arch/powerpc/include/asm/vas.h b/arch/powerpc/include/asm/vas.h >> index 4e5a470..7315621

Re: [PATCH v2] crypto: arm64/sha: Add constant operand modifier to ASM_EXPORT

On 5 April 2017 at 19:34, Matthias Kaehlcke wrote: > The operand is an integer constant, make the constness explicit by > adding the modifier. This is needed for clang to generate valid code > and also works with gcc. > > Also change the constraint of the operand from 'I'

Re: [PATCH 2/7] Makefile, x86, LLVM: disable unsupported optimization flags

It "works" for the cases that I currently care about but I have to say that I am uneasy about adding -Werror to the cc-option test in this way. Suppose that one of the *other* flags that is implicitly passed to the compiler by cc-option - eg something that was explicitly specified in

Re: [PATCH 2/7] Makefile, x86, LLVM: disable unsupported optimization flags

Hi Masahiro, El Thu, Apr 06, 2017 at 03:08:26AM +0900 Masahiro Yamada ha dit: > 2017-03-17 9:15 GMT+09:00 Michael Davidson : > > Unfortunately, while clang generates a warning about these flags > > being unsupported it still exits with a status of 0 so we have > > to explicitly

[PATCH v2] crypto: arm64/sha: Add constant operand modifier to ASM_EXPORT

The operand is an integer constant, make the constness explicit by adding the modifier. This is needed for clang to generate valid code and also works with gcc. Also change the constraint of the operand from 'I' ("Integer constant that is valid as an immediate operand in an ADD instruction",

Re: [PATCH] crypto: arm64/sha: use %c constraint code in ASM_EXPORT

Hoi Ard! El Wed, Apr 05, 2017 at 06:08:37PM +0100 Ard Biesheuvel ha dit: > On 5 April 2017 at 17:56, Matthias Kaehlcke wrote: > > From: Greg Hackmann > > > > The current definition of ASM_EXPORT doesn't work properly with clang, > > according to

Re: [PATCH] crypto: arm64/sha: use %c constraint code in ASM_EXPORT

On 5 April 2017 at 18:21, Robin Murphy wrote: > On 05/04/17 18:08, Ard Biesheuvel wrote: >> Hoi Matthias! >> >> On 5 April 2017 at 17:56, Matthias Kaehlcke wrote: >>> From: Greg Hackmann >>> >>> The current definition of ASM_EXPORT

Re: [PATCH] crypto: arm64/sha: use %c constraint code in ASM_EXPORT

On 05/04/17 18:08, Ard Biesheuvel wrote: > Hoi Matthias! > > On 5 April 2017 at 17:56, Matthias Kaehlcke wrote: >> From: Greg Hackmann >> >> The current definition of ASM_EXPORT doesn't work properly with clang, >> according to

[PATCH] crypto: arm64/sha: use %c constraint code in ASM_EXPORT

From: Greg Hackmann The current definition of ASM_EXPORT doesn't work properly with clang, according to https://bugs.llvm.org//show_bug.cgi?id=27250#c3 it relies on gcc specific behavior. Change the constraint from an intermediate to an output expression which works with

Re: [PATCH] crypto: caam - fix JR platform device subsequent (re)creations

On 4/5/2017 5:14 PM, Herbert Xu wrote: > On Mon, Apr 03, 2017 at 06:12:04PM +0300, Horia Geantă wrote: >> The way Job Ring platform devices are created and released does not >> allow for multiple create-release cycles. >> >> JR0 Platform device creation error >> JR0 Platform device creation error

Re: [PATCH] crypto: arm64/sha: use %c constraint code in ASM_EXPORT

Hoi Matthias! On 5 April 2017 at 17:56, Matthias Kaehlcke wrote: > From: Greg Hackmann > > The current definition of ASM_EXPORT doesn't work properly with clang, > according to https://bugs.llvm.org//show_bug.cgi?id=27250#c3 it relies on > gcc specific

Re: [PATCH] crypto: AF_ALG: handle 0 lengths in af_alg_make_sg

Am Mittwoch, 5. April 2017, 14:50:12 CEST schrieb Herbert Xu: Hi Herbert, > So this is only possible with patches that have not been applied > yet? Correct. > In that case please fold this into whichever patch series > that needs it. Ok, let us defer it. Ciao Stephan

Re: [PATCH v2 0/5] STM32 CRC crypto driver

On Tue, Mar 21, 2017 at 04:13:26PM +0100, Fabien Dessenne wrote: > This set of patches adds a new crypto driver for STMicroelectronics stm32f746. > The drivers uses the crypto API and provides with an HW-enabled CRC32 > algorithm. > It was developed and tested (tcrypt / testmgr) on evaluation

Re: [PATCH] crypto: caam - fix invalid dereference in caam_rsa_init_tfm()

On Mon, Apr 03, 2017 at 06:30:07PM +0300, Horia Geantă wrote: > In case caam_jr_alloc() fails, ctx->dev carries the error code, > thus accessing it with dev_err() is incorrect. > > Cc: # 4.8+ > Fixes: 8c419778ab57e ("crypto: caam - add support for RSA algorithm") >

Re: [PATCH v5 0/4] gf128mul refactoring

On Sun, Apr 02, 2017 at 09:19:12PM +0200, Ondrej Mosnacek wrote: > This patchset contains the following gf128mul-related changes: > 1. The gf128mul_x_* functions are moved to gf128mul.h for performance > reasons. > 2. The gf128mul_x_ble function is fixed to use the correct block type. > 3.

Re: [PATCH] crypto: caam - fix RNG deinstantiation error checking

On Wed, Apr 05, 2017 at 11:41:03AM +0300, Horia Geantă wrote: > RNG instantiation was previously fixed by > commit 62743a4145bb9 ("crypto: caam - fix RNG init descriptor ret. code > checking") > while deinstantiation was not addressed. > > Since the descriptors used are similar, in the sense

Re: [PATCH] crypto: caam - fix JR platform device subsequent (re)creations

On Mon, Apr 03, 2017 at 06:12:04PM +0300, Horia Geantă wrote: > The way Job Ring platform devices are created and released does not > allow for multiple create-release cycles. > > JR0 Platform device creation error > JR0 Platform device creation error > caam 210.caam: no queues configured,

Re: [PATCH] crypto/nx: Update MAINTAINERS entry for 842 compression

On Sat, Apr 01, 2017 at 10:25:40AM -0700, Haren Myneni wrote: > [PATCH] crypto/nx: Update MAINTAINERS entry for 842 compression > > Signed-off-by: Haren Myneni Patch applied. Thanks. -- Email: Herbert Xu Home Page:

Re: [PATCH V2] crypto: ccp - Rearrange structure members to minimize size

On Tue, Mar 28, 2017 at 10:57:26AM -0500, Gary R Hook wrote: > The AES GCM function (in ccp-ops) requires a fair amount of > stack space, which elicits a complaint when KASAN is enabled. > Rearranging and packing a few structures eliminates the > warning. > > Signed-off-by: Gary R Hook

Re: [PATCH] crypto: ccp - Remove redundant cpu-to-le32 macros

On Tue, Mar 28, 2017 at 08:58:28AM -0500, Gary R Hook wrote: > Endianness is dealt with when the command descriptor is > copied into the command queue. Remove any occurrences of > cpu_to_le32() found elsewhere. > > Signed-off-by: Gary R Hook Patch applied. Thanks. -- Email:

Re: [PATCH v1] hw_random: Fix timeriomem_rng for sub-jiffie update periods

On Tue, Apr 04, 2017 at 02:43:07PM -0700, Rick Altherr wrote: > Some hardware RNGs provide a single register for obtaining random data. > Instead of signaling when new data is available, the reader must wait a > fixed amount of time between reads for new data to be generated. > timeriomem_rng

Re: [PATCH] crypto: AF_ALG: handle 0 lengths in af_alg_make_sg

On Sat, Apr 01, 2017 at 07:46:39PM +0200, Stephan Müller wrote: > Am Samstag, 1. April 2017, 17:04:28 CEST schrieb Stephan Müller: > > Hi Herbert, > > > Hi Herbert, > > > > If you concur with the patch, I think it should go to 4.11 as well as > > to stable. > > After checking this issue again,

Re: [7/7] crypto: caam/qi - add ablkcipher and authenc algorithms

On 04/05/2017 01:06 PM, Michael Ellerman wrote: > Laurentiu Tudor writes: > >> Hi Michael, >> >> Just a couple of basic things to check: >>- was the dtb updated to the newest? > > Possibly not, it's an automated build/boot, I'll have to check what it > does with the

Re: [PATCH] padata: avoid race in reordering

On Tue, Apr 04, 2017 at 08:26:12PM +0200, Greg KH wrote: > Any clue as to what the git commit id is? It's https://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git/commit/?h=linus=de5540d088fe97ad583cc7d396586437b32149a5 Thanks, -- Email: Herbert Xu

Re: [7/7] crypto: caam/qi - add ablkcipher and authenc algorithms

Laurentiu Tudor writes: > Hi Michael, > > Just a couple of basic things to check: > - was the dtb updated to the newest? Possibly not, it's an automated build/boot, I'll have to check what it does with the dtb. > - is the qman node present? This should be easily