The PM core in the device_prepare() phase, resets the wakeup_path status flag to the value of device_may_wakeup(). This means if a ->prepare() or a ->suspend() callback for the device would update the device's wakeup setting, this doesn't become reflected in the wakeup_path status flag.
In general this isn't a problem, because wakeup settings isn't supposed to be changed during those system suspend phases. Nevertheless, there are a cases not conforming to that behaviour, as device_set_wakeup_enable() is indeed called from ->suspend() callbacks. To address this, let's move the assignment of the wakeup_path status flag to the __device_suspend() phase and more precisely, after the ->suspend() callback has been invoked. Signed-off-by: Ulf Hansson <[email protected]> --- drivers/base/power/main.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c index 6e8cc5d..810e5fb 100644 --- a/drivers/base/power/main.c +++ b/drivers/base/power/main.c @@ -1620,6 +1620,8 @@ static int __device_suspend(struct device *dev, pm_message_t state, bool async) End: if (!error) { dev->power.is_suspended = true; + if (device_may_wakeup(dev)) + dev->power.wakeup_path = true; dpm_propagate_to_parent(dev); dpm_clear_suppliers_direct_complete(dev); } @@ -1744,7 +1746,7 @@ static int device_prepare(struct device *dev, pm_message_t state) device_lock(dev); - dev->power.wakeup_path = device_may_wakeup(dev); + dev->power.wakeup_path = false; if (dev->power.no_pm_callbacks) { ret = 1; /* Let device go direct_complete */ -- 2.7.4
