From: Dan Williams <dcbw@redhat.com>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Jiri Benc <jbenc@suse.cz>, Arjan van de Ven <arjan@infradead.org>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: Network drivers that don't suspend on interface down
Date: Wed, 20 Dec 2006 22:06:51 -0500 [thread overview]
Message-ID: <1166670411.23168.13.camel@localhost.localdomain> (raw)
In-Reply-To: <20061221011526.GB32625@srcf.ucam.org>
On Thu, 2006-12-21 at 01:15 +0000, Matthew Garrett wrote:
> On Wed, Dec 20, 2006 at 01:12:51PM -0500, Dan Williams wrote:
>
> > Entirely correct. If the card is DOWN, the radio should be off (both TX
> > & RX) and it should be in max power save mode. If userspace expects to
> > be able to get the card to do _anything_ when it's down, that's just
> > 110% wrong. You can't get link events for many wired cards when they
> > are down, so I fail to see where userspace could expect to do anything
> > with a wireless card when it's down too.
>
> Because it works on the common hardware? If there's documentation about
> what userspace can legitimately expect, then I'm happy to defer to that.
> But in the absence of any indication as to what functionality users can
> depend on, deciding that existing functionality is a bug is, well,
> impolite.
>
> > Also, how does rfkill fit into this? rfkill implies killing TX, but do
> > we have the granularity to still receive while the transmit paths are
> > powered down?
>
> Is rfkill not just primarily an interface for us getting events when the
> radio changes state? Every time I read up on it I get a little more
> confused - some time I really need to make sense of it...
That's OK, it's really complicated. There are 3 cases of rfkill
switches AFAICT:
a) tied to the wireless hardware, switch kills hardware directly
b) tied to wireless hardware, but driver handles the kill request
c) just another key, a separate key driver handles the event and asks
the wireless driver to kill the card
It's also complicated because some switches are supposed to rfkill both
an 802.11 module _and_ a bluetooth module at the same time, or I guess
some laptops may even have one rfkill switch for each wireless device.
Furthermore, some people want to 'softkill' the hardware via software
without pushing the key, which is a subset of (b) or (c) above.
It sucks. But we _need_ a unified interface to handle it.
Dan
next prev parent reply other threads:[~2006-12-21 3:04 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20061219185223.GA13256@srcf.ucam.org>
[not found] ` <200612191959.43019.david-b@pacbell.net>
[not found] ` <20061220042648.GA19814@srcf.ucam.org>
[not found] ` <200612192114.49920.david-b@pacbell.net>
[not found] ` <20061220053417.GA29877@suse.de>
[not found] ` <20061220055209.GA20483@srcf.ucam.org>
[not found] ` <1166601025.3365.1345.camel@laptopd505.fenrus.org>
2006-12-20 12:53 ` Network drivers that don't suspend on interface down Matthew Garrett
2006-12-20 13:38 ` Arjan van de Ven
2006-12-20 14:31 ` Matthew Garrett
2006-12-20 15:51 ` Arjan van de Ven
2006-12-20 22:49 ` Stephen Hemminger
2006-12-20 23:37 ` Rick Jones
2006-12-19 23:51 ` Stephen Hemminger
2006-12-21 0:11 ` Francois Romieu
2006-12-20 0:26 ` Stephen Hemminger
2006-12-21 11:18 ` Francois Romieu
2006-12-21 1:12 ` Matthew Garrett
2006-12-21 2:05 ` Michael Wu
2006-12-21 2:18 ` Matthew Garrett
2006-12-21 2:38 ` Daniel Drake
2006-12-21 2:45 ` Matthew Garrett
2006-12-21 3:08 ` Daniel Drake
2006-12-21 3:25 ` Matthew Garrett
2006-12-21 3:37 ` Dan Williams
2006-12-21 3:29 ` Dan Williams
2006-12-21 3:14 ` Dan Williams
2006-12-21 13:14 ` jamal
2006-12-21 2:29 ` Daniel Drake
2006-12-21 2:10 ` Jesse Brandeburg
2006-12-21 8:54 ` Arjan van de Ven
2006-12-22 1:03 ` Herbert Xu
2006-12-23 8:54 ` Pavel Machek
2006-12-20 15:27 ` Olivier Galibert
2006-12-20 15:34 ` Arjan van de Ven
2006-12-20 16:40 ` Olivier Galibert
2006-12-20 17:21 ` Arjan van de Ven
2006-12-20 20:40 ` Benny Amorsen
2006-12-20 21:49 ` Arjan van de Ven
2006-12-20 21:15 ` Stefan Rompf
2006-12-20 14:00 ` Jiri Benc
2006-12-20 18:12 ` Dan Williams
2006-12-21 1:15 ` Matthew Garrett
2006-12-21 1:57 ` Michael Wu
2006-12-21 2:20 ` Matthew Garrett
2006-12-21 3:02 ` Dan Williams
2006-12-21 3:06 ` Dan Williams [this message]
2006-12-21 3:14 ` Matthew Garrett
2006-12-21 3:32 ` Dan Williams
2006-12-21 13:19 ` Sven-Haegar Koch
2006-12-21 17:16 ` Dan Williams
2006-12-21 18:27 ` Valdis.Kletnieks
2006-12-22 1:25 ` Matt Domsch
2006-12-20 16:04 ` Maciej W. Rozycki
2006-12-21 5:25 David Brownell
2006-12-21 7:08 ` Stephen Hemminger
2006-12-21 8:11 ` David Brownell
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=1166670411.23168.13.camel@localhost.localdomain \
--to=dcbw@redhat.com \
--cc=arjan@infradead.org \
--cc=jbenc@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=netdev@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).