On Fri, 2009-06-05 at 21:01 +0200, Michael Buesch wrote: > > The rfkill polling routine brings the interface back to the initialized > > state if it is found to be uninitialized. This way the rfkill switch > > may be interpreted. In addition, the radio LED is not turned on in the > > initialization routine unless the rfkill switch is on. > > This is pretty silly behavior IMO. Just to bring it to the point: > We initialize a huge wireless MAC, PHY and Radio that consume several watts of power > just to poll a silly RF-kill bit. 1) you're MUCH overstating the power consumption 2) we don't actually have to turn on the PHY, just the MAC core, if we can do that, but that requires some refactoring afaict > We can't we just accept that the RF-kill status is unknown while the device is down? No, because then we don't know whether we can allow users to bring up the device. We could work around that and bring it up, check rfkill, and bring it back down return -ERFKILL to the user then. But then guess what will happen: userspace will have to poll rfkill again. > 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. Fine. Just don't stand in my way then. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
