On Tue, 05 Aug 2008, Johannes Berg wrote: > On Tue, 2008-08-05 at 14:50 +0200, Johannes Berg wrote: > > On Tue, 2008-08-05 at 09:48 -0300, Henrique de Moraes Holschuh wrote: > > > > > Maybe on net/wireless, but I am really not going to trust that one for, > > > e.g., serial and USB drivers (USB being a bus that is often not shut down > > > during suspend because there are USB wake devices), unless you clearly state > > > you DID review them all, and which ones. > > > > Look, this is _clearly_ the wrong thing to do, so unless you want your > > patches blocked over it, just rip it out. > > You can of course keep the current _wrong_ behaviour of blocking the > radio when suspending, but instead of adding extra API for the > wake-on-wlan case you should work on fixing that. > > If you think that you then need to review all drivers, so be it. I don't > think it makes sense because keeping the device alive requires > additional code nobody in their right mind would write unless they knew > they needed it, like libertas. > > As it stands, rfkill also does the wrong thing for rfkill. You don't > have to fix it, of course, but don't add workarounds. I have prepared a patch that does exactly what you wanted (remove BLOCK on suspend altogether), in the grounds that all drivers should be trying to properly suspend and resume by themselves as much as possible, anyway. I have added the maintainers of the drivers that *might* want to do something about it (i.e. take action to block their transmitters explicitly) in the CC, and documented the source files that might object to the change in the commit message. It will be in my next patchset. I am NOT happy about doing things this way, but I am just too tired of the issue to bother. -- "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
