Entropy sources (was: /dev/random - a new approach)

On Fri, Aug 19, 2016 at 1:20 PM, H. Peter Anvin wrote: > On 08/18/16 22:56, Herbert Xu wrote: >> On Thu, Aug 18, 2016 at 10:49:47PM -0400, Theodore Ts'o wrote: >>> >>> That really depends on the system. We can't assume that people are >>> using systems with a 100Hz clock

Re: [PATCH v6 0/5] /dev/random - a new approach

On Fri, Aug 19, 2016 at 10:20:18AM -0700, H. Peter Anvin wrote: > On 08/18/16 22:56, Herbert Xu wrote: > > On Thu, Aug 18, 2016 at 10:49:47PM -0400, Theodore Ts'o wrote: > >> > >> That really depends on the system. We can't assume that people are > >> using systems with a 100Hz clock interrupt.

[PATCH] hw_random: omap3-rom-rng.c: Remove obsoleted functions

Remove omap3_rom_rng_data_present method as it was returning 1 always. Use .read callback instead of .data_read callback. This avoids use of obsolete callbacks. This patch is not tested with hardware as I don't have access to it. Signed-off-by: PrasannaKumar Muralidharan

[PATCH -next] crypto: drbg - fix error return code

Fix to return a negative error code from the error handling case instead of 0. Signed-off-by: Wei Yongjun --- crypto/drbg.c | 16 +++- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/crypto/drbg.c b/crypto/drbg.c index edf3ce0..fb33f7d 100644 ---

[PATCH -next v2] crypto: sun4i-ss - fix missing unlock on error in sun4i_hash()

Add the missing unlock before return from function sun4i_hash() in the error handling case. Fixes: 477d9b2e591b ("crypto: sun4i-ss - unify update/final function") Signed-off-by: Wei Yongjun --- v1 -> v2: goto release_ss as LABBE Corentin's suggestion ---

Re: [PATCH 2/2] crypto: marvell - Don't break chain for computable last ahash requests

On Thu, 18 Aug 2016 14:12:14 +0200 Romain Perier wrote: > Currently, the driver breaks chain for all kind of hash requests in order > to don't override intermediate states of partial ahash updates. However, > some final ahash requests can be directly processed

Re: [PATCH 1/2] crypto: marvell - Use an unique pool to copy results of requests

Hi Romain, On Thu, 18 Aug 2016 14:12:13 +0200 Romain Perier wrote: > So far, we used a dedicated dma pool to copy the result of outer IV for > cipher requests. Instead of using a dma pool per outer data, we prefer > use a common dma pool that contains the part