Re: [PATCH] crypto: qat Fix typo othewise-otherwise
On Fri, Jul 24, 2015 at 01:18:26PM -0700, Tadeusz Struk wrote: From: Ahsan Atta ahsan.a...@intel.com Signed-off-by: Ahsan Atta ahsan.a...@intel.com Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com Applied. -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: qat - remove redundant struct elem
On Fri, Jul 24, 2015 at 01:18:25PM -0700, Tadeusz Struk wrote: From: Bruce Allan bruce.w.al...@intel.com The element pci_dev_id in the struct adf_hw_device_data is redundant since the PCI device id can be retrieved from the struct pci_dev. Signed-off-by: Bruce Allan bruce.w.al...@intel.com Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com Applied. -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: qat - remove unused define
On Fri, Jul 24, 2015 at 01:18:25PM -0700, Tadeusz Struk wrote: From: Bruce Allan bruce.w.al...@intel.com Signed-off-by: Bruce Allan bruce.w.al...@intel.com Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com Applied. -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: qat - remove unnecessary list iteration
On Mon, Jul 27, 2015 at 12:58:32PM -0700, Tadeusz Struk wrote: From: Bruce Allan bruce.w.al...@intel.com There's no need to iterate through the list for instances in the accel_table since the number of devices is already known in this file. Signed-off-by: Bruce Allan bruce.w.al...@intel.com Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com Applied. -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hwrng: correct error check of kthread_run call
On Fri, Jul 24, 2015 at 01:13:30PM +0200, Martin Schwidefsky wrote: The kthread_run() function can return two different error values but the hwrng core only checks for -ENOMEM. If the other error value -EINTR is returned it is assigned to hwrng_fill and later used on a kthread_stop() call which naturally crashes. Signed-off-by: Martin Schwidefsky schwidef...@de.ibm.com Applied to crypto. -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ath9k: export HW random number generator
On Mon, Jul 27, 2015 at 7:01 AM, Stephan Mueller smuel...@chronox.de wrote: This one does not look good for a claim that the RNG produces white noise. An RNG that is wired up to /dev/hwrng should produce white noise. Either by having an appropriate noise source or by conditioning the output of the noise source. Yes. When conditioning the output, you have to be careful about the entropy claim. A very good analysis of how to deal with this is in Denker's Turbid paper: http://www.av8n.com/turbid/ In particular, see section 4.2 on Saturation However, the hwrandom framework does not provide any conditioning logic. At first sight, this sounds like a blunder to me, but I have not looked at hwrandom at all. Is there a rationale? For example, not building conditioning into that driver would make perfect sense if the output were just being fed into the random(4) which does plenty of mixing. The only problem then would be to make sure of giving random(4) reasonable entropy estimates. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
