[...] >>>> How many drivers actually do call device_set_wakeup_enable() during >>>> suspend? >>> >>> There are some ethernet/wifi drivers, although it hard to say how many >>> without a more thorough investigation. >>> >>> Besides those I found these more obvious ones: >>> drivers/ssb/pcihost_wrapper.c >>> drivers/staging/rtlwifi/core.c >>> drivers/tty/serial/atmel_serial.c >>> drivers/usb/core/hcd-pci.c >> >> Ugh. I need to look at the last one at least ... > > The drivers/usb/core/hcd-pci.c instance is actually valid, because it > calls device_set_wakeup_enable() to remove the wakeup source object in > case the device is dead. Moreover, it does that in the "noirq" phase > which is not covered by your patch anyway.
Right, but this puzzles me a bit. Could you explain what you mean by valid here? Is it okay to call device_set_wakeup_enable() in the suspend phase after all? No? My very vague idea at this point is, if we find cases where device_set_wakeup_enable() makes sense to call during system suspend, probably those could/should be replaces by using the "wakeup_path" flag instead, somehow. Kind regards Uffe
