diff options
| author | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2017-10-26 12:12:08 +0200 |
|---|---|---|
| committer | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2017-11-06 13:57:01 +0100 |
| commit | 0eab11c9ae3b3cc5dd76f20b81d0247647a6e96f (patch) | |
| tree | 28017e02257ab291f966247ad61d37e670c0a320 /drivers/base | |
| parent | c2eac4d3a115e2f511844e7bcf73f4e877fbf5da (diff) | |
| download | linux-0eab11c9ae3b3cc5dd76f20b81d0247647a6e96f.tar.bz2 | |
PM / core: Add SMART_SUSPEND driver flag
Define and document a SMART_SUSPEND flag to instruct bus types and PM
domains that the system suspend callbacks provided by the driver can
cope with runtime-suspended devices, so from the driver's perspective
it should be safe to leave devices in runtime suspend during system
suspend.
Setting that flag may also cause middle-layer code (bus types,
PM domains etc.) to skip invocations of the ->suspend_late and
->suspend_noirq callbacks provided by the driver if the device
is in runtime suspend at the beginning of the "late" phase of
the system-wide suspend transition, in which case the driver's
system-wide resume callbacks may be invoked back-to-back with
its ->runtime_suspend callback, so the driver has to be able to
cope with that too.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Diffstat (limited to 'drivers/base')
| -rw-r--r-- | drivers/base/power/main.c | 3 |
1 files changed, 3 insertions, 0 deletions
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c index c0135cd95ada..8d9024017645 100644 --- a/drivers/base/power/main.c +++ b/drivers/base/power/main.c @@ -1652,6 +1652,9 @@ static int device_prepare(struct device *dev, pm_message_t state) if (dev->power.syscore) return 0; + WARN_ON(dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_SUSPEND) && + !pm_runtime_enabled(dev)); + /* * If a device's parent goes into runtime suspend at the wrong time, * it won't be possible to resume the device. To prevent this we |