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: 122+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-19 18:52 Changes to sysfs PM layer break userspace Matthew Garrett
2006-12-19 19:34 ` Arjan van de Ven
2006-12-19 19:44 ` Matthew Garrett
2006-12-19 20:03 ` Arjan van de Ven
2006-12-19 20:08 ` Matthew Garrett
2006-12-19 20:23 ` Arjan van de Ven
2006-12-19 20:32 ` Matthew Garrett
2006-12-19 20:55 ` Arjan van de Ven
2006-12-21 0:08 ` Kyle Moffett
2006-12-19 21:34 ` David Brownell
2006-12-20 0:25 ` Matthew Garrett
2006-12-20 3:59 ` Changes to " David Brownell
2006-12-20 4:26 ` Matthew Garrett
2006-12-20 5:14 ` David Brownell
2006-12-20 5:34 ` Greg KH
2006-12-20 5:52 ` Matthew Garrett
2006-12-20 7:50 ` Arjan van de Ven
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-22 21:09 ` Changes to PM layer break userspace Pavel Machek
2006-12-24 7:02 ` David Brownell
2006-12-28 13:31 ` Alan
2006-12-28 16:04 ` Arjan van de Ven
2006-12-29 5:27 ` David Brownell
2006-12-20 2:15 ` Changes to sysfs " Andrew Morton
2006-12-20 2:35 ` Randy Dunlap
2006-12-20 3:49 ` Andrew Morton
2006-12-20 3:29 ` David Brownell
2006-12-21 3:51 ` Andrew Morton
2006-12-21 4:56 ` David Brownell
2006-12-21 5:02 ` Andrew Morton
2006-12-21 7:05 ` David Brownell
2006-12-21 8:27 ` Arjan van de Ven
2006-12-22 20:44 ` Pavel Machek
2006-12-23 14:02 ` Stefan Seyfried
2006-12-19 21:22 ` David Brownell
2006-12-19 22:57 ` Matthew Garrett
2006-12-19 23:36 ` Changes to " David Brownell
2006-12-20 0:09 ` Matthew Garrett
2006-12-20 3:19 ` David Brownell
2006-12-20 3:43 ` Matthew Garrett
2006-12-20 4:15 ` David Brownell
2006-12-20 4:56 ` [PATCH 1/2] Fix /sys/device/.../power/state Matthew Garrett
2006-12-20 21:18 ` David Brownell
2006-12-21 1:29 ` Matthew Garrett
2006-12-21 3:04 ` David Brownell
2006-12-21 4:06 ` Matthew Garrett
2006-12-21 4:51 ` David Brownell
2007-01-25 5:00 ` [PATCH] Fix /sys/device/.../power/state regression Matthew Garrett
2007-01-26 19:59 ` Andrew Morton
2007-01-26 20:42 ` Greg KH
2007-01-27 1:26 ` Matthew Garrett
2007-01-27 17:19 ` Pavel Machek
2007-01-26 20:41 ` Greg KH
2007-01-26 21:56 ` David Brownell
2007-01-26 22:19 ` Greg KH
2007-01-26 23:15 ` Matthew Garrett
2007-01-27 0:42 ` David Brownell
2007-01-27 0:56 ` Andrew Morton
2007-01-27 2:40 ` David Brownell
2007-01-27 17:38 ` Pavel Machek
2007-01-27 22:42 ` Matthew Garrett
2007-01-31 10:34 ` Pavel Machek
2007-01-27 1:19 ` Matthew Garrett
2007-01-27 3:02 ` David Brownell
2007-01-29 17:36 ` Stephen Hemminger
2007-01-27 13:17 ` Pavel Machek
2007-01-30 18:43 ` Eric Piel
2007-01-30 18:47 ` Oliver Neukum
2007-01-30 19:01 ` Eric Piel
2007-01-31 10:55 ` Jiri Kosina
2007-01-31 11:03 ` Oliver Neukum
2006-12-20 4:56 ` [PATCH 2/2] Update feature-removal-schedule.txt Matthew Garrett
2006-12-22 20:47 ` Changes to PM layer break userspace Pavel Machek
2006-12-21 5:25 Network drivers that don't suspend on interface down 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
Powered by JetHome