From: "Mario 'BitKoenig' Holbe" <Mario.Holbe@TU-Ilmenau.DE>
To: "John W. Linville" <linville@tuxdriver.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: b43 wireless driver inhibits access to /dev/hwrng
Date: Fri, 23 Jul 2010 17:31:02 +0200 [thread overview]
Message-ID: <20100723153101.GA12795@darkside.kls.lan> (raw)
In-Reply-To: <20100723143219.GA2426@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 1714 bytes --]
On Fri, Jul 23, 2010 at 10:32:19AM -0400, John W. Linville wrote:
> The hwrng driver is provided by the b43 hardware, which is shutdown
> when the network interface is down. I'm not sure how one could expect
> this to work.
Nope. It's provided by the VIA PadLock hardware (through the via-rng
driver). I'm not sure how one could expect this not to work when the
network interface provided by the b43 driver is down.
Well, maybe let's try to become a bit less offensive... :)
Probably there are two Hardware RNGs on that machine: one provided by
VIA PadLock through via-rng, one provided by BCM4312 through b43:
hw_random/via-rng.c: err = hwrng_register(&via_rng);
b43/main.c: err = hwrng_register(&wl->rng);
But at least now it's a bit more likely that the problem is located in
the rng core which should not render /dev/hwrng inaccessible when only
one of the RNGs unregisters.
However, what I don't fully understand is: I find only one way where b43
unregisters its RNG, which is via
b43_remove() -> b43_rng_exit() -> hwrng_unregister()
And, I'm really not sure if I got this right, but... I guess,
b43_remove() is only called when the module is removed from the kernel
and not when the network interface is shut down.
So, maybe it's not really rng core's fault?
I guess, b43 just stops delivering data through b43_rng_read() when the
hardware is shut down and instead returns ENODEV (which is btw. what I
get when I'm trying to read /dev/hwrng while b43 is down), and the rng
core just delivers this error up when it's trying to deliver the read
request to the b43 RNG.
Mario
--
User sind wie ideale Gase - sie verteilen sich gleichmaessig ueber alle Platten
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 482 bytes --]
next prev parent reply other threads:[~2010-07-23 15:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-22 22:52 b43 wireless driver inhibits access to /dev/hwrng Mario 'BitKoenig' Holbe
2010-07-23 14:32 ` John W. Linville
2010-07-23 15:31 ` Mario 'BitKoenig' Holbe [this message]
2010-07-23 17:32 ` John W. Linville
2010-07-23 18:21 ` Mario 'BitKoenig' Holbe
2010-07-31 6:15 ` Pavel Machek
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=20100723153101.GA12795@darkside.kls.lan \
--to=mario.holbe@tu-ilmenau.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linville@tuxdriver.com \
/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.