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:

quoted

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.

quoted

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