kernel/linux.git/drivers/base/power/main.c, branch v4.19.16

PM / core: Clear the direct_complete flag on errors

2018-10-04T17:39:31+00:00

If __device_suspend() runs asynchronously (in which case the device passed to it is in dpm_suspended_list at that point) and it returns early on an error or pending wakeup, and the power.direct_complete flag has been set for the device already, the subsequent device_resume() will be confused by that and it will call pm_runtime_enable() incorrectly, as runtime PM has not been disabled for the device by __device_suspend(). To avoid that, clear power.direct_complete if __device_suspend() is not going to disable runtime PM for the device before returning. Fixes: aae4518b3124 (PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily) Reported-by: Al Cooper Tested-by: Al Cooper Reviewed-by: Ulf Hansson Cc: 3.16+ # 3.16+ Signed-off-by: Rafael J. Wysocki

Merge back PM core material for v4.18.

2018-05-25T08:39:39+00:00

PM / core: Fix direct_complete handling for devices with no callbacks

2018-05-22T12:50:11+00:00

Commit 08810a4119aa (PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags) inadvertently prevented the power.direct_complete flag from being set for devices without PM callbacks and with disabled runtime PM which also prevents power.direct_complete from being set for their parents. That led to problems including a resume crash on HP ZBook 14u. Restore the previous behavior by causing power.direct_complete to be set for those devices again, but do that in a more direct way to avoid overlooking that case in the future. Link: https://bugzilla.kernel.org/show_bug.cgi?id=199693 Fixes: 08810a4119aa (PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags) Reported-by: Thomas Martitz Tested-by: Thomas Martitz Cc: 4.15+ # 4.15+ Signed-off-by: Rafael J. Wysocki Reviewed-by: Ulf Hansson Reviewed-by: Johan Hovold

PM / core: Use dev_printk() and symbols in suspend/resume diagnostics

2018-05-10T09:31:45+00:00

When we print diagnostic messages about suspend/resume, we have a device pointer, so use dev_printk() to match other device-related things. Add the function name, similar to initcall_debug output. E.g., - calling 0000:01:00.0+ @ 998, parent: 0000:00:1c.0 + pci 0000:01:00.0: calling @ 998, parent: 0000:00:1c.0 I wondered if this would break scripts/bootgraph.pl, but I don't think it will because bootgraph.pl doesn't add any timing information to $start{} after it sees "Write protecting the" or "Freeing unused kernel memory". Signed-off-by: Bjorn Helgaas Signed-off-by: Rafael J. Wysocki

PM / core: Simplify initcall_debug_report() timing

2018-05-10T09:31:45+00:00

initcall_debug_report() always called ktime_get(), even if we didn't need the result. Change it so we only call it when we're going to use the result, and change initcall_debug_start() to follow the same style. Signed-off-by: Bjorn Helgaas Signed-off-by: Rafael J. Wysocki

PM / core: Remove unused initcall_debug_report() arguments

2018-05-10T09:31:45+00:00

Commit e8bca479c3f2 (PM / sleep: trace events for device PM callbacks) removed the only uses of "state" and "info" from initcall_debug_report(). Remove the now-unused arguments completely. Signed-off-by: Bjorn Helgaas Signed-off-by: Rafael J. Wysocki

PM / core: Propagate wakeup_path status flag in __device_suspend_late()

2018-01-10T12:13:57+00:00

Currently the wakeup_path status flag becomes propagated from a child device to its parent device at __device_suspend(). This allows a driver dealing with a parent device to act on the flag from its ->suspend() callback. However, in situations when the wakeup_path status flag needs to be set from a ->suspend_late() callback, its value doesn't get propagated to the parent by the PM core. Let's address this limitation, by also propagating the flag at __device_suspend_late(). Signed-off-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki

PM / core: Re-structure code for clearing the direct_complete flag

2018-01-10T12:13:56+00:00

To make the code more consistent, let's clear the parent's direct_complete flag along with clearing it for suppliers, instead of as currently, when propagating the wakeup_path flag to parents. While changing this, let's take the opportunity to rename the affected internal functions, to make them self-explanatory. Like this: dpm_clear_suppliers_direct_complete -> dpm_clear_superiors_direct_complete dpm_propagate_to_parent -> dpm_propagate_wakeup_to_parent Signed-off-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki

PM / core: Assign the wakeup_path status flag in __device_prepare()

2018-01-09T12:09:16+00:00

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 are not supposed to be changed (via for example calling device_set_wakeup_enable()) during any system wide suspend/resume phase. Nevertheless there are some users, which can be considered as legacy, that don't conform to this behaviour. These legacy cases should be corrected, however until that is done, let's address the issue from the PM core, by moving the assignment of the wakeup_path status flag to the __device_suspend() phase and after the ->suspend() callback has been invoked. Signed-off-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki

PM / core: Direct DPM_FLAG_LEAVE_SUSPENDED handling

2018-01-02T23:30:00+00:00

Make the PM core handle DPM_FLAG_LEAVE_SUSPENDED directly for devices whose "noirq", "late" and "early" driver callbacks are invoked directly by it. Namely, make it skip all of the system-wide resume callbacks for such devices with DPM_FLAG_LEAVE_SUSPENDED set if they are in runtime suspend during the "noirq" phase of system-wide suspend (or analogous) transitions or the system transition under way is a proper suspend (rather than anything related to hibernation) and the device's wakeup settings are compatible with runtime PM (that is, the device cannot generate wakeup signals at all or it is allowed to wake up the system from sleep). Signed-off-by: Rafael J. Wysocki