On Fri, 2009-06-05 at 16:20 -0500, Larry Finger wrote: > The problem is that while the interface is down the switch status > cannot be interrogated. If you try, you get a fatal SSB error. Thus > the only way to bring it back up is to flip the switch, then > rmmod/insmod the driver. If you want hardware rfkill to be one-way, > then take Johannes's patch. We would save a little power by calling > b43_wireless_exit() if we brought it up to test the switch, and the > switch was still off. That would leave everything off most of the time. Actually we should do that all the time, since after the user pushes the button he might still not actually want to use the device. > > I really do hate all that rfkill crap and I'm still refusing to sign off on anything that's > > related to rfkill (like I did for the past year or so). If people want this merged, > > somebody else maintain and sign it off, please. > > I'm sick of rfkill as well and really detest the endless discussions > that have taken place; however, I do want the stuff to work. > > As I see it, we have several options (presented in my order of > preference): > > 1. We switch to the cfg80211 rfkill and use this patch modified to > turn the interface back off if the switch is still off. I'll do that. > 2. We continue to use the old rfkill mechanism. It works just fine, > but this method runs the risk of the old method being deprecated and > eliminated. It won't be, but you won't get proper userspace integration, NM will not integrate properly and then we will continue having to rely on users reading dmesg saying something like "rfkill off, press button before wireless will connect" and mac80211 will at the same time try to connect and do things unsuccessfully. > 3. We get new callbacks that will only power down/up the radio when it > is blocked. That saves a little power. Less so than actually turning off most things most of the time, I'd think. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
