On Mon, 2008-08-04 at 19:30 -0300, Henrique de Moraes Holschuh wrote: > On Mon, 04 Aug 2008, Dan Williams wrote: > > On Sat, 2008-08-02 at 16:27 -0300, Henrique de Moraes Holschuh wrote: > > > On Sat, 02 Aug 2008, Johannes Berg wrote: > > > > On Sat, 2008-08-02 at 15:11 -0300, Henrique de Moraes Holschuh wrote: > > > > > Currently, rfkill would stand in the way of properly supporting wireless > > > > > devices that are capable of waking the system up from sleep or hibernation > > > > > when they receive a special wireless message. > > > > > > > > > > Since rfkill attempts to soft-block any transmitters during class suspend, > > > > > > > > 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. > > > > rfkill shouldn't be touching stuff during suspend. > > rfkill shouldn't *need* to touch stuff during suspend. But for that to be > true, all drivers using rfkill need to properly suspend in the first place. > > And that's more than just drivers/net/wireless. > > > In the OLPC libertas case, the radio may remain _ON_ during suspend, > > because the OLPC machines are expected to suspend/resume many times per > > second, and the radio must continue to participate in the mesh during > > that time. The only case where the radio gets blocked is when the user > > requests it or when regulations require it. > > Yes. And the fact that rfkill stood in the way of doing that is a bug. > However, even my first try of a patch would already allow libertas to > declare it doesn't want rfkill to bother it on suspend. > > It is very clear some drivers don't want rfkill to block radios on suspend. > Really. So far, libertas and iwl* are on my list of "don't want" or "don't > need". From what I can see, PCI-based rt2xxx is also "don't need". And I > can assume everything in drivers/misc is "don't need" without too much risk > of being wrong. > > But the OPPOSITE is not clear at all to me. I don't know whether the other > users of rfkill need a radio block on suspend or not. Unless someone can > look over *all* in-tree users of linux/rfkill.h and state that none of them > need it because all of them DO shutdown their devices on suspend, I will > have to ask the maintainers of every single one about it before I ask a > patch to be merged. I already looked, and I don't know enough to have a > definitive answer by myself. Using rfkill to enforce suspend power policy at a kernel-level is just wrong. That's a policy decision for gnome-power-manager or kde-power-manager or whatever. At the very least, it should be an option in sysfs to turn this behavior on or off. Dan > > Suspend != block, and tying suspend and rfkill together really is a > > policy decision. Thus, I don't agree that rfkill should block radios on > > suspend. > > If some drivers out there are relying on it to, we need to know that before > we remove it completely. > -- 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
