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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
