wifi: ath9k: remove most hidden macro dependencies on ah

Adds an explicit _ah parameter to most macros that previously had a
hidden dependency on ah. This makes the code more compliant with the
style guide.

This change does not appear to affect the final binary.

Signed-off-by: Wenli Looi <wlooi@ucalgary.ca>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/c8369317-cf84-f0e3-fe8-9b6e22e43a6a@ucalgary.ca

hwrng: core - let sleep be interrupted when unregistering hwrng

There are two deadlock scenarios that need addressing, which cause
problems when the computer goes to sleep, the interface is set down, and
hwrng_unregister() is called. When the deadlock is hit, sleep is delayed
for tens of seconds, causing it to fail. These scenarios are:

1) The hwrng kthread can't be stopped while it's sleeping, because it
uses msleep_interruptible() which does not react to kthread_stop.

2) A normal user thread can't be interrupted by hwrng_unregister() while
it's sleeping, because hwrng_unregister() is called from elsewhere.

We solve both issues by add a completion object called dying that
fulfils waiters once we have started the process in hwrng_unregister.

At the same time, we should cleanup a common and useless dmesg splat
in the same area.

Cc: <stable@vger.kernel.org>
Reported-by: Gregory Erwin <gregerwin256@gmail.com>
Fixes: fcd09c90c3c5 ("ath9k: use hw_random API instead of directly dumping into random.c")
Link: https://lore.kernel.org/all/CAO+Okf6ZJC5-nTE_EJUGQtd8JiCkiEHytGgDsFGTEjs0c00giw@mail.gmail.com/
Link: https://lore.kernel.org/lkml/CAO+Okf5k+C+SE6pMVfPf-d8MfVPVq4PO7EY8Hys_DVXtent3HA@mail.gmail.com/
Link: https://bugs.archlinux.org/task/75138
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Acked-by: Kalle Valo <kvalo@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

ath9k: use hw_random API instead of directly dumping into random.c

Hardware random number generators are supposed to use the hw_random
framework. This commit turns ath9k's kthread-based design into a proper
hw_random driver.

Cc: Toke Høiland-Jørgensen <toke@redhat.com>
Cc: Kalle Valo <kvalo@kernel.org>
Cc: Rui Salvaterra <rsalvaterra@gmail.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Tested-by: Rui Salvaterra <rsalvaterra@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220216113323.53332-1-Jason@zx2c4.com

ath9k: avoid potential freezing during random generator read

In the worst case, ath9k_rng_stop() may take 10s to stop rng kthread.
The time is too long for users, use wait_event_interruptible_timeout()
instead of msleep_interruptible(), wakup immediately once
kthread_should_stop() is true.

Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath9k: fix an invalid pointer dereference in ath9k_rng_stop()

The bug was triggered when do suspend/resuming continuously
on Dell XPS L322X/0PJHXN version 9333 (2013) with kernel
4.12.0-041200rc4-generic. But can't reproduce on DELL
E5440 + AR9300 PCIE chips.

The warning is caused by accessing invalid pointer sc->rng_task.
sc->rng_task is not be cleared after kthread_stop(sc->rng_task)
be called in ath9k_rng_stop(). Because the kthread is stopped
before ath9k_rng_kthread() be scheduled.

So set sc->rng_task to null after kthread_stop(sc->rng_task) to
resolve this issue.

WARNING: CPU: 0 PID: 984 at linux/kernel/kthread.c:71 kthread_stop+0xf1/0x100
CPU: 0 PID: 984 Comm: NetworkManager Not tainted 4.12.0-041200rc4-generic #201706042031
Hardware name: Dell Inc. Dell System XPS L322X/0PJHXN, BIOS A09 05/15/2013
task: ffff950170fdda00 task.stack: ffffa22c01538000
RIP: 0010:kthread_stop+0xf1/0x100
RSP: 0018:ffffa22c0153b5b0 EFLAGS: 00010246
RAX: ffffffffa6257800 RBX: ffff950171b79560 RCX: 0000000000000000
RDX: 0000000080000000 RSI: 000000007fffffff RDI: ffff9500ac9a9680
RBP: ffffa22c0153b5c8 R08: 0000000000000000 R09: 0000000000000000
R10: ffffa22c0153b648 R11: ffff9501768004b8 R12: ffff9500ac9a9680
R13: ffff950171b79f70 R14: ffff950171b78780 R15: ffff9501749dc018
FS: 00007f0d6bfd5540(0000) GS:ffff95017f200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fc190161a08 CR3: 0000000232906000 CR4: 00000000001406f0
Call Trace:
ath9k_rng_stop+0x1a/0x20 [ath9k]
ath9k_stop+0x3b/0x1d0 [ath9k]
drv_stop+0x33/0xf0 [mac80211]
ieee80211_stop_device+0x43/0x50 [mac80211]
ieee80211_do_stop+0x4f2/0x810 [mac80211]

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196043
Reported-by: Giulio Genovese <giulio.genovese@gmail.com>
Tested-by: Giulio Genovese <giulio.genovese@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath9k: change entropy formula for easier understanding

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 <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath9k: fix rng high cpu load

If no valid ADC randomness output, ath9k rng will continuously
reading ADC, which will cause high CPU load. So increase the
delay to wait for ADC ready.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114261
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath9k: feeding entropy in kernel from ADC capture

This patch is derived from
commit 6301566e0b2d ("ath9k: export HW random number generator"),

We evaluated the entropy of the ADC data on QCA9531, QCA9561, QCA955x,
and AR9340, and it has sufficient quality random data (at least 10 bits
and up to 22 bits of min-entropy for a 32-bit value). We conservatively
assume the min-entropy is 10 bits out of 32 bits. Thus, ATH9K_RNG_BUF_SIZE
is set to 320 (u32) i.e., 1.25 kilobytes of data is inserted to fill up
the pool as soon as the entropy counter becomes 896/4096 (set by random.c).
Since ADC was not designed to be a dedicated HW RNG, we do not want to bind
it to /dev/hwrng framework directly. This patch feeds the entropy directly
from the WiFi driver to the input pool. The ADC register output is only
used as a seed for the Linux entropy pool. No conditioning is needed,
since all the conditioning is performed by the pool itself.

Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Revert "ath9k: export HW random number generator"

This reverts commit 6301566e0b2dafa7d6779598621bca867962a0a2. Oleksij Rempel
noticed that the randomness doesn't look to be good enough and Stephan Mueller
commented:

"I would say that the discussed RNG does not seem fit for hooking it up with the
hwrandom framework."

http://lkml.kernel.org/g/3945775.m5HblJPgiO@tauon.atsec.com

So let's the revert the patch until we are sure that we can trust this random
generator.

Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath9k: export HW random number generator

We measured the FFT-based entropy in 3 ways, Shannon entropy,
collision entropy, and directly measured min-entropy. Just to
be conservative, we recommend the estimated min-Entropy to be
10 bits per 16-bit value.

Analysis was done by Jacobson,David(djacobso@qti.qualcomm.com).

Signed-off-by: Miaoqing Pan <miaoqing@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>