All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: "Kalle Valo" <kvalo@kernel.org>,
	miaoqing@codeaurora.org, "Rui Salvaterra" <rsalvaterra@gmail.com>,
	"Toke Høiland-Jørgensen" <toke@toke.dk>,
	"Sepehrdad, Pouyan" <pouyans@qti.qualcomm.com>,
	ath9k-devel <ath9k-devel@qca.qualcomm.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"Dominik Brodowski" <linux@dominikbrodowski.net>,
	"Linux Crypto Mailing List" <linux-crypto@vger.kernel.org>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	LKML <linux-kernel@vger.kernel.org>,
	Netdev <netdev@vger.kernel.org>,
	"Toke Høiland-Jørgensen" <toke@redhat.com>,
	"Florian Fainelli" <f.fainelli@gmail.com>
Subject: Re: [PATCH v3] ath9k: use hw_random API instead of directly dumping into random.c
Date: Tue, 22 Feb 2022 11:13:45 +0100	[thread overview]
Message-ID: <CAHmME9rOWOki8fpMC=wNr=4En8iN4DhWm8XVOquprnUUh62yqA@mail.gmail.com> (raw)
In-Reply-To: <CAMj1kXFLx1xGexd5P9xnB-2=cFn1DScCa8U6a7AyRAxQPLCWLw@mail.gmail.com>

On 2/22/22, Ard Biesheuvel <ardb@kernel.org> wrote:
> On Mon, 21 Feb 2022 at 11:57, Kalle Valo <kvalo@kernel.org> wrote:
>>
>> "Jason A. Donenfeld" <Jason@zx2c4.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@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>
>>
>> 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.

  reply	other threads:[~2022-02-22 10:13 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-08 16:51 ath9k should perhaps use hw_random api? Jason A. Donenfeld
2022-02-15 15:38 ` Jason A. Donenfeld
2022-02-15 16:28   ` [PATCH] ath9k: use hw_random API instead of directly dumping into random.c Jason A. Donenfeld
2022-02-15 22:55     ` Rui Salvaterra
2022-02-15 23:22     ` Toke Høiland-Jørgensen
2022-02-15 23:52       ` Jason A. Donenfeld
2022-02-16  0:02         ` [PATCH v2] " Jason A. Donenfeld
2022-02-16  3:13           ` Florian Fainelli
2022-02-16 10:43             ` Jason A. Donenfeld
2022-02-16 11:33               ` [PATCH v3] " Jason A. Donenfeld
2022-02-16 13:27                 ` Rui Salvaterra
2022-02-17 13:51                 ` Toke Høiland-Jørgensen
2022-02-21 10:22                 ` Kalle Valo
2022-02-22 10:01                   ` Ard Biesheuvel
2022-02-22 10:13                     ` Jason A. Donenfeld [this message]
2022-02-16  5:38           ` [PATCH v2] " Kalle Valo
2022-02-16  7:15           ` Dominik Brodowski
2022-02-16  7:11         ` [PATCH] " Dominik Brodowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHmME9rOWOki8fpMC=wNr=4En8iN4DhWm8XVOquprnUUh62yqA@mail.gmail.com' \
    --to=jason@zx2c4.com \
    --cc=ardb@kernel.org \
    --cc=ath9k-devel@qca.qualcomm.com \
    --cc=f.fainelli@gmail.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=kvalo@kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linux@dominikbrodowski.net \
    --cc=miaoqing@codeaurora.org \
    --cc=netdev@vger.kernel.org \
    --cc=pouyans@qti.qualcomm.com \
    --cc=rsalvaterra@gmail.com \
    --cc=toke@redhat.com \
    --cc=toke@toke.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.