On Mon, 2008-08-04 at 20:35 -0300, Henrique de Moraes Holschuh wrote: > On Mon, 04 Aug 2008, Dan Williams wrote: > > > 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. > > There is no way I am adding an interface for userspace to decide how a > driver+rfkill stack should go in order to properly suspend a device. The > kernel is to get it right by itself. It already knows whether the device > was blocked or not before the suspend. And, when it is suppored by the > device, the device driver already knows if it is part of a non-stop mesh > (libertas), or has to have WoWL enabled, etc. > > And it is already damn clear that what we currently have (rfkill always > blocks on suspend) is not the correct way to go about it. WHAT I want to > know now is whether there are any drivers out there which need the current > behaviour. Ah! I seem to have misunderstood you. If some drivers _do_ need the current block-on-suspend behavior, I feel like that should be an internal driver decision that rfkill shouldn't need to be aware of. Drivers know how to suspend themselves; we shouldn't expect rfkill to know how certain hardware needs to suspend. Dan -- 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
