[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAHmME9rOWOki8fpMC=wNr=4En8iN4DhWm8XVOquprnUUh62yqA@mail.gmail.com>
Date: Tue, 22 Feb 2022 11:13:45 +0100
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Kalle Valo <kvalo@...nel.org>, miaoqing@...eaurora.org,
Rui Salvaterra <rsalvaterra@...il.com>,
Toke Høiland-Jørgensen <toke@...e.dk>,
"Sepehrdad, Pouyan" <pouyans@....qualcomm.com>,
ath9k-devel <ath9k-devel@....qualcomm.com>,
"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
Dominik Brodowski <linux@...inikbrodowski.net>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
Herbert Xu <herbert@...dor.apana.org.au>,
LKML <linux-kernel@...r.kernel.org>,
Netdev <netdev@...r.kernel.org>,
Toke Høiland-Jørgensen <toke@...hat.com>,
Florian Fainelli <f.fainelli@...il.com>
Subject: Re: [PATCH v3] ath9k: use hw_random API instead of directly dumping
into random.c
On 2/22/22, Ard Biesheuvel <ardb@...nel.org> wrote:
> On Mon, 21 Feb 2022 at 11:57, Kalle Valo <kvalo@...nel.org> wrote:
>>
>> "Jason A. Donenfeld" <Jason@...c4.com> 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@...hat.com>
>> > Cc: Kalle Valo <kvalo@...nel.org>
>> > Cc: Rui Salvaterra <rsalvaterra@...il.com>
>> > Cc: Dominik Brodowski <linux@...inikbrodowski.net>
>> > Cc: Herbert Xu <herbert@...dor.apana.org.au>
>> > Signed-off-by: Jason A. Donenfeld <Jason@...c4.com>
>> > Tested-by: Rui Salvaterra <rsalvaterra@...il.com>
>> > Acked-by: Toke Høiland-Jørgensen <toke@...e.dk>
>> > Signed-off-by: Kalle Valo <quic_kvalo@...cinc.com>
>>
>> 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.
Powered by blists - more mailing lists