Re: [PATCH] crypto: testmgr - fix overlap in chunked tests again

On Thu, Dec 08, 2016 at 08:23:52AM +, Ard Biesheuvel wrote: > Commit 7e4c7f17cde2 ("crypto: testmgr - avoid overlap in chunked tests") > attempted to address a problem in the crypto testmgr code where chunked > test cases are copied to memory in a way that results in overlap. > > However, the

Re: [PATCH] crypto: algif_aead - fix uninitialized variable warning

On Thu, Dec 08, 2016 at 07:09:44AM +0100, Stephan Müller wrote: > In case the user provided insufficient data, the code may return > prematurely without any operation. In this case, the processed > data indicated with outlen is zero. > > Reported-by: Stephen Rothwell >

[PATCH 0/2] crypto: arm64/ARM: NEON accelerated ChaCha20

Another port of existing x86 SSE code to NEON, again both for arm64 and ARM. ChaCha20 is a stream cipher described in RFC 7539, and is intended to be an efficient software implementable 'standby cipher', in case AES cannot be used. This NEON implementation is almost 2x as fast as the generic C

[PATCH] crypto: testmgr - fix overlap in chunked tests again

Commit 7e4c7f17cde2 ("crypto: testmgr - avoid overlap in chunked tests") attempted to address a problem in the crypto testmgr code where chunked test cases are copied to memory in a way that results in overlap. However, the fix recreated the exact same issue for other chunked tests, by putting

crypto regression?

: 300 refcnt : 1 selftest : passed internal : no type : ablkcipher async: yes blocksize: 16 min keysize : 32 max keysize : 64 ivsize : 16 geniv: and no output from the test manager in the boot log. Whereas on 4.9.0-rc8-next-20161208, we get

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

On Thu, Dec 08, 2016 at 05:06:18PM +0800, Herbert Xu wrote: > On Wed, Dec 07, 2016 at 01:51:27PM +0100, Corentin Labbe wrote: > > > > So I must expose it as a crypto_rng ? > > If it is to be exposed at all then algif_rng would be the best > place. > I have badly said my question. So I need to

Re: [PATCH] linux/types.h: enable endian checks for all sparse builds

On Thu, Dec 08, 2016 at 06:38:11AM +, Bart Van Assche wrote: > On 12/07/16 21:54, Michael S. Tsirkin wrote: > > On Thu, Dec 08, 2016 at 05:21:47AM +, Bart Van Assche wrote: > >> Additionally, there are notable exceptions to the rule that most drivers > >> are endian-clean, e.g.

Re: [PATCH] linux/types.h: enable endian checks for all sparse builds

On 12/07/16 21:54, Michael S. Tsirkin wrote: > On Thu, Dec 08, 2016 at 05:21:47AM +, Bart Van Assche wrote: >> Additionally, there are notable exceptions to the rule that most drivers >> are endian-clean, e.g. drivers/scsi/qla2xxx. I would appreciate it if it >> would remain possible to check

Re: [PATCH v1 2/2] crypto: mediatek - add DT bindings documentation

Hello, On Mon, 2016-12-05 at 11:18 +0100, Matthias Brugger wrote: > > On 05/12/16 08:01, Ryder Lee wrote: > > Add DT bindings documentation for the crypto driver > > > > Signed-off-by: Ryder Lee > > --- > > .../devicetree/bindings/crypto/mediatek-crypto.txt | 32 > >

Re: [PATCH v1 1/2] Add crypto driver support for some MediaTek chips

Hello, On Mon, 2016-12-05 at 09:52 +0100, Corentin Labbe wrote: > Hello > > I have two minor comment. > > On Mon, Dec 05, 2016 at 03:01:23PM +0800, Ryder Lee wrote: > > This adds support for the MediaTek hardware accelerator on > > mt7623/mt2701/mt8521p SoC. > > > > This driver currently

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

On Wed, Dec 07, 2016 at 01:51:27PM +0100, Corentin Labbe wrote: > > So I must expose it as a crypto_rng ? If it is to be exposed at all then algif_rng would be the best place. > Could you explain why PRNG must not be used as hw_random ? The hwrng interface was always meant to be an interface

Re: crypto regression?

On Thu, Dec 08, 2016 at 11:41:55AM +0100, Cyrille Pitchen wrote: > Hi Herbert, > > Let me report a potential regression I've noticed this morning when testing > linux-next. > > I've set CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=n when compiling both kernel > images. > > > On 4.9.0-rc2-next-20161028,

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

>> The hwrng interface was always meant to be an interface for real >> hardware random number generators. People rely on that so we >> should not provide bogus entropy sources through this interface. >> > > Why not adding a KCONFIG HW_RANDOM_ACCEPT_ALSO_PRNG with big warning ? > Or a HW_PRNG

Re: [PATCH] linux/types.h: enable endian checks for all sparse builds

On Thu, 8 Dec 2016 04:29:39 +0200 "Michael S. Tsirkin" wrote: > By now, linux is mostly endian-clean. Enabling endian-ness > checks for everyone produces about 200 new sparse warnings for me - > less than 10% over the 2000 sparse warnings already there. Out of curiousity: Where