On Sun, 03 Aug 2008, Tomas Winkler wrote: > >> why does it interfere with suspend anyway? > > > > The class makes sure that all transmitters are blocked on suspend. You'd > > have to ask Ivo for the reason, but AFAIK, it is for both safety and to help > > conserve power. > > This one is also on my list to remove. Suspend/Hibernate Resume > definitelly doesn't mean to rfkill radio on and off.. Driver should I *certainly* don't want the chip active during S3 or S4 unless I want WoWL active, so I do agree that just killing the radio is not enough. > This only creates conflicts as both driver and rfkill system are > trying to bring radio down No conflicts. The wireless driver gets the request to shut the radio down BEFORE its suspend method is called (the class suspends first). It will also get the request to enable/disable (whatever state it was in before the suspend) the radio AFTER its resume method is called (the class resumes after). > RFKILL IMHO shell track rfkill switches states and not to invent RFKILL is not about tracking, it is about *controlling*. > them. If the radio was SW switched off before NIC was suspend it > shell be switched off also in resume. That's should be role of rfkill > system, probably with some help from user space. Without the patch, rfkill always disables radios on suspend. If they were enabled before the suspend, it will try to enable them on resume. If they were disabled before the suspend, it will try to disable them on resume. That's well part of rfkill's role. It might not be *needed* at all though, and if it is not, it is best to stop doing it. If it is needed just in a few situations, we need to make it configurable (that's what my patch does). -- "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
