forked from luck/tmp_suning_uos_patched
4ecd6e651d
Kevin points out that if there's a device that can wake up the system from sleep states, but it doesn't generate wakeup signals by itself (they are generated on its behalf by other parts of the system) and it currently is not enabled to wake up the system (that is, device_may_wakeup() returns "false" for it), we may need to change its wakeup settings during system suspend (for example, the device might have been configured to signal remote wakeup from the system's working state, as needed by runtime PM). Therefore the generic PM domains code should invoke the system suspend callbacks provided by the device's driver, which it doesn't do if the PM domain is powered off during the system suspend's "prepare" stage. This is a valid point. Moreover, this code also should make sure that system wakeup devices that are enabled to wake up the system from sleep states and have to remain active for this purpose are not suspended while the system is in a sleep state. To avoid the above issues, make the generic PM domains' .prepare() routine, pm_genpd_prepare(), force runtime resume of devices whose system wakeup settings may need to be changed during system suspend or that should remain active while the system is in a sleep state to be able to wake it up from that state. Reported-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> |
||
|---|---|---|
| .. | ||
| power | ||
| attribute_container.c | ||
| base.h | ||
| bus.c | ||
| class.c | ||
| core.c | ||
| cpu.c | ||
| dd.c | ||
| devres.c | ||
| devtmpfs.c | ||
| dma-coherent.c | ||
| dma-mapping.c | ||
| driver.c | ||
| firmware_class.c | ||
| firmware.c | ||
| hypervisor.c | ||
| init.c | ||
| iommu.c | ||
| isa.c | ||
| Kconfig | ||
| Makefile | ||
| map.c | ||
| memory.c | ||
| module.c | ||
| node.c | ||
| platform.c | ||
| sys.c | ||
| syscore.c | ||
| topology.c | ||
| transport_class.c | ||