Hi Stephan,
For those less perfect noise source, can't pass the FIPS test.
static int update_kernel_random(int random_step,
unsigned char *buf, fips_ctx_t *fipsctx_in)
{
unsigned char *p;
int fips;
fips = fips_run_rng_test(fipsctx_in, buf);
if (fips)
Henrique de Moraes Holschuh writes:
> IMHO, this is mightly annoying to use from inside a rngd-like utility in
> a race-free, safe way. It looks to me that ioctl() would be a much
> better interface for everything but the "enabled" functionality (which
> should be reported to the rngd-like utili
On Sat, 6 Aug 2016, Stephan Mueller wrote:
diff --git a/security/keys/internal.h b/security/keys/internal.h
index a705a7d..7659b52 100644
--- a/security/keys/internal.h
+++ b/security/keys/internal.h
@@ -259,15 +259,32 @@ static inline long keyctl_get_persistent(uid_t uid,
key_serial_t destrin
On Sat, 6 Aug 2016, Stephan Mueller wrote:
diff --git a/man/keyctl_dh_compute.3 b/man/keyctl_dh_compute.3
index b06d39e..92d358f 100644
--- a/man/keyctl_dh_compute.3
+++ b/man/keyctl_dh_compute.3
@@ -11,6 +11,8 @@
.\"
.
Hi Stephan,
Thanks. The patch that I applied have different line numbers than yours.
In any case, patch worked to get rid of Œdrbg¹ related error.
Now, fips mode is failing on self-test:
/boot/vmlinuz-4.7.0-1.tos2_5: OK
[1.296714] alg: skcipher: setkey failed on test 1 for xts(aes-asm):
flag
On Tue, 09 Aug 2016, Jason Cooper wrote:
> Perhaps a /dev/hwrng[0-9] per rng? That would lend itself nicely to a
> sysfs interface for per device quality, rate, and enabled attributes.
> e.g. /sys/class/hw_random/hwrng0/{device/,quality,rate,enabled}
IMHO, this is mightly annoying to use from ins
Am Dienstag, 9. August 2016, 19:52:46 CEST schrieb Stephan Mueller:
Hi Tapas,
I think I found the issue. Can you please test the attached patch?
---8<---
When calling the DRBG health test in FIPS mode, the Jitter RNG is not
yet present in the kernel crypto API which will cause the instantiation
Jason Cooper writes:
> On another thread, regarding the ath9k-rng (actually just the adc
> registers), Henrique asked about per-source knobs. My suggestion
> follows from that.
I'd do that with the source-specific driver instead of attempting to
route controls through hwrng. Anything else seems
Hi Keith,
On Tue, Aug 09, 2016 at 10:58:05AM -0700, Keith Packard wrote:
> Jason Cooper writes:
> > Perhaps a /dev/hwrng[0-9] per rng? That would lend itself nicely to a
> > sysfs interface for per device quality, rate, and enabled attributes.
> > e.g. /sys/class/hw_random/hwrng0/{device/,qualit
Jason Cooper writes:
> Perhaps a /dev/hwrng[0-9] per rng? That would lend itself nicely to a
> sysfs interface for per device quality, rate, and enabled attributes.
> e.g. /sys/class/hw_random/hwrng0/{device/,quality,rate,enabled}
I was interested in the data being provided for /dev/random; tha
Hi Henrique,
On Tue, Aug 09, 2016 at 07:24:58AM -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 09 Aug 2016, Stephan Mueller wrote:
> > RHEL 7 and Fedora do not adjust it. So, shall we consider those rng-tools
> > then
> > broken (at least in those large distros)?
>
> Might I humbly suggest
Am Dienstag, 9. August 2016, 17:11:09 CEST schrieb Tapas Sarangi:
Hi Tapas, Herbert,
> Hi Stephan,
>
> Thanks. I have already tried that. ‘drbg’ module is loaded fine in a
> non-fips mode. Here are output from some commands.
There is something strange going on. I have to compile the DRBG static
On Tue, Aug 09, 2016 at 03:02:27PM +0800, miaoq...@codeaurora.org wrote:
> From: Miaoqing Pan
>
> ath9k RNG will dominates all the noise sources from the real HW
> RNG, disable it by default. But we strongly recommand to enable
> it if the system without HW RNG, especially on embedded systems.
>
Hi Stephan,
Thanks. I have already tried that. ‘drbg’ module is loaded fine in a
non-fips mode. Here are output from some commands.
I see that at some point you had a patch to use CONFIG_CRYPTO_LRNG. I am
not using that, could that be a problem ?
-Tapas
[root@localhost ~]# modprobe drbg
[root@
Am Dienstag, 9. August 2016, 16:34:59 CEST schrieb Tapas Sarangi:
Hi Tapas,
> Hi Stephan,
>
> Following up from the other thread:
>
> While trying to boot in FIPS mode, kernel panics with the following
> message. So far, I don¹t have success to get more information about which
> module or symbo
Hi Keith, Herbert,
On Tue, Aug 09, 2016 at 05:50:58PM +0800, Herbert Xu wrote:
> On Mon, Jul 25, 2016 at 01:07:35PM -0700, Keith Packard wrote:
> > Instead of having only one hwrng feeding /dev/random at a time, maintain
> > a list of devices and cycle between them when filling the entropy pool.
>
Hi Stephan,
Following up from the other thread:
While trying to boot in FIPS mode, kernel panics with the following
message. So far, I don¹t have success to get more information about which
module or symbol is causing this. I haven¹t found any errors or warnings
in kernel compilation. It boots fi
Am Dienstag, 9. August 2016, 16:07:06 CEST schrieb Tapas Sarangi:
Hi Tapas,
> Hi Stephan,
>
>
> Thanks for your responses. I am past this error now.
>
> I am still NOT out of trouble. Now, test integrity fails while trying to
> get into FIPS mode. Here is the snippet of error messages. I will
Hi Stephan,
Thanks for your responses. I am past this error now.
I am still NOT out of trouble. Now, test integrity fails while trying to
get into FIPS mode. Here is the snippet of error messages. I will create
a separate thread for this,
/boot/vmlinuz-4.7.0-1.tos2_5: OK
modprobe: ERROR: could
Embarrassing! Yes, I just saw this while you are pressing send on that
replyŠ default bits were set to 4096 in x509.genkey. :-(
I am trying out with 2048 bits. I will confirm.
-Tapas
On 8/9/16, 9:55 AM, "Stephan Mueller" wrote:
>Am Dienstag, 9. August 2016, 14:39:03 CEST schrieb Tapas Sarangi
Am Dienstag, 9. August 2016, 14:39:03 CEST schrieb Tapas Sarangi:
Hi Tapas, David,
> Hi Stephan,
>
> If I understand this correctly, this (CONFIG_MODULE_SIG_HASH=“sha256")
> tells about the key size used.
> I am using “sha256”. Initially, I was using “sha512” which I thought could
> be causing p
Looking at the kernel compilation log, it seems to be generating a 4k
(4096 bits) private key, although I am specifying
CONFIG_MODULE_SIG_HASH=“sha256”. How can I generate RSA key that is within
2k-3k bits ?
Here is a snippet from the compilation log:
### Now generating an X.509 key pair to be us
Hi Stephan,
If I understand this correctly, this (CONFIG_MODULE_SIG_HASH=“sha256")
tells about the key size used.
I am using “sha256”. Initially, I was using “sha512” which I thought could
be causing problem, but I am getting same error when change it to
“sha256”.
[root@localhost ~]# grep MODULE_
On 08/09/2016 09:10 AM, Tapas Sarangi wrote:
Ps : I could not send any attachment, is it possible to send attachment to
this mailing list ?
Pretty sure that's frowned upon.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.ker
Am Dienstag, 9. August 2016, 14:10:33 CEST schrieb Tapas Sarangi:
Hi Tapas,
> Hello,
>
> I am using vanilla kernel-4.7 source. It crashes with the following when
> booted with ³fips=1 boot=/dev/sda1² option at the kernel command line
> argument.
The kernel only allows 2k and 3k RSA keys in FIPS
Hello,
I am using vanilla kernel-4.7 source. It crashes with the following when
booted with ³fips=1 boot=/dev/sda1² option at the kernel command line
argument.
[0.642411] RSA: key size not allowed in FIPS mode
[0.643099] Problem loading in-kernel X.509 certificate (-22)
[0.800524] BUG
Hi Ted,
On Tue, Aug 09, 2016 at 07:56:22AM -0400, Theodore Ts'o wrote:
> On Tue, Aug 09, 2016 at 06:30:03AM +, Pan, Miaoqing wrote:
> > Agree with Jason's point, also understand Stephan's concern. The
> > date rate can be roughly estimated by 'cat /dev/random |rngtest -c
> > 1000', the averag
Am Dienstag, 9. August 2016, 08:21:43 CEST schrieb Gary R Hook:
Hi Gary,
> Q: Is there a policy (de facto or otherwise) on adding tests to testmgr.h?
> Two cases:
>
> 1) Tests from the NIST document(s) on various ciphers and hashes wherein
> we add to an existing set of tests? For example, 3DES
Q: Is there a policy (de facto or otherwise) on adding tests to testmgr.h?
Two cases:
1) Tests from the NIST document(s) on various ciphers and hashes wherein
we add to an existing set of tests? For example, 3DES ECB mode, or AES
GCM? I suppose this question is really about, "how much is enough?"
This patch adds the ability to register templates for RNGs. RNGs are
"meta" mechanisms using raw cipher primitives. Thus, RNGs can now be
implemented as templates to allow the complete flexibility the kernel
crypto API provides.
Signed-off-by: Stephan Mueller
---
crypto/rng.c |
Add known answer tests to the testmgr for the KDF (SP800-108) cipher.
Signed-off-by: Stephan Mueller
---
crypto/testmgr.c | 226 +++
crypto/testmgr.h | 110 +++
2 files changed, 336 insertions(+)
diff --git a/crypto/tes
The SP800-108 compliant Key Derivation Function is implemented as a
random number generator considering that it behaves like a deterministic
RNG.
All three KDF types specified in SP800-108 are implemented.
The code comments provide details about how to invoke the different KDF
types.
Signed-off-
Hi,
this patch set implements all three key derivation functions defined in
SP800-108.
The implementation is provided as a template for random number generators,
since a KDF can be considered a form of deterministic RNG where the key
material is used as a seed.
With the KDF implemented as a temp
Include KDF into Kconfig and Makefile for compilation.
Signed-off-by: Stephan Mueller
---
crypto/Kconfig | 7 +++
crypto/Makefile | 1 +
2 files changed, 8 insertions(+)
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 84d7148..16f3221 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@
On Tue, Aug 09, 2016 at 06:30:03AM +, Pan, Miaoqing wrote:
> Agree with Jason's point, also understand Stephan's concern. The
> date rate can be roughly estimated by 'cat /dev/random |rngtest -c
> 1000', the average speed is .294Kibits/s. I will sent the patch
> to disable ath9k RNG by def
Romain Perier wrote:
> This patches series contains various fixes for ahash requests, dma
> operations and an important fixe in the core of the driver (cesa.c). It
> also includes some code cleanups.
All applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP
On Thu, 2016-04-08 at 06:38:15 UTC, Anton Blanchard wrote:
> From: Anton Blanchard
>
> This patch utilises the GENERIC_CPU_AUTOPROBE infrastructure
> to automatically load the crc32c-vpmsum module if the CPU supports
> it.
>
> Signed-off-by: Anton Blanchard
Applied to powerpc fixes, thanks.
h
On Tue, Aug 09, 2016 at 08:30:10AM +0100, Russell King wrote:
> While debugging setkey issues, the following warnings were found while
> trying to reinsert the caam module. Fix this by avoiding the duplicated
> cleanup in the probe path after caam_remove(), which has already cleaned
> up the resou
On Mon, Aug 08, 2016 at 06:04:01PM +0100, Russell King - ARM Linux wrote:
> This is a re-post (with hopefully bugs fixed from December's review).
> Untested, because AF_ALG appears to be broken in 4.8-rc1. Maybe
> someone can provide some hints how to test using tcrypt please?
>
> Here are furthe
On Fri, Aug 05, 2016 at 02:00:13PM +0100, Will Thomas wrote:
> Hi Herbert,
>
> This patchset includes small stability fixes, power management
> and import/export interface functions for the img-hash driver.
>
> Changes as discussed for [1/7], [2/7] and [5/7].
>
>
> Govindraj Raja (1):
> crypt
On Fri, Jul 29, 2016 at 04:32:09PM +0800, yanjiang@windriver.com wrote:
> From: Yanjiang Jin
>
> "if (!ret == template[i].fail)" is confusing to compilers (gcc5):
>
> crypto/testmgr.c: In function '__test_aead':
> crypto/testmgr.c:531:12: warning: logical not is only applied to the
> left ha
On Tue, Jul 26, 2016 at 07:09:11PM -0500, Gary R Hook wrote:
> The following series updates the CCP driver to support
> both current and new cryptographic coprocessor models.
> Refactor code to further separate device-specific code
> from driver logic, then add equivalent support for the
> new devi
On Tue, Jul 26, 2016 at 06:09:46PM -0500, Gary R Hook wrote:
> Adhere to the cryptodev comment convention.
>
> Signed-off-by: Gary R Hook
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To u
On Fri, Jul 22, 2016 at 03:32:40PM +0200, Quentin Lambert wrote:
> The first patch is a style fix, the second add calls to npe_release.
> The reason for me thinking that they are necessary is that every other
> branches
> leading to an error return are calling this function.
Both patches applied.
On Tue, Aug 09, 2016 at 08:46:15AM +1000, Michael Ellerman wrote:
> The optimised crc32c implementation depends on VMX (aka. Altivec)
> instructions, so the kernel must be built with Altivec support in order
> for the crc32c code to build.
>
> Fixes: 6dd7a82cc54e ("crypto: powerpc - Add POWER8 opt
On Tue, Aug 09, 2016 at 08:27:17AM +0100, Russell King - ARM Linux wrote:
>
> From: Russell King
> Subject: [PATCH] crypto: caam - fix non-hmac hashes
>
> Since 6de62f15b581 ("crypto: algif_hash - Require setkey before
> accept(2)"), the AF_ALG interface requires userspace to provide a key
> to a
On Tue, 09 Aug 2016, Stephan Mueller wrote:
> RHEL 7 and Fedora do not adjust it. So, shall we consider those rng-tools
> then
> broken (at least in those large distros)?
Might I humbly suggest that the kernel start providing some metatada
about the quality of the random source that userspace ca
On Thu, Aug 04, 2016 at 01:28:38PM +0300, Tero Kristo wrote:
> Context export/import are now required for ahash algorithms due to
> required support in algif_hash. Implement these for OMAP SHA driver,
> saving and restoring the internal state of the driver.
>
> Signed-off-by: Tero Kristo
> ---
>
Am Dienstag, 9. August 2016, 17:56:57 CEST schrieb Herbert Xu:
Hi Herbert,
> On Tue, Aug 09, 2016 at 11:56:08AM +0200, Stephan Mueller wrote:
> > Am Dienstag, 9. August 2016, 17:46:56 CEST schrieb Herbert Xu:
> >
> > Hi Herbert,
> >
> > > You're supposed to tweak the quality of the input. In a
Stephan Mueller wrote:
> +
> +static inline struct rng_alg *__crypto_rng_alg(struct crypto_alg *alg)
> +{
> + return container_of(alg, struct rng_alg, base);
> +}
> +
> +static inline struct rng_instance *rng_instance(
> + struct crypto_instance *inst)
> +{
> + return container_o
On Tue, Aug 09, 2016 at 11:56:08AM +0200, Stephan Mueller wrote:
> Am Dienstag, 9. August 2016, 17:46:56 CEST schrieb Herbert Xu:
>
> Hi Herbert,
> >
> > You're supposed to tweak the quality of the input. In any case,
>
> How is that tweak supposed to happen? The rngd does not allow changing th
Am Dienstag, 9. August 2016, 17:46:56 CEST schrieb Herbert Xu:
Hi Herbert,
>
> You're supposed to tweak the quality of the input. In any case,
How is that tweak supposed to happen? The rngd does not allow changing the
amount of read data relative to the assumed entropy.
> this is not affected
On Mon, Jul 25, 2016 at 01:07:35PM -0700, Keith Packard wrote:
> Instead of having only one hwrng feeding /dev/random at a time, maintain
> a list of devices and cycle between them when filling the entropy pool.
>
> Signed-off-by: Keith Packard
So you're cycling RNGs even for user-space reads? T
Hello,
Is it normal that Herbert, as the crypto maintainer, is not Cc'ed on
those patches?
On Tue, 9 Aug 2016 11:03:13 +0200, Romain Perier wrote:
> This patches series contains various fixes for ahash requests, dma
> operations and an important fixe in the core of the driver (cesa.c). It
> also
On Tue, Aug 09, 2016 at 11:37:39AM +0200, Stephan Mueller wrote:
> Am Dienstag, 9. August 2016, 17:17:55 CEST schrieb Herbert Xu:
>
> Hi Herbert,
>
> > On Tue, Aug 09, 2016 at 11:02:58AM +0200, Stephan Mueller wrote:
> > > But shouldn't the default of the rngd then be adjusted a bit?
> >
> > Ple
On Tue, Aug 09, 2016 at 10:18:34AM +0100, Russell King - ARM Linux wrote:
> Hi,
>
> While testing AF_ALG with openssl af-alg-rr, I've found that:
>
> OPENSSL_CONF=/shared/crypto/openssl-imx.cnf openssl dgst -sha1
> fails with a zero hash result:
>
> socket(PF_ALG, SOCK_SEQPACKET, 0) = 3
Am Dienstag, 9. August 2016, 17:17:55 CEST schrieb Herbert Xu:
Hi Herbert,
> On Tue, Aug 09, 2016 at 11:02:58AM +0200, Stephan Mueller wrote:
> > But shouldn't the default of the rngd then be adjusted a bit?
>
> Please elaborate.
in rngd_linux.c:random_add_entropy(void *buf, size_t size):
On Tue, Aug 09, 2016 at 11:02:58AM +0200, Stephan Mueller wrote:
>
> But shouldn't the default of the rngd then be adjusted a bit?
Please elaborate.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubs
Hi,
While testing AF_ALG with openssl af-alg-rr, I've found that:
OPENSSL_CONF=/shared/crypto/openssl-imx.cnf openssl dgst -sha1 http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from t
So far, sub part of mv_cesa_int was responsible of dequeuing complete
requests, then call the 'cleanup' operation on these reqs and call the
crypto api callback 'complete'. The problem is that the transformation
context 'ctx' is retrieved only once before the while loop. Which means
that the wrong
Don't use 64 'as is', as max block size in mv_cesa_ahash_cache_req. Use
CESA_MAX_HASH_BLOCK_SIZE instead, this is better for readability.
Signed-off-by: Romain Perier
---
drivers/crypto/marvell/hash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/marvell/hash
From: Thomas Petazzoni
The mv_cesa_ahash_cache_req() function always returns 0, which makes
its return value pretty much useless. However, in addition to
returning a useless value, it also returns a boolean in a variable
passed by reference to indicate if the request was already cached.
So, this
Currently, in mv_cesa_{md5,sha1,sha256}_init creq->state is initialized
before the call to mv_cesa_ahash_init. This is wrong because this
function fills creq with zero by using memset, so its 'state' that
contains the default DIGEST is overwritten. This commit fixes the issue
by initializing creq->
This patches series contains various fixes for ahash requests, dma
operations and an important fixe in the core of the driver (cesa.c). It
also includes some code cleanups.
Romain Perier (3):
crypto: marvell - Update transformation context for each dequeued req
crypto: marvell - Don't overwrit
From: Thomas Petazzoni
The dma_iter parameter of mv_cesa_ahash_dma_add_cache() is never used,
so get rid of it.
Signed-off-by: Thomas Petazzoni
---
drivers/crypto/marvell/hash.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto
From: Thomas Petazzoni
The mv_cesa_ahash_init() function always returns 0, and the return
value is anyway never checked. Turn it into a function returning void.
Signed-off-by: Thomas Petazzoni
---
drivers/crypto/marvell/hash.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --gi
From: Thomas Petazzoni
The mv_cesa_dma_add_op() function builds a mv_cesa_tdma_desc structure
to copy the operation description to the SRAM, but doesn't explicitly
initialize the destination of the copy. It works fine because the
operatin description must be copied at the beginning of the SRAM, a
Am Dienstag, 9. August 2016, 16:58:58 CEST schrieb Herbert Xu:
Hi Herbert,
> On Tue, Aug 09, 2016 at 10:07:29AM +0200, Stephan Mueller wrote:
> > Herbert, Matt, should such noise sources be added to the HW random
> > framework? The thing is that the in-kernel HW random to input_pool link
> > per
On Tue, Aug 09, 2016 at 10:07:29AM +0200, Stephan Mueller wrote:
>
> Herbert, Matt, should such noise sources be added to the HW random framework?
> The thing is that the in-kernel HW random to input_pool link per default uses
> a more conservative entropy estimate than the user space rngd. I wo
Am Dienstag, 9. August 2016, 07:35:33 CEST schrieb Pan, Miaoqing:
Hi Miaoqing, Herbert, Matt,
> Hi Stephan,
>
> So your suggestion is to use HW Random framework ? Actually, which was
> done by the commit 6301566e0b2d ("ath9k: export HW random number
> generator"), but it was reverted, you can
Hi Stephan,
So your suggestion is to use HW Random framework ? Actually, which was done
by the commit 6301566e0b2d ("ath9k: export HW random number generator"), but it
was reverted, you can refer to
https://www.mail-archive.com/linux-crypto%40vger.kernel.org/msg15483.html for
more informatio
While debugging setkey issues, the following warnings were found while
trying to reinsert the caam module. Fix this by avoiding the duplicated
cleanup in the probe path after caam_remove(), which has already cleaned
up the resources.
[ cut here ]
WARNING: CPU: 0 PID: 2346
On Tue, Aug 09, 2016 at 03:14:02PM +0800, Herbert Xu wrote:
> On Tue, Aug 09, 2016 at 08:08:59AM +0100, Russell King - ARM Linux wrote:
> >
> > I thought I gave the commands and link to your example code. The
> > openssl case is md5, though sha* also gives the same result. Your
> > example code
Am Dienstag, 9. August 2016, 15:02:27 CEST schrieb miaoq...@codeaurora.org:
Hi Miaoqing,
> From: Miaoqing Pan
>
> ath9k RNG will dominates all the noise sources from the real HW
> RNG, disable it by default. But we strongly recommand to enable
> it if the system without HW RNG, especially on em
On Tue, Aug 09, 2016 at 08:08:59AM +0100, Russell King - ARM Linux wrote:
>
> I thought I gave the commands and link to your example code. The
> openssl case is md5, though sha* also gives the same result. Your
> example code was sha1 iirc. I guess none of these would be using
> HMAC - the open
On Tue, Aug 09, 2016 at 11:18:20AM +0800, Herbert Xu wrote:
> Russell King - ARM Linux wrote:
> > Testing that code on 4.8-rc (and 4.7 fwiw) gives:
> >
> > socket(PF_ALG, SOCK_SEQPACKET, 0) = 3
> > bind(3, {sa_family=AF_ALG, sa_data="hash\0\0\0\0\0\0\0\0\0\0"}, 88) = 0
> > accept(3, 0, NULL
From: Miaoqing Pan
ath9k RNG will dominates all the noise sources from the real HW
RNG, disable it by default. But we strongly recommand to enable
it if the system without HW RNG, especially on embedded systems.
Signed-off-by: Miaoqing Pan
---
drivers/net/wireless/ath/ath9k/Kconfig | 2 +-
1 f
From: Miaoqing Pan
The quality of ADC entropy is 10 bits of min-entropy for
a 32-bit value, change '(((x) * 8 * 320) >> 10)' to
'(((x) * 8 * 10) >> 5)' for easier understanding.
Signed-off-by: Miaoqing Pan
---
drivers/net/wireless/ath/ath9k/rng.c | 2 +-
1 file changed, 1 insertion(+), 1 delet
78 matches
Mail list logo
