On 2/22/22, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > On Mon, 21 Feb 2022 at 11:57, Kalle Valo <kvalo@xxxxxxxxxx> wrote: >> >> "Jason A. Donenfeld" <Jason@xxxxxxxxx> wrote: >> >> > 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@xxxxxxxxxx> >> > Cc: Kalle Valo <kvalo@xxxxxxxxxx> >> > Cc: Rui Salvaterra <rsalvaterra@xxxxxxxxx> >> > Cc: Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx> >> > Cc: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> >> > Signed-off-by: Jason A. Donenfeld <Jason@xxxxxxxxx> >> > Tested-by: Rui Salvaterra <rsalvaterra@xxxxxxxxx> >> > Acked-by: Toke Høiland-Jørgensen <toke@xxxxxxx> >> > Signed-off-by: Kalle Valo <quic_kvalo@xxxxxxxxxxx> >> >> Patch applied to ath-next branch of ath.git, thanks. >> >> fcd09c90c3c5 ath9k: use hw_random API instead of directly dumping into >> random.c >> > > With this patch, it seems we end up registering the hw_rng every time > the link goes up, and unregister it again when the link goes down, > right? > > Wouldn't it be better to split off this driver from the 802.11 link > state handling? > I really have no idea how this thing works, and I tried hard to change as little as possible in converting it to the API. You may want to send some follow-up patches if you have hardware to experiment with. One consideration does leap out, which is that in my experience wifi cards use a lot less power when they're set "down", as though a decent amount of hardware is being switched off. I think this ath9k rng call might be using the ADC to gather samples of ether from somewhere. I imagine this gets shutdown too as part of that dame circuitry.
