On Tue, 2011-02-08 at 13:47 +0200, ext Kalle Valo wrote: > Juuso Oikarinen <juuso.oikarinen@xxxxxxxxx> writes: > > > On Tue, 2011-02-08 at 12:13 +0200, ext Kalle Valo wrote: > >> Juuso Oikarinen <juuso.oikarinen@xxxxxxxxx> writes: > >> > >> To me platform specific changes in drivers are always problematic. > > > > Yeah I tend to agree. > > > > But then for some reason there is this interface in interrupts.h to do > > this, and AFAIU the one requesting the IRQ and controlling enabling and > > disabling of it is supposed to also tune this wakeing on/off. Apparently > > it should even do this when just enabling/disabling the interrupt - > > which are things performed in the driver. > > Yeah, you have a point. There has to be some reason for adding this. > Unfortunately the documentation I found was scarse and I didn't get > how it should be used. For example, wakeup from what? Only from > suspend? Or also from sleep states? But then again, isn't it obvious > that an irq from the device should wake the cpu from sleep states? > > And to make this more generic: should all wifi drivers use > enable_irq_wake()? > > (Just trying to understand this.) > Luca, please discard this patch. Based on the text in interrupt.h this is for waking up from suspend and the like, which is not why I'm calling it here - the wl12xx is switched off in suspend anyway, so no IRQ's. As you say, it should be self-evident that a WLAN driver (or most other drivers for that matter) will want to wake the host from cpu-power-saving state without explicitly having to say that. Starts to sound like there is some weird hack in our kernel tree. I'll need to pursue that further. -Juuso -- 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
