On Sun, Aug 3, 2008 at 4:52 PM, Henrique de Moraes Holschuh <hmh@xxxxxxxxxx> wrote: > 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. May point is that there are radio event out of scope rfkill so the driver although obey rfkill system requests but rfkill switch doesn't control the radio, the driver does. But it's really just point of view. > > 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). I think we are aligned in general. Thanks Tomas -- 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
