On Sun, 03 Aug 2008, Tomas Winkler wrote: > At least from iwlwifi perspective killing radio is not the same > operation as shutting down the card. It almost never is. Which is why I said we should not bother if nobody needs that. > The intention is different if nothing it's really redundant operation On proper drivers that do proper power management? Certainly :-) > > RFKILL is not about tracking, it is about *controlling*. > > I think driver controls the radio why need to add another entity for > that. I don't like this definition, But that's just wording I hope. All the radio-is-allowed-to-transmit decisions are rfkill's. The driver is not allowed to override those. This is done to present a uniform behaviour and interface to the system's user (and any instance of rfkill doing something the user wouldn't expect to the radio is to be considered a major bug). rfkill is supposed to represend the will of the system's user regarding permission to transmit energy out of wireless transmitters. Not even WoWL is an exception, if your radio is blocked before suspend, you are not allowed to enable the transmitter [to get WoWL to work -- I sure hope this is not necessary, but it could be]. I'd expect a printk complaining about it, though :-) > I rather remove it, If the driver has D3 operation it should move card > to operation Sure. I was wondering about drivers that *don't* have it, if any, out of the potential set of drivers that should be using rfkill (it is not a matter of those who are using rfkill right now). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html