2019-04-02 13:32:01 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* drivers/base/power/main.c - Where the driver meets power management.
|
|
|
|
*
|
|
|
|
* Copyright (c) 2003 Patrick Mochel
|
|
|
|
* Copyright (c) 2003 Open Source Development Lab
|
|
|
|
*
|
|
|
|
* The driver model core calls device_pm_add() when a device is registered.
|
tree-wide: fix comment/printk typos
"gadget", "through", "command", "maintain", "maintain", "controller", "address",
"between", "initiali[zs]e", "instead", "function", "select", "already",
"equal", "access", "management", "hierarchy", "registration", "interest",
"relative", "memory", "offset", "already",
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2010-11-01 19:38:34 +00:00
|
|
|
* This will initialize the embedded device_pm_info object in the device
|
2005-04-16 22:20:36 +00:00
|
|
|
* and add it to the list of power-controlled devices. sysfs entries for
|
|
|
|
* controlling device power management will also be added.
|
|
|
|
*
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
* A separate list is used for keeping track of power info, because the power
|
|
|
|
* domain dependencies may differ from the ancestral dependencies that the
|
|
|
|
* subsystem list maintains.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
|
|
|
|
2019-03-04 17:14:38 +00:00
|
|
|
#define pr_fmt(fmt) "PM: " fmt
|
2021-01-26 21:29:40 +00:00
|
|
|
#define dev_fmt pr_fmt
|
2019-03-04 17:14:38 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
#include <linux/device.h>
|
2011-05-27 11:12:15 +00:00
|
|
|
#include <linux/export.h>
|
2007-05-23 21:19:41 +00:00
|
|
|
#include <linux/mutex.h>
|
2007-09-21 19:36:56 +00:00
|
|
|
#include <linux/pm.h>
|
2009-08-18 21:38:32 +00:00
|
|
|
#include <linux/pm_runtime.h>
|
2015-03-18 14:54:27 +00:00
|
|
|
#include <linux/pm-trace.h>
|
PM / Wakeirq: Add automated device wake IRQ handling
Turns out we can automate the handling for the device_may_wakeup()
quite a bit by using the kernel wakeup source list as suggested
by Rafael J. Wysocki <rjw@rjwysocki.net>.
And as some hardware has separate dedicated wake-up interrupt
in addition to the IO interrupt, we can automate the handling by
adding a generic threaded interrupt handler that just calls the
device PM runtime to wake up the device.
This allows dropping code from device drivers as we currently
are doing it in multiple ways, and often wrong.
For most drivers, we should be able to drop the following
boilerplate code from runtime_suspend and runtime_resume
functions:
...
device_init_wakeup(dev, true);
...
if (device_may_wakeup(dev))
enable_irq_wake(irq);
...
if (device_may_wakeup(dev))
disable_irq_wake(irq);
...
device_init_wakeup(dev, false);
...
We can replace it with just the following init and exit
time code:
...
device_init_wakeup(dev, true);
dev_pm_set_wake_irq(dev, irq);
...
dev_pm_clear_wake_irq(dev);
device_init_wakeup(dev, false);
...
And for hardware with dedicated wake-up interrupts:
...
device_init_wakeup(dev, true);
dev_pm_set_dedicated_wake_irq(dev, irq);
...
dev_pm_clear_wake_irq(dev);
device_init_wakeup(dev, false);
...
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-05-18 22:40:29 +00:00
|
|
|
#include <linux/pm_wakeirq.h>
|
2009-03-16 21:34:06 +00:00
|
|
|
#include <linux/interrupt.h>
|
2009-12-13 19:29:01 +00:00
|
|
|
#include <linux/sched.h>
|
2017-02-08 17:51:35 +00:00
|
|
|
#include <linux/sched/debug.h>
|
PM: Asynchronous suspend and resume of devices
Theoretically, the total time of system sleep transitions (suspend
to RAM, hibernation) can be reduced by running suspend and resume
callbacks of device drivers in parallel with each other. However,
there are dependencies between devices such that we're not allowed
to suspend the parent of a device before suspending the device
itself. Analogously, we're not allowed to resume a device before
resuming its parent.
The most straightforward way to take these dependencies into accout
is to start the async threads used for suspending and resuming
devices at the core level, so that async_schedule() is called for
each suspend and resume callback supposed to be executed
asynchronously.
For this purpose, introduce a new device flag, power.async_suspend,
used to mark the devices whose suspend and resume callbacks are to be
executed asynchronously (ie. in parallel with the main suspend/resume
thread and possibly in parallel with each other) and helper function
device_enable_async_suspend() allowing one to set power.async_suspend
for given device (power.async_suspend is unset by default for all
devices). For each device with the power.async_suspend flag set the
PM core will use async_schedule() to execute its suspend and resume
callbacks.
The async threads started for different devices as a result of
calling async_schedule() are synchronized with each other and with
the main suspend/resume thread with the help of completions, in the
following way:
(1) There is a completion, power.completion, for each device object.
(2) Each device's completion is reset before calling async_schedule()
for the device or, in the case of devices with the
power.async_suspend flags unset, before executing the device's
suspend and resume callbacks.
(3) During suspend, right before running the bus type, device type
and device class suspend callbacks for the device, the PM core
waits for the completions of all the device's children to be
completed.
(4) During resume, right before running the bus type, device type and
device class resume callbacks for the device, the PM core waits
for the completion of the device's parent to be completed.
(5) The PM core completes power.completion for each device right
after the bus type, device type and device class suspend (or
resume) callbacks executed for the device have returned.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-01-23 21:23:32 +00:00
|
|
|
#include <linux/async.h>
|
2010-12-03 21:58:05 +00:00
|
|
|
#include <linux/suspend.h>
|
2013-07-26 19:30:20 +00:00
|
|
|
#include <trace/events/power.h>
|
2014-03-04 03:00:26 +00:00
|
|
|
#include <linux/cpufreq.h>
|
2018-12-05 11:05:55 +00:00
|
|
|
#include <linux/devfreq.h>
|
2013-10-17 17:48:46 +00:00
|
|
|
#include <linux/timer.h>
|
|
|
|
|
2007-09-21 19:36:56 +00:00
|
|
|
#include "../base.h"
|
2005-04-16 22:20:36 +00:00
|
|
|
#include "power.h"
|
|
|
|
|
2011-12-17 23:34:01 +00:00
|
|
|
typedef int (*pm_callback_t)(struct device *);
|
|
|
|
|
2020-03-03 19:41:30 +00:00
|
|
|
#define list_for_each_entry_rcu_locked(pos, head, member) \
|
|
|
|
list_for_each_entry_rcu(pos, head, member, \
|
|
|
|
device_links_read_lock_held())
|
|
|
|
|
2008-01-12 19:40:46 +00:00
|
|
|
/*
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
* The entries in the dpm_list list are in a depth first order, simply
|
2008-01-12 19:40:46 +00:00
|
|
|
* because children are guaranteed to be discovered after parents, and
|
|
|
|
* are inserted at the back of the list on discovery.
|
|
|
|
*
|
2010-02-17 18:57:05 +00:00
|
|
|
* Since device_pm_add() may be called with a device lock held,
|
|
|
|
* we must never try to acquire a device lock while holding
|
2008-01-12 19:40:46 +00:00
|
|
|
* dpm_list_mutex.
|
|
|
|
*/
|
|
|
|
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
LIST_HEAD(dpm_list);
|
2012-07-17 20:38:08 +00:00
|
|
|
static LIST_HEAD(dpm_prepared_list);
|
|
|
|
static LIST_HEAD(dpm_suspended_list);
|
|
|
|
static LIST_HEAD(dpm_late_early_list);
|
|
|
|
static LIST_HEAD(dpm_noirq_list);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
PM / Suspend: Add statistics debugfs file for suspend to RAM
Record S3 failure time about each reason and the latest two failed
devices' names in S3 progress.
We can check it through 'suspend_stats' entry in debugfs.
The motivation of the patch:
We are enabling power features on Medfield. Comparing with PC/notebook,
a mobile enters/exits suspend-2-ram (we call it s3 on Medfield) far
more frequently. If it can't enter suspend-2-ram in time, the power
might be used up soon.
We often find sometimes, a device suspend fails. Then, system retries
s3 over and over again. As display is off, testers and developers
don't know what happens.
Some testers and developers complain they don't know if system
tries suspend-2-ram, and what device fails to suspend. They need
such info for a quick check. The patch adds suspend_stats under
debugfs for users to check suspend to RAM statistics quickly.
If not using this patch, we have other methods to get info about
what device fails. One is to turn on CONFIG_PM_DEBUG, but users
would get too much info and testers need recompile the system.
In addition, dynamic debug is another good tool to dump debug info.
But it still doesn't match our utilization scenario closely.
1) user need write a user space parser to process the syslog output;
2) Our testing scenario is we leave the mobile for at least hours.
Then, check its status. No serial console available during the
testing. One is because console would be suspended, and the other
is serial console connecting with spi or HSU devices would consume
power. These devices are powered off at suspend-2-ram.
Signed-off-by: ShuoX Liu <shuox.liu@intel.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-08-10 21:01:26 +00:00
|
|
|
struct suspend_stats suspend_stats;
|
2007-09-21 19:36:56 +00:00
|
|
|
static DEFINE_MUTEX(dpm_list_mtx);
|
PM: Asynchronous suspend and resume of devices
Theoretically, the total time of system sleep transitions (suspend
to RAM, hibernation) can be reduced by running suspend and resume
callbacks of device drivers in parallel with each other. However,
there are dependencies between devices such that we're not allowed
to suspend the parent of a device before suspending the device
itself. Analogously, we're not allowed to resume a device before
resuming its parent.
The most straightforward way to take these dependencies into accout
is to start the async threads used for suspending and resuming
devices at the core level, so that async_schedule() is called for
each suspend and resume callback supposed to be executed
asynchronously.
For this purpose, introduce a new device flag, power.async_suspend,
used to mark the devices whose suspend and resume callbacks are to be
executed asynchronously (ie. in parallel with the main suspend/resume
thread and possibly in parallel with each other) and helper function
device_enable_async_suspend() allowing one to set power.async_suspend
for given device (power.async_suspend is unset by default for all
devices). For each device with the power.async_suspend flag set the
PM core will use async_schedule() to execute its suspend and resume
callbacks.
The async threads started for different devices as a result of
calling async_schedule() are synchronized with each other and with
the main suspend/resume thread with the help of completions, in the
following way:
(1) There is a completion, power.completion, for each device object.
(2) Each device's completion is reset before calling async_schedule()
for the device or, in the case of devices with the
power.async_suspend flags unset, before executing the device's
suspend and resume callbacks.
(3) During suspend, right before running the bus type, device type
and device class suspend callbacks for the device, the PM core
waits for the completions of all the device's children to be
completed.
(4) During resume, right before running the bus type, device type and
device class resume callbacks for the device, the PM core waits
for the completion of the device's parent to be completed.
(5) The PM core completes power.completion for each device right
after the bus type, device type and device class suspend (or
resume) callbacks executed for the device have returned.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-01-23 21:23:32 +00:00
|
|
|
static pm_message_t pm_transition;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2010-09-22 20:10:57 +00:00
|
|
|
static int async_error;
|
|
|
|
|
2017-06-12 15:19:31 +00:00
|
|
|
static const char *pm_verb(int event)
|
2013-07-26 19:30:20 +00:00
|
|
|
{
|
|
|
|
switch (event) {
|
|
|
|
case PM_EVENT_SUSPEND:
|
|
|
|
return "suspend";
|
|
|
|
case PM_EVENT_RESUME:
|
|
|
|
return "resume";
|
|
|
|
case PM_EVENT_FREEZE:
|
|
|
|
return "freeze";
|
|
|
|
case PM_EVENT_QUIESCE:
|
|
|
|
return "quiesce";
|
|
|
|
case PM_EVENT_HIBERNATE:
|
|
|
|
return "hibernate";
|
|
|
|
case PM_EVENT_THAW:
|
|
|
|
return "thaw";
|
|
|
|
case PM_EVENT_RESTORE:
|
|
|
|
return "restore";
|
|
|
|
case PM_EVENT_RECOVER:
|
|
|
|
return "recover";
|
|
|
|
default:
|
|
|
|
return "(unknown PM event)";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-08-18 21:38:32 +00:00
|
|
|
/**
|
2012-08-05 23:44:28 +00:00
|
|
|
* device_pm_sleep_init - Initialize system suspend-related device fields.
|
2009-08-18 21:38:32 +00:00
|
|
|
* @dev: Device object being initialized.
|
|
|
|
*/
|
2012-08-05 23:44:28 +00:00
|
|
|
void device_pm_sleep_init(struct device *dev)
|
2009-08-18 21:38:32 +00:00
|
|
|
{
|
2011-06-18 18:22:23 +00:00
|
|
|
dev->power.is_prepared = false;
|
2011-06-18 20:42:09 +00:00
|
|
|
dev->power.is_suspended = false;
|
2014-02-18 02:28:44 +00:00
|
|
|
dev->power.is_noirq_suspended = false;
|
|
|
|
dev->power.is_late_suspended = false;
|
PM: Asynchronous suspend and resume of devices
Theoretically, the total time of system sleep transitions (suspend
to RAM, hibernation) can be reduced by running suspend and resume
callbacks of device drivers in parallel with each other. However,
there are dependencies between devices such that we're not allowed
to suspend the parent of a device before suspending the device
itself. Analogously, we're not allowed to resume a device before
resuming its parent.
The most straightforward way to take these dependencies into accout
is to start the async threads used for suspending and resuming
devices at the core level, so that async_schedule() is called for
each suspend and resume callback supposed to be executed
asynchronously.
For this purpose, introduce a new device flag, power.async_suspend,
used to mark the devices whose suspend and resume callbacks are to be
executed asynchronously (ie. in parallel with the main suspend/resume
thread and possibly in parallel with each other) and helper function
device_enable_async_suspend() allowing one to set power.async_suspend
for given device (power.async_suspend is unset by default for all
devices). For each device with the power.async_suspend flag set the
PM core will use async_schedule() to execute its suspend and resume
callbacks.
The async threads started for different devices as a result of
calling async_schedule() are synchronized with each other and with
the main suspend/resume thread with the help of completions, in the
following way:
(1) There is a completion, power.completion, for each device object.
(2) Each device's completion is reset before calling async_schedule()
for the device or, in the case of devices with the
power.async_suspend flags unset, before executing the device's
suspend and resume callbacks.
(3) During suspend, right before running the bus type, device type
and device class suspend callbacks for the device, the PM core
waits for the completions of all the device's children to be
completed.
(4) During resume, right before running the bus type, device type and
device class resume callbacks for the device, the PM core waits
for the completion of the device's parent to be completed.
(5) The PM core completes power.completion for each device right
after the bus type, device type and device class suspend (or
resume) callbacks executed for the device have returned.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-01-23 21:23:32 +00:00
|
|
|
init_completion(&dev->power.completion);
|
PM: Prevent waiting forever on asynchronous resume after failing suspend
During suspend, the power.completion is expected to be set when a
device has not yet started suspending. Set it on init to fix a
corner case where a device is resumed when its parent has never
suspended.
Consider three drivers, A, B, and C. The parent of A is C, and C
has async_suspend set. On boot, C->power.completion is initialized
to 0.
During the first suspend:
suspend_devices_and_enter(...)
dpm_resume(...)
device_suspend(A)
device_suspend(B) returns error, aborts suspend
dpm_resume_end(...)
dpm_resume(...)
device_resume(A)
dpm_wait(A->parent == C)
wait_for_completion(C->power.completion)
The wait_for_completion will never complete, because
complete_all(C->power.completion) will only be called from
device_suspend(C) or device_resume(C), neither of which is called
if suspend is aborted before C.
After a successful suspend->resume cycle, where B doesn't abort
suspend, C->power.completion is left in the completed state by the
call to device_resume(C), and the same call path will work if B
aborts suspend.
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-09-02 23:24:07 +00:00
|
|
|
complete_all(&dev->power.completion);
|
2010-09-22 20:09:10 +00:00
|
|
|
dev->power.wakeup = NULL;
|
2011-04-26 09:33:09 +00:00
|
|
|
INIT_LIST_HEAD(&dev->power.entry);
|
2009-08-18 21:38:32 +00:00
|
|
|
}
|
|
|
|
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
/**
|
2009-08-20 18:25:52 +00:00
|
|
|
* device_pm_lock - Lock the list of active devices used by the PM core.
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
*/
|
|
|
|
void device_pm_lock(void)
|
|
|
|
{
|
|
|
|
mutex_lock(&dpm_list_mtx);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2009-08-20 18:25:52 +00:00
|
|
|
* device_pm_unlock - Unlock the list of active devices used by the PM core.
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
*/
|
|
|
|
void device_pm_unlock(void)
|
|
|
|
{
|
|
|
|
mutex_unlock(&dpm_list_mtx);
|
|
|
|
}
|
2007-04-26 07:12:06 +00:00
|
|
|
|
2008-01-12 19:40:46 +00:00
|
|
|
/**
|
2009-08-20 18:25:52 +00:00
|
|
|
* device_pm_add - Add a device to the PM core's list of active devices.
|
|
|
|
* @dev: Device to add to the list.
|
2008-01-12 19:40:46 +00:00
|
|
|
*/
|
2008-08-07 17:06:12 +00:00
|
|
|
void device_pm_add(struct device *dev)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2019-02-14 18:29:10 +00:00
|
|
|
/* Skip PM setup/initialization. */
|
|
|
|
if (device_pm_not_required(dev))
|
|
|
|
return;
|
|
|
|
|
2019-03-04 17:14:38 +00:00
|
|
|
pr_debug("Adding info for %s:%s\n",
|
2010-12-24 14:03:34 +00:00
|
|
|
dev->bus ? dev->bus->name : "No Bus", dev_name(dev));
|
2016-01-07 15:46:14 +00:00
|
|
|
device_pm_check_callbacks(dev);
|
2007-05-23 21:19:41 +00:00
|
|
|
mutex_lock(&dpm_list_mtx);
|
2011-06-18 18:22:23 +00:00
|
|
|
if (dev->parent && dev->parent->power.is_prepared)
|
2010-12-16 16:11:45 +00:00
|
|
|
dev_warn(dev, "parent %s should not be sleeping\n",
|
|
|
|
dev_name(dev->parent));
|
2008-08-07 17:06:12 +00:00
|
|
|
list_add_tail(&dev->power.entry, &dpm_list);
|
driver core: Functional dependencies tracking support
Currently, there is a problem with taking functional dependencies
between devices into account.
What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.
Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.
The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).
For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.
Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.
The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.
In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().
New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.
One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.
For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.
There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().
Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().
Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.
For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-30 16:32:16 +00:00
|
|
|
dev->power.in_dpm_list = true;
|
2011-09-29 20:29:44 +00:00
|
|
|
mutex_unlock(&dpm_list_mtx);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2008-01-12 19:40:46 +00:00
|
|
|
/**
|
2009-08-20 18:25:52 +00:00
|
|
|
* device_pm_remove - Remove a device from the PM core's list of active devices.
|
|
|
|
* @dev: Device to be removed from the list.
|
2008-01-12 19:40:46 +00:00
|
|
|
*/
|
2007-06-13 13:53:34 +00:00
|
|
|
void device_pm_remove(struct device *dev)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2019-02-14 18:29:10 +00:00
|
|
|
if (device_pm_not_required(dev))
|
|
|
|
return;
|
|
|
|
|
2019-03-04 17:14:38 +00:00
|
|
|
pr_debug("Removing info for %s:%s\n",
|
2010-12-24 14:03:34 +00:00
|
|
|
dev->bus ? dev->bus->name : "No Bus", dev_name(dev));
|
PM: Asynchronous suspend and resume of devices
Theoretically, the total time of system sleep transitions (suspend
to RAM, hibernation) can be reduced by running suspend and resume
callbacks of device drivers in parallel with each other. However,
there are dependencies between devices such that we're not allowed
to suspend the parent of a device before suspending the device
itself. Analogously, we're not allowed to resume a device before
resuming its parent.
The most straightforward way to take these dependencies into accout
is to start the async threads used for suspending and resuming
devices at the core level, so that async_schedule() is called for
each suspend and resume callback supposed to be executed
asynchronously.
For this purpose, introduce a new device flag, power.async_suspend,
used to mark the devices whose suspend and resume callbacks are to be
executed asynchronously (ie. in parallel with the main suspend/resume
thread and possibly in parallel with each other) and helper function
device_enable_async_suspend() allowing one to set power.async_suspend
for given device (power.async_suspend is unset by default for all
devices). For each device with the power.async_suspend flag set the
PM core will use async_schedule() to execute its suspend and resume
callbacks.
The async threads started for different devices as a result of
calling async_schedule() are synchronized with each other and with
the main suspend/resume thread with the help of completions, in the
following way:
(1) There is a completion, power.completion, for each device object.
(2) Each device's completion is reset before calling async_schedule()
for the device or, in the case of devices with the
power.async_suspend flags unset, before executing the device's
suspend and resume callbacks.
(3) During suspend, right before running the bus type, device type
and device class suspend callbacks for the device, the PM core
waits for the completions of all the device's children to be
completed.
(4) During resume, right before running the bus type, device type and
device class resume callbacks for the device, the PM core waits
for the completion of the device's parent to be completed.
(5) The PM core completes power.completion for each device right
after the bus type, device type and device class suspend (or
resume) callbacks executed for the device have returned.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-01-23 21:23:32 +00:00
|
|
|
complete_all(&dev->power.completion);
|
2007-05-23 21:19:41 +00:00
|
|
|
mutex_lock(&dpm_list_mtx);
|
2005-04-16 22:20:36 +00:00
|
|
|
list_del_init(&dev->power.entry);
|
driver core: Functional dependencies tracking support
Currently, there is a problem with taking functional dependencies
between devices into account.
What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.
Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.
The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).
For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.
Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.
The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.
In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().
New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.
One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.
For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.
There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().
Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().
Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.
For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-30 16:32:16 +00:00
|
|
|
dev->power.in_dpm_list = false;
|
2007-05-23 21:19:41 +00:00
|
|
|
mutex_unlock(&dpm_list_mtx);
|
2010-09-22 20:09:10 +00:00
|
|
|
device_wakeup_disable(dev);
|
2009-08-18 21:38:32 +00:00
|
|
|
pm_runtime_remove(dev);
|
2016-01-07 15:46:14 +00:00
|
|
|
device_pm_check_callbacks(dev);
|
2008-01-12 19:40:46 +00:00
|
|
|
}
|
|
|
|
|
2009-03-04 11:44:00 +00:00
|
|
|
/**
|
2009-08-20 18:25:52 +00:00
|
|
|
* device_pm_move_before - Move device in the PM core's list of active devices.
|
|
|
|
* @deva: Device to move in dpm_list.
|
|
|
|
* @devb: Device @deva should come before.
|
2009-03-04 11:44:00 +00:00
|
|
|
*/
|
|
|
|
void device_pm_move_before(struct device *deva, struct device *devb)
|
|
|
|
{
|
2019-03-04 17:14:38 +00:00
|
|
|
pr_debug("Moving %s:%s before %s:%s\n",
|
2010-12-24 14:03:34 +00:00
|
|
|
deva->bus ? deva->bus->name : "No Bus", dev_name(deva),
|
|
|
|
devb->bus ? devb->bus->name : "No Bus", dev_name(devb));
|
2009-03-04 11:44:00 +00:00
|
|
|
/* Delete deva from dpm_list and reinsert before devb. */
|
|
|
|
list_move_tail(&deva->power.entry, &devb->power.entry);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2009-08-20 18:25:52 +00:00
|
|
|
* device_pm_move_after - Move device in the PM core's list of active devices.
|
|
|
|
* @deva: Device to move in dpm_list.
|
|
|
|
* @devb: Device @deva should come after.
|
2009-03-04 11:44:00 +00:00
|
|
|
*/
|
|
|
|
void device_pm_move_after(struct device *deva, struct device *devb)
|
|
|
|
{
|
2019-03-04 17:14:38 +00:00
|
|
|
pr_debug("Moving %s:%s after %s:%s\n",
|
2010-12-24 14:03:34 +00:00
|
|
|
deva->bus ? deva->bus->name : "No Bus", dev_name(deva),
|
|
|
|
devb->bus ? devb->bus->name : "No Bus", dev_name(devb));
|
2009-03-04 11:44:00 +00:00
|
|
|
/* Delete deva from dpm_list and reinsert after devb. */
|
|
|
|
list_move(&deva->power.entry, &devb->power.entry);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2009-08-20 18:25:52 +00:00
|
|
|
* device_pm_move_last - Move device to end of the PM core's list of devices.
|
|
|
|
* @dev: Device to move in dpm_list.
|
2009-03-04 11:44:00 +00:00
|
|
|
*/
|
|
|
|
void device_pm_move_last(struct device *dev)
|
|
|
|
{
|
2019-03-04 17:14:38 +00:00
|
|
|
pr_debug("Moving %s:%s to end of list\n",
|
2010-12-24 14:03:34 +00:00
|
|
|
dev->bus ? dev->bus->name : "No Bus", dev_name(dev));
|
2009-03-04 11:44:00 +00:00
|
|
|
list_move_tail(&dev->power.entry, &dpm_list);
|
|
|
|
}
|
|
|
|
|
2018-04-26 21:36:41 +00:00
|
|
|
static ktime_t initcall_debug_start(struct device *dev, void *cb)
|
2009-12-18 00:57:31 +00:00
|
|
|
{
|
2018-04-26 21:36:34 +00:00
|
|
|
if (!pm_print_times_enabled)
|
|
|
|
return 0;
|
2009-12-18 00:57:31 +00:00
|
|
|
|
2019-03-25 19:32:28 +00:00
|
|
|
dev_info(dev, "calling %pS @ %i, parent: %s\n", cb,
|
2018-04-26 21:36:41 +00:00
|
|
|
task_pid_nr(current),
|
|
|
|
dev->parent ? dev_name(dev->parent) : "none");
|
2018-04-26 21:36:34 +00:00
|
|
|
return ktime_get();
|
2009-12-18 00:57:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void initcall_debug_report(struct device *dev, ktime_t calltime,
|
2018-04-26 21:36:41 +00:00
|
|
|
void *cb, int error)
|
2009-12-18 00:57:31 +00:00
|
|
|
{
|
2013-07-26 19:30:20 +00:00
|
|
|
ktime_t rettime;
|
|
|
|
|
2018-04-26 21:36:34 +00:00
|
|
|
if (!pm_print_times_enabled)
|
|
|
|
return;
|
|
|
|
|
2013-07-26 19:30:20 +00:00
|
|
|
rettime = ktime_get();
|
2019-03-25 19:32:28 +00:00
|
|
|
dev_info(dev, "%pS returned %d after %Ld usecs\n", cb, error,
|
2021-07-01 00:45:38 +00:00
|
|
|
(unsigned long long)ktime_us_delta(rettime, calltime));
|
2009-12-18 00:57:31 +00:00
|
|
|
}
|
|
|
|
|
PM: Asynchronous suspend and resume of devices
Theoretically, the total time of system sleep transitions (suspend
to RAM, hibernation) can be reduced by running suspend and resume
callbacks of device drivers in parallel with each other. However,
there are dependencies between devices such that we're not allowed
to suspend the parent of a device before suspending the device
itself. Analogously, we're not allowed to resume a device before
resuming its parent.
The most straightforward way to take these dependencies into accout
is to start the async threads used for suspending and resuming
devices at the core level, so that async_schedule() is called for
each suspend and resume callback supposed to be executed
asynchronously.
For this purpose, introduce a new device flag, power.async_suspend,
used to mark the devices whose suspend and resume callbacks are to be
executed asynchronously (ie. in parallel with the main suspend/resume
thread and possibly in parallel with each other) and helper function
device_enable_async_suspend() allowing one to set power.async_suspend
for given device (power.async_suspend is unset by default for all
devices). For each device with the power.async_suspend flag set the
PM core will use async_schedule() to execute its suspend and resume
callbacks.
The async threads started for different devices as a result of
calling async_schedule() are synchronized with each other and with
the main suspend/resume thread with the help of completions, in the
following way:
(1) There is a completion, power.completion, for each device object.
(2) Each device's completion is reset before calling async_schedule()
for the device or, in the case of devices with the
power.async_suspend flags unset, before executing the device's
suspend and resume callbacks.
(3) During suspend, right before running the bus type, device type
and device class suspend callbacks for the device, the PM core
waits for the completions of all the device's children to be
completed.
(4) During resume, right before running the bus type, device type and
device class resume callbacks for the device, the PM core waits
for the completion of the device's parent to be completed.
(5) The PM core completes power.completion for each device right
after the bus type, device type and device class suspend (or
resume) callbacks executed for the device have returned.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-01-23 21:23:32 +00:00
|
|
|
/**
|
|
|
|
* dpm_wait - Wait for a PM operation to complete.
|
|
|
|
* @dev: Device to wait for.
|
|
|
|
* @async: If unset, wait only if the device's power.async_suspend flag is set.
|
|
|
|
*/
|
|
|
|
static void dpm_wait(struct device *dev, bool async)
|
|
|
|
{
|
|
|
|
if (!dev)
|
|
|
|
return;
|
|
|
|
|
2010-01-23 21:25:15 +00:00
|
|
|
if (async || (pm_async_enabled && dev->power.async_suspend))
|
PM: Asynchronous suspend and resume of devices
Theoretically, the total time of system sleep transitions (suspend
to RAM, hibernation) can be reduced by running suspend and resume
callbacks of device drivers in parallel with each other. However,
there are dependencies between devices such that we're not allowed
to suspend the parent of a device before suspending the device
itself. Analogously, we're not allowed to resume a device before
resuming its parent.
The most straightforward way to take these dependencies into accout
is to start the async threads used for suspending and resuming
devices at the core level, so that async_schedule() is called for
each suspend and resume callback supposed to be executed
asynchronously.
For this purpose, introduce a new device flag, power.async_suspend,
used to mark the devices whose suspend and resume callbacks are to be
executed asynchronously (ie. in parallel with the main suspend/resume
thread and possibly in parallel with each other) and helper function
device_enable_async_suspend() allowing one to set power.async_suspend
for given device (power.async_suspend is unset by default for all
devices). For each device with the power.async_suspend flag set the
PM core will use async_schedule() to execute its suspend and resume
callbacks.
The async threads started for different devices as a result of
calling async_schedule() are synchronized with each other and with
the main suspend/resume thread with the help of completions, in the
following way:
(1) There is a completion, power.completion, for each device object.
(2) Each device's completion is reset before calling async_schedule()
for the device or, in the case of devices with the
power.async_suspend flags unset, before executing the device's
suspend and resume callbacks.
(3) During suspend, right before running the bus type, device type
and device class suspend callbacks for the device, the PM core
waits for the completions of all the device's children to be
completed.
(4) During resume, right before running the bus type, device type and
device class resume callbacks for the device, the PM core waits
for the completion of the device's parent to be completed.
(5) The PM core completes power.completion for each device right
after the bus type, device type and device class suspend (or
resume) callbacks executed for the device have returned.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-01-23 21:23:32 +00:00
|
|
|
wait_for_completion(&dev->power.completion);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dpm_wait_fn(struct device *dev, void *async_ptr)
|
|
|
|
{
|
|
|
|
dpm_wait(dev, *((bool *)async_ptr));
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void dpm_wait_for_children(struct device *dev, bool async)
|
|
|
|
{
|
|
|
|
device_for_each_child(dev, &async, dpm_wait_fn);
|
|
|
|
}
|
|
|
|
|
2016-10-30 16:28:49 +00:00
|
|
|
static void dpm_wait_for_suppliers(struct device *dev, bool async)
|
|
|
|
{
|
|
|
|
struct device_link *link;
|
|
|
|
int idx;
|
|
|
|
|
|
|
|
idx = device_links_read_lock();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the supplier goes away right after we've checked the link to it,
|
|
|
|
* we'll wait for its completion to change the state, but that's fine,
|
|
|
|
* because the only things that will block as a result are the SRCU
|
|
|
|
* callbacks freeing the link objects for the links in the list we're
|
|
|
|
* walking.
|
|
|
|
*/
|
2020-03-03 19:41:30 +00:00
|
|
|
list_for_each_entry_rcu_locked(link, &dev->links.suppliers, c_node)
|
2016-10-30 16:28:49 +00:00
|
|
|
if (READ_ONCE(link->status) != DL_STATE_DORMANT)
|
|
|
|
dpm_wait(link->supplier, async);
|
|
|
|
|
|
|
|
device_links_read_unlock(idx);
|
|
|
|
}
|
|
|
|
|
PM: core: Fix handling of devices deleted during system-wide resume
If a device is deleted by one of its system-wide resume callbacks
(for example, because it does not appear to be present or accessible
any more) along with its children, the resume of the children may
continue leading to use-after-free errors and other issues
(potentially).
Namely, if the device's children are resumed asynchronously, their
resume may have been scheduled already before the device's callback
runs and so the device may be deleted while dpm_wait_for_superior()
is being executed for them. The memory taken up by the parent device
object may be freed then while dpm_wait() is waiting for the parent's
resume callback to complete, which leads to a use-after-free.
Moreover, the resume of the children is really not expected to
continue after they have been unregistered, so it must be terminated
right away in that case.
To address this problem, modify dpm_wait_for_superior() to check
if the target device is still there in the system-wide PM list of
devices and if so, to increment its parent's reference counter, both
under dpm_list_mtx which prevents device_del() running for the child
from dropping the parent's reference counter prematurely.
If the device is not present in the system-wide PM list of devices
any more, the resume of it cannot continue, so check that again after
dpm_wait() returns, which means that the parent's callback has been
completed, and pass the result of that check to the caller of
dpm_wait_for_superior() to allow it to abort the device's resume
if it is not there any more.
Link: https://lore.kernel.org/linux-pm/1579568452-27253-1-git-send-email-chanho.min@lge.com
Reported-by: Chanho Min <chanho.min@lge.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-22 23:11:24 +00:00
|
|
|
static bool dpm_wait_for_superior(struct device *dev, bool async)
|
2016-10-30 16:28:49 +00:00
|
|
|
{
|
PM: core: Fix handling of devices deleted during system-wide resume
If a device is deleted by one of its system-wide resume callbacks
(for example, because it does not appear to be present or accessible
any more) along with its children, the resume of the children may
continue leading to use-after-free errors and other issues
(potentially).
Namely, if the device's children are resumed asynchronously, their
resume may have been scheduled already before the device's callback
runs and so the device may be deleted while dpm_wait_for_superior()
is being executed for them. The memory taken up by the parent device
object may be freed then while dpm_wait() is waiting for the parent's
resume callback to complete, which leads to a use-after-free.
Moreover, the resume of the children is really not expected to
continue after they have been unregistered, so it must be terminated
right away in that case.
To address this problem, modify dpm_wait_for_superior() to check
if the target device is still there in the system-wide PM list of
devices and if so, to increment its parent's reference counter, both
under dpm_list_mtx which prevents device_del() running for the child
from dropping the parent's reference counter prematurely.
If the device is not present in the system-wide PM list of devices
any more, the resume of it cannot continue, so check that again after
dpm_wait() returns, which means that the parent's callback has been
completed, and pass the result of that check to the caller of
dpm_wait_for_superior() to allow it to abort the device's resume
if it is not there any more.
Link: https://lore.kernel.org/linux-pm/1579568452-27253-1-git-send-email-chanho.min@lge.com
Reported-by: Chanho Min <chanho.min@lge.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-22 23:11:24 +00:00
|
|
|
struct device *parent;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the device is resumed asynchronously and the parent's callback
|
|
|
|
* deletes both the device and the parent itself, the parent object may
|
|
|
|
* be freed while this function is running, so avoid that by reference
|
|
|
|
* counting the parent once more unless the device has been deleted
|
|
|
|
* already (in which case return right away).
|
|
|
|
*/
|
|
|
|
mutex_lock(&dpm_list_mtx);
|
|
|
|
|
|
|
|
if (!device_pm_initialized(dev)) {
|
|
|
|
mutex_unlock(&dpm_list_mtx);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
parent = get_device(dev->parent);
|
|
|
|
|
|
|
|
mutex_unlock(&dpm_list_mtx);
|
|
|
|
|
|
|
|
dpm_wait(parent, async);
|
|
|
|
put_device(parent);
|
|
|
|
|
2016-10-30 16:28:49 +00:00
|
|
|
dpm_wait_for_suppliers(dev, async);
|
PM: core: Fix handling of devices deleted during system-wide resume
If a device is deleted by one of its system-wide resume callbacks
(for example, because it does not appear to be present or accessible
any more) along with its children, the resume of the children may
continue leading to use-after-free errors and other issues
(potentially).
Namely, if the device's children are resumed asynchronously, their
resume may have been scheduled already before the device's callback
runs and so the device may be deleted while dpm_wait_for_superior()
is being executed for them. The memory taken up by the parent device
object may be freed then while dpm_wait() is waiting for the parent's
resume callback to complete, which leads to a use-after-free.
Moreover, the resume of the children is really not expected to
continue after they have been unregistered, so it must be terminated
right away in that case.
To address this problem, modify dpm_wait_for_superior() to check
if the target device is still there in the system-wide PM list of
devices and if so, to increment its parent's reference counter, both
under dpm_list_mtx which prevents device_del() running for the child
from dropping the parent's reference counter prematurely.
If the device is not present in the system-wide PM list of devices
any more, the resume of it cannot continue, so check that again after
dpm_wait() returns, which means that the parent's callback has been
completed, and pass the result of that check to the caller of
dpm_wait_for_superior() to allow it to abort the device's resume
if it is not there any more.
Link: https://lore.kernel.org/linux-pm/1579568452-27253-1-git-send-email-chanho.min@lge.com
Reported-by: Chanho Min <chanho.min@lge.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-22 23:11:24 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If the parent's callback has deleted the device, attempting to resume
|
|
|
|
* it would be invalid, so avoid doing that then.
|
|
|
|
*/
|
|
|
|
return device_pm_initialized(dev);
|
2016-10-30 16:28:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void dpm_wait_for_consumers(struct device *dev, bool async)
|
|
|
|
{
|
|
|
|
struct device_link *link;
|
|
|
|
int idx;
|
|
|
|
|
|
|
|
idx = device_links_read_lock();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The status of a device link can only be changed from "dormant" by a
|
|
|
|
* probe, but that cannot happen during system suspend/resume. In
|
|
|
|
* theory it can change to "dormant" at that time, but then it is
|
|
|
|
* reasonable to wait for the target device anyway (eg. if it goes
|
|
|
|
* away, it's better to wait for it to go away completely and then
|
|
|
|
* continue instead of trying to continue in parallel with its
|
|
|
|
* unregistration).
|
|
|
|
*/
|
2020-03-03 19:41:30 +00:00
|
|
|
list_for_each_entry_rcu_locked(link, &dev->links.consumers, s_node)
|
2016-10-30 16:28:49 +00:00
|
|
|
if (READ_ONCE(link->status) != DL_STATE_DORMANT)
|
|
|
|
dpm_wait(link->consumer, async);
|
|
|
|
|
|
|
|
device_links_read_unlock(idx);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void dpm_wait_for_subordinate(struct device *dev, bool async)
|
|
|
|
{
|
|
|
|
dpm_wait_for_children(dev, async);
|
|
|
|
dpm_wait_for_consumers(dev, async);
|
|
|
|
}
|
|
|
|
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
/**
|
2011-12-17 23:34:01 +00:00
|
|
|
* pm_op - Return the PM operation appropriate for given PM event.
|
2009-08-20 18:25:52 +00:00
|
|
|
* @ops: PM operations to choose from.
|
|
|
|
* @state: PM transition of the system being carried out.
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
*/
|
2011-12-17 23:34:01 +00:00
|
|
|
static pm_callback_t pm_op(const struct dev_pm_ops *ops, pm_message_t state)
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
{
|
|
|
|
switch (state.event) {
|
|
|
|
#ifdef CONFIG_SUSPEND
|
|
|
|
case PM_EVENT_SUSPEND:
|
2011-12-17 23:34:01 +00:00
|
|
|
return ops->suspend;
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
case PM_EVENT_RESUME:
|
2011-12-17 23:34:01 +00:00
|
|
|
return ops->resume;
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
#endif /* CONFIG_SUSPEND */
|
2011-04-11 20:54:42 +00:00
|
|
|
#ifdef CONFIG_HIBERNATE_CALLBACKS
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
case PM_EVENT_FREEZE:
|
|
|
|
case PM_EVENT_QUIESCE:
|
2011-12-17 23:34:01 +00:00
|
|
|
return ops->freeze;
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
case PM_EVENT_HIBERNATE:
|
2011-12-17 23:34:01 +00:00
|
|
|
return ops->poweroff;
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
case PM_EVENT_THAW:
|
|
|
|
case PM_EVENT_RECOVER:
|
2011-12-17 23:34:01 +00:00
|
|
|
return ops->thaw;
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
case PM_EVENT_RESTORE:
|
2011-12-17 23:34:01 +00:00
|
|
|
return ops->restore;
|
2011-04-11 20:54:42 +00:00
|
|
|
#endif /* CONFIG_HIBERNATE_CALLBACKS */
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
}
|
2009-12-13 19:29:01 +00:00
|
|
|
|
2011-12-17 23:34:01 +00:00
|
|
|
return NULL;
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
}
|
|
|
|
|
2012-01-29 19:38:29 +00:00
|
|
|
/**
|
|
|
|
* pm_late_early_op - Return the PM operation appropriate for given PM event.
|
|
|
|
* @ops: PM operations to choose from.
|
|
|
|
* @state: PM transition of the system being carried out.
|
|
|
|
*
|
|
|
|
* Runtime PM is disabled for @dev while this function is being executed.
|
|
|
|
*/
|
|
|
|
static pm_callback_t pm_late_early_op(const struct dev_pm_ops *ops,
|
|
|
|
pm_message_t state)
|
|
|
|
{
|
|
|
|
switch (state.event) {
|
|
|
|
#ifdef CONFIG_SUSPEND
|
|
|
|
case PM_EVENT_SUSPEND:
|
|
|
|
return ops->suspend_late;
|
|
|
|
case PM_EVENT_RESUME:
|
|
|
|
return ops->resume_early;
|
|
|
|
#endif /* CONFIG_SUSPEND */
|
|
|
|
#ifdef CONFIG_HIBERNATE_CALLBACKS
|
|
|
|
case PM_EVENT_FREEZE:
|
|
|
|
case PM_EVENT_QUIESCE:
|
|
|
|
return ops->freeze_late;
|
|
|
|
case PM_EVENT_HIBERNATE:
|
|
|
|
return ops->poweroff_late;
|
|
|
|
case PM_EVENT_THAW:
|
|
|
|
case PM_EVENT_RECOVER:
|
|
|
|
return ops->thaw_early;
|
|
|
|
case PM_EVENT_RESTORE:
|
|
|
|
return ops->restore_early;
|
|
|
|
#endif /* CONFIG_HIBERNATE_CALLBACKS */
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
/**
|
2011-12-17 23:34:01 +00:00
|
|
|
* pm_noirq_op - Return the PM operation appropriate for given PM event.
|
2009-08-20 18:25:52 +00:00
|
|
|
* @ops: PM operations to choose from.
|
|
|
|
* @state: PM transition of the system being carried out.
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
*
|
2009-08-20 18:25:52 +00:00
|
|
|
* The driver of @dev will not receive interrupts while this function is being
|
|
|
|
* executed.
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
*/
|
2011-12-17 23:34:01 +00:00
|
|
|
static pm_callback_t pm_noirq_op(const struct dev_pm_ops *ops, pm_message_t state)
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
{
|
|
|
|
switch (state.event) {
|
|
|
|
#ifdef CONFIG_SUSPEND
|
|
|
|
case PM_EVENT_SUSPEND:
|
2011-12-17 23:34:01 +00:00
|
|
|
return ops->suspend_noirq;
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
case PM_EVENT_RESUME:
|
2011-12-17 23:34:01 +00:00
|
|
|
return ops->resume_noirq;
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
#endif /* CONFIG_SUSPEND */
|
2011-04-11 20:54:42 +00:00
|
|
|
#ifdef CONFIG_HIBERNATE_CALLBACKS
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
case PM_EVENT_FREEZE:
|
|
|
|
case PM_EVENT_QUIESCE:
|
2011-12-17 23:34:01 +00:00
|
|
|
return ops->freeze_noirq;
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
case PM_EVENT_HIBERNATE:
|
2011-12-17 23:34:01 +00:00
|
|
|
return ops->poweroff_noirq;
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
case PM_EVENT_THAW:
|
|
|
|
case PM_EVENT_RECOVER:
|
2011-12-17 23:34:01 +00:00
|
|
|
return ops->thaw_noirq;
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
case PM_EVENT_RESTORE:
|
2011-12-17 23:34:01 +00:00
|
|
|
return ops->restore_noirq;
|
2011-04-11 20:54:42 +00:00
|
|
|
#endif /* CONFIG_HIBERNATE_CALLBACKS */
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
}
|
2009-12-13 19:29:01 +00:00
|
|
|
|
2011-12-17 23:34:01 +00:00
|
|
|
return NULL;
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
}
|
|
|
|
|
2017-06-12 15:19:32 +00:00
|
|
|
static void pm_dev_dbg(struct device *dev, pm_message_t state, const char *info)
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
{
|
2020-10-23 11:02:54 +00:00
|
|
|
dev_dbg(dev, "%s%s%s driver flags: %x\n", info, pm_verb(state.event),
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
((state.event & PM_EVENT_SLEEP) && device_may_wakeup(dev)) ?
|
2020-10-23 11:02:54 +00:00
|
|
|
", may wakeup" : "", dev->power.driver_flags);
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
}
|
|
|
|
|
2017-06-12 15:19:32 +00:00
|
|
|
static void pm_dev_err(struct device *dev, pm_message_t state, const char *info,
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
int error)
|
|
|
|
{
|
2021-01-26 21:29:40 +00:00
|
|
|
dev_err(dev, "failed to %s%s: error %d\n", pm_verb(state.event), info,
|
|
|
|
error);
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
}
|
|
|
|
|
2017-07-21 00:10:22 +00:00
|
|
|
static void dpm_show_time(ktime_t starttime, pm_message_t state, int error,
|
2017-06-12 15:19:32 +00:00
|
|
|
const char *info)
|
2009-12-18 00:57:47 +00:00
|
|
|
{
|
|
|
|
ktime_t calltime;
|
2010-09-20 20:32:10 +00:00
|
|
|
u64 usecs64;
|
2009-12-18 00:57:47 +00:00
|
|
|
int usecs;
|
|
|
|
|
|
|
|
calltime = ktime_get();
|
|
|
|
usecs64 = ktime_to_ns(ktime_sub(calltime, starttime));
|
|
|
|
do_div(usecs64, NSEC_PER_USEC);
|
|
|
|
usecs = usecs64;
|
|
|
|
if (usecs == 0)
|
|
|
|
usecs = 1;
|
2017-07-19 00:38:44 +00:00
|
|
|
|
2017-07-21 00:10:22 +00:00
|
|
|
pm_pr_dbg("%s%s%s of devices %s after %ld.%03ld msecs\n",
|
2017-07-19 00:38:44 +00:00
|
|
|
info ?: "", info ? " " : "", pm_verb(state.event),
|
2017-07-21 00:10:22 +00:00
|
|
|
error ? "aborted" : "complete",
|
2017-07-19 00:38:44 +00:00
|
|
|
usecs / USEC_PER_MSEC, usecs % USEC_PER_MSEC);
|
2009-12-18 00:57:47 +00:00
|
|
|
}
|
|
|
|
|
2011-12-17 23:34:01 +00:00
|
|
|
static int dpm_run_callback(pm_callback_t cb, struct device *dev,
|
2017-06-12 15:19:32 +00:00
|
|
|
pm_message_t state, const char *info)
|
2011-12-17 23:34:01 +00:00
|
|
|
{
|
|
|
|
ktime_t calltime;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
if (!cb)
|
|
|
|
return 0;
|
|
|
|
|
2018-04-26 21:36:41 +00:00
|
|
|
calltime = initcall_debug_start(dev, cb);
|
2011-12-17 23:34:01 +00:00
|
|
|
|
|
|
|
pm_dev_dbg(dev, state, info);
|
2014-06-10 14:31:22 +00:00
|
|
|
trace_device_pm_callback_start(dev, info, state.event);
|
2011-12-17 23:34:01 +00:00
|
|
|
error = cb(dev);
|
2014-06-10 14:31:22 +00:00
|
|
|
trace_device_pm_callback_end(dev, error);
|
2022-03-07 19:07:39 +00:00
|
|
|
suspend_report_result(dev, cb, error);
|
2011-12-17 23:34:01 +00:00
|
|
|
|
2018-04-26 21:36:41 +00:00
|
|
|
initcall_debug_report(dev, calltime, cb, error);
|
2011-12-17 23:34:01 +00:00
|
|
|
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
2013-10-17 17:48:46 +00:00
|
|
|
#ifdef CONFIG_DPM_WATCHDOG
|
|
|
|
struct dpm_watchdog {
|
|
|
|
struct device *dev;
|
|
|
|
struct task_struct *tsk;
|
|
|
|
struct timer_list timer;
|
|
|
|
};
|
|
|
|
|
|
|
|
#define DECLARE_DPM_WATCHDOG_ON_STACK(wd) \
|
|
|
|
struct dpm_watchdog wd
|
|
|
|
|
|
|
|
/**
|
|
|
|
* dpm_watchdog_handler - Driver suspend / resume watchdog handler.
|
2019-03-16 03:37:51 +00:00
|
|
|
* @t: The timer that PM watchdog depends on.
|
2013-10-17 17:48:46 +00:00
|
|
|
*
|
|
|
|
* Called when a driver has timed out suspending or resuming.
|
|
|
|
* There's not much we can do here to recover so panic() to
|
|
|
|
* capture a crash-dump in pstore.
|
|
|
|
*/
|
2017-10-04 23:26:57 +00:00
|
|
|
static void dpm_watchdog_handler(struct timer_list *t)
|
2013-10-17 17:48:46 +00:00
|
|
|
{
|
2017-10-04 23:26:57 +00:00
|
|
|
struct dpm_watchdog *wd = from_timer(wd, t, timer);
|
2013-10-17 17:48:46 +00:00
|
|
|
|
|
|
|
dev_emerg(wd->dev, "**** DPM device timeout ****\n");
|
2020-06-09 04:32:29 +00:00
|
|
|
show_stack(wd->tsk, NULL, KERN_EMERG);
|
2013-10-17 17:48:46 +00:00
|
|
|
panic("%s %s: unrecoverable failure\n",
|
|
|
|
dev_driver_string(wd->dev), dev_name(wd->dev));
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* dpm_watchdog_set - Enable pm watchdog for given device.
|
|
|
|
* @wd: Watchdog. Must be allocated on the stack.
|
|
|
|
* @dev: Device to handle.
|
|
|
|
*/
|
|
|
|
static void dpm_watchdog_set(struct dpm_watchdog *wd, struct device *dev)
|
|
|
|
{
|
|
|
|
struct timer_list *timer = &wd->timer;
|
|
|
|
|
|
|
|
wd->dev = dev;
|
|
|
|
wd->tsk = current;
|
|
|
|
|
2017-10-04 23:26:57 +00:00
|
|
|
timer_setup_on_stack(timer, dpm_watchdog_handler, 0);
|
2013-10-17 17:48:46 +00:00
|
|
|
/* use same timeout value for both suspend and resume */
|
|
|
|
timer->expires = jiffies + HZ * CONFIG_DPM_WATCHDOG_TIMEOUT;
|
|
|
|
add_timer(timer);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* dpm_watchdog_clear - Disable suspend/resume watchdog.
|
|
|
|
* @wd: Watchdog to disable.
|
|
|
|
*/
|
|
|
|
static void dpm_watchdog_clear(struct dpm_watchdog *wd)
|
|
|
|
{
|
|
|
|
struct timer_list *timer = &wd->timer;
|
|
|
|
|
|
|
|
del_timer_sync(timer);
|
|
|
|
destroy_timer_on_stack(timer);
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
#define DECLARE_DPM_WATCHDOG_ON_STACK(wd)
|
|
|
|
#define dpm_watchdog_set(x, y)
|
|
|
|
#define dpm_watchdog_clear(x)
|
|
|
|
#endif
|
|
|
|
|
2007-09-21 19:36:56 +00:00
|
|
|
/*------------------------- Resume routines -------------------------*/
|
|
|
|
|
PM / core: Direct DPM_FLAG_SMART_SUSPEND optimization
Make the PM core avoid invoking the "late" and "noirq" system-wide
suspend (or analogous) callbacks provided by device drivers directly
for devices with DPM_FLAG_SMART_SUSPEND set that are in runtime
suspend during the "late" and "noirq" phases of system-wide suspend
(or analogous) transitions. That is only done for devices without
any middle-layer "late" and "noirq" suspend callbacks (to avoid
confusing the middle layer if there is one).
The underlying observation is that runtime PM is disabled for devices
during the "late" and "noirq" system-wide suspend phases, so if they
remain in runtime suspend from the "late" phase forward, it doesn't
make sense to invoke the "late" and "noirq" callbacks provided by
the drivers for them (arguably, the device is already suspended and
in the right state). Thus, if the remaining driver suspend callbacks
are to be invoked directly by the core, they can be skipped.
This change really makes it possible for, say, platform device
drivers to re-use runtime PM suspend and resume callbacks by
pointing ->suspend_late and ->resume_early, respectively (and
possibly the analogous hibernation-related callback pointers too),
to them without adding any extra "is the device already suspended?"
type of checks to the callback routines, as long as they will be
invoked directly by the core.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-10 00:00:45 +00:00
|
|
|
/**
|
2020-04-18 16:52:30 +00:00
|
|
|
* dev_pm_skip_resume - System-wide device resume optimization check.
|
2017-11-18 14:31:49 +00:00
|
|
|
* @dev: Target device.
|
|
|
|
*
|
PM: sleep: core: Do not skip callbacks in the resume phase
The current code in device_resume_noirq() causes the entire early
resume and resume phases of device suspend to be skipped for
devices for which the noirq resume phase have been skipped (due
to the LEAVE_SUSPENDED flag being set) on the premise that those
devices should stay in runtime-suspend after system-wide resume.
However, that may not be correct in two situations. First, the
middle layer (subsystem) noirq resume callback may be missing for
a given device, but its early resume callback may be present and it
may need to do something even if it decides to skip the driver
callback. Second, if the device's wakeup settings were adjusted
in the suspend phase without resuming the device (that was in
runtime suspend at that time), they most likely need to be
adjusted again in the resume phase and so the driver callback
in that phase needs to be run.
For the above reason, modify the core to allow the middle layer
->resume_late callback to run even if its ->resume_noirq callback
is missing (and the core has skipped the driver-level callback
in that phase) and to allow all device callbacks to run in the
resume phase. Also make the core set the PM-runtime status of
devices with SMART_SUSPEND set whose resume callbacks are not
skipped to "active" in the "noirq" resume phase and update the
affected subsystems (PCI and ACPI) accordingly.
After this change, middle-layer (subsystem) callbacks will always
be invoked in all phases of system suspend and resume and driver
callbacks will always run in the prepare, suspend, resume, and
complete phases for all devices.
For devices with SMART_SUSPEND set, driver callbacks will be
skipped in the late and noirq phases of system suspend if those
devices remain in runtime suspend in __device_suspend_late().
Driver callbacks will also be skipped for them during the
noirq and early phases of the "thaw" transition related to
hibernation in that case.
Setting LEAVE_SUSPENDED means that the driver allows its callbacks
to be skipped in the noirq and early phases of system resume, but
some additional conditions need to be met for that to happen (among
other things, the power.may_skip_resume flag needs to be set for the
device during system suspend for the driver callbacks to be skipped
during the subsequent resume transition).
For all devices with SMART_SUSPEND set whose driver callbacks are
invoked during system resume, the PM-runtime status will be set to
"active" (by the core).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2020-04-18 16:52:08 +00:00
|
|
|
* Return:
|
|
|
|
* - %false if the transition under way is RESTORE.
|
2020-04-18 16:52:48 +00:00
|
|
|
* - Return value of dev_pm_skip_suspend() if the transition under way is THAW.
|
PM: sleep: core: Do not skip callbacks in the resume phase
The current code in device_resume_noirq() causes the entire early
resume and resume phases of device suspend to be skipped for
devices for which the noirq resume phase have been skipped (due
to the LEAVE_SUSPENDED flag being set) on the premise that those
devices should stay in runtime-suspend after system-wide resume.
However, that may not be correct in two situations. First, the
middle layer (subsystem) noirq resume callback may be missing for
a given device, but its early resume callback may be present and it
may need to do something even if it decides to skip the driver
callback. Second, if the device's wakeup settings were adjusted
in the suspend phase without resuming the device (that was in
runtime suspend at that time), they most likely need to be
adjusted again in the resume phase and so the driver callback
in that phase needs to be run.
For the above reason, modify the core to allow the middle layer
->resume_late callback to run even if its ->resume_noirq callback
is missing (and the core has skipped the driver-level callback
in that phase) and to allow all device callbacks to run in the
resume phase. Also make the core set the PM-runtime status of
devices with SMART_SUSPEND set whose resume callbacks are not
skipped to "active" in the "noirq" resume phase and update the
affected subsystems (PCI and ACPI) accordingly.
After this change, middle-layer (subsystem) callbacks will always
be invoked in all phases of system suspend and resume and driver
callbacks will always run in the prepare, suspend, resume, and
complete phases for all devices.
For devices with SMART_SUSPEND set, driver callbacks will be
skipped in the late and noirq phases of system suspend if those
devices remain in runtime suspend in __device_suspend_late().
Driver callbacks will also be skipped for them during the
noirq and early phases of the "thaw" transition related to
hibernation in that case.
Setting LEAVE_SUSPENDED means that the driver allows its callbacks
to be skipped in the noirq and early phases of system resume, but
some additional conditions need to be met for that to happen (among
other things, the power.may_skip_resume flag needs to be set for the
device during system suspend for the driver callbacks to be skipped
during the subsequent resume transition).
For all devices with SMART_SUSPEND set whose driver callbacks are
invoked during system resume, the PM-runtime status will be set to
"active" (by the core).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2020-04-18 16:52:08 +00:00
|
|
|
* - The logical negation of %power.must_resume otherwise (that is, when the
|
|
|
|
* transition under way is RESUME).
|
2017-11-18 14:31:49 +00:00
|
|
|
*/
|
2020-04-18 16:52:30 +00:00
|
|
|
bool dev_pm_skip_resume(struct device *dev)
|
2017-11-18 14:31:49 +00:00
|
|
|
{
|
PM: sleep: core: Do not skip callbacks in the resume phase
The current code in device_resume_noirq() causes the entire early
resume and resume phases of device suspend to be skipped for
devices for which the noirq resume phase have been skipped (due
to the LEAVE_SUSPENDED flag being set) on the premise that those
devices should stay in runtime-suspend after system-wide resume.
However, that may not be correct in two situations. First, the
middle layer (subsystem) noirq resume callback may be missing for
a given device, but its early resume callback may be present and it
may need to do something even if it decides to skip the driver
callback. Second, if the device's wakeup settings were adjusted
in the suspend phase without resuming the device (that was in
runtime suspend at that time), they most likely need to be
adjusted again in the resume phase and so the driver callback
in that phase needs to be run.
For the above reason, modify the core to allow the middle layer
->resume_late callback to run even if its ->resume_noirq callback
is missing (and the core has skipped the driver-level callback
in that phase) and to allow all device callbacks to run in the
resume phase. Also make the core set the PM-runtime status of
devices with SMART_SUSPEND set whose resume callbacks are not
skipped to "active" in the "noirq" resume phase and update the
affected subsystems (PCI and ACPI) accordingly.
After this change, middle-layer (subsystem) callbacks will always
be invoked in all phases of system suspend and resume and driver
callbacks will always run in the prepare, suspend, resume, and
complete phases for all devices.
For devices with SMART_SUSPEND set, driver callbacks will be
skipped in the late and noirq phases of system suspend if those
devices remain in runtime suspend in __device_suspend_late().
Driver callbacks will also be skipped for them during the
noirq and early phases of the "thaw" transition related to
hibernation in that case.
Setting LEAVE_SUSPENDED means that the driver allows its callbacks
to be skipped in the noirq and early phases of system resume, but
some additional conditions need to be met for that to happen (among
other things, the power.may_skip_resume flag needs to be set for the
device during system suspend for the driver callbacks to be skipped
during the subsequent resume transition).
For all devices with SMART_SUSPEND set whose driver callbacks are
invoked during system resume, the PM-runtime status will be set to
"active" (by the core).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2020-04-18 16:52:08 +00:00
|
|
|
if (pm_transition.event == PM_EVENT_RESTORE)
|
|
|
|
return false;
|
2017-12-09 23:58:18 +00:00
|
|
|
|
PM: sleep: core: Do not skip callbacks in the resume phase
The current code in device_resume_noirq() causes the entire early
resume and resume phases of device suspend to be skipped for
devices for which the noirq resume phase have been skipped (due
to the LEAVE_SUSPENDED flag being set) on the premise that those
devices should stay in runtime-suspend after system-wide resume.
However, that may not be correct in two situations. First, the
middle layer (subsystem) noirq resume callback may be missing for
a given device, but its early resume callback may be present and it
may need to do something even if it decides to skip the driver
callback. Second, if the device's wakeup settings were adjusted
in the suspend phase without resuming the device (that was in
runtime suspend at that time), they most likely need to be
adjusted again in the resume phase and so the driver callback
in that phase needs to be run.
For the above reason, modify the core to allow the middle layer
->resume_late callback to run even if its ->resume_noirq callback
is missing (and the core has skipped the driver-level callback
in that phase) and to allow all device callbacks to run in the
resume phase. Also make the core set the PM-runtime status of
devices with SMART_SUSPEND set whose resume callbacks are not
skipped to "active" in the "noirq" resume phase and update the
affected subsystems (PCI and ACPI) accordingly.
After this change, middle-layer (subsystem) callbacks will always
be invoked in all phases of system suspend and resume and driver
callbacks will always run in the prepare, suspend, resume, and
complete phases for all devices.
For devices with SMART_SUSPEND set, driver callbacks will be
skipped in the late and noirq phases of system suspend if those
devices remain in runtime suspend in __device_suspend_late().
Driver callbacks will also be skipped for them during the
noirq and early phases of the "thaw" transition related to
hibernation in that case.
Setting LEAVE_SUSPENDED means that the driver allows its callbacks
to be skipped in the noirq and early phases of system resume, but
some additional conditions need to be met for that to happen (among
other things, the power.may_skip_resume flag needs to be set for the
device during system suspend for the driver callbacks to be skipped
during the subsequent resume transition).
For all devices with SMART_SUSPEND set whose driver callbacks are
invoked during system resume, the PM-runtime status will be set to
"active" (by the core).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2020-04-18 16:52:08 +00:00
|
|
|
if (pm_transition.event == PM_EVENT_THAW)
|
2020-04-18 16:52:48 +00:00
|
|
|
return dev_pm_skip_suspend(dev);
|
2017-12-09 23:58:18 +00:00
|
|
|
|
PM: sleep: core: Do not skip callbacks in the resume phase
The current code in device_resume_noirq() causes the entire early
resume and resume phases of device suspend to be skipped for
devices for which the noirq resume phase have been skipped (due
to the LEAVE_SUSPENDED flag being set) on the premise that those
devices should stay in runtime-suspend after system-wide resume.
However, that may not be correct in two situations. First, the
middle layer (subsystem) noirq resume callback may be missing for
a given device, but its early resume callback may be present and it
may need to do something even if it decides to skip the driver
callback. Second, if the device's wakeup settings were adjusted
in the suspend phase without resuming the device (that was in
runtime suspend at that time), they most likely need to be
adjusted again in the resume phase and so the driver callback
in that phase needs to be run.
For the above reason, modify the core to allow the middle layer
->resume_late callback to run even if its ->resume_noirq callback
is missing (and the core has skipped the driver-level callback
in that phase) and to allow all device callbacks to run in the
resume phase. Also make the core set the PM-runtime status of
devices with SMART_SUSPEND set whose resume callbacks are not
skipped to "active" in the "noirq" resume phase and update the
affected subsystems (PCI and ACPI) accordingly.
After this change, middle-layer (subsystem) callbacks will always
be invoked in all phases of system suspend and resume and driver
callbacks will always run in the prepare, suspend, resume, and
complete phases for all devices.
For devices with SMART_SUSPEND set, driver callbacks will be
skipped in the late and noirq phases of system suspend if those
devices remain in runtime suspend in __device_suspend_late().
Driver callbacks will also be skipped for them during the
noirq and early phases of the "thaw" transition related to
hibernation in that case.
Setting LEAVE_SUSPENDED means that the driver allows its callbacks
to be skipped in the noirq and early phases of system resume, but
some additional conditions need to be met for that to happen (among
other things, the power.may_skip_resume flag needs to be set for the
device during system suspend for the driver callbacks to be skipped
during the subsequent resume transition).
For all devices with SMART_SUSPEND set whose driver callbacks are
invoked during system resume, the PM-runtime status will be set to
"active" (by the core).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2020-04-18 16:52:08 +00:00
|
|
|
return !dev->power.must_resume;
|
2017-12-09 23:58:18 +00:00
|
|
|
}
|
|
|
|
|
2007-09-21 19:36:56 +00:00
|
|
|
/**
|
2017-10-13 13:25:39 +00:00
|
|
|
* device_resume_noirq - Execute a "noirq resume" callback for given device.
|
2009-08-20 18:25:52 +00:00
|
|
|
* @dev: Device to handle.
|
|
|
|
* @state: PM transition of the system being carried out.
|
2014-07-27 23:17:15 +00:00
|
|
|
* @async: If true, the device is being resumed asynchronously.
|
2007-09-21 19:36:56 +00:00
|
|
|
*
|
2009-08-20 18:25:52 +00:00
|
|
|
* The driver of @dev will not receive interrupts while this function is being
|
|
|
|
* executed.
|
2007-09-21 19:36:56 +00:00
|
|
|
*/
|
2014-02-18 02:28:45 +00:00
|
|
|
static int device_resume_noirq(struct device *dev, pm_message_t state, bool async)
|
2007-09-21 19:36:56 +00:00
|
|
|
{
|
2020-04-18 16:51:44 +00:00
|
|
|
pm_callback_t callback = NULL;
|
|
|
|
const char *info = NULL;
|
2017-12-10 00:02:13 +00:00
|
|
|
bool skip_resume;
|
2007-09-21 19:36:56 +00:00
|
|
|
int error = 0;
|
|
|
|
|
|
|
|
TRACE_DEVICE(dev);
|
|
|
|
TRACE_RESUME(0);
|
|
|
|
|
PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily
Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
resume all runtime-suspended devices during system suspend, mostly
because those devices may need to be reprogrammed due to different
wakeup settings for system sleep and for runtime PM.
For some devices, though, it's OK to remain in runtime suspend
throughout a complete system suspend/resume cycle (if the device was in
runtime suspend at the start of the cycle). We would like to do this
whenever possible, to avoid the overhead of extra power-up and power-down
events.
However, problems may arise because the device's descendants may require
it to be at full power at various points during the cycle. Therefore the
most straightforward way to do this safely is if the device and all its
descendants can remain runtime suspended until the complete stage of
system resume.
To this end, introduce a new device PM flag, power.direct_complete
and modify the PM core to use that flag as follows.
If the ->prepare() callback of a device returns a positive number,
the PM core will regard that as an indication that it may leave the
device runtime-suspended. It will then check if the system power
transition in progress is a suspend (and not hibernation in particular)
and if the device is, indeed, runtime-suspended. In that case, the PM
core will set the device's power.direct_complete flag. Otherwise it
will clear power.direct_complete for the device and it also will later
clear it for the device's parent (if there's one).
Next, the PM core will not invoke the ->suspend() ->suspend_late(),
->suspend_irq(), ->resume_irq(), ->resume_early(), or ->resume()
callbacks for all devices having power.direct_complete set. It
will invoke their ->complete() callbacks, however, and those
callbacks are then responsible for resuming the devices as
appropriate, if necessary. For example, in some cases they may
need to queue up runtime resume requests for the devices using
pm_request_resume().
Changelog partly based on an Alan Stern's description of the idea
(http://marc.info/?l=linux-pm&m=139940466625569&w=2).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
2014-05-16 00:46:50 +00:00
|
|
|
if (dev->power.syscore || dev->power.direct_complete)
|
2012-08-05 23:46:39 +00:00
|
|
|
goto Out;
|
|
|
|
|
2014-02-18 02:28:44 +00:00
|
|
|
if (!dev->power.is_noirq_suspended)
|
|
|
|
goto Out;
|
|
|
|
|
PM: core: Fix handling of devices deleted during system-wide resume
If a device is deleted by one of its system-wide resume callbacks
(for example, because it does not appear to be present or accessible
any more) along with its children, the resume of the children may
continue leading to use-after-free errors and other issues
(potentially).
Namely, if the device's children are resumed asynchronously, their
resume may have been scheduled already before the device's callback
runs and so the device may be deleted while dpm_wait_for_superior()
is being executed for them. The memory taken up by the parent device
object may be freed then while dpm_wait() is waiting for the parent's
resume callback to complete, which leads to a use-after-free.
Moreover, the resume of the children is really not expected to
continue after they have been unregistered, so it must be terminated
right away in that case.
To address this problem, modify dpm_wait_for_superior() to check
if the target device is still there in the system-wide PM list of
devices and if so, to increment its parent's reference counter, both
under dpm_list_mtx which prevents device_del() running for the child
from dropping the parent's reference counter prematurely.
If the device is not present in the system-wide PM list of devices
any more, the resume of it cannot continue, so check that again after
dpm_wait() returns, which means that the parent's callback has been
completed, and pass the result of that check to the caller of
dpm_wait_for_superior() to allow it to abort the device's resume
if it is not there any more.
Link: https://lore.kernel.org/linux-pm/1579568452-27253-1-git-send-email-chanho.min@lge.com
Reported-by: Chanho Min <chanho.min@lge.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-22 23:11:24 +00:00
|
|
|
if (!dpm_wait_for_superior(dev, async))
|
|
|
|
goto Out;
|
2014-02-18 02:28:45 +00:00
|
|
|
|
2020-04-18 16:52:30 +00:00
|
|
|
skip_resume = dev_pm_skip_resume(dev);
|
PM: sleep: core: Do not skip callbacks in the resume phase
The current code in device_resume_noirq() causes the entire early
resume and resume phases of device suspend to be skipped for
devices for which the noirq resume phase have been skipped (due
to the LEAVE_SUSPENDED flag being set) on the premise that those
devices should stay in runtime-suspend after system-wide resume.
However, that may not be correct in two situations. First, the
middle layer (subsystem) noirq resume callback may be missing for
a given device, but its early resume callback may be present and it
may need to do something even if it decides to skip the driver
callback. Second, if the device's wakeup settings were adjusted
in the suspend phase without resuming the device (that was in
runtime suspend at that time), they most likely need to be
adjusted again in the resume phase and so the driver callback
in that phase needs to be run.
For the above reason, modify the core to allow the middle layer
->resume_late callback to run even if its ->resume_noirq callback
is missing (and the core has skipped the driver-level callback
in that phase) and to allow all device callbacks to run in the
resume phase. Also make the core set the PM-runtime status of
devices with SMART_SUSPEND set whose resume callbacks are not
skipped to "active" in the "noirq" resume phase and update the
affected subsystems (PCI and ACPI) accordingly.
After this change, middle-layer (subsystem) callbacks will always
be invoked in all phases of system suspend and resume and driver
callbacks will always run in the prepare, suspend, resume, and
complete phases for all devices.
For devices with SMART_SUSPEND set, driver callbacks will be
skipped in the late and noirq phases of system suspend if those
devices remain in runtime suspend in __device_suspend_late().
Driver callbacks will also be skipped for them during the
noirq and early phases of the "thaw" transition related to
hibernation in that case.
Setting LEAVE_SUSPENDED means that the driver allows its callbacks
to be skipped in the noirq and early phases of system resume, but
some additional conditions need to be met for that to happen (among
other things, the power.may_skip_resume flag needs to be set for the
device during system suspend for the driver callbacks to be skipped
during the subsequent resume transition).
For all devices with SMART_SUSPEND set whose driver callbacks are
invoked during system resume, the PM-runtime status will be set to
"active" (by the core).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2020-04-18 16:52:08 +00:00
|
|
|
/*
|
|
|
|
* If the driver callback is skipped below or by the middle layer
|
|
|
|
* callback and device_resume_early() also skips the driver callback for
|
|
|
|
* this device later, it needs to appear as "suspended" to PM-runtime,
|
|
|
|
* so change its status accordingly.
|
|
|
|
*
|
|
|
|
* Otherwise, the device is going to be resumed, so set its PM-runtime
|
|
|
|
* status to "active", but do that only if DPM_FLAG_SMART_SUSPEND is set
|
|
|
|
* to avoid confusing drivers that don't use it.
|
|
|
|
*/
|
|
|
|
if (skip_resume)
|
|
|
|
pm_runtime_set_suspended(dev);
|
2020-04-18 16:52:48 +00:00
|
|
|
else if (dev_pm_skip_suspend(dev))
|
PM: sleep: core: Do not skip callbacks in the resume phase
The current code in device_resume_noirq() causes the entire early
resume and resume phases of device suspend to be skipped for
devices for which the noirq resume phase have been skipped (due
to the LEAVE_SUSPENDED flag being set) on the premise that those
devices should stay in runtime-suspend after system-wide resume.
However, that may not be correct in two situations. First, the
middle layer (subsystem) noirq resume callback may be missing for
a given device, but its early resume callback may be present and it
may need to do something even if it decides to skip the driver
callback. Second, if the device's wakeup settings were adjusted
in the suspend phase without resuming the device (that was in
runtime suspend at that time), they most likely need to be
adjusted again in the resume phase and so the driver callback
in that phase needs to be run.
For the above reason, modify the core to allow the middle layer
->resume_late callback to run even if its ->resume_noirq callback
is missing (and the core has skipped the driver-level callback
in that phase) and to allow all device callbacks to run in the
resume phase. Also make the core set the PM-runtime status of
devices with SMART_SUSPEND set whose resume callbacks are not
skipped to "active" in the "noirq" resume phase and update the
affected subsystems (PCI and ACPI) accordingly.
After this change, middle-layer (subsystem) callbacks will always
be invoked in all phases of system suspend and resume and driver
callbacks will always run in the prepare, suspend, resume, and
complete phases for all devices.
For devices with SMART_SUSPEND set, driver callbacks will be
skipped in the late and noirq phases of system suspend if those
devices remain in runtime suspend in __device_suspend_late().
Driver callbacks will also be skipped for them during the
noirq and early phases of the "thaw" transition related to
hibernation in that case.
Setting LEAVE_SUSPENDED means that the driver allows its callbacks
to be skipped in the noirq and early phases of system resume, but
some additional conditions need to be met for that to happen (among
other things, the power.may_skip_resume flag needs to be set for the
device during system suspend for the driver callbacks to be skipped
during the subsequent resume transition).
For all devices with SMART_SUSPEND set whose driver callbacks are
invoked during system resume, the PM-runtime status will be set to
"active" (by the core).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2020-04-18 16:52:08 +00:00
|
|
|
pm_runtime_set_active(dev);
|
2017-12-10 00:02:13 +00:00
|
|
|
|
2020-04-18 16:51:44 +00:00
|
|
|
if (dev->pm_domain) {
|
|
|
|
info = "noirq power domain ";
|
|
|
|
callback = pm_noirq_op(&dev->pm_domain->ops, state);
|
|
|
|
} else if (dev->type && dev->type->pm) {
|
|
|
|
info = "noirq type ";
|
|
|
|
callback = pm_noirq_op(dev->type->pm, state);
|
|
|
|
} else if (dev->class && dev->class->pm) {
|
|
|
|
info = "noirq class ";
|
|
|
|
callback = pm_noirq_op(dev->class->pm, state);
|
|
|
|
} else if (dev->bus && dev->bus->pm) {
|
|
|
|
info = "noirq bus ";
|
|
|
|
callback = pm_noirq_op(dev->bus->pm, state);
|
|
|
|
}
|
PM / core: Direct DPM_FLAG_SMART_SUSPEND optimization
Make the PM core avoid invoking the "late" and "noirq" system-wide
suspend (or analogous) callbacks provided by device drivers directly
for devices with DPM_FLAG_SMART_SUSPEND set that are in runtime
suspend during the "late" and "noirq" phases of system-wide suspend
(or analogous) transitions. That is only done for devices without
any middle-layer "late" and "noirq" suspend callbacks (to avoid
confusing the middle layer if there is one).
The underlying observation is that runtime PM is disabled for devices
during the "late" and "noirq" system-wide suspend phases, so if they
remain in runtime suspend from the "late" phase forward, it doesn't
make sense to invoke the "late" and "noirq" callbacks provided by
the drivers for them (arguably, the device is already suspended and
in the right state). Thus, if the remaining driver suspend callbacks
are to be invoked directly by the core, they can be skipped.
This change really makes it possible for, say, platform device
drivers to re-use runtime PM suspend and resume callbacks by
pointing ->suspend_late and ->resume_early, respectively (and
possibly the analogous hibernation-related callback pointers too),
to them without adding any extra "is the device already suspended?"
type of checks to the callback routines, as long as they will be
invoked directly by the core.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-10 00:00:45 +00:00
|
|
|
if (callback)
|
|
|
|
goto Run;
|
2010-03-15 20:43:11 +00:00
|
|
|
|
2017-12-10 00:02:13 +00:00
|
|
|
if (skip_resume)
|
|
|
|
goto Skip;
|
|
|
|
|
PM / core: Direct DPM_FLAG_SMART_SUSPEND optimization
Make the PM core avoid invoking the "late" and "noirq" system-wide
suspend (or analogous) callbacks provided by device drivers directly
for devices with DPM_FLAG_SMART_SUSPEND set that are in runtime
suspend during the "late" and "noirq" phases of system-wide suspend
(or analogous) transitions. That is only done for devices without
any middle-layer "late" and "noirq" suspend callbacks (to avoid
confusing the middle layer if there is one).
The underlying observation is that runtime PM is disabled for devices
during the "late" and "noirq" system-wide suspend phases, so if they
remain in runtime suspend from the "late" phase forward, it doesn't
make sense to invoke the "late" and "noirq" callbacks provided by
the drivers for them (arguably, the device is already suspended and
in the right state). Thus, if the remaining driver suspend callbacks
are to be invoked directly by the core, they can be skipped.
This change really makes it possible for, say, platform device
drivers to re-use runtime PM suspend and resume callbacks by
pointing ->suspend_late and ->resume_early, respectively (and
possibly the analogous hibernation-related callback pointers too),
to them without adding any extra "is the device already suspended?"
type of checks to the callback routines, as long as they will be
invoked directly by the core.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-10 00:00:45 +00:00
|
|
|
if (dev->driver && dev->driver->pm) {
|
2012-01-29 19:38:29 +00:00
|
|
|
info = "noirq driver ";
|
2011-12-17 23:34:13 +00:00
|
|
|
callback = pm_noirq_op(dev->driver->pm, state);
|
|
|
|
}
|
|
|
|
|
PM / core: Direct DPM_FLAG_SMART_SUSPEND optimization
Make the PM core avoid invoking the "late" and "noirq" system-wide
suspend (or analogous) callbacks provided by device drivers directly
for devices with DPM_FLAG_SMART_SUSPEND set that are in runtime
suspend during the "late" and "noirq" phases of system-wide suspend
(or analogous) transitions. That is only done for devices without
any middle-layer "late" and "noirq" suspend callbacks (to avoid
confusing the middle layer if there is one).
The underlying observation is that runtime PM is disabled for devices
during the "late" and "noirq" system-wide suspend phases, so if they
remain in runtime suspend from the "late" phase forward, it doesn't
make sense to invoke the "late" and "noirq" callbacks provided by
the drivers for them (arguably, the device is already suspended and
in the right state). Thus, if the remaining driver suspend callbacks
are to be invoked directly by the core, they can be skipped.
This change really makes it possible for, say, platform device
drivers to re-use runtime PM suspend and resume callbacks by
pointing ->suspend_late and ->resume_early, respectively (and
possibly the analogous hibernation-related callback pointers too),
to them without adding any extra "is the device already suspended?"
type of checks to the callback routines, as long as they will be
invoked directly by the core.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-10 00:00:45 +00:00
|
|
|
Run:
|
2011-12-17 23:34:01 +00:00
|
|
|
error = dpm_run_callback(callback, dev, state, info);
|
PM / core: Direct DPM_FLAG_SMART_SUSPEND optimization
Make the PM core avoid invoking the "late" and "noirq" system-wide
suspend (or analogous) callbacks provided by device drivers directly
for devices with DPM_FLAG_SMART_SUSPEND set that are in runtime
suspend during the "late" and "noirq" phases of system-wide suspend
(or analogous) transitions. That is only done for devices without
any middle-layer "late" and "noirq" suspend callbacks (to avoid
confusing the middle layer if there is one).
The underlying observation is that runtime PM is disabled for devices
during the "late" and "noirq" system-wide suspend phases, so if they
remain in runtime suspend from the "late" phase forward, it doesn't
make sense to invoke the "late" and "noirq" callbacks provided by
the drivers for them (arguably, the device is already suspended and
in the right state). Thus, if the remaining driver suspend callbacks
are to be invoked directly by the core, they can be skipped.
This change really makes it possible for, say, platform device
drivers to re-use runtime PM suspend and resume callbacks by
pointing ->suspend_late and ->resume_early, respectively (and
possibly the analogous hibernation-related callback pointers too),
to them without adding any extra "is the device already suspended?"
type of checks to the callback routines, as long as they will be
invoked directly by the core.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-10 00:00:45 +00:00
|
|
|
|
|
|
|
Skip:
|
2014-02-18 02:28:44 +00:00
|
|
|
dev->power.is_noirq_suspended = false;
|
2011-12-17 23:34:01 +00:00
|
|
|
|
PM / core: Direct DPM_FLAG_SMART_SUSPEND optimization
Make the PM core avoid invoking the "late" and "noirq" system-wide
suspend (or analogous) callbacks provided by device drivers directly
for devices with DPM_FLAG_SMART_SUSPEND set that are in runtime
suspend during the "late" and "noirq" phases of system-wide suspend
(or analogous) transitions. That is only done for devices without
any middle-layer "late" and "noirq" suspend callbacks (to avoid
confusing the middle layer if there is one).
The underlying observation is that runtime PM is disabled for devices
during the "late" and "noirq" system-wide suspend phases, so if they
remain in runtime suspend from the "late" phase forward, it doesn't
make sense to invoke the "late" and "noirq" callbacks provided by
the drivers for them (arguably, the device is already suspended and
in the right state). Thus, if the remaining driver suspend callbacks
are to be invoked directly by the core, they can be skipped.
This change really makes it possible for, say, platform device
drivers to re-use runtime PM suspend and resume callbacks by
pointing ->suspend_late and ->resume_early, respectively (and
possibly the analogous hibernation-related callback pointers too),
to them without adding any extra "is the device already suspended?"
type of checks to the callback routines, as long as they will be
invoked directly by the core.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-10 00:00:45 +00:00
|
|
|
Out:
|
2014-02-18 02:28:45 +00:00
|
|
|
complete_all(&dev->power.completion);
|
2008-01-12 19:40:46 +00:00
|
|
|
TRACE_RESUME(error);
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
2014-02-18 02:28:45 +00:00
|
|
|
static bool is_async(struct device *dev)
|
|
|
|
{
|
|
|
|
return dev->power.async_suspend && pm_async_enabled
|
|
|
|
&& !pm_trace_is_enabled();
|
|
|
|
}
|
|
|
|
|
2019-03-16 04:59:25 +00:00
|
|
|
static bool dpm_async_fn(struct device *dev, async_func_t func)
|
|
|
|
{
|
|
|
|
reinit_completion(&dev->power.completion);
|
|
|
|
|
|
|
|
if (is_async(dev)) {
|
|
|
|
get_device(dev);
|
2020-04-21 08:21:55 +00:00
|
|
|
async_schedule_dev(func, dev);
|
2019-03-16 04:59:25 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-02-18 02:28:45 +00:00
|
|
|
static void async_resume_noirq(void *data, async_cookie_t cookie)
|
|
|
|
{
|
|
|
|
struct device *dev = (struct device *)data;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
error = device_resume_noirq(dev, pm_transition, true);
|
|
|
|
if (error)
|
|
|
|
pm_dev_err(dev, pm_transition, " async", error);
|
|
|
|
|
|
|
|
put_device(dev);
|
|
|
|
}
|
|
|
|
|
2019-07-15 21:52:18 +00:00
|
|
|
static void dpm_noirq_resume_devices(pm_message_t state)
|
2008-01-12 19:40:46 +00:00
|
|
|
{
|
2014-02-18 02:28:45 +00:00
|
|
|
struct device *dev;
|
2009-12-18 00:57:47 +00:00
|
|
|
ktime_t starttime = ktime_get();
|
2008-01-12 19:40:46 +00:00
|
|
|
|
2014-06-06 12:40:17 +00:00
|
|
|
trace_suspend_resume(TPS("dpm_resume_noirq"), state.event, true);
|
2009-05-24 19:15:07 +00:00
|
|
|
mutex_lock(&dpm_list_mtx);
|
2014-02-18 02:28:45 +00:00
|
|
|
pm_transition = state;
|
2010-11-11 00:50:53 +00:00
|
|
|
|
2014-02-18 02:28:45 +00:00
|
|
|
/*
|
|
|
|
* Advanced the async threads upfront,
|
|
|
|
* in case the starting of async threads is
|
|
|
|
* delayed by non-async resuming devices.
|
|
|
|
*/
|
2019-03-16 04:59:25 +00:00
|
|
|
list_for_each_entry(dev, &dpm_noirq_list, power.entry)
|
|
|
|
dpm_async_fn(dev, async_resume_noirq);
|
2014-02-18 02:28:45 +00:00
|
|
|
|
|
|
|
while (!list_empty(&dpm_noirq_list)) {
|
|
|
|
dev = to_device(dpm_noirq_list.next);
|
2010-11-11 00:50:53 +00:00
|
|
|
get_device(dev);
|
2012-01-29 19:38:29 +00:00
|
|
|
list_move_tail(&dev->power.entry, &dpm_late_early_list);
|
PM: sleep: Avoid calling put_device() under dpm_list_mtx
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
[ 3290.969514] ======================================================
[ 3290.969517] WARNING: possible circular locking dependency detected
[ 3290.969519] 5.15.0+ #2420 Tainted: G S
[ 3290.969523] ------------------------------------------------------
[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
[ 3290.969554]
but task is already holding lock:
[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.969571]
which lock already depends on the new lock.
[ 3290.969573]
the existing dependency chain (in reverse order) is:
[ 3290.969575]
-> #3 (dpm_list_mtx){+.+.}-{3:3}:
[ 3290.969583] __mutex_lock+0x9d/0xa30
[ 3290.969591] device_pm_add+0x2e/0xe0
[ 3290.969597] device_add+0x4d5/0x8f0
[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969842] process_one_work+0x2aa/0x650
[ 3290.969851] worker_thread+0x39/0x400
[ 3290.969859] kthread+0x142/0x170
[ 3290.969865] ret_from_fork+0x22/0x30
[ 3290.969872]
-> #2 (&hdev->lock){+.+.}-{3:3}:
[ 3290.969881] __mutex_lock+0x9d/0xa30
[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969978] process_one_work+0x2aa/0x650
[ 3290.969985] worker_thread+0x39/0x400
[ 3290.969993] kthread+0x142/0x170
[ 3290.969999] ret_from_fork+0x22/0x30
[ 3290.970004]
-> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
[ 3290.970013] process_one_work+0x27d/0x650
[ 3290.970020] worker_thread+0x39/0x400
[ 3290.970028] kthread+0x142/0x170
[ 3290.970033] ret_from_fork+0x22/0x30
[ 3290.970038]
-> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
[ 3290.970047] __lock_acquire+0x15cb/0x1b50
[ 3290.970054] lock_acquire+0x26c/0x300
[ 3290.970059] flush_workqueue+0xae/0x4a0
[ 3290.970066] drain_workqueue+0xa1/0x130
[ 3290.970073] destroy_workqueue+0x34/0x1f0
[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970195] device_release+0x33/0x90
[ 3290.970201] kobject_release+0x63/0x160
[ 3290.970211] dpm_resume+0x164/0x3e0
[ 3290.970215] dpm_resume_end+0xd/0x20
[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970229] pm_suspend+0x26b/0x310
[ 3290.970236] state_store+0x42/0x90
[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970251] new_sync_write+0x125/0x1c0
[ 3290.970257] vfs_write+0x360/0x3c0
[ 3290.970263] ksys_write+0xa7/0xe0
[ 3290.970269] do_syscall_64+0x3a/0x80
[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970284]
other info that might help us debug this:
[ 3290.970285] Chain exists of:
(wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
[ 3290.970297] Possible unsafe locking scenario:
[ 3290.970299] CPU0 CPU1
[ 3290.970300] ---- ----
[ 3290.970302] lock(dpm_list_mtx);
[ 3290.970306] lock(&hdev->lock);
[ 3290.970310] lock(dpm_list_mtx);
[ 3290.970314] lock((wq_completion)hci0#2);
[ 3290.970319]
*** DEADLOCK ***
[ 3290.970321] 7 locks held by systemd-sleep/4553:
[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.970428]
stack backtrace:
[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
[ 3290.970441] Call Trace:
[ 3290.970446] dump_stack_lvl+0x44/0x57
[ 3290.970454] check_noncircular+0x105/0x120
[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
[ 3290.970474] __lock_acquire+0x15cb/0x1b50
[ 3290.970487] lock_acquire+0x26c/0x300
[ 3290.970493] ? flush_workqueue+0x87/0x4a0
[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
[ 3290.970519] flush_workqueue+0xae/0x4a0
[ 3290.970526] ? flush_workqueue+0x87/0x4a0
[ 3290.970544] ? drain_workqueue+0xa1/0x130
[ 3290.970552] drain_workqueue+0xa1/0x130
[ 3290.970561] destroy_workqueue+0x34/0x1f0
[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970687] device_release+0x33/0x90
[ 3290.970695] kobject_release+0x63/0x160
[ 3290.970705] dpm_resume+0x164/0x3e0
[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
[ 3290.970718] dpm_resume_end+0xd/0x20
[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970737] pm_suspend+0x26b/0x310
[ 3290.970746] state_store+0x42/0x90
[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970764] new_sync_write+0x125/0x1c0
[ 3290.970777] vfs_write+0x360/0x3c0
[ 3290.970785] ksys_write+0xa7/0xe0
[ 3290.970794] do_syscall_64+0x3a/0x80
[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970811] RIP: 0033:0x7f41b1328164
[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-11-04 17:26:26 +00:00
|
|
|
|
2010-12-15 23:51:08 +00:00
|
|
|
mutex_unlock(&dpm_list_mtx);
|
2010-11-11 00:50:53 +00:00
|
|
|
|
2014-02-18 02:28:45 +00:00
|
|
|
if (!is_async(dev)) {
|
|
|
|
int error;
|
|
|
|
|
|
|
|
error = device_resume_noirq(dev, state, false);
|
|
|
|
if (error) {
|
|
|
|
suspend_stats.failed_resume_noirq++;
|
|
|
|
dpm_save_failed_step(SUSPEND_RESUME_NOIRQ);
|
|
|
|
dpm_save_failed_dev(dev_name(dev));
|
|
|
|
pm_dev_err(dev, state, " noirq", error);
|
|
|
|
}
|
2012-01-29 19:38:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
put_device(dev);
|
PM: sleep: Avoid calling put_device() under dpm_list_mtx
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
[ 3290.969514] ======================================================
[ 3290.969517] WARNING: possible circular locking dependency detected
[ 3290.969519] 5.15.0+ #2420 Tainted: G S
[ 3290.969523] ------------------------------------------------------
[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
[ 3290.969554]
but task is already holding lock:
[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.969571]
which lock already depends on the new lock.
[ 3290.969573]
the existing dependency chain (in reverse order) is:
[ 3290.969575]
-> #3 (dpm_list_mtx){+.+.}-{3:3}:
[ 3290.969583] __mutex_lock+0x9d/0xa30
[ 3290.969591] device_pm_add+0x2e/0xe0
[ 3290.969597] device_add+0x4d5/0x8f0
[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969842] process_one_work+0x2aa/0x650
[ 3290.969851] worker_thread+0x39/0x400
[ 3290.969859] kthread+0x142/0x170
[ 3290.969865] ret_from_fork+0x22/0x30
[ 3290.969872]
-> #2 (&hdev->lock){+.+.}-{3:3}:
[ 3290.969881] __mutex_lock+0x9d/0xa30
[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969978] process_one_work+0x2aa/0x650
[ 3290.969985] worker_thread+0x39/0x400
[ 3290.969993] kthread+0x142/0x170
[ 3290.969999] ret_from_fork+0x22/0x30
[ 3290.970004]
-> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
[ 3290.970013] process_one_work+0x27d/0x650
[ 3290.970020] worker_thread+0x39/0x400
[ 3290.970028] kthread+0x142/0x170
[ 3290.970033] ret_from_fork+0x22/0x30
[ 3290.970038]
-> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
[ 3290.970047] __lock_acquire+0x15cb/0x1b50
[ 3290.970054] lock_acquire+0x26c/0x300
[ 3290.970059] flush_workqueue+0xae/0x4a0
[ 3290.970066] drain_workqueue+0xa1/0x130
[ 3290.970073] destroy_workqueue+0x34/0x1f0
[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970195] device_release+0x33/0x90
[ 3290.970201] kobject_release+0x63/0x160
[ 3290.970211] dpm_resume+0x164/0x3e0
[ 3290.970215] dpm_resume_end+0xd/0x20
[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970229] pm_suspend+0x26b/0x310
[ 3290.970236] state_store+0x42/0x90
[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970251] new_sync_write+0x125/0x1c0
[ 3290.970257] vfs_write+0x360/0x3c0
[ 3290.970263] ksys_write+0xa7/0xe0
[ 3290.970269] do_syscall_64+0x3a/0x80
[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970284]
other info that might help us debug this:
[ 3290.970285] Chain exists of:
(wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
[ 3290.970297] Possible unsafe locking scenario:
[ 3290.970299] CPU0 CPU1
[ 3290.970300] ---- ----
[ 3290.970302] lock(dpm_list_mtx);
[ 3290.970306] lock(&hdev->lock);
[ 3290.970310] lock(dpm_list_mtx);
[ 3290.970314] lock((wq_completion)hci0#2);
[ 3290.970319]
*** DEADLOCK ***
[ 3290.970321] 7 locks held by systemd-sleep/4553:
[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.970428]
stack backtrace:
[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
[ 3290.970441] Call Trace:
[ 3290.970446] dump_stack_lvl+0x44/0x57
[ 3290.970454] check_noncircular+0x105/0x120
[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
[ 3290.970474] __lock_acquire+0x15cb/0x1b50
[ 3290.970487] lock_acquire+0x26c/0x300
[ 3290.970493] ? flush_workqueue+0x87/0x4a0
[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
[ 3290.970519] flush_workqueue+0xae/0x4a0
[ 3290.970526] ? flush_workqueue+0x87/0x4a0
[ 3290.970544] ? drain_workqueue+0xa1/0x130
[ 3290.970552] drain_workqueue+0xa1/0x130
[ 3290.970561] destroy_workqueue+0x34/0x1f0
[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970687] device_release+0x33/0x90
[ 3290.970695] kobject_release+0x63/0x160
[ 3290.970705] dpm_resume+0x164/0x3e0
[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
[ 3290.970718] dpm_resume_end+0xd/0x20
[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970737] pm_suspend+0x26b/0x310
[ 3290.970746] state_store+0x42/0x90
[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970764] new_sync_write+0x125/0x1c0
[ 3290.970777] vfs_write+0x360/0x3c0
[ 3290.970785] ksys_write+0xa7/0xe0
[ 3290.970794] do_syscall_64+0x3a/0x80
[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970811] RIP: 0033:0x7f41b1328164
[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-11-04 17:26:26 +00:00
|
|
|
|
|
|
|
mutex_lock(&dpm_list_mtx);
|
2012-01-29 19:38:29 +00:00
|
|
|
}
|
|
|
|
mutex_unlock(&dpm_list_mtx);
|
2014-02-18 02:28:45 +00:00
|
|
|
async_synchronize_full();
|
2017-07-21 00:10:22 +00:00
|
|
|
dpm_show_time(starttime, state, 0, "noirq");
|
2017-07-21 00:09:22 +00:00
|
|
|
trace_suspend_resume(TPS("dpm_resume_noirq"), state.event, false);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* dpm_resume_noirq - Execute "noirq resume" callbacks for all devices.
|
|
|
|
* @state: PM transition of the system being carried out.
|
|
|
|
*
|
|
|
|
* Invoke the "noirq" resume callbacks for all devices in dpm_noirq_list and
|
|
|
|
* allow device drivers' interrupt handlers to be called.
|
|
|
|
*/
|
|
|
|
void dpm_resume_noirq(pm_message_t state)
|
|
|
|
{
|
|
|
|
dpm_noirq_resume_devices(state);
|
2019-07-15 21:52:18 +00:00
|
|
|
|
|
|
|
resume_device_irqs();
|
|
|
|
device_wakeup_disarm_wake_irqs();
|
2012-01-29 19:38:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* device_resume_early - Execute an "early resume" callback for given device.
|
|
|
|
* @dev: Device to handle.
|
|
|
|
* @state: PM transition of the system being carried out.
|
2014-07-27 23:17:15 +00:00
|
|
|
* @async: If true, the device is being resumed asynchronously.
|
2012-01-29 19:38:29 +00:00
|
|
|
*
|
|
|
|
* Runtime PM is disabled for @dev while this function is being executed.
|
|
|
|
*/
|
2014-02-18 02:28:46 +00:00
|
|
|
static int device_resume_early(struct device *dev, pm_message_t state, bool async)
|
2012-01-29 19:38:29 +00:00
|
|
|
{
|
2020-04-18 16:51:44 +00:00
|
|
|
pm_callback_t callback = NULL;
|
|
|
|
const char *info = NULL;
|
2012-01-29 19:38:29 +00:00
|
|
|
int error = 0;
|
|
|
|
|
|
|
|
TRACE_DEVICE(dev);
|
|
|
|
TRACE_RESUME(0);
|
|
|
|
|
PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily
Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
resume all runtime-suspended devices during system suspend, mostly
because those devices may need to be reprogrammed due to different
wakeup settings for system sleep and for runtime PM.
For some devices, though, it's OK to remain in runtime suspend
throughout a complete system suspend/resume cycle (if the device was in
runtime suspend at the start of the cycle). We would like to do this
whenever possible, to avoid the overhead of extra power-up and power-down
events.
However, problems may arise because the device's descendants may require
it to be at full power at various points during the cycle. Therefore the
most straightforward way to do this safely is if the device and all its
descendants can remain runtime suspended until the complete stage of
system resume.
To this end, introduce a new device PM flag, power.direct_complete
and modify the PM core to use that flag as follows.
If the ->prepare() callback of a device returns a positive number,
the PM core will regard that as an indication that it may leave the
device runtime-suspended. It will then check if the system power
transition in progress is a suspend (and not hibernation in particular)
and if the device is, indeed, runtime-suspended. In that case, the PM
core will set the device's power.direct_complete flag. Otherwise it
will clear power.direct_complete for the device and it also will later
clear it for the device's parent (if there's one).
Next, the PM core will not invoke the ->suspend() ->suspend_late(),
->suspend_irq(), ->resume_irq(), ->resume_early(), or ->resume()
callbacks for all devices having power.direct_complete set. It
will invoke their ->complete() callbacks, however, and those
callbacks are then responsible for resuming the devices as
appropriate, if necessary. For example, in some cases they may
need to queue up runtime resume requests for the devices using
pm_request_resume().
Changelog partly based on an Alan Stern's description of the idea
(http://marc.info/?l=linux-pm&m=139940466625569&w=2).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
2014-05-16 00:46:50 +00:00
|
|
|
if (dev->power.syscore || dev->power.direct_complete)
|
2012-08-05 23:46:39 +00:00
|
|
|
goto Out;
|
|
|
|
|
2014-02-18 02:28:44 +00:00
|
|
|
if (!dev->power.is_late_suspended)
|
|
|
|
goto Out;
|
|
|
|
|
PM: core: Fix handling of devices deleted during system-wide resume
If a device is deleted by one of its system-wide resume callbacks
(for example, because it does not appear to be present or accessible
any more) along with its children, the resume of the children may
continue leading to use-after-free errors and other issues
(potentially).
Namely, if the device's children are resumed asynchronously, their
resume may have been scheduled already before the device's callback
runs and so the device may be deleted while dpm_wait_for_superior()
is being executed for them. The memory taken up by the parent device
object may be freed then while dpm_wait() is waiting for the parent's
resume callback to complete, which leads to a use-after-free.
Moreover, the resume of the children is really not expected to
continue after they have been unregistered, so it must be terminated
right away in that case.
To address this problem, modify dpm_wait_for_superior() to check
if the target device is still there in the system-wide PM list of
devices and if so, to increment its parent's reference counter, both
under dpm_list_mtx which prevents device_del() running for the child
from dropping the parent's reference counter prematurely.
If the device is not present in the system-wide PM list of devices
any more, the resume of it cannot continue, so check that again after
dpm_wait() returns, which means that the parent's callback has been
completed, and pass the result of that check to the caller of
dpm_wait_for_superior() to allow it to abort the device's resume
if it is not there any more.
Link: https://lore.kernel.org/linux-pm/1579568452-27253-1-git-send-email-chanho.min@lge.com
Reported-by: Chanho Min <chanho.min@lge.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-22 23:11:24 +00:00
|
|
|
if (!dpm_wait_for_superior(dev, async))
|
|
|
|
goto Out;
|
2014-02-18 02:28:46 +00:00
|
|
|
|
2020-04-18 16:51:44 +00:00
|
|
|
if (dev->pm_domain) {
|
|
|
|
info = "early power domain ";
|
|
|
|
callback = pm_late_early_op(&dev->pm_domain->ops, state);
|
|
|
|
} else if (dev->type && dev->type->pm) {
|
|
|
|
info = "early type ";
|
|
|
|
callback = pm_late_early_op(dev->type->pm, state);
|
|
|
|
} else if (dev->class && dev->class->pm) {
|
|
|
|
info = "early class ";
|
|
|
|
callback = pm_late_early_op(dev->class->pm, state);
|
|
|
|
} else if (dev->bus && dev->bus->pm) {
|
|
|
|
info = "early bus ";
|
|
|
|
callback = pm_late_early_op(dev->bus->pm, state);
|
PM: sleep: core: Do not skip callbacks in the resume phase
The current code in device_resume_noirq() causes the entire early
resume and resume phases of device suspend to be skipped for
devices for which the noirq resume phase have been skipped (due
to the LEAVE_SUSPENDED flag being set) on the premise that those
devices should stay in runtime-suspend after system-wide resume.
However, that may not be correct in two situations. First, the
middle layer (subsystem) noirq resume callback may be missing for
a given device, but its early resume callback may be present and it
may need to do something even if it decides to skip the driver
callback. Second, if the device's wakeup settings were adjusted
in the suspend phase without resuming the device (that was in
runtime suspend at that time), they most likely need to be
adjusted again in the resume phase and so the driver callback
in that phase needs to be run.
For the above reason, modify the core to allow the middle layer
->resume_late callback to run even if its ->resume_noirq callback
is missing (and the core has skipped the driver-level callback
in that phase) and to allow all device callbacks to run in the
resume phase. Also make the core set the PM-runtime status of
devices with SMART_SUSPEND set whose resume callbacks are not
skipped to "active" in the "noirq" resume phase and update the
affected subsystems (PCI and ACPI) accordingly.
After this change, middle-layer (subsystem) callbacks will always
be invoked in all phases of system suspend and resume and driver
callbacks will always run in the prepare, suspend, resume, and
complete phases for all devices.
For devices with SMART_SUSPEND set, driver callbacks will be
skipped in the late and noirq phases of system suspend if those
devices remain in runtime suspend in __device_suspend_late().
Driver callbacks will also be skipped for them during the
noirq and early phases of the "thaw" transition related to
hibernation in that case.
Setting LEAVE_SUSPENDED means that the driver allows its callbacks
to be skipped in the noirq and early phases of system resume, but
some additional conditions need to be met for that to happen (among
other things, the power.may_skip_resume flag needs to be set for the
device during system suspend for the driver callbacks to be skipped
during the subsequent resume transition).
For all devices with SMART_SUSPEND set whose driver callbacks are
invoked during system resume, the PM-runtime status will be set to
"active" (by the core).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2020-04-18 16:52:08 +00:00
|
|
|
}
|
|
|
|
if (callback)
|
|
|
|
goto Run;
|
|
|
|
|
2020-04-18 16:52:30 +00:00
|
|
|
if (dev_pm_skip_resume(dev))
|
PM: sleep: core: Do not skip callbacks in the resume phase
The current code in device_resume_noirq() causes the entire early
resume and resume phases of device suspend to be skipped for
devices for which the noirq resume phase have been skipped (due
to the LEAVE_SUSPENDED flag being set) on the premise that those
devices should stay in runtime-suspend after system-wide resume.
However, that may not be correct in two situations. First, the
middle layer (subsystem) noirq resume callback may be missing for
a given device, but its early resume callback may be present and it
may need to do something even if it decides to skip the driver
callback. Second, if the device's wakeup settings were adjusted
in the suspend phase without resuming the device (that was in
runtime suspend at that time), they most likely need to be
adjusted again in the resume phase and so the driver callback
in that phase needs to be run.
For the above reason, modify the core to allow the middle layer
->resume_late callback to run even if its ->resume_noirq callback
is missing (and the core has skipped the driver-level callback
in that phase) and to allow all device callbacks to run in the
resume phase. Also make the core set the PM-runtime status of
devices with SMART_SUSPEND set whose resume callbacks are not
skipped to "active" in the "noirq" resume phase and update the
affected subsystems (PCI and ACPI) accordingly.
After this change, middle-layer (subsystem) callbacks will always
be invoked in all phases of system suspend and resume and driver
callbacks will always run in the prepare, suspend, resume, and
complete phases for all devices.
For devices with SMART_SUSPEND set, driver callbacks will be
skipped in the late and noirq phases of system suspend if those
devices remain in runtime suspend in __device_suspend_late().
Driver callbacks will also be skipped for them during the
noirq and early phases of the "thaw" transition related to
hibernation in that case.
Setting LEAVE_SUSPENDED means that the driver allows its callbacks
to be skipped in the noirq and early phases of system resume, but
some additional conditions need to be met for that to happen (among
other things, the power.may_skip_resume flag needs to be set for the
device during system suspend for the driver callbacks to be skipped
during the subsequent resume transition).
For all devices with SMART_SUSPEND set whose driver callbacks are
invoked during system resume, the PM-runtime status will be set to
"active" (by the core).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2020-04-18 16:52:08 +00:00
|
|
|
goto Skip;
|
2012-01-29 19:38:29 +00:00
|
|
|
|
PM: sleep: core: Do not skip callbacks in the resume phase
The current code in device_resume_noirq() causes the entire early
resume and resume phases of device suspend to be skipped for
devices for which the noirq resume phase have been skipped (due
to the LEAVE_SUSPENDED flag being set) on the premise that those
devices should stay in runtime-suspend after system-wide resume.
However, that may not be correct in two situations. First, the
middle layer (subsystem) noirq resume callback may be missing for
a given device, but its early resume callback may be present and it
may need to do something even if it decides to skip the driver
callback. Second, if the device's wakeup settings were adjusted
in the suspend phase without resuming the device (that was in
runtime suspend at that time), they most likely need to be
adjusted again in the resume phase and so the driver callback
in that phase needs to be run.
For the above reason, modify the core to allow the middle layer
->resume_late callback to run even if its ->resume_noirq callback
is missing (and the core has skipped the driver-level callback
in that phase) and to allow all device callbacks to run in the
resume phase. Also make the core set the PM-runtime status of
devices with SMART_SUSPEND set whose resume callbacks are not
skipped to "active" in the "noirq" resume phase and update the
affected subsystems (PCI and ACPI) accordingly.
After this change, middle-layer (subsystem) callbacks will always
be invoked in all phases of system suspend and resume and driver
callbacks will always run in the prepare, suspend, resume, and
complete phases for all devices.
For devices with SMART_SUSPEND set, driver callbacks will be
skipped in the late and noirq phases of system suspend if those
devices remain in runtime suspend in __device_suspend_late().
Driver callbacks will also be skipped for them during the
noirq and early phases of the "thaw" transition related to
hibernation in that case.
Setting LEAVE_SUSPENDED means that the driver allows its callbacks
to be skipped in the noirq and early phases of system resume, but
some additional conditions need to be met for that to happen (among
other things, the power.may_skip_resume flag needs to be set for the
device during system suspend for the driver callbacks to be skipped
during the subsequent resume transition).
For all devices with SMART_SUSPEND set whose driver callbacks are
invoked during system resume, the PM-runtime status will be set to
"active" (by the core).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2020-04-18 16:52:08 +00:00
|
|
|
if (dev->driver && dev->driver->pm) {
|
2012-01-29 19:38:29 +00:00
|
|
|
info = "early driver ";
|
|
|
|
callback = pm_late_early_op(dev->driver->pm, state);
|
|
|
|
}
|
|
|
|
|
PM: sleep: core: Do not skip callbacks in the resume phase
The current code in device_resume_noirq() causes the entire early
resume and resume phases of device suspend to be skipped for
devices for which the noirq resume phase have been skipped (due
to the LEAVE_SUSPENDED flag being set) on the premise that those
devices should stay in runtime-suspend after system-wide resume.
However, that may not be correct in two situations. First, the
middle layer (subsystem) noirq resume callback may be missing for
a given device, but its early resume callback may be present and it
may need to do something even if it decides to skip the driver
callback. Second, if the device's wakeup settings were adjusted
in the suspend phase without resuming the device (that was in
runtime suspend at that time), they most likely need to be
adjusted again in the resume phase and so the driver callback
in that phase needs to be run.
For the above reason, modify the core to allow the middle layer
->resume_late callback to run even if its ->resume_noirq callback
is missing (and the core has skipped the driver-level callback
in that phase) and to allow all device callbacks to run in the
resume phase. Also make the core set the PM-runtime status of
devices with SMART_SUSPEND set whose resume callbacks are not
skipped to "active" in the "noirq" resume phase and update the
affected subsystems (PCI and ACPI) accordingly.
After this change, middle-layer (subsystem) callbacks will always
be invoked in all phases of system suspend and resume and driver
callbacks will always run in the prepare, suspend, resume, and
complete phases for all devices.
For devices with SMART_SUSPEND set, driver callbacks will be
skipped in the late and noirq phases of system suspend if those
devices remain in runtime suspend in __device_suspend_late().
Driver callbacks will also be skipped for them during the
noirq and early phases of the "thaw" transition related to
hibernation in that case.
Setting LEAVE_SUSPENDED means that the driver allows its callbacks
to be skipped in the noirq and early phases of system resume, but
some additional conditions need to be met for that to happen (among
other things, the power.may_skip_resume flag needs to be set for the
device during system suspend for the driver callbacks to be skipped
during the subsequent resume transition).
For all devices with SMART_SUSPEND set whose driver callbacks are
invoked during system resume, the PM-runtime status will be set to
"active" (by the core).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2020-04-18 16:52:08 +00:00
|
|
|
Run:
|
2012-01-29 19:38:29 +00:00
|
|
|
error = dpm_run_callback(callback, dev, state, info);
|
PM: sleep: core: Do not skip callbacks in the resume phase
The current code in device_resume_noirq() causes the entire early
resume and resume phases of device suspend to be skipped for
devices for which the noirq resume phase have been skipped (due
to the LEAVE_SUSPENDED flag being set) on the premise that those
devices should stay in runtime-suspend after system-wide resume.
However, that may not be correct in two situations. First, the
middle layer (subsystem) noirq resume callback may be missing for
a given device, but its early resume callback may be present and it
may need to do something even if it decides to skip the driver
callback. Second, if the device's wakeup settings were adjusted
in the suspend phase without resuming the device (that was in
runtime suspend at that time), they most likely need to be
adjusted again in the resume phase and so the driver callback
in that phase needs to be run.
For the above reason, modify the core to allow the middle layer
->resume_late callback to run even if its ->resume_noirq callback
is missing (and the core has skipped the driver-level callback
in that phase) and to allow all device callbacks to run in the
resume phase. Also make the core set the PM-runtime status of
devices with SMART_SUSPEND set whose resume callbacks are not
skipped to "active" in the "noirq" resume phase and update the
affected subsystems (PCI and ACPI) accordingly.
After this change, middle-layer (subsystem) callbacks will always
be invoked in all phases of system suspend and resume and driver
callbacks will always run in the prepare, suspend, resume, and
complete phases for all devices.
For devices with SMART_SUSPEND set, driver callbacks will be
skipped in the late and noirq phases of system suspend if those
devices remain in runtime suspend in __device_suspend_late().
Driver callbacks will also be skipped for them during the
noirq and early phases of the "thaw" transition related to
hibernation in that case.
Setting LEAVE_SUSPENDED means that the driver allows its callbacks
to be skipped in the noirq and early phases of system resume, but
some additional conditions need to be met for that to happen (among
other things, the power.may_skip_resume flag needs to be set for the
device during system suspend for the driver callbacks to be skipped
during the subsequent resume transition).
For all devices with SMART_SUSPEND set whose driver callbacks are
invoked during system resume, the PM-runtime status will be set to
"active" (by the core).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2020-04-18 16:52:08 +00:00
|
|
|
|
|
|
|
Skip:
|
2014-02-18 02:28:44 +00:00
|
|
|
dev->power.is_late_suspended = false;
|
2012-01-29 19:38:29 +00:00
|
|
|
|
PM: sleep: core: Do not skip callbacks in the resume phase
The current code in device_resume_noirq() causes the entire early
resume and resume phases of device suspend to be skipped for
devices for which the noirq resume phase have been skipped (due
to the LEAVE_SUSPENDED flag being set) on the premise that those
devices should stay in runtime-suspend after system-wide resume.
However, that may not be correct in two situations. First, the
middle layer (subsystem) noirq resume callback may be missing for
a given device, but its early resume callback may be present and it
may need to do something even if it decides to skip the driver
callback. Second, if the device's wakeup settings were adjusted
in the suspend phase without resuming the device (that was in
runtime suspend at that time), they most likely need to be
adjusted again in the resume phase and so the driver callback
in that phase needs to be run.
For the above reason, modify the core to allow the middle layer
->resume_late callback to run even if its ->resume_noirq callback
is missing (and the core has skipped the driver-level callback
in that phase) and to allow all device callbacks to run in the
resume phase. Also make the core set the PM-runtime status of
devices with SMART_SUSPEND set whose resume callbacks are not
skipped to "active" in the "noirq" resume phase and update the
affected subsystems (PCI and ACPI) accordingly.
After this change, middle-layer (subsystem) callbacks will always
be invoked in all phases of system suspend and resume and driver
callbacks will always run in the prepare, suspend, resume, and
complete phases for all devices.
For devices with SMART_SUSPEND set, driver callbacks will be
skipped in the late and noirq phases of system suspend if those
devices remain in runtime suspend in __device_suspend_late().
Driver callbacks will also be skipped for them during the
noirq and early phases of the "thaw" transition related to
hibernation in that case.
Setting LEAVE_SUSPENDED means that the driver allows its callbacks
to be skipped in the noirq and early phases of system resume, but
some additional conditions need to be met for that to happen (among
other things, the power.may_skip_resume flag needs to be set for the
device during system suspend for the driver callbacks to be skipped
during the subsequent resume transition).
For all devices with SMART_SUSPEND set whose driver callbacks are
invoked during system resume, the PM-runtime status will be set to
"active" (by the core).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2020-04-18 16:52:08 +00:00
|
|
|
Out:
|
2012-01-29 19:38:29 +00:00
|
|
|
TRACE_RESUME(error);
|
2012-12-22 22:59:01 +00:00
|
|
|
|
|
|
|
pm_runtime_enable(dev);
|
2014-02-18 02:28:46 +00:00
|
|
|
complete_all(&dev->power.completion);
|
2012-01-29 19:38:29 +00:00
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
2014-02-18 02:28:46 +00:00
|
|
|
static void async_resume_early(void *data, async_cookie_t cookie)
|
|
|
|
{
|
|
|
|
struct device *dev = (struct device *)data;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
error = device_resume_early(dev, pm_transition, true);
|
|
|
|
if (error)
|
|
|
|
pm_dev_err(dev, pm_transition, " async", error);
|
|
|
|
|
|
|
|
put_device(dev);
|
|
|
|
}
|
|
|
|
|
2012-01-29 19:38:29 +00:00
|
|
|
/**
|
|
|
|
* dpm_resume_early - Execute "early resume" callbacks for all devices.
|
|
|
|
* @state: PM transition of the system being carried out.
|
|
|
|
*/
|
2014-09-30 00:21:34 +00:00
|
|
|
void dpm_resume_early(pm_message_t state)
|
2012-01-29 19:38:29 +00:00
|
|
|
{
|
2014-02-18 02:28:46 +00:00
|
|
|
struct device *dev;
|
2012-01-29 19:38:29 +00:00
|
|
|
ktime_t starttime = ktime_get();
|
|
|
|
|
2014-06-06 12:40:17 +00:00
|
|
|
trace_suspend_resume(TPS("dpm_resume_early"), state.event, true);
|
2012-01-29 19:38:29 +00:00
|
|
|
mutex_lock(&dpm_list_mtx);
|
2014-02-18 02:28:46 +00:00
|
|
|
pm_transition = state;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Advanced the async threads upfront,
|
|
|
|
* in case the starting of async threads is
|
|
|
|
* delayed by non-async resuming devices.
|
|
|
|
*/
|
2019-03-16 04:59:25 +00:00
|
|
|
list_for_each_entry(dev, &dpm_late_early_list, power.entry)
|
|
|
|
dpm_async_fn(dev, async_resume_early);
|
2012-01-29 19:38:29 +00:00
|
|
|
|
2014-02-18 02:28:46 +00:00
|
|
|
while (!list_empty(&dpm_late_early_list)) {
|
|
|
|
dev = to_device(dpm_late_early_list.next);
|
2012-01-29 19:38:29 +00:00
|
|
|
get_device(dev);
|
|
|
|
list_move_tail(&dev->power.entry, &dpm_suspended_list);
|
PM: sleep: Avoid calling put_device() under dpm_list_mtx
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
[ 3290.969514] ======================================================
[ 3290.969517] WARNING: possible circular locking dependency detected
[ 3290.969519] 5.15.0+ #2420 Tainted: G S
[ 3290.969523] ------------------------------------------------------
[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
[ 3290.969554]
but task is already holding lock:
[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.969571]
which lock already depends on the new lock.
[ 3290.969573]
the existing dependency chain (in reverse order) is:
[ 3290.969575]
-> #3 (dpm_list_mtx){+.+.}-{3:3}:
[ 3290.969583] __mutex_lock+0x9d/0xa30
[ 3290.969591] device_pm_add+0x2e/0xe0
[ 3290.969597] device_add+0x4d5/0x8f0
[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969842] process_one_work+0x2aa/0x650
[ 3290.969851] worker_thread+0x39/0x400
[ 3290.969859] kthread+0x142/0x170
[ 3290.969865] ret_from_fork+0x22/0x30
[ 3290.969872]
-> #2 (&hdev->lock){+.+.}-{3:3}:
[ 3290.969881] __mutex_lock+0x9d/0xa30
[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969978] process_one_work+0x2aa/0x650
[ 3290.969985] worker_thread+0x39/0x400
[ 3290.969993] kthread+0x142/0x170
[ 3290.969999] ret_from_fork+0x22/0x30
[ 3290.970004]
-> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
[ 3290.970013] process_one_work+0x27d/0x650
[ 3290.970020] worker_thread+0x39/0x400
[ 3290.970028] kthread+0x142/0x170
[ 3290.970033] ret_from_fork+0x22/0x30
[ 3290.970038]
-> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
[ 3290.970047] __lock_acquire+0x15cb/0x1b50
[ 3290.970054] lock_acquire+0x26c/0x300
[ 3290.970059] flush_workqueue+0xae/0x4a0
[ 3290.970066] drain_workqueue+0xa1/0x130
[ 3290.970073] destroy_workqueue+0x34/0x1f0
[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970195] device_release+0x33/0x90
[ 3290.970201] kobject_release+0x63/0x160
[ 3290.970211] dpm_resume+0x164/0x3e0
[ 3290.970215] dpm_resume_end+0xd/0x20
[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970229] pm_suspend+0x26b/0x310
[ 3290.970236] state_store+0x42/0x90
[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970251] new_sync_write+0x125/0x1c0
[ 3290.970257] vfs_write+0x360/0x3c0
[ 3290.970263] ksys_write+0xa7/0xe0
[ 3290.970269] do_syscall_64+0x3a/0x80
[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970284]
other info that might help us debug this:
[ 3290.970285] Chain exists of:
(wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
[ 3290.970297] Possible unsafe locking scenario:
[ 3290.970299] CPU0 CPU1
[ 3290.970300] ---- ----
[ 3290.970302] lock(dpm_list_mtx);
[ 3290.970306] lock(&hdev->lock);
[ 3290.970310] lock(dpm_list_mtx);
[ 3290.970314] lock((wq_completion)hci0#2);
[ 3290.970319]
*** DEADLOCK ***
[ 3290.970321] 7 locks held by systemd-sleep/4553:
[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.970428]
stack backtrace:
[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
[ 3290.970441] Call Trace:
[ 3290.970446] dump_stack_lvl+0x44/0x57
[ 3290.970454] check_noncircular+0x105/0x120
[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
[ 3290.970474] __lock_acquire+0x15cb/0x1b50
[ 3290.970487] lock_acquire+0x26c/0x300
[ 3290.970493] ? flush_workqueue+0x87/0x4a0
[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
[ 3290.970519] flush_workqueue+0xae/0x4a0
[ 3290.970526] ? flush_workqueue+0x87/0x4a0
[ 3290.970544] ? drain_workqueue+0xa1/0x130
[ 3290.970552] drain_workqueue+0xa1/0x130
[ 3290.970561] destroy_workqueue+0x34/0x1f0
[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970687] device_release+0x33/0x90
[ 3290.970695] kobject_release+0x63/0x160
[ 3290.970705] dpm_resume+0x164/0x3e0
[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
[ 3290.970718] dpm_resume_end+0xd/0x20
[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970737] pm_suspend+0x26b/0x310
[ 3290.970746] state_store+0x42/0x90
[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970764] new_sync_write+0x125/0x1c0
[ 3290.970777] vfs_write+0x360/0x3c0
[ 3290.970785] ksys_write+0xa7/0xe0
[ 3290.970794] do_syscall_64+0x3a/0x80
[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970811] RIP: 0033:0x7f41b1328164
[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-11-04 17:26:26 +00:00
|
|
|
|
2012-01-29 19:38:29 +00:00
|
|
|
mutex_unlock(&dpm_list_mtx);
|
|
|
|
|
2014-02-18 02:28:46 +00:00
|
|
|
if (!is_async(dev)) {
|
|
|
|
int error;
|
2010-11-11 00:50:53 +00:00
|
|
|
|
2014-02-18 02:28:46 +00:00
|
|
|
error = device_resume_early(dev, state, false);
|
|
|
|
if (error) {
|
|
|
|
suspend_stats.failed_resume_early++;
|
|
|
|
dpm_save_failed_step(SUSPEND_RESUME_EARLY);
|
|
|
|
dpm_save_failed_dev(dev_name(dev));
|
|
|
|
pm_dev_err(dev, state, " early", error);
|
|
|
|
}
|
|
|
|
}
|
PM: sleep: Avoid calling put_device() under dpm_list_mtx
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
[ 3290.969514] ======================================================
[ 3290.969517] WARNING: possible circular locking dependency detected
[ 3290.969519] 5.15.0+ #2420 Tainted: G S
[ 3290.969523] ------------------------------------------------------
[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
[ 3290.969554]
but task is already holding lock:
[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.969571]
which lock already depends on the new lock.
[ 3290.969573]
the existing dependency chain (in reverse order) is:
[ 3290.969575]
-> #3 (dpm_list_mtx){+.+.}-{3:3}:
[ 3290.969583] __mutex_lock+0x9d/0xa30
[ 3290.969591] device_pm_add+0x2e/0xe0
[ 3290.969597] device_add+0x4d5/0x8f0
[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969842] process_one_work+0x2aa/0x650
[ 3290.969851] worker_thread+0x39/0x400
[ 3290.969859] kthread+0x142/0x170
[ 3290.969865] ret_from_fork+0x22/0x30
[ 3290.969872]
-> #2 (&hdev->lock){+.+.}-{3:3}:
[ 3290.969881] __mutex_lock+0x9d/0xa30
[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969978] process_one_work+0x2aa/0x650
[ 3290.969985] worker_thread+0x39/0x400
[ 3290.969993] kthread+0x142/0x170
[ 3290.969999] ret_from_fork+0x22/0x30
[ 3290.970004]
-> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
[ 3290.970013] process_one_work+0x27d/0x650
[ 3290.970020] worker_thread+0x39/0x400
[ 3290.970028] kthread+0x142/0x170
[ 3290.970033] ret_from_fork+0x22/0x30
[ 3290.970038]
-> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
[ 3290.970047] __lock_acquire+0x15cb/0x1b50
[ 3290.970054] lock_acquire+0x26c/0x300
[ 3290.970059] flush_workqueue+0xae/0x4a0
[ 3290.970066] drain_workqueue+0xa1/0x130
[ 3290.970073] destroy_workqueue+0x34/0x1f0
[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970195] device_release+0x33/0x90
[ 3290.970201] kobject_release+0x63/0x160
[ 3290.970211] dpm_resume+0x164/0x3e0
[ 3290.970215] dpm_resume_end+0xd/0x20
[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970229] pm_suspend+0x26b/0x310
[ 3290.970236] state_store+0x42/0x90
[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970251] new_sync_write+0x125/0x1c0
[ 3290.970257] vfs_write+0x360/0x3c0
[ 3290.970263] ksys_write+0xa7/0xe0
[ 3290.970269] do_syscall_64+0x3a/0x80
[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970284]
other info that might help us debug this:
[ 3290.970285] Chain exists of:
(wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
[ 3290.970297] Possible unsafe locking scenario:
[ 3290.970299] CPU0 CPU1
[ 3290.970300] ---- ----
[ 3290.970302] lock(dpm_list_mtx);
[ 3290.970306] lock(&hdev->lock);
[ 3290.970310] lock(dpm_list_mtx);
[ 3290.970314] lock((wq_completion)hci0#2);
[ 3290.970319]
*** DEADLOCK ***
[ 3290.970321] 7 locks held by systemd-sleep/4553:
[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.970428]
stack backtrace:
[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
[ 3290.970441] Call Trace:
[ 3290.970446] dump_stack_lvl+0x44/0x57
[ 3290.970454] check_noncircular+0x105/0x120
[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
[ 3290.970474] __lock_acquire+0x15cb/0x1b50
[ 3290.970487] lock_acquire+0x26c/0x300
[ 3290.970493] ? flush_workqueue+0x87/0x4a0
[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
[ 3290.970519] flush_workqueue+0xae/0x4a0
[ 3290.970526] ? flush_workqueue+0x87/0x4a0
[ 3290.970544] ? drain_workqueue+0xa1/0x130
[ 3290.970552] drain_workqueue+0xa1/0x130
[ 3290.970561] destroy_workqueue+0x34/0x1f0
[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970687] device_release+0x33/0x90
[ 3290.970695] kobject_release+0x63/0x160
[ 3290.970705] dpm_resume+0x164/0x3e0
[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
[ 3290.970718] dpm_resume_end+0xd/0x20
[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970737] pm_suspend+0x26b/0x310
[ 3290.970746] state_store+0x42/0x90
[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970764] new_sync_write+0x125/0x1c0
[ 3290.970777] vfs_write+0x360/0x3c0
[ 3290.970785] ksys_write+0xa7/0xe0
[ 3290.970794] do_syscall_64+0x3a/0x80
[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970811] RIP: 0033:0x7f41b1328164
[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-11-04 17:26:26 +00:00
|
|
|
|
2010-11-11 00:50:53 +00:00
|
|
|
put_device(dev);
|
PM: sleep: Avoid calling put_device() under dpm_list_mtx
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
[ 3290.969514] ======================================================
[ 3290.969517] WARNING: possible circular locking dependency detected
[ 3290.969519] 5.15.0+ #2420 Tainted: G S
[ 3290.969523] ------------------------------------------------------
[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
[ 3290.969554]
but task is already holding lock:
[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.969571]
which lock already depends on the new lock.
[ 3290.969573]
the existing dependency chain (in reverse order) is:
[ 3290.969575]
-> #3 (dpm_list_mtx){+.+.}-{3:3}:
[ 3290.969583] __mutex_lock+0x9d/0xa30
[ 3290.969591] device_pm_add+0x2e/0xe0
[ 3290.969597] device_add+0x4d5/0x8f0
[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969842] process_one_work+0x2aa/0x650
[ 3290.969851] worker_thread+0x39/0x400
[ 3290.969859] kthread+0x142/0x170
[ 3290.969865] ret_from_fork+0x22/0x30
[ 3290.969872]
-> #2 (&hdev->lock){+.+.}-{3:3}:
[ 3290.969881] __mutex_lock+0x9d/0xa30
[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969978] process_one_work+0x2aa/0x650
[ 3290.969985] worker_thread+0x39/0x400
[ 3290.969993] kthread+0x142/0x170
[ 3290.969999] ret_from_fork+0x22/0x30
[ 3290.970004]
-> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
[ 3290.970013] process_one_work+0x27d/0x650
[ 3290.970020] worker_thread+0x39/0x400
[ 3290.970028] kthread+0x142/0x170
[ 3290.970033] ret_from_fork+0x22/0x30
[ 3290.970038]
-> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
[ 3290.970047] __lock_acquire+0x15cb/0x1b50
[ 3290.970054] lock_acquire+0x26c/0x300
[ 3290.970059] flush_workqueue+0xae/0x4a0
[ 3290.970066] drain_workqueue+0xa1/0x130
[ 3290.970073] destroy_workqueue+0x34/0x1f0
[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970195] device_release+0x33/0x90
[ 3290.970201] kobject_release+0x63/0x160
[ 3290.970211] dpm_resume+0x164/0x3e0
[ 3290.970215] dpm_resume_end+0xd/0x20
[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970229] pm_suspend+0x26b/0x310
[ 3290.970236] state_store+0x42/0x90
[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970251] new_sync_write+0x125/0x1c0
[ 3290.970257] vfs_write+0x360/0x3c0
[ 3290.970263] ksys_write+0xa7/0xe0
[ 3290.970269] do_syscall_64+0x3a/0x80
[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970284]
other info that might help us debug this:
[ 3290.970285] Chain exists of:
(wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
[ 3290.970297] Possible unsafe locking scenario:
[ 3290.970299] CPU0 CPU1
[ 3290.970300] ---- ----
[ 3290.970302] lock(dpm_list_mtx);
[ 3290.970306] lock(&hdev->lock);
[ 3290.970310] lock(dpm_list_mtx);
[ 3290.970314] lock((wq_completion)hci0#2);
[ 3290.970319]
*** DEADLOCK ***
[ 3290.970321] 7 locks held by systemd-sleep/4553:
[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.970428]
stack backtrace:
[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
[ 3290.970441] Call Trace:
[ 3290.970446] dump_stack_lvl+0x44/0x57
[ 3290.970454] check_noncircular+0x105/0x120
[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
[ 3290.970474] __lock_acquire+0x15cb/0x1b50
[ 3290.970487] lock_acquire+0x26c/0x300
[ 3290.970493] ? flush_workqueue+0x87/0x4a0
[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
[ 3290.970519] flush_workqueue+0xae/0x4a0
[ 3290.970526] ? flush_workqueue+0x87/0x4a0
[ 3290.970544] ? drain_workqueue+0xa1/0x130
[ 3290.970552] drain_workqueue+0xa1/0x130
[ 3290.970561] destroy_workqueue+0x34/0x1f0
[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970687] device_release+0x33/0x90
[ 3290.970695] kobject_release+0x63/0x160
[ 3290.970705] dpm_resume+0x164/0x3e0
[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
[ 3290.970718] dpm_resume_end+0xd/0x20
[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970737] pm_suspend+0x26b/0x310
[ 3290.970746] state_store+0x42/0x90
[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970764] new_sync_write+0x125/0x1c0
[ 3290.970777] vfs_write+0x360/0x3c0
[ 3290.970785] ksys_write+0xa7/0xe0
[ 3290.970794] do_syscall_64+0x3a/0x80
[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970811] RIP: 0033:0x7f41b1328164
[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-11-04 17:26:26 +00:00
|
|
|
|
|
|
|
mutex_lock(&dpm_list_mtx);
|
2010-11-11 00:50:53 +00:00
|
|
|
}
|
2009-05-24 19:15:07 +00:00
|
|
|
mutex_unlock(&dpm_list_mtx);
|
2014-02-18 02:28:46 +00:00
|
|
|
async_synchronize_full();
|
2017-07-21 00:10:22 +00:00
|
|
|
dpm_show_time(starttime, state, 0, "early");
|
2014-06-06 12:40:17 +00:00
|
|
|
trace_suspend_resume(TPS("dpm_resume_early"), state.event, false);
|
2008-01-12 19:40:46 +00:00
|
|
|
}
|
2012-01-29 19:38:29 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* dpm_resume_start - Execute "noirq" and "early" device callbacks.
|
|
|
|
* @state: PM transition of the system being carried out.
|
|
|
|
*/
|
|
|
|
void dpm_resume_start(pm_message_t state)
|
|
|
|
{
|
|
|
|
dpm_resume_noirq(state);
|
|
|
|
dpm_resume_early(state);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(dpm_resume_start);
|
2008-01-12 19:40:46 +00:00
|
|
|
|
|
|
|
/**
|
2010-01-23 21:25:31 +00:00
|
|
|
* device_resume - Execute "resume" callbacks for given device.
|
2009-08-20 18:25:52 +00:00
|
|
|
* @dev: Device to handle.
|
|
|
|
* @state: PM transition of the system being carried out.
|
PM: Asynchronous suspend and resume of devices
Theoretically, the total time of system sleep transitions (suspend
to RAM, hibernation) can be reduced by running suspend and resume
callbacks of device drivers in parallel with each other. However,
there are dependencies between devices such that we're not allowed
to suspend the parent of a device before suspending the device
itself. Analogously, we're not allowed to resume a device before
resuming its parent.
The most straightforward way to take these dependencies into accout
is to start the async threads used for suspending and resuming
devices at the core level, so that async_schedule() is called for
each suspend and resume callback supposed to be executed
asynchronously.
For this purpose, introduce a new device flag, power.async_suspend,
used to mark the devices whose suspend and resume callbacks are to be
executed asynchronously (ie. in parallel with the main suspend/resume
thread and possibly in parallel with each other) and helper function
device_enable_async_suspend() allowing one to set power.async_suspend
for given device (power.async_suspend is unset by default for all
devices). For each device with the power.async_suspend flag set the
PM core will use async_schedule() to execute its suspend and resume
callbacks.
The async threads started for different devices as a result of
calling async_schedule() are synchronized with each other and with
the main suspend/resume thread with the help of completions, in the
following way:
(1) There is a completion, power.completion, for each device object.
(2) Each device's completion is reset before calling async_schedule()
for the device or, in the case of devices with the
power.async_suspend flags unset, before executing the device's
suspend and resume callbacks.
(3) During suspend, right before running the bus type, device type
and device class suspend callbacks for the device, the PM core
waits for the completions of all the device's children to be
completed.
(4) During resume, right before running the bus type, device type and
device class resume callbacks for the device, the PM core waits
for the completion of the device's parent to be completed.
(5) The PM core completes power.completion for each device right
after the bus type, device type and device class suspend (or
resume) callbacks executed for the device have returned.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-01-23 21:23:32 +00:00
|
|
|
* @async: If true, the device is being resumed asynchronously.
|
2008-01-12 19:40:46 +00:00
|
|
|
*/
|
2010-01-23 21:25:31 +00:00
|
|
|
static int device_resume(struct device *dev, pm_message_t state, bool async)
|
2008-01-12 19:40:46 +00:00
|
|
|
{
|
2011-12-17 23:34:01 +00:00
|
|
|
pm_callback_t callback = NULL;
|
2017-06-12 15:19:32 +00:00
|
|
|
const char *info = NULL;
|
2008-01-12 19:40:46 +00:00
|
|
|
int error = 0;
|
2013-10-17 17:48:46 +00:00
|
|
|
DECLARE_DPM_WATCHDOG_ON_STACK(wd);
|
2008-01-12 19:40:46 +00:00
|
|
|
|
|
|
|
TRACE_DEVICE(dev);
|
|
|
|
TRACE_RESUME(0);
|
2007-09-21 19:36:56 +00:00
|
|
|
|
2012-08-05 23:46:39 +00:00
|
|
|
if (dev->power.syscore)
|
|
|
|
goto Complete;
|
|
|
|
|
PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily
Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
resume all runtime-suspended devices during system suspend, mostly
because those devices may need to be reprogrammed due to different
wakeup settings for system sleep and for runtime PM.
For some devices, though, it's OK to remain in runtime suspend
throughout a complete system suspend/resume cycle (if the device was in
runtime suspend at the start of the cycle). We would like to do this
whenever possible, to avoid the overhead of extra power-up and power-down
events.
However, problems may arise because the device's descendants may require
it to be at full power at various points during the cycle. Therefore the
most straightforward way to do this safely is if the device and all its
descendants can remain runtime suspended until the complete stage of
system resume.
To this end, introduce a new device PM flag, power.direct_complete
and modify the PM core to use that flag as follows.
If the ->prepare() callback of a device returns a positive number,
the PM core will regard that as an indication that it may leave the
device runtime-suspended. It will then check if the system power
transition in progress is a suspend (and not hibernation in particular)
and if the device is, indeed, runtime-suspended. In that case, the PM
core will set the device's power.direct_complete flag. Otherwise it
will clear power.direct_complete for the device and it also will later
clear it for the device's parent (if there's one).
Next, the PM core will not invoke the ->suspend() ->suspend_late(),
->suspend_irq(), ->resume_irq(), ->resume_early(), or ->resume()
callbacks for all devices having power.direct_complete set. It
will invoke their ->complete() callbacks, however, and those
callbacks are then responsible for resuming the devices as
appropriate, if necessary. For example, in some cases they may
need to queue up runtime resume requests for the devices using
pm_request_resume().
Changelog partly based on an Alan Stern's description of the idea
(http://marc.info/?l=linux-pm&m=139940466625569&w=2).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
2014-05-16 00:46:50 +00:00
|
|
|
if (dev->power.direct_complete) {
|
|
|
|
/* Match the pm_runtime_disable() in __device_suspend(). */
|
|
|
|
pm_runtime_enable(dev);
|
|
|
|
goto Complete;
|
|
|
|
}
|
|
|
|
|
PM: core: Fix handling of devices deleted during system-wide resume
If a device is deleted by one of its system-wide resume callbacks
(for example, because it does not appear to be present or accessible
any more) along with its children, the resume of the children may
continue leading to use-after-free errors and other issues
(potentially).
Namely, if the device's children are resumed asynchronously, their
resume may have been scheduled already before the device's callback
runs and so the device may be deleted while dpm_wait_for_superior()
is being executed for them. The memory taken up by the parent device
object may be freed then while dpm_wait() is waiting for the parent's
resume callback to complete, which leads to a use-after-free.
Moreover, the resume of the children is really not expected to
continue after they have been unregistered, so it must be terminated
right away in that case.
To address this problem, modify dpm_wait_for_superior() to check
if the target device is still there in the system-wide PM list of
devices and if so, to increment its parent's reference counter, both
under dpm_list_mtx which prevents device_del() running for the child
from dropping the parent's reference counter prematurely.
If the device is not present in the system-wide PM list of devices
any more, the resume of it cannot continue, so check that again after
dpm_wait() returns, which means that the parent's callback has been
completed, and pass the result of that check to the caller of
dpm_wait_for_superior() to allow it to abort the device's resume
if it is not there any more.
Link: https://lore.kernel.org/linux-pm/1579568452-27253-1-git-send-email-chanho.min@lge.com
Reported-by: Chanho Min <chanho.min@lge.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-22 23:11:24 +00:00
|
|
|
if (!dpm_wait_for_superior(dev, async))
|
|
|
|
goto Complete;
|
|
|
|
|
2013-10-17 17:48:46 +00:00
|
|
|
dpm_watchdog_set(&wd, dev);
|
2010-02-17 18:57:05 +00:00
|
|
|
device_lock(dev);
|
2008-02-24 23:35:04 +00:00
|
|
|
|
2011-06-18 18:22:23 +00:00
|
|
|
/*
|
|
|
|
* This is a fib. But we'll allow new children to be added below
|
|
|
|
* a resumed device, even if the device hasn't been completed yet.
|
|
|
|
*/
|
|
|
|
dev->power.is_prepared = false;
|
2010-01-23 21:25:31 +00:00
|
|
|
|
2011-06-18 20:42:09 +00:00
|
|
|
if (!dev->power.is_suspended)
|
|
|
|
goto Unlock;
|
|
|
|
|
2011-06-22 23:52:55 +00:00
|
|
|
if (dev->pm_domain) {
|
2011-12-17 23:34:01 +00:00
|
|
|
info = "power domain ";
|
|
|
|
callback = pm_op(&dev->pm_domain->ops, state);
|
2011-12-17 23:34:13 +00:00
|
|
|
goto Driver;
|
2011-02-16 20:53:17 +00:00
|
|
|
}
|
|
|
|
|
PM: Make system-wide PM and runtime PM treat subsystems consistently
The code handling system-wide power transitions (eg. suspend-to-RAM)
can in theory execute callbacks provided by the device's bus type,
device type and class in each phase of the power transition. In
turn, the runtime PM core code only calls one of those callbacks at
a time, preferring bus type callbacks to device type or class
callbacks and device type callbacks to class callbacks.
It seems reasonable to make them both behave in the same way in that
respect. Moreover, even though a device may belong to two subsystems
(eg. bus type and device class) simultaneously, in practice power
management callbacks for system-wide power transitions are always
provided by only one of them (ie. if the bus type callbacks are
defined, the device class ones are not and vice versa). Thus it is
possible to modify the code handling system-wide power transitions
so that it follows the core runtime PM code (ie. treats the
subsystem callbacks as mutually exclusive).
On the other hand, the core runtime PM code will choose to execute,
for example, a runtime suspend callback provided by the device type
even if the bus type's struct dev_pm_ops object exists, but the
runtime_suspend pointer in it happens to be NULL. This is confusing,
because it may lead to the execution of callbacks from different
subsystems during different operations (eg. the bus type suspend
callback may be executed during runtime suspend of the device, while
the device type callback will be executed during system suspend).
Make all of the power management code treat subsystem callbacks in
a consistent way, such that:
(1) If the device's type is defined (eg. dev->type is not NULL)
and its pm pointer is not NULL, the callbacks from dev->type->pm
will be used.
(2) If dev->type is NULL or dev->type->pm is NULL, but the device's
class is defined (eg. dev->class is not NULL) and its pm pointer
is not NULL, the callbacks from dev->class->pm will be used.
(3) If dev->type is NULL or dev->type->pm is NULL and dev->class is
NULL or dev->class->pm is NULL, the callbacks from dev->bus->pm
will be used provided that both dev->bus and dev->bus->pm are
not NULL.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Kevin Hilman <khilman@ti.com>
Reasoning-sounds-sane-to: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-18 22:20:21 +00:00
|
|
|
if (dev->type && dev->type->pm) {
|
2011-12-17 23:34:01 +00:00
|
|
|
info = "type ";
|
|
|
|
callback = pm_op(dev->type->pm, state);
|
2011-12-17 23:34:13 +00:00
|
|
|
goto Driver;
|
2007-09-21 19:36:56 +00:00
|
|
|
}
|
|
|
|
|
2017-09-25 12:56:44 +00:00
|
|
|
if (dev->class && dev->class->pm) {
|
|
|
|
info = "class ";
|
|
|
|
callback = pm_op(dev->class->pm, state);
|
|
|
|
goto Driver;
|
2007-09-21 19:36:56 +00:00
|
|
|
}
|
PM: Make system-wide PM and runtime PM treat subsystems consistently
The code handling system-wide power transitions (eg. suspend-to-RAM)
can in theory execute callbacks provided by the device's bus type,
device type and class in each phase of the power transition. In
turn, the runtime PM core code only calls one of those callbacks at
a time, preferring bus type callbacks to device type or class
callbacks and device type callbacks to class callbacks.
It seems reasonable to make them both behave in the same way in that
respect. Moreover, even though a device may belong to two subsystems
(eg. bus type and device class) simultaneously, in practice power
management callbacks for system-wide power transitions are always
provided by only one of them (ie. if the bus type callbacks are
defined, the device class ones are not and vice versa). Thus it is
possible to modify the code handling system-wide power transitions
so that it follows the core runtime PM code (ie. treats the
subsystem callbacks as mutually exclusive).
On the other hand, the core runtime PM code will choose to execute,
for example, a runtime suspend callback provided by the device type
even if the bus type's struct dev_pm_ops object exists, but the
runtime_suspend pointer in it happens to be NULL. This is confusing,
because it may lead to the execution of callbacks from different
subsystems during different operations (eg. the bus type suspend
callback may be executed during runtime suspend of the device, while
the device type callback will be executed during system suspend).
Make all of the power management code treat subsystem callbacks in
a consistent way, such that:
(1) If the device's type is defined (eg. dev->type is not NULL)
and its pm pointer is not NULL, the callbacks from dev->type->pm
will be used.
(2) If dev->type is NULL or dev->type->pm is NULL, but the device's
class is defined (eg. dev->class is not NULL) and its pm pointer
is not NULL, the callbacks from dev->class->pm will be used.
(3) If dev->type is NULL or dev->type->pm is NULL and dev->class is
NULL or dev->class->pm is NULL, the callbacks from dev->bus->pm
will be used provided that both dev->bus and dev->bus->pm are
not NULL.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Kevin Hilman <khilman@ti.com>
Reasoning-sounds-sane-to: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-18 22:20:21 +00:00
|
|
|
|
|
|
|
if (dev->bus) {
|
|
|
|
if (dev->bus->pm) {
|
2011-12-17 23:34:13 +00:00
|
|
|
info = "bus ";
|
2011-12-17 23:34:01 +00:00
|
|
|
callback = pm_op(dev->bus->pm, state);
|
PM: Make system-wide PM and runtime PM treat subsystems consistently
The code handling system-wide power transitions (eg. suspend-to-RAM)
can in theory execute callbacks provided by the device's bus type,
device type and class in each phase of the power transition. In
turn, the runtime PM core code only calls one of those callbacks at
a time, preferring bus type callbacks to device type or class
callbacks and device type callbacks to class callbacks.
It seems reasonable to make them both behave in the same way in that
respect. Moreover, even though a device may belong to two subsystems
(eg. bus type and device class) simultaneously, in practice power
management callbacks for system-wide power transitions are always
provided by only one of them (ie. if the bus type callbacks are
defined, the device class ones are not and vice versa). Thus it is
possible to modify the code handling system-wide power transitions
so that it follows the core runtime PM code (ie. treats the
subsystem callbacks as mutually exclusive).
On the other hand, the core runtime PM code will choose to execute,
for example, a runtime suspend callback provided by the device type
even if the bus type's struct dev_pm_ops object exists, but the
runtime_suspend pointer in it happens to be NULL. This is confusing,
because it may lead to the execution of callbacks from different
subsystems during different operations (eg. the bus type suspend
callback may be executed during runtime suspend of the device, while
the device type callback will be executed during system suspend).
Make all of the power management code treat subsystem callbacks in
a consistent way, such that:
(1) If the device's type is defined (eg. dev->type is not NULL)
and its pm pointer is not NULL, the callbacks from dev->type->pm
will be used.
(2) If dev->type is NULL or dev->type->pm is NULL, but the device's
class is defined (eg. dev->class is not NULL) and its pm pointer
is not NULL, the callbacks from dev->class->pm will be used.
(3) If dev->type is NULL or dev->type->pm is NULL and dev->class is
NULL or dev->class->pm is NULL, the callbacks from dev->bus->pm
will be used provided that both dev->bus and dev->bus->pm are
not NULL.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Kevin Hilman <khilman@ti.com>
Reasoning-sounds-sane-to: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-18 22:20:21 +00:00
|
|
|
} else if (dev->bus->resume) {
|
2011-12-17 23:34:13 +00:00
|
|
|
info = "legacy bus ";
|
2011-12-17 23:34:01 +00:00
|
|
|
callback = dev->bus->resume;
|
2011-12-17 23:34:13 +00:00
|
|
|
goto End;
|
PM: Make system-wide PM and runtime PM treat subsystems consistently
The code handling system-wide power transitions (eg. suspend-to-RAM)
can in theory execute callbacks provided by the device's bus type,
device type and class in each phase of the power transition. In
turn, the runtime PM core code only calls one of those callbacks at
a time, preferring bus type callbacks to device type or class
callbacks and device type callbacks to class callbacks.
It seems reasonable to make them both behave in the same way in that
respect. Moreover, even though a device may belong to two subsystems
(eg. bus type and device class) simultaneously, in practice power
management callbacks for system-wide power transitions are always
provided by only one of them (ie. if the bus type callbacks are
defined, the device class ones are not and vice versa). Thus it is
possible to modify the code handling system-wide power transitions
so that it follows the core runtime PM code (ie. treats the
subsystem callbacks as mutually exclusive).
On the other hand, the core runtime PM code will choose to execute,
for example, a runtime suspend callback provided by the device type
even if the bus type's struct dev_pm_ops object exists, but the
runtime_suspend pointer in it happens to be NULL. This is confusing,
because it may lead to the execution of callbacks from different
subsystems during different operations (eg. the bus type suspend
callback may be executed during runtime suspend of the device, while
the device type callback will be executed during system suspend).
Make all of the power management code treat subsystem callbacks in
a consistent way, such that:
(1) If the device's type is defined (eg. dev->type is not NULL)
and its pm pointer is not NULL, the callbacks from dev->type->pm
will be used.
(2) If dev->type is NULL or dev->type->pm is NULL, but the device's
class is defined (eg. dev->class is not NULL) and its pm pointer
is not NULL, the callbacks from dev->class->pm will be used.
(3) If dev->type is NULL or dev->type->pm is NULL and dev->class is
NULL or dev->class->pm is NULL, the callbacks from dev->bus->pm
will be used provided that both dev->bus and dev->bus->pm are
not NULL.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Kevin Hilman <khilman@ti.com>
Reasoning-sounds-sane-to: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-18 22:20:21 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-12-17 23:34:13 +00:00
|
|
|
Driver:
|
|
|
|
if (!callback && dev->driver && dev->driver->pm) {
|
|
|
|
info = "driver ";
|
|
|
|
callback = pm_op(dev->driver->pm, state);
|
|
|
|
}
|
|
|
|
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
End:
|
2011-12-17 23:34:01 +00:00
|
|
|
error = dpm_run_callback(callback, dev, state, info);
|
2011-06-18 20:42:09 +00:00
|
|
|
dev->power.is_suspended = false;
|
|
|
|
|
|
|
|
Unlock:
|
2010-02-17 18:57:05 +00:00
|
|
|
device_unlock(dev);
|
2013-10-17 17:48:46 +00:00
|
|
|
dpm_watchdog_clear(&wd);
|
2012-08-05 23:46:39 +00:00
|
|
|
|
|
|
|
Complete:
|
PM: Asynchronous suspend and resume of devices
Theoretically, the total time of system sleep transitions (suspend
to RAM, hibernation) can be reduced by running suspend and resume
callbacks of device drivers in parallel with each other. However,
there are dependencies between devices such that we're not allowed
to suspend the parent of a device before suspending the device
itself. Analogously, we're not allowed to resume a device before
resuming its parent.
The most straightforward way to take these dependencies into accout
is to start the async threads used for suspending and resuming
devices at the core level, so that async_schedule() is called for
each suspend and resume callback supposed to be executed
asynchronously.
For this purpose, introduce a new device flag, power.async_suspend,
used to mark the devices whose suspend and resume callbacks are to be
executed asynchronously (ie. in parallel with the main suspend/resume
thread and possibly in parallel with each other) and helper function
device_enable_async_suspend() allowing one to set power.async_suspend
for given device (power.async_suspend is unset by default for all
devices). For each device with the power.async_suspend flag set the
PM core will use async_schedule() to execute its suspend and resume
callbacks.
The async threads started for different devices as a result of
calling async_schedule() are synchronized with each other and with
the main suspend/resume thread with the help of completions, in the
following way:
(1) There is a completion, power.completion, for each device object.
(2) Each device's completion is reset before calling async_schedule()
for the device or, in the case of devices with the
power.async_suspend flags unset, before executing the device's
suspend and resume callbacks.
(3) During suspend, right before running the bus type, device type
and device class suspend callbacks for the device, the PM core
waits for the completions of all the device's children to be
completed.
(4) During resume, right before running the bus type, device type and
device class resume callbacks for the device, the PM core waits
for the completion of the device's parent to be completed.
(5) The PM core completes power.completion for each device right
after the bus type, device type and device class suspend (or
resume) callbacks executed for the device have returned.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-01-23 21:23:32 +00:00
|
|
|
complete_all(&dev->power.completion);
|
2008-02-24 23:35:04 +00:00
|
|
|
|
2007-09-21 19:36:56 +00:00
|
|
|
TRACE_RESUME(error);
|
PM: Limit race conditions between runtime PM and system sleep (v2)
One of the roles of the PM core is to prevent different PM callbacks
executed for the same device object from racing with each other.
Unfortunately, after commit e8665002477f0278f84f898145b1f141ba26ee26
(PM: Allow pm_runtime_suspend() to succeed during system suspend)
runtime PM callbacks may be executed concurrently with system
suspend/resume callbacks for the same device.
The main reason for commit e8665002477f0278f84f898145b1f141ba26ee26
was that some subsystems and device drivers wanted to use runtime PM
helpers, pm_runtime_suspend() and pm_runtime_put_sync() in
particular, for carrying out the suspend of devices in their
.suspend() callbacks. However, as it's been determined recently,
there are multiple reasons not to do so, inlcuding:
* The caller really doesn't control the runtime PM usage counters,
because user space can access them through sysfs and effectively
block runtime PM. That means using pm_runtime_suspend() or
pm_runtime_get_sync() to suspend devices during system suspend
may or may not work.
* If a driver calls pm_runtime_suspend() from its .suspend()
callback, it causes the subsystem's .runtime_suspend() callback to
be executed, which leads to the call sequence:
subsys->suspend(dev)
driver->suspend(dev)
pm_runtime_suspend(dev)
subsys->runtime_suspend(dev)
recursive from the subsystem's point of view. For some subsystems
that may actually work (e.g. the platform bus type), but for some
it will fail in a rather spectacular fashion (e.g. PCI). In each
case it means a layering violation.
* Both the subsystem and the driver can provide .suspend_noirq()
callbacks for system suspend that can do whatever the
.runtime_suspend() callbacks do just fine, so it really isn't
necessary to call pm_runtime_suspend() during system suspend.
* The runtime PM's handling of wakeup devices is usually different
from the system suspend's one, so .runtime_suspend() may simply be
inappropriate for system suspend.
* System suspend is supposed to work even if CONFIG_PM_RUNTIME is
unset.
* The runtime PM workqueue is frozen before system suspend, so if
whatever the driver is going to do during system suspend depends
on it, that simply won't work.
Still, there is a good reason to allow pm_runtime_resume() to
succeed during system suspend and resume (for instance, some
subsystems and device drivers may legitimately use it to ensure that
their devices are in full-power states before suspending them).
Moreover, there is no reason to prevent runtime PM callbacks from
being executed in parallel with the system suspend/resume .prepare()
and .complete() callbacks and the code removed by commit
e8665002477f0278f84f898145b1f141ba26ee26 went too far in this
respect. On the other hand, runtime PM callbacks, including
.runtime_resume(), must not be executed during system suspend's
"late" stage of suspending devices and during system resume's "early"
device resume stage.
Taking all of the above into consideration, make the PM core
acquire a runtime PM reference to every device and resume it if
there's a runtime PM resume request pending right before executing
the subsystem-level .suspend() callback for it. Make the PM core
drop references to all devices right after executing the
subsystem-level .resume() callbacks for them. Additionally,
make the PM core disable the runtime PM framework for all devices
during system suspend, after executing the subsystem-level .suspend()
callbacks for them, and enable the runtime PM framework for all
devices during system resume, right before executing the
subsystem-level .resume() callbacks for them.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Kevin Hilman <khilman@ti.com>
2011-07-06 08:51:58 +00:00
|
|
|
|
2007-09-21 19:36:56 +00:00
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
PM: Asynchronous suspend and resume of devices
Theoretically, the total time of system sleep transitions (suspend
to RAM, hibernation) can be reduced by running suspend and resume
callbacks of device drivers in parallel with each other. However,
there are dependencies between devices such that we're not allowed
to suspend the parent of a device before suspending the device
itself. Analogously, we're not allowed to resume a device before
resuming its parent.
The most straightforward way to take these dependencies into accout
is to start the async threads used for suspending and resuming
devices at the core level, so that async_schedule() is called for
each suspend and resume callback supposed to be executed
asynchronously.
For this purpose, introduce a new device flag, power.async_suspend,
used to mark the devices whose suspend and resume callbacks are to be
executed asynchronously (ie. in parallel with the main suspend/resume
thread and possibly in parallel with each other) and helper function
device_enable_async_suspend() allowing one to set power.async_suspend
for given device (power.async_suspend is unset by default for all
devices). For each device with the power.async_suspend flag set the
PM core will use async_schedule() to execute its suspend and resume
callbacks.
The async threads started for different devices as a result of
calling async_schedule() are synchronized with each other and with
the main suspend/resume thread with the help of completions, in the
following way:
(1) There is a completion, power.completion, for each device object.
(2) Each device's completion is reset before calling async_schedule()
for the device or, in the case of devices with the
power.async_suspend flags unset, before executing the device's
suspend and resume callbacks.
(3) During suspend, right before running the bus type, device type
and device class suspend callbacks for the device, the PM core
waits for the completions of all the device's children to be
completed.
(4) During resume, right before running the bus type, device type and
device class resume callbacks for the device, the PM core waits
for the completion of the device's parent to be completed.
(5) The PM core completes power.completion for each device right
after the bus type, device type and device class suspend (or
resume) callbacks executed for the device have returned.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-01-23 21:23:32 +00:00
|
|
|
static void async_resume(void *data, async_cookie_t cookie)
|
|
|
|
{
|
|
|
|
struct device *dev = (struct device *)data;
|
|
|
|
int error;
|
|
|
|
|
2010-01-23 21:25:31 +00:00
|
|
|
error = device_resume(dev, pm_transition, true);
|
PM: Asynchronous suspend and resume of devices
Theoretically, the total time of system sleep transitions (suspend
to RAM, hibernation) can be reduced by running suspend and resume
callbacks of device drivers in parallel with each other. However,
there are dependencies between devices such that we're not allowed
to suspend the parent of a device before suspending the device
itself. Analogously, we're not allowed to resume a device before
resuming its parent.
The most straightforward way to take these dependencies into accout
is to start the async threads used for suspending and resuming
devices at the core level, so that async_schedule() is called for
each suspend and resume callback supposed to be executed
asynchronously.
For this purpose, introduce a new device flag, power.async_suspend,
used to mark the devices whose suspend and resume callbacks are to be
executed asynchronously (ie. in parallel with the main suspend/resume
thread and possibly in parallel with each other) and helper function
device_enable_async_suspend() allowing one to set power.async_suspend
for given device (power.async_suspend is unset by default for all
devices). For each device with the power.async_suspend flag set the
PM core will use async_schedule() to execute its suspend and resume
callbacks.
The async threads started for different devices as a result of
calling async_schedule() are synchronized with each other and with
the main suspend/resume thread with the help of completions, in the
following way:
(1) There is a completion, power.completion, for each device object.
(2) Each device's completion is reset before calling async_schedule()
for the device or, in the case of devices with the
power.async_suspend flags unset, before executing the device's
suspend and resume callbacks.
(3) During suspend, right before running the bus type, device type
and device class suspend callbacks for the device, the PM core
waits for the completions of all the device's children to be
completed.
(4) During resume, right before running the bus type, device type and
device class resume callbacks for the device, the PM core waits
for the completion of the device's parent to be completed.
(5) The PM core completes power.completion for each device right
after the bus type, device type and device class suspend (or
resume) callbacks executed for the device have returned.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-01-23 21:23:32 +00:00
|
|
|
if (error)
|
|
|
|
pm_dev_err(dev, pm_transition, " async", error);
|
|
|
|
put_device(dev);
|
|
|
|
}
|
|
|
|
|
2008-01-12 19:40:46 +00:00
|
|
|
/**
|
2009-08-20 18:25:52 +00:00
|
|
|
* dpm_resume - Execute "resume" callbacks for non-sysdev devices.
|
|
|
|
* @state: PM transition of the system being carried out.
|
2008-01-12 19:40:46 +00:00
|
|
|
*
|
2009-08-20 18:25:52 +00:00
|
|
|
* Execute the appropriate "resume" callback for all devices whose status
|
|
|
|
* indicates that they are suspended.
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
*/
|
2011-05-17 21:26:00 +00:00
|
|
|
void dpm_resume(pm_message_t state)
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
{
|
2010-01-23 21:25:31 +00:00
|
|
|
struct device *dev;
|
2009-12-18 00:57:47 +00:00
|
|
|
ktime_t starttime = ktime_get();
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
|
2014-06-06 12:40:17 +00:00
|
|
|
trace_suspend_resume(TPS("dpm_resume"), state.event, true);
|
2011-05-17 21:26:00 +00:00
|
|
|
might_sleep();
|
|
|
|
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
mutex_lock(&dpm_list_mtx);
|
PM: Asynchronous suspend and resume of devices
Theoretically, the total time of system sleep transitions (suspend
to RAM, hibernation) can be reduced by running suspend and resume
callbacks of device drivers in parallel with each other. However,
there are dependencies between devices such that we're not allowed
to suspend the parent of a device before suspending the device
itself. Analogously, we're not allowed to resume a device before
resuming its parent.
The most straightforward way to take these dependencies into accout
is to start the async threads used for suspending and resuming
devices at the core level, so that async_schedule() is called for
each suspend and resume callback supposed to be executed
asynchronously.
For this purpose, introduce a new device flag, power.async_suspend,
used to mark the devices whose suspend and resume callbacks are to be
executed asynchronously (ie. in parallel with the main suspend/resume
thread and possibly in parallel with each other) and helper function
device_enable_async_suspend() allowing one to set power.async_suspend
for given device (power.async_suspend is unset by default for all
devices). For each device with the power.async_suspend flag set the
PM core will use async_schedule() to execute its suspend and resume
callbacks.
The async threads started for different devices as a result of
calling async_schedule() are synchronized with each other and with
the main suspend/resume thread with the help of completions, in the
following way:
(1) There is a completion, power.completion, for each device object.
(2) Each device's completion is reset before calling async_schedule()
for the device or, in the case of devices with the
power.async_suspend flags unset, before executing the device's
suspend and resume callbacks.
(3) During suspend, right before running the bus type, device type
and device class suspend callbacks for the device, the PM core
waits for the completions of all the device's children to be
completed.
(4) During resume, right before running the bus type, device type and
device class resume callbacks for the device, the PM core waits
for the completion of the device's parent to be completed.
(5) The PM core completes power.completion for each device right
after the bus type, device type and device class suspend (or
resume) callbacks executed for the device have returned.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-01-23 21:23:32 +00:00
|
|
|
pm_transition = state;
|
2010-09-22 20:10:57 +00:00
|
|
|
async_error = 0;
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
|
2019-03-16 04:59:25 +00:00
|
|
|
list_for_each_entry(dev, &dpm_suspended_list, power.entry)
|
|
|
|
dpm_async_fn(dev, async_resume);
|
2010-01-23 21:25:31 +00:00
|
|
|
|
2010-12-15 23:50:30 +00:00
|
|
|
while (!list_empty(&dpm_suspended_list)) {
|
|
|
|
dev = to_device(dpm_suspended_list.next);
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
get_device(dev);
|
2010-12-15 23:51:08 +00:00
|
|
|
if (!is_async(dev)) {
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
int error;
|
|
|
|
|
|
|
|
mutex_unlock(&dpm_list_mtx);
|
|
|
|
|
2010-01-23 21:25:31 +00:00
|
|
|
error = device_resume(dev, state, false);
|
PM / Suspend: Add statistics debugfs file for suspend to RAM
Record S3 failure time about each reason and the latest two failed
devices' names in S3 progress.
We can check it through 'suspend_stats' entry in debugfs.
The motivation of the patch:
We are enabling power features on Medfield. Comparing with PC/notebook,
a mobile enters/exits suspend-2-ram (we call it s3 on Medfield) far
more frequently. If it can't enter suspend-2-ram in time, the power
might be used up soon.
We often find sometimes, a device suspend fails. Then, system retries
s3 over and over again. As display is off, testers and developers
don't know what happens.
Some testers and developers complain they don't know if system
tries suspend-2-ram, and what device fails to suspend. They need
such info for a quick check. The patch adds suspend_stats under
debugfs for users to check suspend to RAM statistics quickly.
If not using this patch, we have other methods to get info about
what device fails. One is to turn on CONFIG_PM_DEBUG, but users
would get too much info and testers need recompile the system.
In addition, dynamic debug is another good tool to dump debug info.
But it still doesn't match our utilization scenario closely.
1) user need write a user space parser to process the syslog output;
2) Our testing scenario is we leave the mobile for at least hours.
Then, check its status. No serial console available during the
testing. One is because console would be suspended, and the other
is serial console connecting with spi or HSU devices would consume
power. These devices are powered off at suspend-2-ram.
Signed-off-by: ShuoX Liu <shuox.liu@intel.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-08-10 21:01:26 +00:00
|
|
|
if (error) {
|
|
|
|
suspend_stats.failed_resume++;
|
|
|
|
dpm_save_failed_step(SUSPEND_RESUME);
|
|
|
|
dpm_save_failed_dev(dev_name(dev));
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
pm_dev_err(dev, state, "", error);
|
PM / Suspend: Add statistics debugfs file for suspend to RAM
Record S3 failure time about each reason and the latest two failed
devices' names in S3 progress.
We can check it through 'suspend_stats' entry in debugfs.
The motivation of the patch:
We are enabling power features on Medfield. Comparing with PC/notebook,
a mobile enters/exits suspend-2-ram (we call it s3 on Medfield) far
more frequently. If it can't enter suspend-2-ram in time, the power
might be used up soon.
We often find sometimes, a device suspend fails. Then, system retries
s3 over and over again. As display is off, testers and developers
don't know what happens.
Some testers and developers complain they don't know if system
tries suspend-2-ram, and what device fails to suspend. They need
such info for a quick check. The patch adds suspend_stats under
debugfs for users to check suspend to RAM statistics quickly.
If not using this patch, we have other methods to get info about
what device fails. One is to turn on CONFIG_PM_DEBUG, but users
would get too much info and testers need recompile the system.
In addition, dynamic debug is another good tool to dump debug info.
But it still doesn't match our utilization scenario closely.
1) user need write a user space parser to process the syslog output;
2) Our testing scenario is we leave the mobile for at least hours.
Then, check its status. No serial console available during the
testing. One is because console would be suspended, and the other
is serial console connecting with spi or HSU devices would consume
power. These devices are powered off at suspend-2-ram.
Signed-off-by: ShuoX Liu <shuox.liu@intel.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-08-10 21:01:26 +00:00
|
|
|
}
|
2010-12-15 23:51:08 +00:00
|
|
|
|
|
|
|
mutex_lock(&dpm_list_mtx);
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
}
|
|
|
|
if (!list_empty(&dev->power.entry))
|
2010-12-15 23:50:30 +00:00
|
|
|
list_move_tail(&dev->power.entry, &dpm_prepared_list);
|
PM: sleep: Avoid calling put_device() under dpm_list_mtx
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
[ 3290.969514] ======================================================
[ 3290.969517] WARNING: possible circular locking dependency detected
[ 3290.969519] 5.15.0+ #2420 Tainted: G S
[ 3290.969523] ------------------------------------------------------
[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
[ 3290.969554]
but task is already holding lock:
[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.969571]
which lock already depends on the new lock.
[ 3290.969573]
the existing dependency chain (in reverse order) is:
[ 3290.969575]
-> #3 (dpm_list_mtx){+.+.}-{3:3}:
[ 3290.969583] __mutex_lock+0x9d/0xa30
[ 3290.969591] device_pm_add+0x2e/0xe0
[ 3290.969597] device_add+0x4d5/0x8f0
[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969842] process_one_work+0x2aa/0x650
[ 3290.969851] worker_thread+0x39/0x400
[ 3290.969859] kthread+0x142/0x170
[ 3290.969865] ret_from_fork+0x22/0x30
[ 3290.969872]
-> #2 (&hdev->lock){+.+.}-{3:3}:
[ 3290.969881] __mutex_lock+0x9d/0xa30
[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969978] process_one_work+0x2aa/0x650
[ 3290.969985] worker_thread+0x39/0x400
[ 3290.969993] kthread+0x142/0x170
[ 3290.969999] ret_from_fork+0x22/0x30
[ 3290.970004]
-> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
[ 3290.970013] process_one_work+0x27d/0x650
[ 3290.970020] worker_thread+0x39/0x400
[ 3290.970028] kthread+0x142/0x170
[ 3290.970033] ret_from_fork+0x22/0x30
[ 3290.970038]
-> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
[ 3290.970047] __lock_acquire+0x15cb/0x1b50
[ 3290.970054] lock_acquire+0x26c/0x300
[ 3290.970059] flush_workqueue+0xae/0x4a0
[ 3290.970066] drain_workqueue+0xa1/0x130
[ 3290.970073] destroy_workqueue+0x34/0x1f0
[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970195] device_release+0x33/0x90
[ 3290.970201] kobject_release+0x63/0x160
[ 3290.970211] dpm_resume+0x164/0x3e0
[ 3290.970215] dpm_resume_end+0xd/0x20
[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970229] pm_suspend+0x26b/0x310
[ 3290.970236] state_store+0x42/0x90
[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970251] new_sync_write+0x125/0x1c0
[ 3290.970257] vfs_write+0x360/0x3c0
[ 3290.970263] ksys_write+0xa7/0xe0
[ 3290.970269] do_syscall_64+0x3a/0x80
[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970284]
other info that might help us debug this:
[ 3290.970285] Chain exists of:
(wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
[ 3290.970297] Possible unsafe locking scenario:
[ 3290.970299] CPU0 CPU1
[ 3290.970300] ---- ----
[ 3290.970302] lock(dpm_list_mtx);
[ 3290.970306] lock(&hdev->lock);
[ 3290.970310] lock(dpm_list_mtx);
[ 3290.970314] lock((wq_completion)hci0#2);
[ 3290.970319]
*** DEADLOCK ***
[ 3290.970321] 7 locks held by systemd-sleep/4553:
[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.970428]
stack backtrace:
[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
[ 3290.970441] Call Trace:
[ 3290.970446] dump_stack_lvl+0x44/0x57
[ 3290.970454] check_noncircular+0x105/0x120
[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
[ 3290.970474] __lock_acquire+0x15cb/0x1b50
[ 3290.970487] lock_acquire+0x26c/0x300
[ 3290.970493] ? flush_workqueue+0x87/0x4a0
[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
[ 3290.970519] flush_workqueue+0xae/0x4a0
[ 3290.970526] ? flush_workqueue+0x87/0x4a0
[ 3290.970544] ? drain_workqueue+0xa1/0x130
[ 3290.970552] drain_workqueue+0xa1/0x130
[ 3290.970561] destroy_workqueue+0x34/0x1f0
[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970687] device_release+0x33/0x90
[ 3290.970695] kobject_release+0x63/0x160
[ 3290.970705] dpm_resume+0x164/0x3e0
[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
[ 3290.970718] dpm_resume_end+0xd/0x20
[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970737] pm_suspend+0x26b/0x310
[ 3290.970746] state_store+0x42/0x90
[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970764] new_sync_write+0x125/0x1c0
[ 3290.970777] vfs_write+0x360/0x3c0
[ 3290.970785] ksys_write+0xa7/0xe0
[ 3290.970794] do_syscall_64+0x3a/0x80
[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970811] RIP: 0033:0x7f41b1328164
[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-11-04 17:26:26 +00:00
|
|
|
|
|
|
|
mutex_unlock(&dpm_list_mtx);
|
|
|
|
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
put_device(dev);
|
PM: sleep: Avoid calling put_device() under dpm_list_mtx
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
[ 3290.969514] ======================================================
[ 3290.969517] WARNING: possible circular locking dependency detected
[ 3290.969519] 5.15.0+ #2420 Tainted: G S
[ 3290.969523] ------------------------------------------------------
[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
[ 3290.969554]
but task is already holding lock:
[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.969571]
which lock already depends on the new lock.
[ 3290.969573]
the existing dependency chain (in reverse order) is:
[ 3290.969575]
-> #3 (dpm_list_mtx){+.+.}-{3:3}:
[ 3290.969583] __mutex_lock+0x9d/0xa30
[ 3290.969591] device_pm_add+0x2e/0xe0
[ 3290.969597] device_add+0x4d5/0x8f0
[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969842] process_one_work+0x2aa/0x650
[ 3290.969851] worker_thread+0x39/0x400
[ 3290.969859] kthread+0x142/0x170
[ 3290.969865] ret_from_fork+0x22/0x30
[ 3290.969872]
-> #2 (&hdev->lock){+.+.}-{3:3}:
[ 3290.969881] __mutex_lock+0x9d/0xa30
[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969978] process_one_work+0x2aa/0x650
[ 3290.969985] worker_thread+0x39/0x400
[ 3290.969993] kthread+0x142/0x170
[ 3290.969999] ret_from_fork+0x22/0x30
[ 3290.970004]
-> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
[ 3290.970013] process_one_work+0x27d/0x650
[ 3290.970020] worker_thread+0x39/0x400
[ 3290.970028] kthread+0x142/0x170
[ 3290.970033] ret_from_fork+0x22/0x30
[ 3290.970038]
-> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
[ 3290.970047] __lock_acquire+0x15cb/0x1b50
[ 3290.970054] lock_acquire+0x26c/0x300
[ 3290.970059] flush_workqueue+0xae/0x4a0
[ 3290.970066] drain_workqueue+0xa1/0x130
[ 3290.970073] destroy_workqueue+0x34/0x1f0
[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970195] device_release+0x33/0x90
[ 3290.970201] kobject_release+0x63/0x160
[ 3290.970211] dpm_resume+0x164/0x3e0
[ 3290.970215] dpm_resume_end+0xd/0x20
[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970229] pm_suspend+0x26b/0x310
[ 3290.970236] state_store+0x42/0x90
[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970251] new_sync_write+0x125/0x1c0
[ 3290.970257] vfs_write+0x360/0x3c0
[ 3290.970263] ksys_write+0xa7/0xe0
[ 3290.970269] do_syscall_64+0x3a/0x80
[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970284]
other info that might help us debug this:
[ 3290.970285] Chain exists of:
(wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
[ 3290.970297] Possible unsafe locking scenario:
[ 3290.970299] CPU0 CPU1
[ 3290.970300] ---- ----
[ 3290.970302] lock(dpm_list_mtx);
[ 3290.970306] lock(&hdev->lock);
[ 3290.970310] lock(dpm_list_mtx);
[ 3290.970314] lock((wq_completion)hci0#2);
[ 3290.970319]
*** DEADLOCK ***
[ 3290.970321] 7 locks held by systemd-sleep/4553:
[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.970428]
stack backtrace:
[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
[ 3290.970441] Call Trace:
[ 3290.970446] dump_stack_lvl+0x44/0x57
[ 3290.970454] check_noncircular+0x105/0x120
[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
[ 3290.970474] __lock_acquire+0x15cb/0x1b50
[ 3290.970487] lock_acquire+0x26c/0x300
[ 3290.970493] ? flush_workqueue+0x87/0x4a0
[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
[ 3290.970519] flush_workqueue+0xae/0x4a0
[ 3290.970526] ? flush_workqueue+0x87/0x4a0
[ 3290.970544] ? drain_workqueue+0xa1/0x130
[ 3290.970552] drain_workqueue+0xa1/0x130
[ 3290.970561] destroy_workqueue+0x34/0x1f0
[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970687] device_release+0x33/0x90
[ 3290.970695] kobject_release+0x63/0x160
[ 3290.970705] dpm_resume+0x164/0x3e0
[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
[ 3290.970718] dpm_resume_end+0xd/0x20
[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970737] pm_suspend+0x26b/0x310
[ 3290.970746] state_store+0x42/0x90
[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970764] new_sync_write+0x125/0x1c0
[ 3290.970777] vfs_write+0x360/0x3c0
[ 3290.970785] ksys_write+0xa7/0xe0
[ 3290.970794] do_syscall_64+0x3a/0x80
[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970811] RIP: 0033:0x7f41b1328164
[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-11-04 17:26:26 +00:00
|
|
|
|
|
|
|
mutex_lock(&dpm_list_mtx);
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
}
|
|
|
|
mutex_unlock(&dpm_list_mtx);
|
PM: Asynchronous suspend and resume of devices
Theoretically, the total time of system sleep transitions (suspend
to RAM, hibernation) can be reduced by running suspend and resume
callbacks of device drivers in parallel with each other. However,
there are dependencies between devices such that we're not allowed
to suspend the parent of a device before suspending the device
itself. Analogously, we're not allowed to resume a device before
resuming its parent.
The most straightforward way to take these dependencies into accout
is to start the async threads used for suspending and resuming
devices at the core level, so that async_schedule() is called for
each suspend and resume callback supposed to be executed
asynchronously.
For this purpose, introduce a new device flag, power.async_suspend,
used to mark the devices whose suspend and resume callbacks are to be
executed asynchronously (ie. in parallel with the main suspend/resume
thread and possibly in parallel with each other) and helper function
device_enable_async_suspend() allowing one to set power.async_suspend
for given device (power.async_suspend is unset by default for all
devices). For each device with the power.async_suspend flag set the
PM core will use async_schedule() to execute its suspend and resume
callbacks.
The async threads started for different devices as a result of
calling async_schedule() are synchronized with each other and with
the main suspend/resume thread with the help of completions, in the
following way:
(1) There is a completion, power.completion, for each device object.
(2) Each device's completion is reset before calling async_schedule()
for the device or, in the case of devices with the
power.async_suspend flags unset, before executing the device's
suspend and resume callbacks.
(3) During suspend, right before running the bus type, device type
and device class suspend callbacks for the device, the PM core
waits for the completions of all the device's children to be
completed.
(4) During resume, right before running the bus type, device type and
device class resume callbacks for the device, the PM core waits
for the completion of the device's parent to be completed.
(5) The PM core completes power.completion for each device right
after the bus type, device type and device class suspend (or
resume) callbacks executed for the device have returned.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-01-23 21:23:32 +00:00
|
|
|
async_synchronize_full();
|
2017-07-21 00:10:22 +00:00
|
|
|
dpm_show_time(starttime, state, 0, NULL);
|
2014-03-04 03:00:26 +00:00
|
|
|
|
|
|
|
cpufreq_resume();
|
2018-12-05 11:05:55 +00:00
|
|
|
devfreq_resume();
|
2014-06-06 12:40:17 +00:00
|
|
|
trace_suspend_resume(TPS("dpm_resume"), state.event, false);
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2009-08-20 18:25:52 +00:00
|
|
|
* device_complete - Complete a PM transition for given device.
|
|
|
|
* @dev: Device to handle.
|
|
|
|
* @state: PM transition of the system being carried out.
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
*/
|
2009-05-24 20:05:42 +00:00
|
|
|
static void device_complete(struct device *dev, pm_message_t state)
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
{
|
2011-12-17 23:34:13 +00:00
|
|
|
void (*callback)(struct device *) = NULL;
|
2017-06-12 15:19:32 +00:00
|
|
|
const char *info = NULL;
|
2011-12-17 23:34:13 +00:00
|
|
|
|
2012-08-05 23:46:39 +00:00
|
|
|
if (dev->power.syscore)
|
2021-10-22 12:58:23 +00:00
|
|
|
goto out;
|
2012-08-05 23:46:39 +00:00
|
|
|
|
2010-02-17 18:57:05 +00:00
|
|
|
device_lock(dev);
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
|
2011-06-22 23:52:55 +00:00
|
|
|
if (dev->pm_domain) {
|
2011-12-17 23:34:13 +00:00
|
|
|
info = "completing power domain ";
|
|
|
|
callback = dev->pm_domain->ops.complete;
|
PM: Make power domain callbacks take precedence over subsystem ones
Change the PM core's behavior related to power domains in such a way
that, if a power domain is defined for a given device, its callbacks
will be executed instead of and not in addition to the device
subsystem's PM callbacks.
The idea behind the initial implementation of power domains handling
by the PM core was that power domain callbacks would be executed in
addition to subsystem callbacks, so that it would be possible to
extend the subsystem callbacks by using power domains. It turns out,
however, that this wouldn't be really convenient in some important
situations.
For example, there are systems in which power can only be removed
from entire power domains. On those systems it is not desirable to
execute device drivers' PM callbacks until it is known that power is
going to be removed from the devices in question, which means that
they should be executed by power domain callbacks rather then by
subsystem (e.g. bus type) PM callbacks, because subsystems generally
have no information about what devices belong to which power domain.
Thus, for instance, if the bus type in question is the platform bus
type, its PM callbacks generally should not be called in addition to
power domain callbacks, because they run device drivers' callbacks
unconditionally if defined.
While in principle the default subsystem PM callbacks, or a subset of
them, may be replaced with different functions, it doesn't seem
correct to do so, because that would change the subsystem's behavior
with respect to all devices in the system, regardless of whether or
not they belong to any power domains. Thus, the only remaining
option is to make power domain callbacks take precedence over
subsystem callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Kevin Hilman <khilman@ti.com>
2011-04-28 22:35:50 +00:00
|
|
|
} else if (dev->type && dev->type->pm) {
|
2011-12-17 23:34:13 +00:00
|
|
|
info = "completing type ";
|
|
|
|
callback = dev->type->pm->complete;
|
PM: Make system-wide PM and runtime PM treat subsystems consistently
The code handling system-wide power transitions (eg. suspend-to-RAM)
can in theory execute callbacks provided by the device's bus type,
device type and class in each phase of the power transition. In
turn, the runtime PM core code only calls one of those callbacks at
a time, preferring bus type callbacks to device type or class
callbacks and device type callbacks to class callbacks.
It seems reasonable to make them both behave in the same way in that
respect. Moreover, even though a device may belong to two subsystems
(eg. bus type and device class) simultaneously, in practice power
management callbacks for system-wide power transitions are always
provided by only one of them (ie. if the bus type callbacks are
defined, the device class ones are not and vice versa). Thus it is
possible to modify the code handling system-wide power transitions
so that it follows the core runtime PM code (ie. treats the
subsystem callbacks as mutually exclusive).
On the other hand, the core runtime PM code will choose to execute,
for example, a runtime suspend callback provided by the device type
even if the bus type's struct dev_pm_ops object exists, but the
runtime_suspend pointer in it happens to be NULL. This is confusing,
because it may lead to the execution of callbacks from different
subsystems during different operations (eg. the bus type suspend
callback may be executed during runtime suspend of the device, while
the device type callback will be executed during system suspend).
Make all of the power management code treat subsystem callbacks in
a consistent way, such that:
(1) If the device's type is defined (eg. dev->type is not NULL)
and its pm pointer is not NULL, the callbacks from dev->type->pm
will be used.
(2) If dev->type is NULL or dev->type->pm is NULL, but the device's
class is defined (eg. dev->class is not NULL) and its pm pointer
is not NULL, the callbacks from dev->class->pm will be used.
(3) If dev->type is NULL or dev->type->pm is NULL and dev->class is
NULL or dev->class->pm is NULL, the callbacks from dev->bus->pm
will be used provided that both dev->bus and dev->bus->pm are
not NULL.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Kevin Hilman <khilman@ti.com>
Reasoning-sounds-sane-to: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-18 22:20:21 +00:00
|
|
|
} else if (dev->class && dev->class->pm) {
|
2011-12-17 23:34:13 +00:00
|
|
|
info = "completing class ";
|
|
|
|
callback = dev->class->pm->complete;
|
PM: Make system-wide PM and runtime PM treat subsystems consistently
The code handling system-wide power transitions (eg. suspend-to-RAM)
can in theory execute callbacks provided by the device's bus type,
device type and class in each phase of the power transition. In
turn, the runtime PM core code only calls one of those callbacks at
a time, preferring bus type callbacks to device type or class
callbacks and device type callbacks to class callbacks.
It seems reasonable to make them both behave in the same way in that
respect. Moreover, even though a device may belong to two subsystems
(eg. bus type and device class) simultaneously, in practice power
management callbacks for system-wide power transitions are always
provided by only one of them (ie. if the bus type callbacks are
defined, the device class ones are not and vice versa). Thus it is
possible to modify the code handling system-wide power transitions
so that it follows the core runtime PM code (ie. treats the
subsystem callbacks as mutually exclusive).
On the other hand, the core runtime PM code will choose to execute,
for example, a runtime suspend callback provided by the device type
even if the bus type's struct dev_pm_ops object exists, but the
runtime_suspend pointer in it happens to be NULL. This is confusing,
because it may lead to the execution of callbacks from different
subsystems during different operations (eg. the bus type suspend
callback may be executed during runtime suspend of the device, while
the device type callback will be executed during system suspend).
Make all of the power management code treat subsystem callbacks in
a consistent way, such that:
(1) If the device's type is defined (eg. dev->type is not NULL)
and its pm pointer is not NULL, the callbacks from dev->type->pm
will be used.
(2) If dev->type is NULL or dev->type->pm is NULL, but the device's
class is defined (eg. dev->class is not NULL) and its pm pointer
is not NULL, the callbacks from dev->class->pm will be used.
(3) If dev->type is NULL or dev->type->pm is NULL and dev->class is
NULL or dev->class->pm is NULL, the callbacks from dev->bus->pm
will be used provided that both dev->bus and dev->bus->pm are
not NULL.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Kevin Hilman <khilman@ti.com>
Reasoning-sounds-sane-to: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-18 22:20:21 +00:00
|
|
|
} else if (dev->bus && dev->bus->pm) {
|
2011-12-17 23:34:13 +00:00
|
|
|
info = "completing bus ";
|
|
|
|
callback = dev->bus->pm->complete;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!callback && dev->driver && dev->driver->pm) {
|
|
|
|
info = "completing driver ";
|
|
|
|
callback = dev->driver->pm->complete;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (callback) {
|
|
|
|
pm_dev_dbg(dev, state, info);
|
|
|
|
callback(dev);
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
}
|
|
|
|
|
2010-02-17 18:57:05 +00:00
|
|
|
device_unlock(dev);
|
2012-09-19 19:59:02 +00:00
|
|
|
|
2021-10-22 12:58:23 +00:00
|
|
|
out:
|
2013-04-12 09:41:06 +00:00
|
|
|
pm_runtime_put(dev);
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2009-08-20 18:25:52 +00:00
|
|
|
* dpm_complete - Complete a PM transition for all non-sysdev devices.
|
|
|
|
* @state: PM transition of the system being carried out.
|
2008-01-12 19:40:46 +00:00
|
|
|
*
|
2009-08-20 18:25:52 +00:00
|
|
|
* Execute the ->complete() callbacks for all devices whose PM status is not
|
|
|
|
* DPM_ON (this allows new devices to be registered).
|
2007-09-21 19:36:56 +00:00
|
|
|
*/
|
2011-05-17 21:26:00 +00:00
|
|
|
void dpm_complete(pm_message_t state)
|
2007-09-21 19:36:56 +00:00
|
|
|
{
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
struct list_head list;
|
|
|
|
|
2014-06-06 12:40:17 +00:00
|
|
|
trace_suspend_resume(TPS("dpm_complete"), state.event, true);
|
2011-05-17 21:26:00 +00:00
|
|
|
might_sleep();
|
|
|
|
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
INIT_LIST_HEAD(&list);
|
2007-09-21 19:36:56 +00:00
|
|
|
mutex_lock(&dpm_list_mtx);
|
2010-12-15 23:50:30 +00:00
|
|
|
while (!list_empty(&dpm_prepared_list)) {
|
|
|
|
struct device *dev = to_device(dpm_prepared_list.prev);
|
2007-09-21 19:36:56 +00:00
|
|
|
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
get_device(dev);
|
2011-06-18 18:22:23 +00:00
|
|
|
dev->power.is_prepared = false;
|
2010-12-15 23:51:08 +00:00
|
|
|
list_move(&dev->power.entry, &list);
|
PM: sleep: Avoid calling put_device() under dpm_list_mtx
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
[ 3290.969514] ======================================================
[ 3290.969517] WARNING: possible circular locking dependency detected
[ 3290.969519] 5.15.0+ #2420 Tainted: G S
[ 3290.969523] ------------------------------------------------------
[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
[ 3290.969554]
but task is already holding lock:
[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.969571]
which lock already depends on the new lock.
[ 3290.969573]
the existing dependency chain (in reverse order) is:
[ 3290.969575]
-> #3 (dpm_list_mtx){+.+.}-{3:3}:
[ 3290.969583] __mutex_lock+0x9d/0xa30
[ 3290.969591] device_pm_add+0x2e/0xe0
[ 3290.969597] device_add+0x4d5/0x8f0
[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969842] process_one_work+0x2aa/0x650
[ 3290.969851] worker_thread+0x39/0x400
[ 3290.969859] kthread+0x142/0x170
[ 3290.969865] ret_from_fork+0x22/0x30
[ 3290.969872]
-> #2 (&hdev->lock){+.+.}-{3:3}:
[ 3290.969881] __mutex_lock+0x9d/0xa30
[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969978] process_one_work+0x2aa/0x650
[ 3290.969985] worker_thread+0x39/0x400
[ 3290.969993] kthread+0x142/0x170
[ 3290.969999] ret_from_fork+0x22/0x30
[ 3290.970004]
-> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
[ 3290.970013] process_one_work+0x27d/0x650
[ 3290.970020] worker_thread+0x39/0x400
[ 3290.970028] kthread+0x142/0x170
[ 3290.970033] ret_from_fork+0x22/0x30
[ 3290.970038]
-> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
[ 3290.970047] __lock_acquire+0x15cb/0x1b50
[ 3290.970054] lock_acquire+0x26c/0x300
[ 3290.970059] flush_workqueue+0xae/0x4a0
[ 3290.970066] drain_workqueue+0xa1/0x130
[ 3290.970073] destroy_workqueue+0x34/0x1f0
[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970195] device_release+0x33/0x90
[ 3290.970201] kobject_release+0x63/0x160
[ 3290.970211] dpm_resume+0x164/0x3e0
[ 3290.970215] dpm_resume_end+0xd/0x20
[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970229] pm_suspend+0x26b/0x310
[ 3290.970236] state_store+0x42/0x90
[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970251] new_sync_write+0x125/0x1c0
[ 3290.970257] vfs_write+0x360/0x3c0
[ 3290.970263] ksys_write+0xa7/0xe0
[ 3290.970269] do_syscall_64+0x3a/0x80
[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970284]
other info that might help us debug this:
[ 3290.970285] Chain exists of:
(wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
[ 3290.970297] Possible unsafe locking scenario:
[ 3290.970299] CPU0 CPU1
[ 3290.970300] ---- ----
[ 3290.970302] lock(dpm_list_mtx);
[ 3290.970306] lock(&hdev->lock);
[ 3290.970310] lock(dpm_list_mtx);
[ 3290.970314] lock((wq_completion)hci0#2);
[ 3290.970319]
*** DEADLOCK ***
[ 3290.970321] 7 locks held by systemd-sleep/4553:
[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.970428]
stack backtrace:
[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
[ 3290.970441] Call Trace:
[ 3290.970446] dump_stack_lvl+0x44/0x57
[ 3290.970454] check_noncircular+0x105/0x120
[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
[ 3290.970474] __lock_acquire+0x15cb/0x1b50
[ 3290.970487] lock_acquire+0x26c/0x300
[ 3290.970493] ? flush_workqueue+0x87/0x4a0
[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
[ 3290.970519] flush_workqueue+0xae/0x4a0
[ 3290.970526] ? flush_workqueue+0x87/0x4a0
[ 3290.970544] ? drain_workqueue+0xa1/0x130
[ 3290.970552] drain_workqueue+0xa1/0x130
[ 3290.970561] destroy_workqueue+0x34/0x1f0
[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970687] device_release+0x33/0x90
[ 3290.970695] kobject_release+0x63/0x160
[ 3290.970705] dpm_resume+0x164/0x3e0
[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
[ 3290.970718] dpm_resume_end+0xd/0x20
[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970737] pm_suspend+0x26b/0x310
[ 3290.970746] state_store+0x42/0x90
[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970764] new_sync_write+0x125/0x1c0
[ 3290.970777] vfs_write+0x360/0x3c0
[ 3290.970785] ksys_write+0xa7/0xe0
[ 3290.970794] do_syscall_64+0x3a/0x80
[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970811] RIP: 0033:0x7f41b1328164
[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-11-04 17:26:26 +00:00
|
|
|
|
2010-12-15 23:51:08 +00:00
|
|
|
mutex_unlock(&dpm_list_mtx);
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
|
2015-05-28 19:55:53 +00:00
|
|
|
trace_device_pm_callback_start(dev, "", state.event);
|
2010-12-15 23:51:08 +00:00
|
|
|
device_complete(dev, state);
|
2015-05-28 19:55:53 +00:00
|
|
|
trace_device_pm_callback_end(dev, 0);
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
|
|
|
|
put_device(dev);
|
PM: sleep: Avoid calling put_device() under dpm_list_mtx
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
[ 3290.969514] ======================================================
[ 3290.969517] WARNING: possible circular locking dependency detected
[ 3290.969519] 5.15.0+ #2420 Tainted: G S
[ 3290.969523] ------------------------------------------------------
[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
[ 3290.969554]
but task is already holding lock:
[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.969571]
which lock already depends on the new lock.
[ 3290.969573]
the existing dependency chain (in reverse order) is:
[ 3290.969575]
-> #3 (dpm_list_mtx){+.+.}-{3:3}:
[ 3290.969583] __mutex_lock+0x9d/0xa30
[ 3290.969591] device_pm_add+0x2e/0xe0
[ 3290.969597] device_add+0x4d5/0x8f0
[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969842] process_one_work+0x2aa/0x650
[ 3290.969851] worker_thread+0x39/0x400
[ 3290.969859] kthread+0x142/0x170
[ 3290.969865] ret_from_fork+0x22/0x30
[ 3290.969872]
-> #2 (&hdev->lock){+.+.}-{3:3}:
[ 3290.969881] __mutex_lock+0x9d/0xa30
[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969978] process_one_work+0x2aa/0x650
[ 3290.969985] worker_thread+0x39/0x400
[ 3290.969993] kthread+0x142/0x170
[ 3290.969999] ret_from_fork+0x22/0x30
[ 3290.970004]
-> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
[ 3290.970013] process_one_work+0x27d/0x650
[ 3290.970020] worker_thread+0x39/0x400
[ 3290.970028] kthread+0x142/0x170
[ 3290.970033] ret_from_fork+0x22/0x30
[ 3290.970038]
-> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
[ 3290.970047] __lock_acquire+0x15cb/0x1b50
[ 3290.970054] lock_acquire+0x26c/0x300
[ 3290.970059] flush_workqueue+0xae/0x4a0
[ 3290.970066] drain_workqueue+0xa1/0x130
[ 3290.970073] destroy_workqueue+0x34/0x1f0
[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970195] device_release+0x33/0x90
[ 3290.970201] kobject_release+0x63/0x160
[ 3290.970211] dpm_resume+0x164/0x3e0
[ 3290.970215] dpm_resume_end+0xd/0x20
[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970229] pm_suspend+0x26b/0x310
[ 3290.970236] state_store+0x42/0x90
[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970251] new_sync_write+0x125/0x1c0
[ 3290.970257] vfs_write+0x360/0x3c0
[ 3290.970263] ksys_write+0xa7/0xe0
[ 3290.970269] do_syscall_64+0x3a/0x80
[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970284]
other info that might help us debug this:
[ 3290.970285] Chain exists of:
(wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
[ 3290.970297] Possible unsafe locking scenario:
[ 3290.970299] CPU0 CPU1
[ 3290.970300] ---- ----
[ 3290.970302] lock(dpm_list_mtx);
[ 3290.970306] lock(&hdev->lock);
[ 3290.970310] lock(dpm_list_mtx);
[ 3290.970314] lock((wq_completion)hci0#2);
[ 3290.970319]
*** DEADLOCK ***
[ 3290.970321] 7 locks held by systemd-sleep/4553:
[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.970428]
stack backtrace:
[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
[ 3290.970441] Call Trace:
[ 3290.970446] dump_stack_lvl+0x44/0x57
[ 3290.970454] check_noncircular+0x105/0x120
[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
[ 3290.970474] __lock_acquire+0x15cb/0x1b50
[ 3290.970487] lock_acquire+0x26c/0x300
[ 3290.970493] ? flush_workqueue+0x87/0x4a0
[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
[ 3290.970519] flush_workqueue+0xae/0x4a0
[ 3290.970526] ? flush_workqueue+0x87/0x4a0
[ 3290.970544] ? drain_workqueue+0xa1/0x130
[ 3290.970552] drain_workqueue+0xa1/0x130
[ 3290.970561] destroy_workqueue+0x34/0x1f0
[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970687] device_release+0x33/0x90
[ 3290.970695] kobject_release+0x63/0x160
[ 3290.970705] dpm_resume+0x164/0x3e0
[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
[ 3290.970718] dpm_resume_end+0xd/0x20
[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970737] pm_suspend+0x26b/0x310
[ 3290.970746] state_store+0x42/0x90
[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970764] new_sync_write+0x125/0x1c0
[ 3290.970777] vfs_write+0x360/0x3c0
[ 3290.970785] ksys_write+0xa7/0xe0
[ 3290.970794] do_syscall_64+0x3a/0x80
[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970811] RIP: 0033:0x7f41b1328164
[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-11-04 17:26:26 +00:00
|
|
|
|
|
|
|
mutex_lock(&dpm_list_mtx);
|
2007-09-21 19:36:56 +00:00
|
|
|
}
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
list_splice(&list, &dpm_list);
|
2007-09-21 19:36:56 +00:00
|
|
|
mutex_unlock(&dpm_list_mtx);
|
2015-11-10 09:42:34 +00:00
|
|
|
|
|
|
|
/* Allow device probing and trigger re-probing of deferred devices */
|
|
|
|
device_unblock_probing();
|
2014-06-06 12:40:17 +00:00
|
|
|
trace_suspend_resume(TPS("dpm_complete"), state.event, false);
|
2007-09-21 19:36:56 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2009-08-20 18:25:52 +00:00
|
|
|
* dpm_resume_end - Execute "resume" callbacks and complete system transition.
|
|
|
|
* @state: PM transition of the system being carried out.
|
2007-09-21 19:36:56 +00:00
|
|
|
*
|
2009-08-20 18:25:52 +00:00
|
|
|
* Execute "resume" callbacks for all devices and complete the PM transition of
|
|
|
|
* the system.
|
2007-09-21 19:36:56 +00:00
|
|
|
*/
|
2009-05-24 20:05:42 +00:00
|
|
|
void dpm_resume_end(pm_message_t state)
|
2007-09-21 19:36:56 +00:00
|
|
|
{
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
dpm_resume(state);
|
|
|
|
dpm_complete(state);
|
2007-09-21 19:36:56 +00:00
|
|
|
}
|
2009-05-24 20:05:42 +00:00
|
|
|
EXPORT_SYMBOL_GPL(dpm_resume_end);
|
2007-09-21 19:36:56 +00:00
|
|
|
|
|
|
|
|
|
|
|
/*------------------------- Suspend routines -------------------------*/
|
|
|
|
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
/**
|
2009-08-20 18:25:52 +00:00
|
|
|
* resume_event - Return a "resume" message for given "suspend" sleep state.
|
|
|
|
* @sleep_state: PM message representing a sleep state.
|
|
|
|
*
|
|
|
|
* Return a PM message representing the resume event corresponding to given
|
|
|
|
* sleep state.
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
*/
|
|
|
|
static pm_message_t resume_event(pm_message_t sleep_state)
|
2007-09-21 19:36:56 +00:00
|
|
|
{
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
switch (sleep_state.event) {
|
|
|
|
case PM_EVENT_SUSPEND:
|
|
|
|
return PMSG_RESUME;
|
|
|
|
case PM_EVENT_FREEZE:
|
|
|
|
case PM_EVENT_QUIESCE:
|
|
|
|
return PMSG_RECOVER;
|
|
|
|
case PM_EVENT_HIBERNATE:
|
|
|
|
return PMSG_RESTORE;
|
2007-09-21 19:36:56 +00:00
|
|
|
}
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
return PMSG_ON;
|
2007-09-21 19:36:56 +00:00
|
|
|
}
|
|
|
|
|
2017-11-18 14:31:49 +00:00
|
|
|
static void dpm_superior_set_must_resume(struct device *dev)
|
|
|
|
{
|
|
|
|
struct device_link *link;
|
|
|
|
int idx;
|
|
|
|
|
|
|
|
if (dev->parent)
|
|
|
|
dev->parent->power.must_resume = true;
|
|
|
|
|
|
|
|
idx = device_links_read_lock();
|
|
|
|
|
2020-03-03 19:41:30 +00:00
|
|
|
list_for_each_entry_rcu_locked(link, &dev->links.suppliers, c_node)
|
2017-11-18 14:31:49 +00:00
|
|
|
link->supplier->power.must_resume = true;
|
|
|
|
|
|
|
|
device_links_read_unlock(idx);
|
|
|
|
}
|
|
|
|
|
2007-09-21 19:36:56 +00:00
|
|
|
/**
|
2017-10-13 13:25:39 +00:00
|
|
|
* __device_suspend_noirq - Execute a "noirq suspend" callback for given device.
|
2009-08-20 18:25:52 +00:00
|
|
|
* @dev: Device to handle.
|
|
|
|
* @state: PM transition of the system being carried out.
|
2014-07-27 23:17:15 +00:00
|
|
|
* @async: If true, the device is being suspended asynchronously.
|
2008-01-12 19:40:46 +00:00
|
|
|
*
|
2009-08-20 18:25:52 +00:00
|
|
|
* The driver of @dev will not receive interrupts while this function is being
|
|
|
|
* executed.
|
2007-09-21 19:36:56 +00:00
|
|
|
*/
|
2014-02-18 02:28:47 +00:00
|
|
|
static int __device_suspend_noirq(struct device *dev, pm_message_t state, bool async)
|
2008-01-12 19:40:46 +00:00
|
|
|
{
|
2020-04-18 16:51:44 +00:00
|
|
|
pm_callback_t callback = NULL;
|
|
|
|
const char *info = NULL;
|
2014-02-18 02:28:47 +00:00
|
|
|
int error = 0;
|
|
|
|
|
2015-03-18 14:54:27 +00:00
|
|
|
TRACE_DEVICE(dev);
|
|
|
|
TRACE_SUSPEND(0);
|
|
|
|
|
Driver core patches for 4.10-rc1
Here's the new driver core patches for 4.10-rc1.
Big thing here is the nice addition of "functional dependencies" to the
driver core. The idea has been talked about for a very long time, great
job to Rafael for stepping up and implementing it. It's been tested for
longer than the 4.9-rc1 date, we held off on merging it earlier in order
to feel more comfortable about it.
Other than that, it's just a handful of small other patches, some good
cleanups to the mess that is the firmware class code, and we have a test
driver for the deferred probe logic.
All of these have been in linux-next for a while with no reported
issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCWFAvPQ8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ym3NgCgmhFeWEkp9SDt17YGGavmnzQUlBQAoJlUipJp
PHeQkq15ZWw3wWC9FEvM
=91M1
-----END PGP SIGNATURE-----
Merge tag 'driver-core-4.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core updates from Greg KH:
"Here's the new driver core patches for 4.10-rc1.
Big thing here is the nice addition of "functional dependencies" to
the driver core. The idea has been talked about for a very long time,
great job to Rafael for stepping up and implementing it. It's been
tested for longer than the 4.9-rc1 date, we held off on merging it
earlier in order to feel more comfortable about it.
Other than that, it's just a handful of small other patches, some good
cleanups to the mess that is the firmware class code, and we have a
test driver for the deferred probe logic.
All of these have been in linux-next for a while with no reported
issues"
* tag 'driver-core-4.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (30 commits)
firmware: Correct handling of fw_state_wait() return value
driver core: Silence device links sphinx warning
firmware: remove warning at documentation generation time
drivers: base: dma-mapping: Fix typo in dmam_alloc_non_coherent comments
driver core: test_async: fix up typo found by 0-day
firmware: move fw_state_is_done() into UHM section
firmware: do not use fw_lock for fw_state protection
firmware: drop bit ops in favor of simple state machine
firmware: refactor loading status
firmware: fix usermode helper fallback loading
driver core: firmware_class: convert to use class_groups
driver core: devcoredump: convert to use class_groups
driver core: class: add class_groups support
kernfs: Declare two local data structures static
driver-core: fix platform_no_drv_owner.cocci warnings
drivers/base/memory.c: Remove unused 'first_page' variable
driver core: add CLASS_ATTR_WO()
drivers: base: cacheinfo: support DT overrides for cache properties
drivers: base: cacheinfo: add pr_fmt logging
drivers: base: cacheinfo: fix boot error message when acpi is enabled
...
2016-12-13 19:42:18 +00:00
|
|
|
dpm_wait_for_subordinate(dev, async);
|
PM / sleep: don't suspend parent when async child suspend_{noirq, late} fails
Consider two devices, A and B, where B is a child of A, and B utilizes
asynchronous suspend (it does not matter whether A is sync or async). If
B fails to suspend_noirq() or suspend_late(), or is interrupted by a
wakeup (pm_wakeup_pending()), then it aborts and sets the async_error
variable. However, device A does not (immediately) check the async_error
variable; it may continue to run its own suspend_noirq()/suspend_late()
callback. This is bad.
We can resolve this problem by doing our error and wakeup checking
(particularly, for the async_error flag) after waiting for children to
suspend, instead of before. This also helps align the logic for the noirq and
late suspend cases with the logic in __device_suspend().
It's easy to observe this erroneous behavior by, for example, forcing a
device to sleep a bit in its suspend_noirq() (to ensure the parent is
waiting for the child to complete), then return an error, and watch the
parent suspend_noirq() still get called. (Or similarly, fake a wakeup
event at the right (or is it wrong?) time.)
Fixes: de377b397272 (PM / sleep: Asynchronous threads for suspend_late)
Fixes: 28b6fd6e3779 (PM / sleep: Asynchronous threads for suspend_noirq)
Reported-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-11-10 01:21:08 +00:00
|
|
|
|
2014-02-18 02:28:47 +00:00
|
|
|
if (async_error)
|
|
|
|
goto Complete;
|
|
|
|
|
PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily
Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
resume all runtime-suspended devices during system suspend, mostly
because those devices may need to be reprogrammed due to different
wakeup settings for system sleep and for runtime PM.
For some devices, though, it's OK to remain in runtime suspend
throughout a complete system suspend/resume cycle (if the device was in
runtime suspend at the start of the cycle). We would like to do this
whenever possible, to avoid the overhead of extra power-up and power-down
events.
However, problems may arise because the device's descendants may require
it to be at full power at various points during the cycle. Therefore the
most straightforward way to do this safely is if the device and all its
descendants can remain runtime suspended until the complete stage of
system resume.
To this end, introduce a new device PM flag, power.direct_complete
and modify the PM core to use that flag as follows.
If the ->prepare() callback of a device returns a positive number,
the PM core will regard that as an indication that it may leave the
device runtime-suspended. It will then check if the system power
transition in progress is a suspend (and not hibernation in particular)
and if the device is, indeed, runtime-suspended. In that case, the PM
core will set the device's power.direct_complete flag. Otherwise it
will clear power.direct_complete for the device and it also will later
clear it for the device's parent (if there's one).
Next, the PM core will not invoke the ->suspend() ->suspend_late(),
->suspend_irq(), ->resume_irq(), ->resume_early(), or ->resume()
callbacks for all devices having power.direct_complete set. It
will invoke their ->complete() callbacks, however, and those
callbacks are then responsible for resuming the devices as
appropriate, if necessary. For example, in some cases they may
need to queue up runtime resume requests for the devices using
pm_request_resume().
Changelog partly based on an Alan Stern's description of the idea
(http://marc.info/?l=linux-pm&m=139940466625569&w=2).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
2014-05-16 00:46:50 +00:00
|
|
|
if (dev->power.syscore || dev->power.direct_complete)
|
2014-02-18 02:28:47 +00:00
|
|
|
goto Complete;
|
|
|
|
|
2020-04-18 16:51:44 +00:00
|
|
|
if (dev->pm_domain) {
|
|
|
|
info = "noirq power domain ";
|
|
|
|
callback = pm_noirq_op(&dev->pm_domain->ops, state);
|
|
|
|
} else if (dev->type && dev->type->pm) {
|
|
|
|
info = "noirq type ";
|
|
|
|
callback = pm_noirq_op(dev->type->pm, state);
|
|
|
|
} else if (dev->class && dev->class->pm) {
|
|
|
|
info = "noirq class ";
|
|
|
|
callback = pm_noirq_op(dev->class->pm, state);
|
|
|
|
} else if (dev->bus && dev->bus->pm) {
|
|
|
|
info = "noirq bus ";
|
|
|
|
callback = pm_noirq_op(dev->bus->pm, state);
|
|
|
|
}
|
PM / core: Direct DPM_FLAG_SMART_SUSPEND optimization
Make the PM core avoid invoking the "late" and "noirq" system-wide
suspend (or analogous) callbacks provided by device drivers directly
for devices with DPM_FLAG_SMART_SUSPEND set that are in runtime
suspend during the "late" and "noirq" phases of system-wide suspend
(or analogous) transitions. That is only done for devices without
any middle-layer "late" and "noirq" suspend callbacks (to avoid
confusing the middle layer if there is one).
The underlying observation is that runtime PM is disabled for devices
during the "late" and "noirq" system-wide suspend phases, so if they
remain in runtime suspend from the "late" phase forward, it doesn't
make sense to invoke the "late" and "noirq" callbacks provided by
the drivers for them (arguably, the device is already suspended and
in the right state). Thus, if the remaining driver suspend callbacks
are to be invoked directly by the core, they can be skipped.
This change really makes it possible for, say, platform device
drivers to re-use runtime PM suspend and resume callbacks by
pointing ->suspend_late and ->resume_early, respectively (and
possibly the analogous hibernation-related callback pointers too),
to them without adding any extra "is the device already suspended?"
type of checks to the callback routines, as long as they will be
invoked directly by the core.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-10 00:00:45 +00:00
|
|
|
if (callback)
|
|
|
|
goto Run;
|
2011-02-16 20:53:17 +00:00
|
|
|
|
2020-04-18 16:52:48 +00:00
|
|
|
if (dev_pm_skip_suspend(dev))
|
PM / core: Direct DPM_FLAG_SMART_SUSPEND optimization
Make the PM core avoid invoking the "late" and "noirq" system-wide
suspend (or analogous) callbacks provided by device drivers directly
for devices with DPM_FLAG_SMART_SUSPEND set that are in runtime
suspend during the "late" and "noirq" phases of system-wide suspend
(or analogous) transitions. That is only done for devices without
any middle-layer "late" and "noirq" suspend callbacks (to avoid
confusing the middle layer if there is one).
The underlying observation is that runtime PM is disabled for devices
during the "late" and "noirq" system-wide suspend phases, so if they
remain in runtime suspend from the "late" phase forward, it doesn't
make sense to invoke the "late" and "noirq" callbacks provided by
the drivers for them (arguably, the device is already suspended and
in the right state). Thus, if the remaining driver suspend callbacks
are to be invoked directly by the core, they can be skipped.
This change really makes it possible for, say, platform device
drivers to re-use runtime PM suspend and resume callbacks by
pointing ->suspend_late and ->resume_early, respectively (and
possibly the analogous hibernation-related callback pointers too),
to them without adding any extra "is the device already suspended?"
type of checks to the callback routines, as long as they will be
invoked directly by the core.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-10 00:00:45 +00:00
|
|
|
goto Skip;
|
|
|
|
|
|
|
|
if (dev->driver && dev->driver->pm) {
|
2012-01-29 19:38:29 +00:00
|
|
|
info = "noirq driver ";
|
2011-12-17 23:34:13 +00:00
|
|
|
callback = pm_noirq_op(dev->driver->pm, state);
|
|
|
|
}
|
|
|
|
|
PM / core: Direct DPM_FLAG_SMART_SUSPEND optimization
Make the PM core avoid invoking the "late" and "noirq" system-wide
suspend (or analogous) callbacks provided by device drivers directly
for devices with DPM_FLAG_SMART_SUSPEND set that are in runtime
suspend during the "late" and "noirq" phases of system-wide suspend
(or analogous) transitions. That is only done for devices without
any middle-layer "late" and "noirq" suspend callbacks (to avoid
confusing the middle layer if there is one).
The underlying observation is that runtime PM is disabled for devices
during the "late" and "noirq" system-wide suspend phases, so if they
remain in runtime suspend from the "late" phase forward, it doesn't
make sense to invoke the "late" and "noirq" callbacks provided by
the drivers for them (arguably, the device is already suspended and
in the right state). Thus, if the remaining driver suspend callbacks
are to be invoked directly by the core, they can be skipped.
This change really makes it possible for, say, platform device
drivers to re-use runtime PM suspend and resume callbacks by
pointing ->suspend_late and ->resume_early, respectively (and
possibly the analogous hibernation-related callback pointers too),
to them without adding any extra "is the device already suspended?"
type of checks to the callback routines, as long as they will be
invoked directly by the core.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-10 00:00:45 +00:00
|
|
|
Run:
|
2014-02-18 02:28:44 +00:00
|
|
|
error = dpm_run_callback(callback, dev, state, info);
|
2017-11-18 14:31:49 +00:00
|
|
|
if (error) {
|
2014-02-18 02:28:47 +00:00
|
|
|
async_error = error;
|
2017-11-18 14:31:49 +00:00
|
|
|
goto Complete;
|
|
|
|
}
|
|
|
|
|
PM / core: Direct DPM_FLAG_SMART_SUSPEND optimization
Make the PM core avoid invoking the "late" and "noirq" system-wide
suspend (or analogous) callbacks provided by device drivers directly
for devices with DPM_FLAG_SMART_SUSPEND set that are in runtime
suspend during the "late" and "noirq" phases of system-wide suspend
(or analogous) transitions. That is only done for devices without
any middle-layer "late" and "noirq" suspend callbacks (to avoid
confusing the middle layer if there is one).
The underlying observation is that runtime PM is disabled for devices
during the "late" and "noirq" system-wide suspend phases, so if they
remain in runtime suspend from the "late" phase forward, it doesn't
make sense to invoke the "late" and "noirq" callbacks provided by
the drivers for them (arguably, the device is already suspended and
in the right state). Thus, if the remaining driver suspend callbacks
are to be invoked directly by the core, they can be skipped.
This change really makes it possible for, say, platform device
drivers to re-use runtime PM suspend and resume callbacks by
pointing ->suspend_late and ->resume_early, respectively (and
possibly the analogous hibernation-related callback pointers too),
to them without adding any extra "is the device already suspended?"
type of checks to the callback routines, as long as they will be
invoked directly by the core.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-10 00:00:45 +00:00
|
|
|
Skip:
|
2017-11-18 14:31:49 +00:00
|
|
|
dev->power.is_noirq_suspended = true;
|
|
|
|
|
2020-04-18 16:29:30 +00:00
|
|
|
/*
|
|
|
|
* Skipping the resume of devices that were in use right before the
|
|
|
|
* system suspend (as indicated by their PM-runtime usage counters)
|
|
|
|
* would be suboptimal. Also resume them if doing that is not allowed
|
|
|
|
* to be skipped.
|
|
|
|
*/
|
|
|
|
if (atomic_read(&dev->power.usage_count) > 1 ||
|
2020-04-18 16:53:20 +00:00
|
|
|
!(dev_pm_test_driver_flags(dev, DPM_FLAG_MAY_SKIP_RESUME) &&
|
2020-04-18 16:29:30 +00:00
|
|
|
dev->power.may_skip_resume))
|
2017-11-18 14:31:49 +00:00
|
|
|
dev->power.must_resume = true;
|
|
|
|
|
|
|
|
if (dev->power.must_resume)
|
|
|
|
dpm_superior_set_must_resume(dev);
|
2014-02-18 02:28:44 +00:00
|
|
|
|
2014-02-18 02:28:47 +00:00
|
|
|
Complete:
|
|
|
|
complete_all(&dev->power.completion);
|
2015-03-18 14:54:27 +00:00
|
|
|
TRACE_SUSPEND(error);
|
2014-02-18 02:28:44 +00:00
|
|
|
return error;
|
2008-01-12 19:40:46 +00:00
|
|
|
}
|
|
|
|
|
2014-02-18 02:28:47 +00:00
|
|
|
static void async_suspend_noirq(void *data, async_cookie_t cookie)
|
|
|
|
{
|
|
|
|
struct device *dev = (struct device *)data;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
error = __device_suspend_noirq(dev, pm_transition, true);
|
|
|
|
if (error) {
|
|
|
|
dpm_save_failed_dev(dev_name(dev));
|
|
|
|
pm_dev_err(dev, pm_transition, " async", error);
|
|
|
|
}
|
|
|
|
|
|
|
|
put_device(dev);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int device_suspend_noirq(struct device *dev)
|
|
|
|
{
|
2019-03-16 04:59:25 +00:00
|
|
|
if (dpm_async_fn(dev, async_suspend_noirq))
|
2014-02-18 02:28:47 +00:00
|
|
|
return 0;
|
2019-03-16 04:59:25 +00:00
|
|
|
|
2014-02-18 02:28:47 +00:00
|
|
|
return __device_suspend_noirq(dev, pm_transition, false);
|
|
|
|
}
|
|
|
|
|
2019-07-15 21:52:18 +00:00
|
|
|
static int dpm_noirq_suspend_devices(pm_message_t state)
|
2008-01-12 19:40:46 +00:00
|
|
|
{
|
2009-12-18 00:57:47 +00:00
|
|
|
ktime_t starttime = ktime_get();
|
2008-01-12 19:40:46 +00:00
|
|
|
int error = 0;
|
|
|
|
|
2014-06-06 12:40:17 +00:00
|
|
|
trace_suspend_resume(TPS("dpm_suspend_noirq"), state.event, true);
|
2009-05-24 19:15:07 +00:00
|
|
|
mutex_lock(&dpm_list_mtx);
|
2014-02-18 02:28:47 +00:00
|
|
|
pm_transition = state;
|
|
|
|
async_error = 0;
|
|
|
|
|
2012-01-29 19:38:29 +00:00
|
|
|
while (!list_empty(&dpm_late_early_list)) {
|
|
|
|
struct device *dev = to_device(dpm_late_early_list.prev);
|
2010-11-11 00:50:53 +00:00
|
|
|
|
|
|
|
get_device(dev);
|
|
|
|
mutex_unlock(&dpm_list_mtx);
|
|
|
|
|
2014-02-18 02:28:47 +00:00
|
|
|
error = device_suspend_noirq(dev);
|
2010-11-11 00:50:53 +00:00
|
|
|
|
|
|
|
mutex_lock(&dpm_list_mtx);
|
PM: sleep: Avoid calling put_device() under dpm_list_mtx
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
[ 3290.969514] ======================================================
[ 3290.969517] WARNING: possible circular locking dependency detected
[ 3290.969519] 5.15.0+ #2420 Tainted: G S
[ 3290.969523] ------------------------------------------------------
[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
[ 3290.969554]
but task is already holding lock:
[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.969571]
which lock already depends on the new lock.
[ 3290.969573]
the existing dependency chain (in reverse order) is:
[ 3290.969575]
-> #3 (dpm_list_mtx){+.+.}-{3:3}:
[ 3290.969583] __mutex_lock+0x9d/0xa30
[ 3290.969591] device_pm_add+0x2e/0xe0
[ 3290.969597] device_add+0x4d5/0x8f0
[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969842] process_one_work+0x2aa/0x650
[ 3290.969851] worker_thread+0x39/0x400
[ 3290.969859] kthread+0x142/0x170
[ 3290.969865] ret_from_fork+0x22/0x30
[ 3290.969872]
-> #2 (&hdev->lock){+.+.}-{3:3}:
[ 3290.969881] __mutex_lock+0x9d/0xa30
[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969978] process_one_work+0x2aa/0x650
[ 3290.969985] worker_thread+0x39/0x400
[ 3290.969993] kthread+0x142/0x170
[ 3290.969999] ret_from_fork+0x22/0x30
[ 3290.970004]
-> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
[ 3290.970013] process_one_work+0x27d/0x650
[ 3290.970020] worker_thread+0x39/0x400
[ 3290.970028] kthread+0x142/0x170
[ 3290.970033] ret_from_fork+0x22/0x30
[ 3290.970038]
-> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
[ 3290.970047] __lock_acquire+0x15cb/0x1b50
[ 3290.970054] lock_acquire+0x26c/0x300
[ 3290.970059] flush_workqueue+0xae/0x4a0
[ 3290.970066] drain_workqueue+0xa1/0x130
[ 3290.970073] destroy_workqueue+0x34/0x1f0
[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970195] device_release+0x33/0x90
[ 3290.970201] kobject_release+0x63/0x160
[ 3290.970211] dpm_resume+0x164/0x3e0
[ 3290.970215] dpm_resume_end+0xd/0x20
[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970229] pm_suspend+0x26b/0x310
[ 3290.970236] state_store+0x42/0x90
[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970251] new_sync_write+0x125/0x1c0
[ 3290.970257] vfs_write+0x360/0x3c0
[ 3290.970263] ksys_write+0xa7/0xe0
[ 3290.970269] do_syscall_64+0x3a/0x80
[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970284]
other info that might help us debug this:
[ 3290.970285] Chain exists of:
(wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
[ 3290.970297] Possible unsafe locking scenario:
[ 3290.970299] CPU0 CPU1
[ 3290.970300] ---- ----
[ 3290.970302] lock(dpm_list_mtx);
[ 3290.970306] lock(&hdev->lock);
[ 3290.970310] lock(dpm_list_mtx);
[ 3290.970314] lock((wq_completion)hci0#2);
[ 3290.970319]
*** DEADLOCK ***
[ 3290.970321] 7 locks held by systemd-sleep/4553:
[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.970428]
stack backtrace:
[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
[ 3290.970441] Call Trace:
[ 3290.970446] dump_stack_lvl+0x44/0x57
[ 3290.970454] check_noncircular+0x105/0x120
[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
[ 3290.970474] __lock_acquire+0x15cb/0x1b50
[ 3290.970487] lock_acquire+0x26c/0x300
[ 3290.970493] ? flush_workqueue+0x87/0x4a0
[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
[ 3290.970519] flush_workqueue+0xae/0x4a0
[ 3290.970526] ? flush_workqueue+0x87/0x4a0
[ 3290.970544] ? drain_workqueue+0xa1/0x130
[ 3290.970552] drain_workqueue+0xa1/0x130
[ 3290.970561] destroy_workqueue+0x34/0x1f0
[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970687] device_release+0x33/0x90
[ 3290.970695] kobject_release+0x63/0x160
[ 3290.970705] dpm_resume+0x164/0x3e0
[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
[ 3290.970718] dpm_resume_end+0xd/0x20
[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970737] pm_suspend+0x26b/0x310
[ 3290.970746] state_store+0x42/0x90
[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970764] new_sync_write+0x125/0x1c0
[ 3290.970777] vfs_write+0x360/0x3c0
[ 3290.970785] ksys_write+0xa7/0xe0
[ 3290.970794] do_syscall_64+0x3a/0x80
[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970811] RIP: 0033:0x7f41b1328164
[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-11-04 17:26:26 +00:00
|
|
|
|
2008-01-12 19:40:46 +00:00
|
|
|
if (error) {
|
2012-01-29 19:38:29 +00:00
|
|
|
pm_dev_err(dev, state, " noirq", error);
|
PM / Suspend: Add statistics debugfs file for suspend to RAM
Record S3 failure time about each reason and the latest two failed
devices' names in S3 progress.
We can check it through 'suspend_stats' entry in debugfs.
The motivation of the patch:
We are enabling power features on Medfield. Comparing with PC/notebook,
a mobile enters/exits suspend-2-ram (we call it s3 on Medfield) far
more frequently. If it can't enter suspend-2-ram in time, the power
might be used up soon.
We often find sometimes, a device suspend fails. Then, system retries
s3 over and over again. As display is off, testers and developers
don't know what happens.
Some testers and developers complain they don't know if system
tries suspend-2-ram, and what device fails to suspend. They need
such info for a quick check. The patch adds suspend_stats under
debugfs for users to check suspend to RAM statistics quickly.
If not using this patch, we have other methods to get info about
what device fails. One is to turn on CONFIG_PM_DEBUG, but users
would get too much info and testers need recompile the system.
In addition, dynamic debug is another good tool to dump debug info.
But it still doesn't match our utilization scenario closely.
1) user need write a user space parser to process the syslog output;
2) Our testing scenario is we leave the mobile for at least hours.
Then, check its status. No serial console available during the
testing. One is because console would be suspended, and the other
is serial console connecting with spi or HSU devices would consume
power. These devices are powered off at suspend-2-ram.
Signed-off-by: ShuoX Liu <shuox.liu@intel.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-08-10 21:01:26 +00:00
|
|
|
dpm_save_failed_dev(dev_name(dev));
|
PM: sleep: Avoid calling put_device() under dpm_list_mtx
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
[ 3290.969514] ======================================================
[ 3290.969517] WARNING: possible circular locking dependency detected
[ 3290.969519] 5.15.0+ #2420 Tainted: G S
[ 3290.969523] ------------------------------------------------------
[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
[ 3290.969554]
but task is already holding lock:
[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.969571]
which lock already depends on the new lock.
[ 3290.969573]
the existing dependency chain (in reverse order) is:
[ 3290.969575]
-> #3 (dpm_list_mtx){+.+.}-{3:3}:
[ 3290.969583] __mutex_lock+0x9d/0xa30
[ 3290.969591] device_pm_add+0x2e/0xe0
[ 3290.969597] device_add+0x4d5/0x8f0
[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969842] process_one_work+0x2aa/0x650
[ 3290.969851] worker_thread+0x39/0x400
[ 3290.969859] kthread+0x142/0x170
[ 3290.969865] ret_from_fork+0x22/0x30
[ 3290.969872]
-> #2 (&hdev->lock){+.+.}-{3:3}:
[ 3290.969881] __mutex_lock+0x9d/0xa30
[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969978] process_one_work+0x2aa/0x650
[ 3290.969985] worker_thread+0x39/0x400
[ 3290.969993] kthread+0x142/0x170
[ 3290.969999] ret_from_fork+0x22/0x30
[ 3290.970004]
-> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
[ 3290.970013] process_one_work+0x27d/0x650
[ 3290.970020] worker_thread+0x39/0x400
[ 3290.970028] kthread+0x142/0x170
[ 3290.970033] ret_from_fork+0x22/0x30
[ 3290.970038]
-> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
[ 3290.970047] __lock_acquire+0x15cb/0x1b50
[ 3290.970054] lock_acquire+0x26c/0x300
[ 3290.970059] flush_workqueue+0xae/0x4a0
[ 3290.970066] drain_workqueue+0xa1/0x130
[ 3290.970073] destroy_workqueue+0x34/0x1f0
[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970195] device_release+0x33/0x90
[ 3290.970201] kobject_release+0x63/0x160
[ 3290.970211] dpm_resume+0x164/0x3e0
[ 3290.970215] dpm_resume_end+0xd/0x20
[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970229] pm_suspend+0x26b/0x310
[ 3290.970236] state_store+0x42/0x90
[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970251] new_sync_write+0x125/0x1c0
[ 3290.970257] vfs_write+0x360/0x3c0
[ 3290.970263] ksys_write+0xa7/0xe0
[ 3290.970269] do_syscall_64+0x3a/0x80
[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970284]
other info that might help us debug this:
[ 3290.970285] Chain exists of:
(wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
[ 3290.970297] Possible unsafe locking scenario:
[ 3290.970299] CPU0 CPU1
[ 3290.970300] ---- ----
[ 3290.970302] lock(dpm_list_mtx);
[ 3290.970306] lock(&hdev->lock);
[ 3290.970310] lock(dpm_list_mtx);
[ 3290.970314] lock((wq_completion)hci0#2);
[ 3290.970319]
*** DEADLOCK ***
[ 3290.970321] 7 locks held by systemd-sleep/4553:
[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.970428]
stack backtrace:
[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
[ 3290.970441] Call Trace:
[ 3290.970446] dump_stack_lvl+0x44/0x57
[ 3290.970454] check_noncircular+0x105/0x120
[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
[ 3290.970474] __lock_acquire+0x15cb/0x1b50
[ 3290.970487] lock_acquire+0x26c/0x300
[ 3290.970493] ? flush_workqueue+0x87/0x4a0
[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
[ 3290.970519] flush_workqueue+0xae/0x4a0
[ 3290.970526] ? flush_workqueue+0x87/0x4a0
[ 3290.970544] ? drain_workqueue+0xa1/0x130
[ 3290.970552] drain_workqueue+0xa1/0x130
[ 3290.970561] destroy_workqueue+0x34/0x1f0
[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970687] device_release+0x33/0x90
[ 3290.970695] kobject_release+0x63/0x160
[ 3290.970705] dpm_resume+0x164/0x3e0
[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
[ 3290.970718] dpm_resume_end+0xd/0x20
[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970737] pm_suspend+0x26b/0x310
[ 3290.970746] state_store+0x42/0x90
[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970764] new_sync_write+0x125/0x1c0
[ 3290.970777] vfs_write+0x360/0x3c0
[ 3290.970785] ksys_write+0xa7/0xe0
[ 3290.970794] do_syscall_64+0x3a/0x80
[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970811] RIP: 0033:0x7f41b1328164
[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-11-04 17:26:26 +00:00
|
|
|
} else if (!list_empty(&dev->power.entry)) {
|
2010-12-15 23:50:30 +00:00
|
|
|
list_move(&dev->power.entry, &dpm_noirq_list);
|
PM: sleep: Avoid calling put_device() under dpm_list_mtx
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
[ 3290.969514] ======================================================
[ 3290.969517] WARNING: possible circular locking dependency detected
[ 3290.969519] 5.15.0+ #2420 Tainted: G S
[ 3290.969523] ------------------------------------------------------
[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
[ 3290.969554]
but task is already holding lock:
[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.969571]
which lock already depends on the new lock.
[ 3290.969573]
the existing dependency chain (in reverse order) is:
[ 3290.969575]
-> #3 (dpm_list_mtx){+.+.}-{3:3}:
[ 3290.969583] __mutex_lock+0x9d/0xa30
[ 3290.969591] device_pm_add+0x2e/0xe0
[ 3290.969597] device_add+0x4d5/0x8f0
[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969842] process_one_work+0x2aa/0x650
[ 3290.969851] worker_thread+0x39/0x400
[ 3290.969859] kthread+0x142/0x170
[ 3290.969865] ret_from_fork+0x22/0x30
[ 3290.969872]
-> #2 (&hdev->lock){+.+.}-{3:3}:
[ 3290.969881] __mutex_lock+0x9d/0xa30
[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969978] process_one_work+0x2aa/0x650
[ 3290.969985] worker_thread+0x39/0x400
[ 3290.969993] kthread+0x142/0x170
[ 3290.969999] ret_from_fork+0x22/0x30
[ 3290.970004]
-> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
[ 3290.970013] process_one_work+0x27d/0x650
[ 3290.970020] worker_thread+0x39/0x400
[ 3290.970028] kthread+0x142/0x170
[ 3290.970033] ret_from_fork+0x22/0x30
[ 3290.970038]
-> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
[ 3290.970047] __lock_acquire+0x15cb/0x1b50
[ 3290.970054] lock_acquire+0x26c/0x300
[ 3290.970059] flush_workqueue+0xae/0x4a0
[ 3290.970066] drain_workqueue+0xa1/0x130
[ 3290.970073] destroy_workqueue+0x34/0x1f0
[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970195] device_release+0x33/0x90
[ 3290.970201] kobject_release+0x63/0x160
[ 3290.970211] dpm_resume+0x164/0x3e0
[ 3290.970215] dpm_resume_end+0xd/0x20
[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970229] pm_suspend+0x26b/0x310
[ 3290.970236] state_store+0x42/0x90
[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970251] new_sync_write+0x125/0x1c0
[ 3290.970257] vfs_write+0x360/0x3c0
[ 3290.970263] ksys_write+0xa7/0xe0
[ 3290.970269] do_syscall_64+0x3a/0x80
[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970284]
other info that might help us debug this:
[ 3290.970285] Chain exists of:
(wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
[ 3290.970297] Possible unsafe locking scenario:
[ 3290.970299] CPU0 CPU1
[ 3290.970300] ---- ----
[ 3290.970302] lock(dpm_list_mtx);
[ 3290.970306] lock(&hdev->lock);
[ 3290.970310] lock(dpm_list_mtx);
[ 3290.970314] lock((wq_completion)hci0#2);
[ 3290.970319]
*** DEADLOCK ***
[ 3290.970321] 7 locks held by systemd-sleep/4553:
[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.970428]
stack backtrace:
[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
[ 3290.970441] Call Trace:
[ 3290.970446] dump_stack_lvl+0x44/0x57
[ 3290.970454] check_noncircular+0x105/0x120
[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
[ 3290.970474] __lock_acquire+0x15cb/0x1b50
[ 3290.970487] lock_acquire+0x26c/0x300
[ 3290.970493] ? flush_workqueue+0x87/0x4a0
[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
[ 3290.970519] flush_workqueue+0xae/0x4a0
[ 3290.970526] ? flush_workqueue+0x87/0x4a0
[ 3290.970544] ? drain_workqueue+0xa1/0x130
[ 3290.970552] drain_workqueue+0xa1/0x130
[ 3290.970561] destroy_workqueue+0x34/0x1f0
[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970687] device_release+0x33/0x90
[ 3290.970695] kobject_release+0x63/0x160
[ 3290.970705] dpm_resume+0x164/0x3e0
[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
[ 3290.970718] dpm_resume_end+0xd/0x20
[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970737] pm_suspend+0x26b/0x310
[ 3290.970746] state_store+0x42/0x90
[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970764] new_sync_write+0x125/0x1c0
[ 3290.970777] vfs_write+0x360/0x3c0
[ 3290.970785] ksys_write+0xa7/0xe0
[ 3290.970794] do_syscall_64+0x3a/0x80
[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970811] RIP: 0033:0x7f41b1328164
[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-11-04 17:26:26 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
mutex_unlock(&dpm_list_mtx);
|
|
|
|
|
2010-11-11 00:50:53 +00:00
|
|
|
put_device(dev);
|
2012-04-29 20:52:19 +00:00
|
|
|
|
PM: sleep: Avoid calling put_device() under dpm_list_mtx
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
[ 3290.969514] ======================================================
[ 3290.969517] WARNING: possible circular locking dependency detected
[ 3290.969519] 5.15.0+ #2420 Tainted: G S
[ 3290.969523] ------------------------------------------------------
[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
[ 3290.969554]
but task is already holding lock:
[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.969571]
which lock already depends on the new lock.
[ 3290.969573]
the existing dependency chain (in reverse order) is:
[ 3290.969575]
-> #3 (dpm_list_mtx){+.+.}-{3:3}:
[ 3290.969583] __mutex_lock+0x9d/0xa30
[ 3290.969591] device_pm_add+0x2e/0xe0
[ 3290.969597] device_add+0x4d5/0x8f0
[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969842] process_one_work+0x2aa/0x650
[ 3290.969851] worker_thread+0x39/0x400
[ 3290.969859] kthread+0x142/0x170
[ 3290.969865] ret_from_fork+0x22/0x30
[ 3290.969872]
-> #2 (&hdev->lock){+.+.}-{3:3}:
[ 3290.969881] __mutex_lock+0x9d/0xa30
[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969978] process_one_work+0x2aa/0x650
[ 3290.969985] worker_thread+0x39/0x400
[ 3290.969993] kthread+0x142/0x170
[ 3290.969999] ret_from_fork+0x22/0x30
[ 3290.970004]
-> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
[ 3290.970013] process_one_work+0x27d/0x650
[ 3290.970020] worker_thread+0x39/0x400
[ 3290.970028] kthread+0x142/0x170
[ 3290.970033] ret_from_fork+0x22/0x30
[ 3290.970038]
-> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
[ 3290.970047] __lock_acquire+0x15cb/0x1b50
[ 3290.970054] lock_acquire+0x26c/0x300
[ 3290.970059] flush_workqueue+0xae/0x4a0
[ 3290.970066] drain_workqueue+0xa1/0x130
[ 3290.970073] destroy_workqueue+0x34/0x1f0
[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970195] device_release+0x33/0x90
[ 3290.970201] kobject_release+0x63/0x160
[ 3290.970211] dpm_resume+0x164/0x3e0
[ 3290.970215] dpm_resume_end+0xd/0x20
[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970229] pm_suspend+0x26b/0x310
[ 3290.970236] state_store+0x42/0x90
[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970251] new_sync_write+0x125/0x1c0
[ 3290.970257] vfs_write+0x360/0x3c0
[ 3290.970263] ksys_write+0xa7/0xe0
[ 3290.970269] do_syscall_64+0x3a/0x80
[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970284]
other info that might help us debug this:
[ 3290.970285] Chain exists of:
(wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
[ 3290.970297] Possible unsafe locking scenario:
[ 3290.970299] CPU0 CPU1
[ 3290.970300] ---- ----
[ 3290.970302] lock(dpm_list_mtx);
[ 3290.970306] lock(&hdev->lock);
[ 3290.970310] lock(dpm_list_mtx);
[ 3290.970314] lock((wq_completion)hci0#2);
[ 3290.970319]
*** DEADLOCK ***
[ 3290.970321] 7 locks held by systemd-sleep/4553:
[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.970428]
stack backtrace:
[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
[ 3290.970441] Call Trace:
[ 3290.970446] dump_stack_lvl+0x44/0x57
[ 3290.970454] check_noncircular+0x105/0x120
[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
[ 3290.970474] __lock_acquire+0x15cb/0x1b50
[ 3290.970487] lock_acquire+0x26c/0x300
[ 3290.970493] ? flush_workqueue+0x87/0x4a0
[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
[ 3290.970519] flush_workqueue+0xae/0x4a0
[ 3290.970526] ? flush_workqueue+0x87/0x4a0
[ 3290.970544] ? drain_workqueue+0xa1/0x130
[ 3290.970552] drain_workqueue+0xa1/0x130
[ 3290.970561] destroy_workqueue+0x34/0x1f0
[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970687] device_release+0x33/0x90
[ 3290.970695] kobject_release+0x63/0x160
[ 3290.970705] dpm_resume+0x164/0x3e0
[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
[ 3290.970718] dpm_resume_end+0xd/0x20
[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970737] pm_suspend+0x26b/0x310
[ 3290.970746] state_store+0x42/0x90
[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970764] new_sync_write+0x125/0x1c0
[ 3290.970777] vfs_write+0x360/0x3c0
[ 3290.970785] ksys_write+0xa7/0xe0
[ 3290.970794] do_syscall_64+0x3a/0x80
[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970811] RIP: 0033:0x7f41b1328164
[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-11-04 17:26:26 +00:00
|
|
|
mutex_lock(&dpm_list_mtx);
|
|
|
|
|
|
|
|
if (error || async_error)
|
2012-04-29 20:52:19 +00:00
|
|
|
break;
|
2008-01-12 19:40:46 +00:00
|
|
|
}
|
2009-05-24 19:15:07 +00:00
|
|
|
mutex_unlock(&dpm_list_mtx);
|
2014-02-18 02:28:47 +00:00
|
|
|
async_synchronize_full();
|
|
|
|
if (!error)
|
|
|
|
error = async_error;
|
|
|
|
|
|
|
|
if (error) {
|
|
|
|
suspend_stats.failed_suspend_noirq++;
|
|
|
|
dpm_save_failed_step(SUSPEND_SUSPEND_NOIRQ);
|
|
|
|
}
|
2017-07-21 00:10:22 +00:00
|
|
|
dpm_show_time(starttime, state, error, "noirq");
|
2014-06-06 12:40:17 +00:00
|
|
|
trace_suspend_resume(TPS("dpm_suspend_noirq"), state.event, false);
|
2012-01-29 19:38:29 +00:00
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
2017-07-21 00:09:22 +00:00
|
|
|
/**
|
|
|
|
* dpm_suspend_noirq - Execute "noirq suspend" callbacks for all devices.
|
|
|
|
* @state: PM transition of the system being carried out.
|
|
|
|
*
|
|
|
|
* Prevent device drivers' interrupt handlers from being called and invoke
|
|
|
|
* "noirq" suspend callbacks for all non-sysdev devices.
|
|
|
|
*/
|
|
|
|
int dpm_suspend_noirq(pm_message_t state)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2019-07-15 21:52:18 +00:00
|
|
|
device_wakeup_arm_wake_irqs();
|
|
|
|
suspend_device_irqs();
|
|
|
|
|
2017-07-21 00:09:22 +00:00
|
|
|
ret = dpm_noirq_suspend_devices(state);
|
|
|
|
if (ret)
|
|
|
|
dpm_resume_noirq(resume_event(state));
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2018-01-09 09:03:40 +00:00
|
|
|
static void dpm_propagate_wakeup_to_parent(struct device *dev)
|
|
|
|
{
|
|
|
|
struct device *parent = dev->parent;
|
|
|
|
|
|
|
|
if (!parent)
|
|
|
|
return;
|
|
|
|
|
|
|
|
spin_lock_irq(&parent->power.lock);
|
|
|
|
|
2020-11-19 07:25:39 +00:00
|
|
|
if (device_wakeup_path(dev) && !parent->power.ignore_children)
|
2018-01-09 09:03:40 +00:00
|
|
|
parent->power.wakeup_path = true;
|
|
|
|
|
|
|
|
spin_unlock_irq(&parent->power.lock);
|
|
|
|
}
|
|
|
|
|
2012-01-29 19:38:29 +00:00
|
|
|
/**
|
2017-10-13 13:25:39 +00:00
|
|
|
* __device_suspend_late - Execute a "late suspend" callback for given device.
|
2012-01-29 19:38:29 +00:00
|
|
|
* @dev: Device to handle.
|
|
|
|
* @state: PM transition of the system being carried out.
|
2014-07-27 23:17:15 +00:00
|
|
|
* @async: If true, the device is being suspended asynchronously.
|
2012-01-29 19:38:29 +00:00
|
|
|
*
|
|
|
|
* Runtime PM is disabled for @dev while this function is being executed.
|
|
|
|
*/
|
2014-02-18 02:28:48 +00:00
|
|
|
static int __device_suspend_late(struct device *dev, pm_message_t state, bool async)
|
2012-01-29 19:38:29 +00:00
|
|
|
{
|
2020-04-18 16:51:44 +00:00
|
|
|
pm_callback_t callback = NULL;
|
|
|
|
const char *info = NULL;
|
2014-02-18 02:28:48 +00:00
|
|
|
int error = 0;
|
2012-01-29 19:38:29 +00:00
|
|
|
|
2015-03-18 14:54:27 +00:00
|
|
|
TRACE_DEVICE(dev);
|
|
|
|
TRACE_SUSPEND(0);
|
|
|
|
|
2012-12-22 22:59:01 +00:00
|
|
|
__pm_runtime_disable(dev, false);
|
|
|
|
|
Driver core patches for 4.10-rc1
Here's the new driver core patches for 4.10-rc1.
Big thing here is the nice addition of "functional dependencies" to the
driver core. The idea has been talked about for a very long time, great
job to Rafael for stepping up and implementing it. It's been tested for
longer than the 4.9-rc1 date, we held off on merging it earlier in order
to feel more comfortable about it.
Other than that, it's just a handful of small other patches, some good
cleanups to the mess that is the firmware class code, and we have a test
driver for the deferred probe logic.
All of these have been in linux-next for a while with no reported
issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCWFAvPQ8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ym3NgCgmhFeWEkp9SDt17YGGavmnzQUlBQAoJlUipJp
PHeQkq15ZWw3wWC9FEvM
=91M1
-----END PGP SIGNATURE-----
Merge tag 'driver-core-4.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core updates from Greg KH:
"Here's the new driver core patches for 4.10-rc1.
Big thing here is the nice addition of "functional dependencies" to
the driver core. The idea has been talked about for a very long time,
great job to Rafael for stepping up and implementing it. It's been
tested for longer than the 4.9-rc1 date, we held off on merging it
earlier in order to feel more comfortable about it.
Other than that, it's just a handful of small other patches, some good
cleanups to the mess that is the firmware class code, and we have a
test driver for the deferred probe logic.
All of these have been in linux-next for a while with no reported
issues"
* tag 'driver-core-4.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (30 commits)
firmware: Correct handling of fw_state_wait() return value
driver core: Silence device links sphinx warning
firmware: remove warning at documentation generation time
drivers: base: dma-mapping: Fix typo in dmam_alloc_non_coherent comments
driver core: test_async: fix up typo found by 0-day
firmware: move fw_state_is_done() into UHM section
firmware: do not use fw_lock for fw_state protection
firmware: drop bit ops in favor of simple state machine
firmware: refactor loading status
firmware: fix usermode helper fallback loading
driver core: firmware_class: convert to use class_groups
driver core: devcoredump: convert to use class_groups
driver core: class: add class_groups support
kernfs: Declare two local data structures static
driver-core: fix platform_no_drv_owner.cocci warnings
drivers/base/memory.c: Remove unused 'first_page' variable
driver core: add CLASS_ATTR_WO()
drivers: base: cacheinfo: support DT overrides for cache properties
drivers: base: cacheinfo: add pr_fmt logging
drivers: base: cacheinfo: fix boot error message when acpi is enabled
...
2016-12-13 19:42:18 +00:00
|
|
|
dpm_wait_for_subordinate(dev, async);
|
PM / sleep: don't suspend parent when async child suspend_{noirq, late} fails
Consider two devices, A and B, where B is a child of A, and B utilizes
asynchronous suspend (it does not matter whether A is sync or async). If
B fails to suspend_noirq() or suspend_late(), or is interrupted by a
wakeup (pm_wakeup_pending()), then it aborts and sets the async_error
variable. However, device A does not (immediately) check the async_error
variable; it may continue to run its own suspend_noirq()/suspend_late()
callback. This is bad.
We can resolve this problem by doing our error and wakeup checking
(particularly, for the async_error flag) after waiting for children to
suspend, instead of before. This also helps align the logic for the noirq and
late suspend cases with the logic in __device_suspend().
It's easy to observe this erroneous behavior by, for example, forcing a
device to sleep a bit in its suspend_noirq() (to ensure the parent is
waiting for the child to complete), then return an error, and watch the
parent suspend_noirq() still get called. (Or similarly, fake a wakeup
event at the right (or is it wrong?) time.)
Fixes: de377b397272 (PM / sleep: Asynchronous threads for suspend_late)
Fixes: 28b6fd6e3779 (PM / sleep: Asynchronous threads for suspend_noirq)
Reported-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-11-10 01:21:08 +00:00
|
|
|
|
2014-02-18 02:28:48 +00:00
|
|
|
if (async_error)
|
|
|
|
goto Complete;
|
|
|
|
|
|
|
|
if (pm_wakeup_pending()) {
|
|
|
|
async_error = -EBUSY;
|
|
|
|
goto Complete;
|
|
|
|
}
|
|
|
|
|
PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily
Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
resume all runtime-suspended devices during system suspend, mostly
because those devices may need to be reprogrammed due to different
wakeup settings for system sleep and for runtime PM.
For some devices, though, it's OK to remain in runtime suspend
throughout a complete system suspend/resume cycle (if the device was in
runtime suspend at the start of the cycle). We would like to do this
whenever possible, to avoid the overhead of extra power-up and power-down
events.
However, problems may arise because the device's descendants may require
it to be at full power at various points during the cycle. Therefore the
most straightforward way to do this safely is if the device and all its
descendants can remain runtime suspended until the complete stage of
system resume.
To this end, introduce a new device PM flag, power.direct_complete
and modify the PM core to use that flag as follows.
If the ->prepare() callback of a device returns a positive number,
the PM core will regard that as an indication that it may leave the
device runtime-suspended. It will then check if the system power
transition in progress is a suspend (and not hibernation in particular)
and if the device is, indeed, runtime-suspended. In that case, the PM
core will set the device's power.direct_complete flag. Otherwise it
will clear power.direct_complete for the device and it also will later
clear it for the device's parent (if there's one).
Next, the PM core will not invoke the ->suspend() ->suspend_late(),
->suspend_irq(), ->resume_irq(), ->resume_early(), or ->resume()
callbacks for all devices having power.direct_complete set. It
will invoke their ->complete() callbacks, however, and those
callbacks are then responsible for resuming the devices as
appropriate, if necessary. For example, in some cases they may
need to queue up runtime resume requests for the devices using
pm_request_resume().
Changelog partly based on an Alan Stern's description of the idea
(http://marc.info/?l=linux-pm&m=139940466625569&w=2).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
2014-05-16 00:46:50 +00:00
|
|
|
if (dev->power.syscore || dev->power.direct_complete)
|
2014-02-18 02:28:48 +00:00
|
|
|
goto Complete;
|
|
|
|
|
2020-04-18 16:51:44 +00:00
|
|
|
if (dev->pm_domain) {
|
|
|
|
info = "late power domain ";
|
|
|
|
callback = pm_late_early_op(&dev->pm_domain->ops, state);
|
|
|
|
} else if (dev->type && dev->type->pm) {
|
|
|
|
info = "late type ";
|
|
|
|
callback = pm_late_early_op(dev->type->pm, state);
|
|
|
|
} else if (dev->class && dev->class->pm) {
|
|
|
|
info = "late class ";
|
|
|
|
callback = pm_late_early_op(dev->class->pm, state);
|
|
|
|
} else if (dev->bus && dev->bus->pm) {
|
|
|
|
info = "late bus ";
|
|
|
|
callback = pm_late_early_op(dev->bus->pm, state);
|
|
|
|
}
|
PM / core: Direct DPM_FLAG_SMART_SUSPEND optimization
Make the PM core avoid invoking the "late" and "noirq" system-wide
suspend (or analogous) callbacks provided by device drivers directly
for devices with DPM_FLAG_SMART_SUSPEND set that are in runtime
suspend during the "late" and "noirq" phases of system-wide suspend
(or analogous) transitions. That is only done for devices without
any middle-layer "late" and "noirq" suspend callbacks (to avoid
confusing the middle layer if there is one).
The underlying observation is that runtime PM is disabled for devices
during the "late" and "noirq" system-wide suspend phases, so if they
remain in runtime suspend from the "late" phase forward, it doesn't
make sense to invoke the "late" and "noirq" callbacks provided by
the drivers for them (arguably, the device is already suspended and
in the right state). Thus, if the remaining driver suspend callbacks
are to be invoked directly by the core, they can be skipped.
This change really makes it possible for, say, platform device
drivers to re-use runtime PM suspend and resume callbacks by
pointing ->suspend_late and ->resume_early, respectively (and
possibly the analogous hibernation-related callback pointers too),
to them without adding any extra "is the device already suspended?"
type of checks to the callback routines, as long as they will be
invoked directly by the core.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-10 00:00:45 +00:00
|
|
|
if (callback)
|
|
|
|
goto Run;
|
2012-01-29 19:38:29 +00:00
|
|
|
|
2020-04-18 16:52:48 +00:00
|
|
|
if (dev_pm_skip_suspend(dev))
|
PM / core: Direct DPM_FLAG_SMART_SUSPEND optimization
Make the PM core avoid invoking the "late" and "noirq" system-wide
suspend (or analogous) callbacks provided by device drivers directly
for devices with DPM_FLAG_SMART_SUSPEND set that are in runtime
suspend during the "late" and "noirq" phases of system-wide suspend
(or analogous) transitions. That is only done for devices without
any middle-layer "late" and "noirq" suspend callbacks (to avoid
confusing the middle layer if there is one).
The underlying observation is that runtime PM is disabled for devices
during the "late" and "noirq" system-wide suspend phases, so if they
remain in runtime suspend from the "late" phase forward, it doesn't
make sense to invoke the "late" and "noirq" callbacks provided by
the drivers for them (arguably, the device is already suspended and
in the right state). Thus, if the remaining driver suspend callbacks
are to be invoked directly by the core, they can be skipped.
This change really makes it possible for, say, platform device
drivers to re-use runtime PM suspend and resume callbacks by
pointing ->suspend_late and ->resume_early, respectively (and
possibly the analogous hibernation-related callback pointers too),
to them without adding any extra "is the device already suspended?"
type of checks to the callback routines, as long as they will be
invoked directly by the core.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-10 00:00:45 +00:00
|
|
|
goto Skip;
|
|
|
|
|
|
|
|
if (dev->driver && dev->driver->pm) {
|
2012-01-29 19:38:29 +00:00
|
|
|
info = "late driver ";
|
|
|
|
callback = pm_late_early_op(dev->driver->pm, state);
|
|
|
|
}
|
|
|
|
|
PM / core: Direct DPM_FLAG_SMART_SUSPEND optimization
Make the PM core avoid invoking the "late" and "noirq" system-wide
suspend (or analogous) callbacks provided by device drivers directly
for devices with DPM_FLAG_SMART_SUSPEND set that are in runtime
suspend during the "late" and "noirq" phases of system-wide suspend
(or analogous) transitions. That is only done for devices without
any middle-layer "late" and "noirq" suspend callbacks (to avoid
confusing the middle layer if there is one).
The underlying observation is that runtime PM is disabled for devices
during the "late" and "noirq" system-wide suspend phases, so if they
remain in runtime suspend from the "late" phase forward, it doesn't
make sense to invoke the "late" and "noirq" callbacks provided by
the drivers for them (arguably, the device is already suspended and
in the right state). Thus, if the remaining driver suspend callbacks
are to be invoked directly by the core, they can be skipped.
This change really makes it possible for, say, platform device
drivers to re-use runtime PM suspend and resume callbacks by
pointing ->suspend_late and ->resume_early, respectively (and
possibly the analogous hibernation-related callback pointers too),
to them without adding any extra "is the device already suspended?"
type of checks to the callback routines, as long as they will be
invoked directly by the core.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-10 00:00:45 +00:00
|
|
|
Run:
|
2014-02-18 02:28:44 +00:00
|
|
|
error = dpm_run_callback(callback, dev, state, info);
|
PM / core: Direct DPM_FLAG_SMART_SUSPEND optimization
Make the PM core avoid invoking the "late" and "noirq" system-wide
suspend (or analogous) callbacks provided by device drivers directly
for devices with DPM_FLAG_SMART_SUSPEND set that are in runtime
suspend during the "late" and "noirq" phases of system-wide suspend
(or analogous) transitions. That is only done for devices without
any middle-layer "late" and "noirq" suspend callbacks (to avoid
confusing the middle layer if there is one).
The underlying observation is that runtime PM is disabled for devices
during the "late" and "noirq" system-wide suspend phases, so if they
remain in runtime suspend from the "late" phase forward, it doesn't
make sense to invoke the "late" and "noirq" callbacks provided by
the drivers for them (arguably, the device is already suspended and
in the right state). Thus, if the remaining driver suspend callbacks
are to be invoked directly by the core, they can be skipped.
This change really makes it possible for, say, platform device
drivers to re-use runtime PM suspend and resume callbacks by
pointing ->suspend_late and ->resume_early, respectively (and
possibly the analogous hibernation-related callback pointers too),
to them without adding any extra "is the device already suspended?"
type of checks to the callback routines, as long as they will be
invoked directly by the core.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-10 00:00:45 +00:00
|
|
|
if (error) {
|
2014-02-18 02:28:48 +00:00
|
|
|
async_error = error;
|
PM / core: Direct DPM_FLAG_SMART_SUSPEND optimization
Make the PM core avoid invoking the "late" and "noirq" system-wide
suspend (or analogous) callbacks provided by device drivers directly
for devices with DPM_FLAG_SMART_SUSPEND set that are in runtime
suspend during the "late" and "noirq" phases of system-wide suspend
(or analogous) transitions. That is only done for devices without
any middle-layer "late" and "noirq" suspend callbacks (to avoid
confusing the middle layer if there is one).
The underlying observation is that runtime PM is disabled for devices
during the "late" and "noirq" system-wide suspend phases, so if they
remain in runtime suspend from the "late" phase forward, it doesn't
make sense to invoke the "late" and "noirq" callbacks provided by
the drivers for them (arguably, the device is already suspended and
in the right state). Thus, if the remaining driver suspend callbacks
are to be invoked directly by the core, they can be skipped.
This change really makes it possible for, say, platform device
drivers to re-use runtime PM suspend and resume callbacks by
pointing ->suspend_late and ->resume_early, respectively (and
possibly the analogous hibernation-related callback pointers too),
to them without adding any extra "is the device already suspended?"
type of checks to the callback routines, as long as they will be
invoked directly by the core.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-10 00:00:45 +00:00
|
|
|
goto Complete;
|
|
|
|
}
|
2018-01-09 09:03:40 +00:00
|
|
|
dpm_propagate_wakeup_to_parent(dev);
|
PM / core: Direct DPM_FLAG_SMART_SUSPEND optimization
Make the PM core avoid invoking the "late" and "noirq" system-wide
suspend (or analogous) callbacks provided by device drivers directly
for devices with DPM_FLAG_SMART_SUSPEND set that are in runtime
suspend during the "late" and "noirq" phases of system-wide suspend
(or analogous) transitions. That is only done for devices without
any middle-layer "late" and "noirq" suspend callbacks (to avoid
confusing the middle layer if there is one).
The underlying observation is that runtime PM is disabled for devices
during the "late" and "noirq" system-wide suspend phases, so if they
remain in runtime suspend from the "late" phase forward, it doesn't
make sense to invoke the "late" and "noirq" callbacks provided by
the drivers for them (arguably, the device is already suspended and
in the right state). Thus, if the remaining driver suspend callbacks
are to be invoked directly by the core, they can be skipped.
This change really makes it possible for, say, platform device
drivers to re-use runtime PM suspend and resume callbacks by
pointing ->suspend_late and ->resume_early, respectively (and
possibly the analogous hibernation-related callback pointers too),
to them without adding any extra "is the device already suspended?"
type of checks to the callback routines, as long as they will be
invoked directly by the core.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-10 00:00:45 +00:00
|
|
|
|
|
|
|
Skip:
|
|
|
|
dev->power.is_late_suspended = true;
|
2014-02-18 02:28:44 +00:00
|
|
|
|
2014-02-18 02:28:48 +00:00
|
|
|
Complete:
|
2015-03-18 14:54:27 +00:00
|
|
|
TRACE_SUSPEND(error);
|
2014-02-18 02:28:48 +00:00
|
|
|
complete_all(&dev->power.completion);
|
2014-02-18 02:28:44 +00:00
|
|
|
return error;
|
2012-01-29 19:38:29 +00:00
|
|
|
}
|
|
|
|
|
2014-02-18 02:28:48 +00:00
|
|
|
static void async_suspend_late(void *data, async_cookie_t cookie)
|
|
|
|
{
|
|
|
|
struct device *dev = (struct device *)data;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
error = __device_suspend_late(dev, pm_transition, true);
|
|
|
|
if (error) {
|
|
|
|
dpm_save_failed_dev(dev_name(dev));
|
|
|
|
pm_dev_err(dev, pm_transition, " async", error);
|
|
|
|
}
|
|
|
|
put_device(dev);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int device_suspend_late(struct device *dev)
|
|
|
|
{
|
2019-03-16 04:59:25 +00:00
|
|
|
if (dpm_async_fn(dev, async_suspend_late))
|
2014-02-18 02:28:48 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
return __device_suspend_late(dev, pm_transition, false);
|
|
|
|
}
|
|
|
|
|
2012-01-29 19:38:29 +00:00
|
|
|
/**
|
|
|
|
* dpm_suspend_late - Execute "late suspend" callbacks for all devices.
|
|
|
|
* @state: PM transition of the system being carried out.
|
|
|
|
*/
|
2014-09-30 00:21:34 +00:00
|
|
|
int dpm_suspend_late(pm_message_t state)
|
2012-01-29 19:38:29 +00:00
|
|
|
{
|
|
|
|
ktime_t starttime = ktime_get();
|
|
|
|
int error = 0;
|
|
|
|
|
2014-06-06 12:40:17 +00:00
|
|
|
trace_suspend_resume(TPS("dpm_suspend_late"), state.event, true);
|
PM: sleep: Fix runtime PM based cpuidle support
In the cpuidle-psci case, runtime PM in combination with the generic PM
domain (genpd), may be used when entering/exiting a shared idlestate. More
precisely, genpd relies on runtime PM to be enabled for the attached device
(in this case it belongs to a CPU), to properly manage the reference
counting of its PM domain.
This works fine most of the time, but during system suspend in
dpm_suspend_late(), the PM core disables runtime PM for all devices. Beyond
this point, calls to pm_runtime_get_sync() to runtime resume a device may
fail and therefore it could also mess up the reference counting in genpd.
To fix this problem, let's call wake_up_all_idle_cpus() in
dpm_suspend_late(), prior to disabling runtime PM. In this way a device
that belongs to a CPU, becomes runtime resumed through cpuidle-psci and
stays like that, because the runtime PM usage count has been bumped in
device_prepare().
Diagnosed-by: Maulik Shah <mkshah@codeaurora.org>
Suggested-by: Rafael J. Wysocki <rafael@kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-10-29 12:38:55 +00:00
|
|
|
wake_up_all_idle_cpus();
|
2012-01-29 19:38:29 +00:00
|
|
|
mutex_lock(&dpm_list_mtx);
|
2014-02-18 02:28:48 +00:00
|
|
|
pm_transition = state;
|
|
|
|
async_error = 0;
|
|
|
|
|
2012-01-29 19:38:29 +00:00
|
|
|
while (!list_empty(&dpm_suspended_list)) {
|
|
|
|
struct device *dev = to_device(dpm_suspended_list.prev);
|
|
|
|
|
|
|
|
get_device(dev);
|
PM: sleep: Avoid calling put_device() under dpm_list_mtx
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
[ 3290.969514] ======================================================
[ 3290.969517] WARNING: possible circular locking dependency detected
[ 3290.969519] 5.15.0+ #2420 Tainted: G S
[ 3290.969523] ------------------------------------------------------
[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
[ 3290.969554]
but task is already holding lock:
[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.969571]
which lock already depends on the new lock.
[ 3290.969573]
the existing dependency chain (in reverse order) is:
[ 3290.969575]
-> #3 (dpm_list_mtx){+.+.}-{3:3}:
[ 3290.969583] __mutex_lock+0x9d/0xa30
[ 3290.969591] device_pm_add+0x2e/0xe0
[ 3290.969597] device_add+0x4d5/0x8f0
[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969842] process_one_work+0x2aa/0x650
[ 3290.969851] worker_thread+0x39/0x400
[ 3290.969859] kthread+0x142/0x170
[ 3290.969865] ret_from_fork+0x22/0x30
[ 3290.969872]
-> #2 (&hdev->lock){+.+.}-{3:3}:
[ 3290.969881] __mutex_lock+0x9d/0xa30
[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969978] process_one_work+0x2aa/0x650
[ 3290.969985] worker_thread+0x39/0x400
[ 3290.969993] kthread+0x142/0x170
[ 3290.969999] ret_from_fork+0x22/0x30
[ 3290.970004]
-> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
[ 3290.970013] process_one_work+0x27d/0x650
[ 3290.970020] worker_thread+0x39/0x400
[ 3290.970028] kthread+0x142/0x170
[ 3290.970033] ret_from_fork+0x22/0x30
[ 3290.970038]
-> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
[ 3290.970047] __lock_acquire+0x15cb/0x1b50
[ 3290.970054] lock_acquire+0x26c/0x300
[ 3290.970059] flush_workqueue+0xae/0x4a0
[ 3290.970066] drain_workqueue+0xa1/0x130
[ 3290.970073] destroy_workqueue+0x34/0x1f0
[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970195] device_release+0x33/0x90
[ 3290.970201] kobject_release+0x63/0x160
[ 3290.970211] dpm_resume+0x164/0x3e0
[ 3290.970215] dpm_resume_end+0xd/0x20
[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970229] pm_suspend+0x26b/0x310
[ 3290.970236] state_store+0x42/0x90
[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970251] new_sync_write+0x125/0x1c0
[ 3290.970257] vfs_write+0x360/0x3c0
[ 3290.970263] ksys_write+0xa7/0xe0
[ 3290.970269] do_syscall_64+0x3a/0x80
[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970284]
other info that might help us debug this:
[ 3290.970285] Chain exists of:
(wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
[ 3290.970297] Possible unsafe locking scenario:
[ 3290.970299] CPU0 CPU1
[ 3290.970300] ---- ----
[ 3290.970302] lock(dpm_list_mtx);
[ 3290.970306] lock(&hdev->lock);
[ 3290.970310] lock(dpm_list_mtx);
[ 3290.970314] lock((wq_completion)hci0#2);
[ 3290.970319]
*** DEADLOCK ***
[ 3290.970321] 7 locks held by systemd-sleep/4553:
[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.970428]
stack backtrace:
[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
[ 3290.970441] Call Trace:
[ 3290.970446] dump_stack_lvl+0x44/0x57
[ 3290.970454] check_noncircular+0x105/0x120
[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
[ 3290.970474] __lock_acquire+0x15cb/0x1b50
[ 3290.970487] lock_acquire+0x26c/0x300
[ 3290.970493] ? flush_workqueue+0x87/0x4a0
[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
[ 3290.970519] flush_workqueue+0xae/0x4a0
[ 3290.970526] ? flush_workqueue+0x87/0x4a0
[ 3290.970544] ? drain_workqueue+0xa1/0x130
[ 3290.970552] drain_workqueue+0xa1/0x130
[ 3290.970561] destroy_workqueue+0x34/0x1f0
[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970687] device_release+0x33/0x90
[ 3290.970695] kobject_release+0x63/0x160
[ 3290.970705] dpm_resume+0x164/0x3e0
[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
[ 3290.970718] dpm_resume_end+0xd/0x20
[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970737] pm_suspend+0x26b/0x310
[ 3290.970746] state_store+0x42/0x90
[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970764] new_sync_write+0x125/0x1c0
[ 3290.970777] vfs_write+0x360/0x3c0
[ 3290.970785] ksys_write+0xa7/0xe0
[ 3290.970794] do_syscall_64+0x3a/0x80
[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970811] RIP: 0033:0x7f41b1328164
[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-11-04 17:26:26 +00:00
|
|
|
|
2012-01-29 19:38:29 +00:00
|
|
|
mutex_unlock(&dpm_list_mtx);
|
|
|
|
|
2014-02-18 02:28:48 +00:00
|
|
|
error = device_suspend_late(dev);
|
2012-01-29 19:38:29 +00:00
|
|
|
|
|
|
|
mutex_lock(&dpm_list_mtx);
|
PM: sleep: Avoid calling put_device() under dpm_list_mtx
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
[ 3290.969514] ======================================================
[ 3290.969517] WARNING: possible circular locking dependency detected
[ 3290.969519] 5.15.0+ #2420 Tainted: G S
[ 3290.969523] ------------------------------------------------------
[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
[ 3290.969554]
but task is already holding lock:
[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.969571]
which lock already depends on the new lock.
[ 3290.969573]
the existing dependency chain (in reverse order) is:
[ 3290.969575]
-> #3 (dpm_list_mtx){+.+.}-{3:3}:
[ 3290.969583] __mutex_lock+0x9d/0xa30
[ 3290.969591] device_pm_add+0x2e/0xe0
[ 3290.969597] device_add+0x4d5/0x8f0
[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969842] process_one_work+0x2aa/0x650
[ 3290.969851] worker_thread+0x39/0x400
[ 3290.969859] kthread+0x142/0x170
[ 3290.969865] ret_from_fork+0x22/0x30
[ 3290.969872]
-> #2 (&hdev->lock){+.+.}-{3:3}:
[ 3290.969881] __mutex_lock+0x9d/0xa30
[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969978] process_one_work+0x2aa/0x650
[ 3290.969985] worker_thread+0x39/0x400
[ 3290.969993] kthread+0x142/0x170
[ 3290.969999] ret_from_fork+0x22/0x30
[ 3290.970004]
-> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
[ 3290.970013] process_one_work+0x27d/0x650
[ 3290.970020] worker_thread+0x39/0x400
[ 3290.970028] kthread+0x142/0x170
[ 3290.970033] ret_from_fork+0x22/0x30
[ 3290.970038]
-> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
[ 3290.970047] __lock_acquire+0x15cb/0x1b50
[ 3290.970054] lock_acquire+0x26c/0x300
[ 3290.970059] flush_workqueue+0xae/0x4a0
[ 3290.970066] drain_workqueue+0xa1/0x130
[ 3290.970073] destroy_workqueue+0x34/0x1f0
[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970195] device_release+0x33/0x90
[ 3290.970201] kobject_release+0x63/0x160
[ 3290.970211] dpm_resume+0x164/0x3e0
[ 3290.970215] dpm_resume_end+0xd/0x20
[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970229] pm_suspend+0x26b/0x310
[ 3290.970236] state_store+0x42/0x90
[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970251] new_sync_write+0x125/0x1c0
[ 3290.970257] vfs_write+0x360/0x3c0
[ 3290.970263] ksys_write+0xa7/0xe0
[ 3290.970269] do_syscall_64+0x3a/0x80
[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970284]
other info that might help us debug this:
[ 3290.970285] Chain exists of:
(wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
[ 3290.970297] Possible unsafe locking scenario:
[ 3290.970299] CPU0 CPU1
[ 3290.970300] ---- ----
[ 3290.970302] lock(dpm_list_mtx);
[ 3290.970306] lock(&hdev->lock);
[ 3290.970310] lock(dpm_list_mtx);
[ 3290.970314] lock((wq_completion)hci0#2);
[ 3290.970319]
*** DEADLOCK ***
[ 3290.970321] 7 locks held by systemd-sleep/4553:
[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.970428]
stack backtrace:
[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
[ 3290.970441] Call Trace:
[ 3290.970446] dump_stack_lvl+0x44/0x57
[ 3290.970454] check_noncircular+0x105/0x120
[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
[ 3290.970474] __lock_acquire+0x15cb/0x1b50
[ 3290.970487] lock_acquire+0x26c/0x300
[ 3290.970493] ? flush_workqueue+0x87/0x4a0
[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
[ 3290.970519] flush_workqueue+0xae/0x4a0
[ 3290.970526] ? flush_workqueue+0x87/0x4a0
[ 3290.970544] ? drain_workqueue+0xa1/0x130
[ 3290.970552] drain_workqueue+0xa1/0x130
[ 3290.970561] destroy_workqueue+0x34/0x1f0
[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970687] device_release+0x33/0x90
[ 3290.970695] kobject_release+0x63/0x160
[ 3290.970705] dpm_resume+0x164/0x3e0
[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
[ 3290.970718] dpm_resume_end+0xd/0x20
[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970737] pm_suspend+0x26b/0x310
[ 3290.970746] state_store+0x42/0x90
[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970764] new_sync_write+0x125/0x1c0
[ 3290.970777] vfs_write+0x360/0x3c0
[ 3290.970785] ksys_write+0xa7/0xe0
[ 3290.970794] do_syscall_64+0x3a/0x80
[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970811] RIP: 0033:0x7f41b1328164
[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-11-04 17:26:26 +00:00
|
|
|
|
2016-05-20 21:09:49 +00:00
|
|
|
if (!list_empty(&dev->power.entry))
|
|
|
|
list_move(&dev->power.entry, &dpm_late_early_list);
|
|
|
|
|
2012-01-29 19:38:29 +00:00
|
|
|
if (error) {
|
|
|
|
pm_dev_err(dev, state, " late", error);
|
|
|
|
dpm_save_failed_dev(dev_name(dev));
|
|
|
|
}
|
PM: sleep: Avoid calling put_device() under dpm_list_mtx
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
[ 3290.969514] ======================================================
[ 3290.969517] WARNING: possible circular locking dependency detected
[ 3290.969519] 5.15.0+ #2420 Tainted: G S
[ 3290.969523] ------------------------------------------------------
[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
[ 3290.969554]
but task is already holding lock:
[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.969571]
which lock already depends on the new lock.
[ 3290.969573]
the existing dependency chain (in reverse order) is:
[ 3290.969575]
-> #3 (dpm_list_mtx){+.+.}-{3:3}:
[ 3290.969583] __mutex_lock+0x9d/0xa30
[ 3290.969591] device_pm_add+0x2e/0xe0
[ 3290.969597] device_add+0x4d5/0x8f0
[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969842] process_one_work+0x2aa/0x650
[ 3290.969851] worker_thread+0x39/0x400
[ 3290.969859] kthread+0x142/0x170
[ 3290.969865] ret_from_fork+0x22/0x30
[ 3290.969872]
-> #2 (&hdev->lock){+.+.}-{3:3}:
[ 3290.969881] __mutex_lock+0x9d/0xa30
[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969978] process_one_work+0x2aa/0x650
[ 3290.969985] worker_thread+0x39/0x400
[ 3290.969993] kthread+0x142/0x170
[ 3290.969999] ret_from_fork+0x22/0x30
[ 3290.970004]
-> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
[ 3290.970013] process_one_work+0x27d/0x650
[ 3290.970020] worker_thread+0x39/0x400
[ 3290.970028] kthread+0x142/0x170
[ 3290.970033] ret_from_fork+0x22/0x30
[ 3290.970038]
-> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
[ 3290.970047] __lock_acquire+0x15cb/0x1b50
[ 3290.970054] lock_acquire+0x26c/0x300
[ 3290.970059] flush_workqueue+0xae/0x4a0
[ 3290.970066] drain_workqueue+0xa1/0x130
[ 3290.970073] destroy_workqueue+0x34/0x1f0
[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970195] device_release+0x33/0x90
[ 3290.970201] kobject_release+0x63/0x160
[ 3290.970211] dpm_resume+0x164/0x3e0
[ 3290.970215] dpm_resume_end+0xd/0x20
[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970229] pm_suspend+0x26b/0x310
[ 3290.970236] state_store+0x42/0x90
[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970251] new_sync_write+0x125/0x1c0
[ 3290.970257] vfs_write+0x360/0x3c0
[ 3290.970263] ksys_write+0xa7/0xe0
[ 3290.970269] do_syscall_64+0x3a/0x80
[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970284]
other info that might help us debug this:
[ 3290.970285] Chain exists of:
(wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
[ 3290.970297] Possible unsafe locking scenario:
[ 3290.970299] CPU0 CPU1
[ 3290.970300] ---- ----
[ 3290.970302] lock(dpm_list_mtx);
[ 3290.970306] lock(&hdev->lock);
[ 3290.970310] lock(dpm_list_mtx);
[ 3290.970314] lock((wq_completion)hci0#2);
[ 3290.970319]
*** DEADLOCK ***
[ 3290.970321] 7 locks held by systemd-sleep/4553:
[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.970428]
stack backtrace:
[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
[ 3290.970441] Call Trace:
[ 3290.970446] dump_stack_lvl+0x44/0x57
[ 3290.970454] check_noncircular+0x105/0x120
[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
[ 3290.970474] __lock_acquire+0x15cb/0x1b50
[ 3290.970487] lock_acquire+0x26c/0x300
[ 3290.970493] ? flush_workqueue+0x87/0x4a0
[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
[ 3290.970519] flush_workqueue+0xae/0x4a0
[ 3290.970526] ? flush_workqueue+0x87/0x4a0
[ 3290.970544] ? drain_workqueue+0xa1/0x130
[ 3290.970552] drain_workqueue+0xa1/0x130
[ 3290.970561] destroy_workqueue+0x34/0x1f0
[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970687] device_release+0x33/0x90
[ 3290.970695] kobject_release+0x63/0x160
[ 3290.970705] dpm_resume+0x164/0x3e0
[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
[ 3290.970718] dpm_resume_end+0xd/0x20
[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970737] pm_suspend+0x26b/0x310
[ 3290.970746] state_store+0x42/0x90
[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970764] new_sync_write+0x125/0x1c0
[ 3290.970777] vfs_write+0x360/0x3c0
[ 3290.970785] ksys_write+0xa7/0xe0
[ 3290.970794] do_syscall_64+0x3a/0x80
[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970811] RIP: 0033:0x7f41b1328164
[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-11-04 17:26:26 +00:00
|
|
|
|
|
|
|
mutex_unlock(&dpm_list_mtx);
|
|
|
|
|
2012-01-29 19:38:29 +00:00
|
|
|
put_device(dev);
|
2012-04-29 20:52:19 +00:00
|
|
|
|
PM: sleep: Avoid calling put_device() under dpm_list_mtx
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
[ 3290.969514] ======================================================
[ 3290.969517] WARNING: possible circular locking dependency detected
[ 3290.969519] 5.15.0+ #2420 Tainted: G S
[ 3290.969523] ------------------------------------------------------
[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
[ 3290.969554]
but task is already holding lock:
[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.969571]
which lock already depends on the new lock.
[ 3290.969573]
the existing dependency chain (in reverse order) is:
[ 3290.969575]
-> #3 (dpm_list_mtx){+.+.}-{3:3}:
[ 3290.969583] __mutex_lock+0x9d/0xa30
[ 3290.969591] device_pm_add+0x2e/0xe0
[ 3290.969597] device_add+0x4d5/0x8f0
[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969842] process_one_work+0x2aa/0x650
[ 3290.969851] worker_thread+0x39/0x400
[ 3290.969859] kthread+0x142/0x170
[ 3290.969865] ret_from_fork+0x22/0x30
[ 3290.969872]
-> #2 (&hdev->lock){+.+.}-{3:3}:
[ 3290.969881] __mutex_lock+0x9d/0xa30
[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969978] process_one_work+0x2aa/0x650
[ 3290.969985] worker_thread+0x39/0x400
[ 3290.969993] kthread+0x142/0x170
[ 3290.969999] ret_from_fork+0x22/0x30
[ 3290.970004]
-> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
[ 3290.970013] process_one_work+0x27d/0x650
[ 3290.970020] worker_thread+0x39/0x400
[ 3290.970028] kthread+0x142/0x170
[ 3290.970033] ret_from_fork+0x22/0x30
[ 3290.970038]
-> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
[ 3290.970047] __lock_acquire+0x15cb/0x1b50
[ 3290.970054] lock_acquire+0x26c/0x300
[ 3290.970059] flush_workqueue+0xae/0x4a0
[ 3290.970066] drain_workqueue+0xa1/0x130
[ 3290.970073] destroy_workqueue+0x34/0x1f0
[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970195] device_release+0x33/0x90
[ 3290.970201] kobject_release+0x63/0x160
[ 3290.970211] dpm_resume+0x164/0x3e0
[ 3290.970215] dpm_resume_end+0xd/0x20
[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970229] pm_suspend+0x26b/0x310
[ 3290.970236] state_store+0x42/0x90
[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970251] new_sync_write+0x125/0x1c0
[ 3290.970257] vfs_write+0x360/0x3c0
[ 3290.970263] ksys_write+0xa7/0xe0
[ 3290.970269] do_syscall_64+0x3a/0x80
[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970284]
other info that might help us debug this:
[ 3290.970285] Chain exists of:
(wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
[ 3290.970297] Possible unsafe locking scenario:
[ 3290.970299] CPU0 CPU1
[ 3290.970300] ---- ----
[ 3290.970302] lock(dpm_list_mtx);
[ 3290.970306] lock(&hdev->lock);
[ 3290.970310] lock(dpm_list_mtx);
[ 3290.970314] lock((wq_completion)hci0#2);
[ 3290.970319]
*** DEADLOCK ***
[ 3290.970321] 7 locks held by systemd-sleep/4553:
[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.970428]
stack backtrace:
[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
[ 3290.970441] Call Trace:
[ 3290.970446] dump_stack_lvl+0x44/0x57
[ 3290.970454] check_noncircular+0x105/0x120
[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
[ 3290.970474] __lock_acquire+0x15cb/0x1b50
[ 3290.970487] lock_acquire+0x26c/0x300
[ 3290.970493] ? flush_workqueue+0x87/0x4a0
[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
[ 3290.970519] flush_workqueue+0xae/0x4a0
[ 3290.970526] ? flush_workqueue+0x87/0x4a0
[ 3290.970544] ? drain_workqueue+0xa1/0x130
[ 3290.970552] drain_workqueue+0xa1/0x130
[ 3290.970561] destroy_workqueue+0x34/0x1f0
[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970687] device_release+0x33/0x90
[ 3290.970695] kobject_release+0x63/0x160
[ 3290.970705] dpm_resume+0x164/0x3e0
[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
[ 3290.970718] dpm_resume_end+0xd/0x20
[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970737] pm_suspend+0x26b/0x310
[ 3290.970746] state_store+0x42/0x90
[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970764] new_sync_write+0x125/0x1c0
[ 3290.970777] vfs_write+0x360/0x3c0
[ 3290.970785] ksys_write+0xa7/0xe0
[ 3290.970794] do_syscall_64+0x3a/0x80
[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970811] RIP: 0033:0x7f41b1328164
[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-11-04 17:26:26 +00:00
|
|
|
mutex_lock(&dpm_list_mtx);
|
|
|
|
|
|
|
|
if (error || async_error)
|
2012-04-29 20:52:19 +00:00
|
|
|
break;
|
2012-01-29 19:38:29 +00:00
|
|
|
}
|
|
|
|
mutex_unlock(&dpm_list_mtx);
|
2014-02-18 02:28:48 +00:00
|
|
|
async_synchronize_full();
|
2014-10-24 17:29:09 +00:00
|
|
|
if (!error)
|
|
|
|
error = async_error;
|
2014-02-18 02:28:48 +00:00
|
|
|
if (error) {
|
|
|
|
suspend_stats.failed_suspend_late++;
|
|
|
|
dpm_save_failed_step(SUSPEND_SUSPEND_LATE);
|
2012-01-29 19:38:29 +00:00
|
|
|
dpm_resume_early(resume_event(state));
|
2014-02-18 02:28:48 +00:00
|
|
|
}
|
2017-07-21 00:10:22 +00:00
|
|
|
dpm_show_time(starttime, state, error, "late");
|
2014-06-06 12:40:17 +00:00
|
|
|
trace_suspend_resume(TPS("dpm_suspend_late"), state.event, false);
|
2008-01-12 19:40:46 +00:00
|
|
|
return error;
|
|
|
|
}
|
2012-01-29 19:38:29 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* dpm_suspend_end - Execute "late" and "noirq" device suspend callbacks.
|
|
|
|
* @state: PM transition of the system being carried out.
|
|
|
|
*/
|
|
|
|
int dpm_suspend_end(pm_message_t state)
|
|
|
|
{
|
2019-06-05 16:12:37 +00:00
|
|
|
ktime_t starttime = ktime_get();
|
|
|
|
int error;
|
|
|
|
|
|
|
|
error = dpm_suspend_late(state);
|
2012-07-19 08:38:06 +00:00
|
|
|
if (error)
|
2019-06-05 16:12:37 +00:00
|
|
|
goto out;
|
2012-07-19 08:38:06 +00:00
|
|
|
|
|
|
|
error = dpm_suspend_noirq(state);
|
PM: sleep: Pause cpuidle later and resume it earlier during system transitions
Commit 8651f97bd951 ("PM / cpuidle: System resume hang fix with
cpuidle") that introduced cpuidle pausing during system suspend
did that to work around a platform firmware issue causing systems
to hang during resume if CPUs were allowed to enter idle states
in the system suspend and resume code paths.
However, pausing cpuidle before the last phase of suspending
devices is the source of an otherwise arbitrary difference between
the suspend-to-idle path and other system suspend variants, so it is
cleaner to do that later, before taking secondary CPUs offline (it
is still safer to take secondary CPUs offline with cpuidle paused,
though).
Modify the code accordingly, but in order to avoid code duplication,
introduce new wrapper functions, pm_sleep_disable_secondary_cpus()
and pm_sleep_enable_secondary_cpus(), to combine cpuidle_pause()
and cpuidle_resume(), respectively, with the handling of secondary
CPUs during system-wide transitions to sleep states.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-10-22 16:07:47 +00:00
|
|
|
if (error)
|
2012-09-19 12:16:00 +00:00
|
|
|
dpm_resume_early(resume_event(state));
|
2012-01-29 19:38:29 +00:00
|
|
|
|
2019-06-05 16:12:37 +00:00
|
|
|
out:
|
|
|
|
dpm_show_time(starttime, state, error, "end");
|
|
|
|
return error;
|
2012-01-29 19:38:29 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(dpm_suspend_end);
|
2008-01-12 19:40:46 +00:00
|
|
|
|
2009-12-18 00:57:31 +00:00
|
|
|
/**
|
|
|
|
* legacy_suspend - Execute a legacy (bus or class) suspend callback for device.
|
2010-01-08 22:42:57 +00:00
|
|
|
* @dev: Device to suspend.
|
|
|
|
* @state: PM transition of the system being carried out.
|
|
|
|
* @cb: Suspend callback to execute.
|
2014-07-27 23:17:15 +00:00
|
|
|
* @info: string description of caller.
|
2009-12-18 00:57:31 +00:00
|
|
|
*/
|
|
|
|
static int legacy_suspend(struct device *dev, pm_message_t state,
|
2013-07-26 19:30:20 +00:00
|
|
|
int (*cb)(struct device *dev, pm_message_t state),
|
2017-06-12 15:19:32 +00:00
|
|
|
const char *info)
|
2009-12-18 00:57:31 +00:00
|
|
|
{
|
|
|
|
int error;
|
|
|
|
ktime_t calltime;
|
|
|
|
|
2018-04-26 21:36:41 +00:00
|
|
|
calltime = initcall_debug_start(dev, cb);
|
2009-12-18 00:57:31 +00:00
|
|
|
|
2014-06-10 14:31:22 +00:00
|
|
|
trace_device_pm_callback_start(dev, info, state.event);
|
2009-12-18 00:57:31 +00:00
|
|
|
error = cb(dev, state);
|
2014-06-10 14:31:22 +00:00
|
|
|
trace_device_pm_callback_end(dev, error);
|
2022-03-07 19:07:39 +00:00
|
|
|
suspend_report_result(dev, cb, error);
|
2009-12-18 00:57:31 +00:00
|
|
|
|
2018-04-26 21:36:41 +00:00
|
|
|
initcall_debug_report(dev, calltime, cb, error);
|
2009-12-18 00:57:31 +00:00
|
|
|
|
|
|
|
return error;
|
2017-11-13 15:46:41 +00:00
|
|
|
}
|
|
|
|
|
2018-01-09 09:03:39 +00:00
|
|
|
static void dpm_clear_superiors_direct_complete(struct device *dev)
|
2016-10-30 16:28:49 +00:00
|
|
|
{
|
|
|
|
struct device_link *link;
|
|
|
|
int idx;
|
|
|
|
|
2018-01-09 09:03:39 +00:00
|
|
|
if (dev->parent) {
|
|
|
|
spin_lock_irq(&dev->parent->power.lock);
|
|
|
|
dev->parent->power.direct_complete = false;
|
|
|
|
spin_unlock_irq(&dev->parent->power.lock);
|
|
|
|
}
|
|
|
|
|
2016-10-30 16:28:49 +00:00
|
|
|
idx = device_links_read_lock();
|
|
|
|
|
2020-03-03 19:41:30 +00:00
|
|
|
list_for_each_entry_rcu_locked(link, &dev->links.suppliers, c_node) {
|
2016-10-30 16:28:49 +00:00
|
|
|
spin_lock_irq(&link->supplier->power.lock);
|
|
|
|
link->supplier->power.direct_complete = false;
|
|
|
|
spin_unlock_irq(&link->supplier->power.lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
device_links_read_unlock(idx);
|
|
|
|
}
|
|
|
|
|
2008-01-12 19:40:46 +00:00
|
|
|
/**
|
2017-10-13 13:25:39 +00:00
|
|
|
* __device_suspend - Execute "suspend" callbacks for given device.
|
2009-08-20 18:25:52 +00:00
|
|
|
* @dev: Device to handle.
|
|
|
|
* @state: PM transition of the system being carried out.
|
PM: Asynchronous suspend and resume of devices
Theoretically, the total time of system sleep transitions (suspend
to RAM, hibernation) can be reduced by running suspend and resume
callbacks of device drivers in parallel with each other. However,
there are dependencies between devices such that we're not allowed
to suspend the parent of a device before suspending the device
itself. Analogously, we're not allowed to resume a device before
resuming its parent.
The most straightforward way to take these dependencies into accout
is to start the async threads used for suspending and resuming
devices at the core level, so that async_schedule() is called for
each suspend and resume callback supposed to be executed
asynchronously.
For this purpose, introduce a new device flag, power.async_suspend,
used to mark the devices whose suspend and resume callbacks are to be
executed asynchronously (ie. in parallel with the main suspend/resume
thread and possibly in parallel with each other) and helper function
device_enable_async_suspend() allowing one to set power.async_suspend
for given device (power.async_suspend is unset by default for all
devices). For each device with the power.async_suspend flag set the
PM core will use async_schedule() to execute its suspend and resume
callbacks.
The async threads started for different devices as a result of
calling async_schedule() are synchronized with each other and with
the main suspend/resume thread with the help of completions, in the
following way:
(1) There is a completion, power.completion, for each device object.
(2) Each device's completion is reset before calling async_schedule()
for the device or, in the case of devices with the
power.async_suspend flags unset, before executing the device's
suspend and resume callbacks.
(3) During suspend, right before running the bus type, device type
and device class suspend callbacks for the device, the PM core
waits for the completions of all the device's children to be
completed.
(4) During resume, right before running the bus type, device type and
device class resume callbacks for the device, the PM core waits
for the completion of the device's parent to be completed.
(5) The PM core completes power.completion for each device right
after the bus type, device type and device class suspend (or
resume) callbacks executed for the device have returned.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-01-23 21:23:32 +00:00
|
|
|
* @async: If true, the device is being suspended asynchronously.
|
2008-01-12 19:40:46 +00:00
|
|
|
*/
|
PM: Asynchronous suspend and resume of devices
Theoretically, the total time of system sleep transitions (suspend
to RAM, hibernation) can be reduced by running suspend and resume
callbacks of device drivers in parallel with each other. However,
there are dependencies between devices such that we're not allowed
to suspend the parent of a device before suspending the device
itself. Analogously, we're not allowed to resume a device before
resuming its parent.
The most straightforward way to take these dependencies into accout
is to start the async threads used for suspending and resuming
devices at the core level, so that async_schedule() is called for
each suspend and resume callback supposed to be executed
asynchronously.
For this purpose, introduce a new device flag, power.async_suspend,
used to mark the devices whose suspend and resume callbacks are to be
executed asynchronously (ie. in parallel with the main suspend/resume
thread and possibly in parallel with each other) and helper function
device_enable_async_suspend() allowing one to set power.async_suspend
for given device (power.async_suspend is unset by default for all
devices). For each device with the power.async_suspend flag set the
PM core will use async_schedule() to execute its suspend and resume
callbacks.
The async threads started for different devices as a result of
calling async_schedule() are synchronized with each other and with
the main suspend/resume thread with the help of completions, in the
following way:
(1) There is a completion, power.completion, for each device object.
(2) Each device's completion is reset before calling async_schedule()
for the device or, in the case of devices with the
power.async_suspend flags unset, before executing the device's
suspend and resume callbacks.
(3) During suspend, right before running the bus type, device type
and device class suspend callbacks for the device, the PM core
waits for the completions of all the device's children to be
completed.
(4) During resume, right before running the bus type, device type and
device class resume callbacks for the device, the PM core waits
for the completion of the device's parent to be completed.
(5) The PM core completes power.completion for each device right
after the bus type, device type and device class suspend (or
resume) callbacks executed for the device have returned.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-01-23 21:23:32 +00:00
|
|
|
static int __device_suspend(struct device *dev, pm_message_t state, bool async)
|
2007-09-21 19:36:56 +00:00
|
|
|
{
|
2011-12-17 23:34:01 +00:00
|
|
|
pm_callback_t callback = NULL;
|
2017-06-12 15:19:32 +00:00
|
|
|
const char *info = NULL;
|
2007-09-21 19:36:56 +00:00
|
|
|
int error = 0;
|
2013-10-17 17:48:46 +00:00
|
|
|
DECLARE_DPM_WATCHDOG_ON_STACK(wd);
|
2007-09-21 19:36:56 +00:00
|
|
|
|
2015-03-18 14:54:27 +00:00
|
|
|
TRACE_DEVICE(dev);
|
|
|
|
TRACE_SUSPEND(0);
|
|
|
|
|
2016-10-30 16:28:49 +00:00
|
|
|
dpm_wait_for_subordinate(dev, async);
|
2008-02-24 23:35:04 +00:00
|
|
|
|
2018-10-04 09:08:12 +00:00
|
|
|
if (async_error) {
|
|
|
|
dev->power.direct_complete = false;
|
2012-06-24 21:31:09 +00:00
|
|
|
goto Complete;
|
2018-10-04 09:08:12 +00:00
|
|
|
}
|
PM: Limit race conditions between runtime PM and system sleep (v2)
One of the roles of the PM core is to prevent different PM callbacks
executed for the same device object from racing with each other.
Unfortunately, after commit e8665002477f0278f84f898145b1f141ba26ee26
(PM: Allow pm_runtime_suspend() to succeed during system suspend)
runtime PM callbacks may be executed concurrently with system
suspend/resume callbacks for the same device.
The main reason for commit e8665002477f0278f84f898145b1f141ba26ee26
was that some subsystems and device drivers wanted to use runtime PM
helpers, pm_runtime_suspend() and pm_runtime_put_sync() in
particular, for carrying out the suspend of devices in their
.suspend() callbacks. However, as it's been determined recently,
there are multiple reasons not to do so, inlcuding:
* The caller really doesn't control the runtime PM usage counters,
because user space can access them through sysfs and effectively
block runtime PM. That means using pm_runtime_suspend() or
pm_runtime_get_sync() to suspend devices during system suspend
may or may not work.
* If a driver calls pm_runtime_suspend() from its .suspend()
callback, it causes the subsystem's .runtime_suspend() callback to
be executed, which leads to the call sequence:
subsys->suspend(dev)
driver->suspend(dev)
pm_runtime_suspend(dev)
subsys->runtime_suspend(dev)
recursive from the subsystem's point of view. For some subsystems
that may actually work (e.g. the platform bus type), but for some
it will fail in a rather spectacular fashion (e.g. PCI). In each
case it means a layering violation.
* Both the subsystem and the driver can provide .suspend_noirq()
callbacks for system suspend that can do whatever the
.runtime_suspend() callbacks do just fine, so it really isn't
necessary to call pm_runtime_suspend() during system suspend.
* The runtime PM's handling of wakeup devices is usually different
from the system suspend's one, so .runtime_suspend() may simply be
inappropriate for system suspend.
* System suspend is supposed to work even if CONFIG_PM_RUNTIME is
unset.
* The runtime PM workqueue is frozen before system suspend, so if
whatever the driver is going to do during system suspend depends
on it, that simply won't work.
Still, there is a good reason to allow pm_runtime_resume() to
succeed during system suspend and resume (for instance, some
subsystems and device drivers may legitimately use it to ensure that
their devices are in full-power states before suspending them).
Moreover, there is no reason to prevent runtime PM callbacks from
being executed in parallel with the system suspend/resume .prepare()
and .complete() callbacks and the code removed by commit
e8665002477f0278f84f898145b1f141ba26ee26 went too far in this
respect. On the other hand, runtime PM callbacks, including
.runtime_resume(), must not be executed during system suspend's
"late" stage of suspending devices and during system resume's "early"
device resume stage.
Taking all of the above into consideration, make the PM core
acquire a runtime PM reference to every device and resume it if
there's a runtime PM resume request pending right before executing
the subsystem-level .suspend() callback for it. Make the PM core
drop references to all devices right after executing the
subsystem-level .resume() callbacks for them. Additionally,
make the PM core disable the runtime PM framework for all devices
during system suspend, after executing the subsystem-level .suspend()
callbacks for them, and enable the runtime PM framework for all
devices during system resume, right before executing the
subsystem-level .resume() callbacks for them.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Kevin Hilman <khilman@ti.com>
2011-07-06 08:51:58 +00:00
|
|
|
|
2012-09-19 19:59:02 +00:00
|
|
|
/*
|
PM: sleep: core: Fix the handling of pending runtime resume requests
It has been reported that system-wide suspend may be aborted in the
absence of any wakeup events due to unforseen interactions of it with
the runtume PM framework.
One failing scenario is when there are multiple devices sharing an
ACPI power resource and runtime-resume needs to be carried out for
one of them during system-wide suspend (for example, because it needs
to be reconfigured before the whole system goes to sleep). In that
case, the runtime-resume of that device involves turning the ACPI
power resource "on" which in turn causes runtime-resume requests
to be queued up for all of the other devices sharing it. Those
requests go to the runtime PM workqueue which is frozen during
system-wide suspend, so they are not actually taken care of until
the resume of the whole system, but the pm_runtime_barrier()
call in __device_suspend() sees them and triggers system wakeup
events for them which then cause the system-wide suspend to be
aborted if wakeup source objects are in active use.
Of course, the logic that leads to triggering those wakeup events is
questionable in the first place, because clearly there are cases in
which a pending runtime resume request for a device is not connected
to any real wakeup events in any way (like the one above). Moreover,
it is racy, because the device may be resuming already by the time
the pm_runtime_barrier() runs and so if the driver doesn't take care
of signaling the wakeup event as appropriate, it will be lost.
However, if the driver does take care of that, the extra
pm_wakeup_event() call in the core is redundant.
Accordingly, drop the conditional pm_wakeup_event() call fron
__device_suspend() and make the latter call pm_runtime_barrier()
alone. Also modify the comment next to that call to reflect the new
code and extend it to mention the need to avoid unwanted interactions
between runtime PM and system-wide device suspend callbacks.
Fixes: 1e2ef05bb8cf8 ("PM: Limit race conditions between runtime PM and system sleep (v2)")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Utkarsh H Patel <utkarsh.h.patel@intel.com>
Tested-by: Utkarsh H Patel <utkarsh.h.patel@intel.com>
Tested-by: Pengfei Xu <pengfei.xu@intel.com>
Cc: All applicable <stable@vger.kernel.org>
2020-08-24 17:35:31 +00:00
|
|
|
* Wait for possible runtime PM transitions of the device in progress
|
|
|
|
* to complete and if there's a runtime resume request pending for it,
|
|
|
|
* resume it before proceeding with invoking the system-wide suspend
|
|
|
|
* callbacks for it.
|
|
|
|
*
|
|
|
|
* If the system-wide suspend callbacks below change the configuration
|
|
|
|
* of the device, they must disable runtime PM for it or otherwise
|
|
|
|
* ensure that its runtime-resume callbacks will not be confused by that
|
|
|
|
* change in case they are invoked going forward.
|
2012-09-19 19:59:02 +00:00
|
|
|
*/
|
PM: sleep: core: Fix the handling of pending runtime resume requests
It has been reported that system-wide suspend may be aborted in the
absence of any wakeup events due to unforseen interactions of it with
the runtume PM framework.
One failing scenario is when there are multiple devices sharing an
ACPI power resource and runtime-resume needs to be carried out for
one of them during system-wide suspend (for example, because it needs
to be reconfigured before the whole system goes to sleep). In that
case, the runtime-resume of that device involves turning the ACPI
power resource "on" which in turn causes runtime-resume requests
to be queued up for all of the other devices sharing it. Those
requests go to the runtime PM workqueue which is frozen during
system-wide suspend, so they are not actually taken care of until
the resume of the whole system, but the pm_runtime_barrier()
call in __device_suspend() sees them and triggers system wakeup
events for them which then cause the system-wide suspend to be
aborted if wakeup source objects are in active use.
Of course, the logic that leads to triggering those wakeup events is
questionable in the first place, because clearly there are cases in
which a pending runtime resume request for a device is not connected
to any real wakeup events in any way (like the one above). Moreover,
it is racy, because the device may be resuming already by the time
the pm_runtime_barrier() runs and so if the driver doesn't take care
of signaling the wakeup event as appropriate, it will be lost.
However, if the driver does take care of that, the extra
pm_wakeup_event() call in the core is redundant.
Accordingly, drop the conditional pm_wakeup_event() call fron
__device_suspend() and make the latter call pm_runtime_barrier()
alone. Also modify the comment next to that call to reflect the new
code and extend it to mention the need to avoid unwanted interactions
between runtime PM and system-wide device suspend callbacks.
Fixes: 1e2ef05bb8cf8 ("PM: Limit race conditions between runtime PM and system sleep (v2)")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Utkarsh H Patel <utkarsh.h.patel@intel.com>
Tested-by: Utkarsh H Patel <utkarsh.h.patel@intel.com>
Tested-by: Pengfei Xu <pengfei.xu@intel.com>
Cc: All applicable <stable@vger.kernel.org>
2020-08-24 17:35:31 +00:00
|
|
|
pm_runtime_barrier(dev);
|
PM: Asynchronous suspend and resume of devices
Theoretically, the total time of system sleep transitions (suspend
to RAM, hibernation) can be reduced by running suspend and resume
callbacks of device drivers in parallel with each other. However,
there are dependencies between devices such that we're not allowed
to suspend the parent of a device before suspending the device
itself. Analogously, we're not allowed to resume a device before
resuming its parent.
The most straightforward way to take these dependencies into accout
is to start the async threads used for suspending and resuming
devices at the core level, so that async_schedule() is called for
each suspend and resume callback supposed to be executed
asynchronously.
For this purpose, introduce a new device flag, power.async_suspend,
used to mark the devices whose suspend and resume callbacks are to be
executed asynchronously (ie. in parallel with the main suspend/resume
thread and possibly in parallel with each other) and helper function
device_enable_async_suspend() allowing one to set power.async_suspend
for given device (power.async_suspend is unset by default for all
devices). For each device with the power.async_suspend flag set the
PM core will use async_schedule() to execute its suspend and resume
callbacks.
The async threads started for different devices as a result of
calling async_schedule() are synchronized with each other and with
the main suspend/resume thread with the help of completions, in the
following way:
(1) There is a completion, power.completion, for each device object.
(2) Each device's completion is reset before calling async_schedule()
for the device or, in the case of devices with the
power.async_suspend flags unset, before executing the device's
suspend and resume callbacks.
(3) During suspend, right before running the bus type, device type
and device class suspend callbacks for the device, the PM core
waits for the completions of all the device's children to be
completed.
(4) During resume, right before running the bus type, device type and
device class resume callbacks for the device, the PM core waits
for the completion of the device's parent to be completed.
(5) The PM core completes power.completion for each device right
after the bus type, device type and device class suspend (or
resume) callbacks executed for the device have returned.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-01-23 21:23:32 +00:00
|
|
|
|
2010-12-03 22:14:26 +00:00
|
|
|
if (pm_wakeup_pending()) {
|
2018-10-04 09:08:12 +00:00
|
|
|
dev->power.direct_complete = false;
|
2010-12-03 22:14:26 +00:00
|
|
|
async_error = -EBUSY;
|
2012-06-24 21:31:09 +00:00
|
|
|
goto Complete;
|
2010-12-03 22:14:26 +00:00
|
|
|
}
|
|
|
|
|
2012-08-05 23:46:39 +00:00
|
|
|
if (dev->power.syscore)
|
|
|
|
goto Complete;
|
|
|
|
|
2019-04-10 09:55:16 +00:00
|
|
|
/* Avoid direct_complete to let wakeup_path propagate. */
|
2020-11-19 07:25:39 +00:00
|
|
|
if (device_may_wakeup(dev) || device_wakeup_path(dev))
|
2019-04-10 09:55:16 +00:00
|
|
|
dev->power.direct_complete = false;
|
|
|
|
|
PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily
Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
resume all runtime-suspended devices during system suspend, mostly
because those devices may need to be reprogrammed due to different
wakeup settings for system sleep and for runtime PM.
For some devices, though, it's OK to remain in runtime suspend
throughout a complete system suspend/resume cycle (if the device was in
runtime suspend at the start of the cycle). We would like to do this
whenever possible, to avoid the overhead of extra power-up and power-down
events.
However, problems may arise because the device's descendants may require
it to be at full power at various points during the cycle. Therefore the
most straightforward way to do this safely is if the device and all its
descendants can remain runtime suspended until the complete stage of
system resume.
To this end, introduce a new device PM flag, power.direct_complete
and modify the PM core to use that flag as follows.
If the ->prepare() callback of a device returns a positive number,
the PM core will regard that as an indication that it may leave the
device runtime-suspended. It will then check if the system power
transition in progress is a suspend (and not hibernation in particular)
and if the device is, indeed, runtime-suspended. In that case, the PM
core will set the device's power.direct_complete flag. Otherwise it
will clear power.direct_complete for the device and it also will later
clear it for the device's parent (if there's one).
Next, the PM core will not invoke the ->suspend() ->suspend_late(),
->suspend_irq(), ->resume_irq(), ->resume_early(), or ->resume()
callbacks for all devices having power.direct_complete set. It
will invoke their ->complete() callbacks, however, and those
callbacks are then responsible for resuming the devices as
appropriate, if necessary. For example, in some cases they may
need to queue up runtime resume requests for the devices using
pm_request_resume().
Changelog partly based on an Alan Stern's description of the idea
(http://marc.info/?l=linux-pm&m=139940466625569&w=2).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
2014-05-16 00:46:50 +00:00
|
|
|
if (dev->power.direct_complete) {
|
|
|
|
if (pm_runtime_status_suspended(dev)) {
|
|
|
|
pm_runtime_disable(dev);
|
2019-02-11 12:17:12 +00:00
|
|
|
if (pm_runtime_status_suspended(dev)) {
|
|
|
|
pm_dev_dbg(dev, state, "direct-complete ");
|
PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily
Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
resume all runtime-suspended devices during system suspend, mostly
because those devices may need to be reprogrammed due to different
wakeup settings for system sleep and for runtime PM.
For some devices, though, it's OK to remain in runtime suspend
throughout a complete system suspend/resume cycle (if the device was in
runtime suspend at the start of the cycle). We would like to do this
whenever possible, to avoid the overhead of extra power-up and power-down
events.
However, problems may arise because the device's descendants may require
it to be at full power at various points during the cycle. Therefore the
most straightforward way to do this safely is if the device and all its
descendants can remain runtime suspended until the complete stage of
system resume.
To this end, introduce a new device PM flag, power.direct_complete
and modify the PM core to use that flag as follows.
If the ->prepare() callback of a device returns a positive number,
the PM core will regard that as an indication that it may leave the
device runtime-suspended. It will then check if the system power
transition in progress is a suspend (and not hibernation in particular)
and if the device is, indeed, runtime-suspended. In that case, the PM
core will set the device's power.direct_complete flag. Otherwise it
will clear power.direct_complete for the device and it also will later
clear it for the device's parent (if there's one).
Next, the PM core will not invoke the ->suspend() ->suspend_late(),
->suspend_irq(), ->resume_irq(), ->resume_early(), or ->resume()
callbacks for all devices having power.direct_complete set. It
will invoke their ->complete() callbacks, however, and those
callbacks are then responsible for resuming the devices as
appropriate, if necessary. For example, in some cases they may
need to queue up runtime resume requests for the devices using
pm_request_resume().
Changelog partly based on an Alan Stern's description of the idea
(http://marc.info/?l=linux-pm&m=139940466625569&w=2).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
2014-05-16 00:46:50 +00:00
|
|
|
goto Complete;
|
2019-02-11 12:17:12 +00:00
|
|
|
}
|
PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily
Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
resume all runtime-suspended devices during system suspend, mostly
because those devices may need to be reprogrammed due to different
wakeup settings for system sleep and for runtime PM.
For some devices, though, it's OK to remain in runtime suspend
throughout a complete system suspend/resume cycle (if the device was in
runtime suspend at the start of the cycle). We would like to do this
whenever possible, to avoid the overhead of extra power-up and power-down
events.
However, problems may arise because the device's descendants may require
it to be at full power at various points during the cycle. Therefore the
most straightforward way to do this safely is if the device and all its
descendants can remain runtime suspended until the complete stage of
system resume.
To this end, introduce a new device PM flag, power.direct_complete
and modify the PM core to use that flag as follows.
If the ->prepare() callback of a device returns a positive number,
the PM core will regard that as an indication that it may leave the
device runtime-suspended. It will then check if the system power
transition in progress is a suspend (and not hibernation in particular)
and if the device is, indeed, runtime-suspended. In that case, the PM
core will set the device's power.direct_complete flag. Otherwise it
will clear power.direct_complete for the device and it also will later
clear it for the device's parent (if there's one).
Next, the PM core will not invoke the ->suspend() ->suspend_late(),
->suspend_irq(), ->resume_irq(), ->resume_early(), or ->resume()
callbacks for all devices having power.direct_complete set. It
will invoke their ->complete() callbacks, however, and those
callbacks are then responsible for resuming the devices as
appropriate, if necessary. For example, in some cases they may
need to queue up runtime resume requests for the devices using
pm_request_resume().
Changelog partly based on an Alan Stern's description of the idea
(http://marc.info/?l=linux-pm&m=139940466625569&w=2).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
2014-05-16 00:46:50 +00:00
|
|
|
|
|
|
|
pm_runtime_enable(dev);
|
|
|
|
}
|
|
|
|
dev->power.direct_complete = false;
|
|
|
|
}
|
|
|
|
|
2020-04-18 16:52:19 +00:00
|
|
|
dev->power.may_skip_resume = true;
|
2021-09-07 11:24:23 +00:00
|
|
|
dev->power.must_resume = !dev_pm_test_driver_flags(dev, DPM_FLAG_MAY_SKIP_RESUME);
|
2017-11-18 14:31:49 +00:00
|
|
|
|
2013-10-17 17:48:46 +00:00
|
|
|
dpm_watchdog_set(&wd, dev);
|
PM: Limit race conditions between runtime PM and system sleep (v2)
One of the roles of the PM core is to prevent different PM callbacks
executed for the same device object from racing with each other.
Unfortunately, after commit e8665002477f0278f84f898145b1f141ba26ee26
(PM: Allow pm_runtime_suspend() to succeed during system suspend)
runtime PM callbacks may be executed concurrently with system
suspend/resume callbacks for the same device.
The main reason for commit e8665002477f0278f84f898145b1f141ba26ee26
was that some subsystems and device drivers wanted to use runtime PM
helpers, pm_runtime_suspend() and pm_runtime_put_sync() in
particular, for carrying out the suspend of devices in their
.suspend() callbacks. However, as it's been determined recently,
there are multiple reasons not to do so, inlcuding:
* The caller really doesn't control the runtime PM usage counters,
because user space can access them through sysfs and effectively
block runtime PM. That means using pm_runtime_suspend() or
pm_runtime_get_sync() to suspend devices during system suspend
may or may not work.
* If a driver calls pm_runtime_suspend() from its .suspend()
callback, it causes the subsystem's .runtime_suspend() callback to
be executed, which leads to the call sequence:
subsys->suspend(dev)
driver->suspend(dev)
pm_runtime_suspend(dev)
subsys->runtime_suspend(dev)
recursive from the subsystem's point of view. For some subsystems
that may actually work (e.g. the platform bus type), but for some
it will fail in a rather spectacular fashion (e.g. PCI). In each
case it means a layering violation.
* Both the subsystem and the driver can provide .suspend_noirq()
callbacks for system suspend that can do whatever the
.runtime_suspend() callbacks do just fine, so it really isn't
necessary to call pm_runtime_suspend() during system suspend.
* The runtime PM's handling of wakeup devices is usually different
from the system suspend's one, so .runtime_suspend() may simply be
inappropriate for system suspend.
* System suspend is supposed to work even if CONFIG_PM_RUNTIME is
unset.
* The runtime PM workqueue is frozen before system suspend, so if
whatever the driver is going to do during system suspend depends
on it, that simply won't work.
Still, there is a good reason to allow pm_runtime_resume() to
succeed during system suspend and resume (for instance, some
subsystems and device drivers may legitimately use it to ensure that
their devices are in full-power states before suspending them).
Moreover, there is no reason to prevent runtime PM callbacks from
being executed in parallel with the system suspend/resume .prepare()
and .complete() callbacks and the code removed by commit
e8665002477f0278f84f898145b1f141ba26ee26 went too far in this
respect. On the other hand, runtime PM callbacks, including
.runtime_resume(), must not be executed during system suspend's
"late" stage of suspending devices and during system resume's "early"
device resume stage.
Taking all of the above into consideration, make the PM core
acquire a runtime PM reference to every device and resume it if
there's a runtime PM resume request pending right before executing
the subsystem-level .suspend() callback for it. Make the PM core
drop references to all devices right after executing the
subsystem-level .resume() callbacks for them. Additionally,
make the PM core disable the runtime PM framework for all devices
during system suspend, after executing the subsystem-level .suspend()
callbacks for them, and enable the runtime PM framework for all
devices during system resume, right before executing the
subsystem-level .resume() callbacks for them.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Kevin Hilman <khilman@ti.com>
2011-07-06 08:51:58 +00:00
|
|
|
device_lock(dev);
|
|
|
|
|
2011-06-22 23:52:55 +00:00
|
|
|
if (dev->pm_domain) {
|
2011-12-17 23:34:01 +00:00
|
|
|
info = "power domain ";
|
|
|
|
callback = pm_op(&dev->pm_domain->ops, state);
|
|
|
|
goto Run;
|
PM: Make power domain callbacks take precedence over subsystem ones
Change the PM core's behavior related to power domains in such a way
that, if a power domain is defined for a given device, its callbacks
will be executed instead of and not in addition to the device
subsystem's PM callbacks.
The idea behind the initial implementation of power domains handling
by the PM core was that power domain callbacks would be executed in
addition to subsystem callbacks, so that it would be possible to
extend the subsystem callbacks by using power domains. It turns out,
however, that this wouldn't be really convenient in some important
situations.
For example, there are systems in which power can only be removed
from entire power domains. On those systems it is not desirable to
execute device drivers' PM callbacks until it is known that power is
going to be removed from the devices in question, which means that
they should be executed by power domain callbacks rather then by
subsystem (e.g. bus type) PM callbacks, because subsystems generally
have no information about what devices belong to which power domain.
Thus, for instance, if the bus type in question is the platform bus
type, its PM callbacks generally should not be called in addition to
power domain callbacks, because they run device drivers' callbacks
unconditionally if defined.
While in principle the default subsystem PM callbacks, or a subset of
them, may be replaced with different functions, it doesn't seem
correct to do so, because that would change the subsystem's behavior
with respect to all devices in the system, regardless of whether or
not they belong to any power domains. Thus, the only remaining
option is to make power domain callbacks take precedence over
subsystem callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Kevin Hilman <khilman@ti.com>
2011-04-28 22:35:50 +00:00
|
|
|
}
|
|
|
|
|
PM: Make system-wide PM and runtime PM treat subsystems consistently
The code handling system-wide power transitions (eg. suspend-to-RAM)
can in theory execute callbacks provided by the device's bus type,
device type and class in each phase of the power transition. In
turn, the runtime PM core code only calls one of those callbacks at
a time, preferring bus type callbacks to device type or class
callbacks and device type callbacks to class callbacks.
It seems reasonable to make them both behave in the same way in that
respect. Moreover, even though a device may belong to two subsystems
(eg. bus type and device class) simultaneously, in practice power
management callbacks for system-wide power transitions are always
provided by only one of them (ie. if the bus type callbacks are
defined, the device class ones are not and vice versa). Thus it is
possible to modify the code handling system-wide power transitions
so that it follows the core runtime PM code (ie. treats the
subsystem callbacks as mutually exclusive).
On the other hand, the core runtime PM code will choose to execute,
for example, a runtime suspend callback provided by the device type
even if the bus type's struct dev_pm_ops object exists, but the
runtime_suspend pointer in it happens to be NULL. This is confusing,
because it may lead to the execution of callbacks from different
subsystems during different operations (eg. the bus type suspend
callback may be executed during runtime suspend of the device, while
the device type callback will be executed during system suspend).
Make all of the power management code treat subsystem callbacks in
a consistent way, such that:
(1) If the device's type is defined (eg. dev->type is not NULL)
and its pm pointer is not NULL, the callbacks from dev->type->pm
will be used.
(2) If dev->type is NULL or dev->type->pm is NULL, but the device's
class is defined (eg. dev->class is not NULL) and its pm pointer
is not NULL, the callbacks from dev->class->pm will be used.
(3) If dev->type is NULL or dev->type->pm is NULL and dev->class is
NULL or dev->class->pm is NULL, the callbacks from dev->bus->pm
will be used provided that both dev->bus and dev->bus->pm are
not NULL.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Kevin Hilman <khilman@ti.com>
Reasoning-sounds-sane-to: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-18 22:20:21 +00:00
|
|
|
if (dev->type && dev->type->pm) {
|
2011-12-17 23:34:01 +00:00
|
|
|
info = "type ";
|
|
|
|
callback = pm_op(dev->type->pm, state);
|
|
|
|
goto Run;
|
PM: Make system-wide PM and runtime PM treat subsystems consistently
The code handling system-wide power transitions (eg. suspend-to-RAM)
can in theory execute callbacks provided by the device's bus type,
device type and class in each phase of the power transition. In
turn, the runtime PM core code only calls one of those callbacks at
a time, preferring bus type callbacks to device type or class
callbacks and device type callbacks to class callbacks.
It seems reasonable to make them both behave in the same way in that
respect. Moreover, even though a device may belong to two subsystems
(eg. bus type and device class) simultaneously, in practice power
management callbacks for system-wide power transitions are always
provided by only one of them (ie. if the bus type callbacks are
defined, the device class ones are not and vice versa). Thus it is
possible to modify the code handling system-wide power transitions
so that it follows the core runtime PM code (ie. treats the
subsystem callbacks as mutually exclusive).
On the other hand, the core runtime PM code will choose to execute,
for example, a runtime suspend callback provided by the device type
even if the bus type's struct dev_pm_ops object exists, but the
runtime_suspend pointer in it happens to be NULL. This is confusing,
because it may lead to the execution of callbacks from different
subsystems during different operations (eg. the bus type suspend
callback may be executed during runtime suspend of the device, while
the device type callback will be executed during system suspend).
Make all of the power management code treat subsystem callbacks in
a consistent way, such that:
(1) If the device's type is defined (eg. dev->type is not NULL)
and its pm pointer is not NULL, the callbacks from dev->type->pm
will be used.
(2) If dev->type is NULL or dev->type->pm is NULL, but the device's
class is defined (eg. dev->class is not NULL) and its pm pointer
is not NULL, the callbacks from dev->class->pm will be used.
(3) If dev->type is NULL or dev->type->pm is NULL and dev->class is
NULL or dev->class->pm is NULL, the callbacks from dev->bus->pm
will be used provided that both dev->bus and dev->bus->pm are
not NULL.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Kevin Hilman <khilman@ti.com>
Reasoning-sounds-sane-to: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-18 22:20:21 +00:00
|
|
|
}
|
|
|
|
|
2017-09-25 12:56:44 +00:00
|
|
|
if (dev->class && dev->class->pm) {
|
|
|
|
info = "class ";
|
|
|
|
callback = pm_op(dev->class->pm, state);
|
|
|
|
goto Run;
|
2007-09-21 19:36:56 +00:00
|
|
|
}
|
|
|
|
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
if (dev->bus) {
|
|
|
|
if (dev->bus->pm) {
|
2011-12-17 23:34:13 +00:00
|
|
|
info = "bus ";
|
2011-12-17 23:34:01 +00:00
|
|
|
callback = pm_op(dev->bus->pm, state);
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
} else if (dev->bus->suspend) {
|
2011-12-17 23:34:13 +00:00
|
|
|
pm_dev_dbg(dev, state, "legacy bus ");
|
2013-07-26 19:30:20 +00:00
|
|
|
error = legacy_suspend(dev, state, dev->bus->suspend,
|
|
|
|
"legacy bus ");
|
2011-12-17 23:34:01 +00:00
|
|
|
goto End;
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
}
|
2011-02-16 20:53:17 +00:00
|
|
|
}
|
|
|
|
|
2011-12-17 23:34:01 +00:00
|
|
|
Run:
|
2011-12-17 23:34:13 +00:00
|
|
|
if (!callback && dev->driver && dev->driver->pm) {
|
|
|
|
info = "driver ";
|
|
|
|
callback = pm_op(dev->driver->pm, state);
|
|
|
|
}
|
|
|
|
|
2011-12-17 23:34:01 +00:00
|
|
|
error = dpm_run_callback(callback, dev, state, info);
|
|
|
|
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
End:
|
2011-10-16 21:34:36 +00:00
|
|
|
if (!error) {
|
|
|
|
dev->power.is_suspended = true;
|
2018-01-02 16:08:50 +00:00
|
|
|
if (device_may_wakeup(dev))
|
|
|
|
dev->power.wakeup_path = true;
|
|
|
|
|
2018-01-09 09:03:39 +00:00
|
|
|
dpm_propagate_wakeup_to_parent(dev);
|
|
|
|
dpm_clear_superiors_direct_complete(dev);
|
2011-10-16 21:34:36 +00:00
|
|
|
}
|
2011-06-18 20:42:09 +00:00
|
|
|
|
2010-02-17 18:57:05 +00:00
|
|
|
device_unlock(dev);
|
2013-10-17 17:48:46 +00:00
|
|
|
dpm_watchdog_clear(&wd);
|
2012-06-24 21:31:09 +00:00
|
|
|
|
|
|
|
Complete:
|
2012-09-19 19:59:02 +00:00
|
|
|
if (error)
|
2010-09-22 20:10:57 +00:00
|
|
|
async_error = error;
|
|
|
|
|
2016-12-07 14:40:32 +00:00
|
|
|
complete_all(&dev->power.completion);
|
2015-03-18 14:54:27 +00:00
|
|
|
TRACE_SUSPEND(error);
|
2007-09-21 19:36:56 +00:00
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
PM: Asynchronous suspend and resume of devices
Theoretically, the total time of system sleep transitions (suspend
to RAM, hibernation) can be reduced by running suspend and resume
callbacks of device drivers in parallel with each other. However,
there are dependencies between devices such that we're not allowed
to suspend the parent of a device before suspending the device
itself. Analogously, we're not allowed to resume a device before
resuming its parent.
The most straightforward way to take these dependencies into accout
is to start the async threads used for suspending and resuming
devices at the core level, so that async_schedule() is called for
each suspend and resume callback supposed to be executed
asynchronously.
For this purpose, introduce a new device flag, power.async_suspend,
used to mark the devices whose suspend and resume callbacks are to be
executed asynchronously (ie. in parallel with the main suspend/resume
thread and possibly in parallel with each other) and helper function
device_enable_async_suspend() allowing one to set power.async_suspend
for given device (power.async_suspend is unset by default for all
devices). For each device with the power.async_suspend flag set the
PM core will use async_schedule() to execute its suspend and resume
callbacks.
The async threads started for different devices as a result of
calling async_schedule() are synchronized with each other and with
the main suspend/resume thread with the help of completions, in the
following way:
(1) There is a completion, power.completion, for each device object.
(2) Each device's completion is reset before calling async_schedule()
for the device or, in the case of devices with the
power.async_suspend flags unset, before executing the device's
suspend and resume callbacks.
(3) During suspend, right before running the bus type, device type
and device class suspend callbacks for the device, the PM core
waits for the completions of all the device's children to be
completed.
(4) During resume, right before running the bus type, device type and
device class resume callbacks for the device, the PM core waits
for the completion of the device's parent to be completed.
(5) The PM core completes power.completion for each device right
after the bus type, device type and device class suspend (or
resume) callbacks executed for the device have returned.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-01-23 21:23:32 +00:00
|
|
|
static void async_suspend(void *data, async_cookie_t cookie)
|
|
|
|
{
|
|
|
|
struct device *dev = (struct device *)data;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
error = __device_suspend(dev, pm_transition, true);
|
PM / Suspend: Add statistics debugfs file for suspend to RAM
Record S3 failure time about each reason and the latest two failed
devices' names in S3 progress.
We can check it through 'suspend_stats' entry in debugfs.
The motivation of the patch:
We are enabling power features on Medfield. Comparing with PC/notebook,
a mobile enters/exits suspend-2-ram (we call it s3 on Medfield) far
more frequently. If it can't enter suspend-2-ram in time, the power
might be used up soon.
We often find sometimes, a device suspend fails. Then, system retries
s3 over and over again. As display is off, testers and developers
don't know what happens.
Some testers and developers complain they don't know if system
tries suspend-2-ram, and what device fails to suspend. They need
such info for a quick check. The patch adds suspend_stats under
debugfs for users to check suspend to RAM statistics quickly.
If not using this patch, we have other methods to get info about
what device fails. One is to turn on CONFIG_PM_DEBUG, but users
would get too much info and testers need recompile the system.
In addition, dynamic debug is another good tool to dump debug info.
But it still doesn't match our utilization scenario closely.
1) user need write a user space parser to process the syslog output;
2) Our testing scenario is we leave the mobile for at least hours.
Then, check its status. No serial console available during the
testing. One is because console would be suspended, and the other
is serial console connecting with spi or HSU devices would consume
power. These devices are powered off at suspend-2-ram.
Signed-off-by: ShuoX Liu <shuox.liu@intel.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-08-10 21:01:26 +00:00
|
|
|
if (error) {
|
|
|
|
dpm_save_failed_dev(dev_name(dev));
|
PM: Asynchronous suspend and resume of devices
Theoretically, the total time of system sleep transitions (suspend
to RAM, hibernation) can be reduced by running suspend and resume
callbacks of device drivers in parallel with each other. However,
there are dependencies between devices such that we're not allowed
to suspend the parent of a device before suspending the device
itself. Analogously, we're not allowed to resume a device before
resuming its parent.
The most straightforward way to take these dependencies into accout
is to start the async threads used for suspending and resuming
devices at the core level, so that async_schedule() is called for
each suspend and resume callback supposed to be executed
asynchronously.
For this purpose, introduce a new device flag, power.async_suspend,
used to mark the devices whose suspend and resume callbacks are to be
executed asynchronously (ie. in parallel with the main suspend/resume
thread and possibly in parallel with each other) and helper function
device_enable_async_suspend() allowing one to set power.async_suspend
for given device (power.async_suspend is unset by default for all
devices). For each device with the power.async_suspend flag set the
PM core will use async_schedule() to execute its suspend and resume
callbacks.
The async threads started for different devices as a result of
calling async_schedule() are synchronized with each other and with
the main suspend/resume thread with the help of completions, in the
following way:
(1) There is a completion, power.completion, for each device object.
(2) Each device's completion is reset before calling async_schedule()
for the device or, in the case of devices with the
power.async_suspend flags unset, before executing the device's
suspend and resume callbacks.
(3) During suspend, right before running the bus type, device type
and device class suspend callbacks for the device, the PM core
waits for the completions of all the device's children to be
completed.
(4) During resume, right before running the bus type, device type and
device class resume callbacks for the device, the PM core waits
for the completion of the device's parent to be completed.
(5) The PM core completes power.completion for each device right
after the bus type, device type and device class suspend (or
resume) callbacks executed for the device have returned.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-01-23 21:23:32 +00:00
|
|
|
pm_dev_err(dev, pm_transition, " async", error);
|
PM / Suspend: Add statistics debugfs file for suspend to RAM
Record S3 failure time about each reason and the latest two failed
devices' names in S3 progress.
We can check it through 'suspend_stats' entry in debugfs.
The motivation of the patch:
We are enabling power features on Medfield. Comparing with PC/notebook,
a mobile enters/exits suspend-2-ram (we call it s3 on Medfield) far
more frequently. If it can't enter suspend-2-ram in time, the power
might be used up soon.
We often find sometimes, a device suspend fails. Then, system retries
s3 over and over again. As display is off, testers and developers
don't know what happens.
Some testers and developers complain they don't know if system
tries suspend-2-ram, and what device fails to suspend. They need
such info for a quick check. The patch adds suspend_stats under
debugfs for users to check suspend to RAM statistics quickly.
If not using this patch, we have other methods to get info about
what device fails. One is to turn on CONFIG_PM_DEBUG, but users
would get too much info and testers need recompile the system.
In addition, dynamic debug is another good tool to dump debug info.
But it still doesn't match our utilization scenario closely.
1) user need write a user space parser to process the syslog output;
2) Our testing scenario is we leave the mobile for at least hours.
Then, check its status. No serial console available during the
testing. One is because console would be suspended, and the other
is serial console connecting with spi or HSU devices would consume
power. These devices are powered off at suspend-2-ram.
Signed-off-by: ShuoX Liu <shuox.liu@intel.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-08-10 21:01:26 +00:00
|
|
|
}
|
PM: Asynchronous suspend and resume of devices
Theoretically, the total time of system sleep transitions (suspend
to RAM, hibernation) can be reduced by running suspend and resume
callbacks of device drivers in parallel with each other. However,
there are dependencies between devices such that we're not allowed
to suspend the parent of a device before suspending the device
itself. Analogously, we're not allowed to resume a device before
resuming its parent.
The most straightforward way to take these dependencies into accout
is to start the async threads used for suspending and resuming
devices at the core level, so that async_schedule() is called for
each suspend and resume callback supposed to be executed
asynchronously.
For this purpose, introduce a new device flag, power.async_suspend,
used to mark the devices whose suspend and resume callbacks are to be
executed asynchronously (ie. in parallel with the main suspend/resume
thread and possibly in parallel with each other) and helper function
device_enable_async_suspend() allowing one to set power.async_suspend
for given device (power.async_suspend is unset by default for all
devices). For each device with the power.async_suspend flag set the
PM core will use async_schedule() to execute its suspend and resume
callbacks.
The async threads started for different devices as a result of
calling async_schedule() are synchronized with each other and with
the main suspend/resume thread with the help of completions, in the
following way:
(1) There is a completion, power.completion, for each device object.
(2) Each device's completion is reset before calling async_schedule()
for the device or, in the case of devices with the
power.async_suspend flags unset, before executing the device's
suspend and resume callbacks.
(3) During suspend, right before running the bus type, device type
and device class suspend callbacks for the device, the PM core
waits for the completions of all the device's children to be
completed.
(4) During resume, right before running the bus type, device type and
device class resume callbacks for the device, the PM core waits
for the completion of the device's parent to be completed.
(5) The PM core completes power.completion for each device right
after the bus type, device type and device class suspend (or
resume) callbacks executed for the device have returned.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-01-23 21:23:32 +00:00
|
|
|
|
|
|
|
put_device(dev);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int device_suspend(struct device *dev)
|
|
|
|
{
|
2019-03-16 04:59:25 +00:00
|
|
|
if (dpm_async_fn(dev, async_suspend))
|
PM: Asynchronous suspend and resume of devices
Theoretically, the total time of system sleep transitions (suspend
to RAM, hibernation) can be reduced by running suspend and resume
callbacks of device drivers in parallel with each other. However,
there are dependencies between devices such that we're not allowed
to suspend the parent of a device before suspending the device
itself. Analogously, we're not allowed to resume a device before
resuming its parent.
The most straightforward way to take these dependencies into accout
is to start the async threads used for suspending and resuming
devices at the core level, so that async_schedule() is called for
each suspend and resume callback supposed to be executed
asynchronously.
For this purpose, introduce a new device flag, power.async_suspend,
used to mark the devices whose suspend and resume callbacks are to be
executed asynchronously (ie. in parallel with the main suspend/resume
thread and possibly in parallel with each other) and helper function
device_enable_async_suspend() allowing one to set power.async_suspend
for given device (power.async_suspend is unset by default for all
devices). For each device with the power.async_suspend flag set the
PM core will use async_schedule() to execute its suspend and resume
callbacks.
The async threads started for different devices as a result of
calling async_schedule() are synchronized with each other and with
the main suspend/resume thread with the help of completions, in the
following way:
(1) There is a completion, power.completion, for each device object.
(2) Each device's completion is reset before calling async_schedule()
for the device or, in the case of devices with the
power.async_suspend flags unset, before executing the device's
suspend and resume callbacks.
(3) During suspend, right before running the bus type, device type
and device class suspend callbacks for the device, the PM core
waits for the completions of all the device's children to be
completed.
(4) During resume, right before running the bus type, device type and
device class resume callbacks for the device, the PM core waits
for the completion of the device's parent to be completed.
(5) The PM core completes power.completion for each device right
after the bus type, device type and device class suspend (or
resume) callbacks executed for the device have returned.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-01-23 21:23:32 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
return __device_suspend(dev, pm_transition, false);
|
|
|
|
}
|
|
|
|
|
2007-09-21 19:36:56 +00:00
|
|
|
/**
|
2009-08-20 18:25:52 +00:00
|
|
|
* dpm_suspend - Execute "suspend" callbacks for all non-sysdev devices.
|
|
|
|
* @state: PM transition of the system being carried out.
|
2007-09-21 19:36:56 +00:00
|
|
|
*/
|
2011-05-17 21:26:00 +00:00
|
|
|
int dpm_suspend(pm_message_t state)
|
2007-09-21 19:36:56 +00:00
|
|
|
{
|
2009-12-18 00:57:47 +00:00
|
|
|
ktime_t starttime = ktime_get();
|
2007-09-21 19:36:56 +00:00
|
|
|
int error = 0;
|
|
|
|
|
2014-06-06 12:40:17 +00:00
|
|
|
trace_suspend_resume(TPS("dpm_suspend"), state.event, true);
|
2011-05-17 21:26:00 +00:00
|
|
|
might_sleep();
|
|
|
|
|
2018-12-05 11:05:55 +00:00
|
|
|
devfreq_suspend();
|
2014-03-04 03:00:26 +00:00
|
|
|
cpufreq_suspend();
|
|
|
|
|
2007-09-21 19:36:56 +00:00
|
|
|
mutex_lock(&dpm_list_mtx);
|
PM: Asynchronous suspend and resume of devices
Theoretically, the total time of system sleep transitions (suspend
to RAM, hibernation) can be reduced by running suspend and resume
callbacks of device drivers in parallel with each other. However,
there are dependencies between devices such that we're not allowed
to suspend the parent of a device before suspending the device
itself. Analogously, we're not allowed to resume a device before
resuming its parent.
The most straightforward way to take these dependencies into accout
is to start the async threads used for suspending and resuming
devices at the core level, so that async_schedule() is called for
each suspend and resume callback supposed to be executed
asynchronously.
For this purpose, introduce a new device flag, power.async_suspend,
used to mark the devices whose suspend and resume callbacks are to be
executed asynchronously (ie. in parallel with the main suspend/resume
thread and possibly in parallel with each other) and helper function
device_enable_async_suspend() allowing one to set power.async_suspend
for given device (power.async_suspend is unset by default for all
devices). For each device with the power.async_suspend flag set the
PM core will use async_schedule() to execute its suspend and resume
callbacks.
The async threads started for different devices as a result of
calling async_schedule() are synchronized with each other and with
the main suspend/resume thread with the help of completions, in the
following way:
(1) There is a completion, power.completion, for each device object.
(2) Each device's completion is reset before calling async_schedule()
for the device or, in the case of devices with the
power.async_suspend flags unset, before executing the device's
suspend and resume callbacks.
(3) During suspend, right before running the bus type, device type
and device class suspend callbacks for the device, the PM core
waits for the completions of all the device's children to be
completed.
(4) During resume, right before running the bus type, device type and
device class resume callbacks for the device, the PM core waits
for the completion of the device's parent to be completed.
(5) The PM core completes power.completion for each device right
after the bus type, device type and device class suspend (or
resume) callbacks executed for the device have returned.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-01-23 21:23:32 +00:00
|
|
|
pm_transition = state;
|
|
|
|
async_error = 0;
|
2010-12-15 23:50:30 +00:00
|
|
|
while (!list_empty(&dpm_prepared_list)) {
|
|
|
|
struct device *dev = to_device(dpm_prepared_list.prev);
|
PM: Handle device registrations during suspend/resume
Modify the PM core to protect its data structures, specifically the
dpm_active list, from being corrupted if a child of the currently
suspending device is registered concurrently with its ->suspend()
callback. In that case, since the new device (the child) is added
to dpm_active after its parent, the PM core will attempt to
suspend it after the parent, which is wrong.
Introduce a new member of struct dev_pm_info, called 'sleeping',
and use it to check if the parent of the device being added to
dpm_active has been suspended, in which case the device registration
fails. Also, use 'sleeping' for checking if the ordering of devices
on dpm_active is correct.
Introduce variable 'all_sleeping' that will be set to 'true' once all
devices have been suspended and make new device registrations fail
until 'all_sleeping' is reset to 'false', in order to avoid having
unsuspended devices around while the system is going into a sleep state.
Remove pm_sleep_rwsem which is not necessary any more.
Special thanks to Alan Stern for discussions and suggestions that
lead to the creation of this patch.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-11 23:57:22 +00:00
|
|
|
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
get_device(dev);
|
PM: sleep: Avoid calling put_device() under dpm_list_mtx
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
[ 3290.969514] ======================================================
[ 3290.969517] WARNING: possible circular locking dependency detected
[ 3290.969519] 5.15.0+ #2420 Tainted: G S
[ 3290.969523] ------------------------------------------------------
[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
[ 3290.969554]
but task is already holding lock:
[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.969571]
which lock already depends on the new lock.
[ 3290.969573]
the existing dependency chain (in reverse order) is:
[ 3290.969575]
-> #3 (dpm_list_mtx){+.+.}-{3:3}:
[ 3290.969583] __mutex_lock+0x9d/0xa30
[ 3290.969591] device_pm_add+0x2e/0xe0
[ 3290.969597] device_add+0x4d5/0x8f0
[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969842] process_one_work+0x2aa/0x650
[ 3290.969851] worker_thread+0x39/0x400
[ 3290.969859] kthread+0x142/0x170
[ 3290.969865] ret_from_fork+0x22/0x30
[ 3290.969872]
-> #2 (&hdev->lock){+.+.}-{3:3}:
[ 3290.969881] __mutex_lock+0x9d/0xa30
[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969978] process_one_work+0x2aa/0x650
[ 3290.969985] worker_thread+0x39/0x400
[ 3290.969993] kthread+0x142/0x170
[ 3290.969999] ret_from_fork+0x22/0x30
[ 3290.970004]
-> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
[ 3290.970013] process_one_work+0x27d/0x650
[ 3290.970020] worker_thread+0x39/0x400
[ 3290.970028] kthread+0x142/0x170
[ 3290.970033] ret_from_fork+0x22/0x30
[ 3290.970038]
-> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
[ 3290.970047] __lock_acquire+0x15cb/0x1b50
[ 3290.970054] lock_acquire+0x26c/0x300
[ 3290.970059] flush_workqueue+0xae/0x4a0
[ 3290.970066] drain_workqueue+0xa1/0x130
[ 3290.970073] destroy_workqueue+0x34/0x1f0
[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970195] device_release+0x33/0x90
[ 3290.970201] kobject_release+0x63/0x160
[ 3290.970211] dpm_resume+0x164/0x3e0
[ 3290.970215] dpm_resume_end+0xd/0x20
[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970229] pm_suspend+0x26b/0x310
[ 3290.970236] state_store+0x42/0x90
[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970251] new_sync_write+0x125/0x1c0
[ 3290.970257] vfs_write+0x360/0x3c0
[ 3290.970263] ksys_write+0xa7/0xe0
[ 3290.970269] do_syscall_64+0x3a/0x80
[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970284]
other info that might help us debug this:
[ 3290.970285] Chain exists of:
(wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
[ 3290.970297] Possible unsafe locking scenario:
[ 3290.970299] CPU0 CPU1
[ 3290.970300] ---- ----
[ 3290.970302] lock(dpm_list_mtx);
[ 3290.970306] lock(&hdev->lock);
[ 3290.970310] lock(dpm_list_mtx);
[ 3290.970314] lock((wq_completion)hci0#2);
[ 3290.970319]
*** DEADLOCK ***
[ 3290.970321] 7 locks held by systemd-sleep/4553:
[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.970428]
stack backtrace:
[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
[ 3290.970441] Call Trace:
[ 3290.970446] dump_stack_lvl+0x44/0x57
[ 3290.970454] check_noncircular+0x105/0x120
[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
[ 3290.970474] __lock_acquire+0x15cb/0x1b50
[ 3290.970487] lock_acquire+0x26c/0x300
[ 3290.970493] ? flush_workqueue+0x87/0x4a0
[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
[ 3290.970519] flush_workqueue+0xae/0x4a0
[ 3290.970526] ? flush_workqueue+0x87/0x4a0
[ 3290.970544] ? drain_workqueue+0xa1/0x130
[ 3290.970552] drain_workqueue+0xa1/0x130
[ 3290.970561] destroy_workqueue+0x34/0x1f0
[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970687] device_release+0x33/0x90
[ 3290.970695] kobject_release+0x63/0x160
[ 3290.970705] dpm_resume+0x164/0x3e0
[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
[ 3290.970718] dpm_resume_end+0xd/0x20
[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970737] pm_suspend+0x26b/0x310
[ 3290.970746] state_store+0x42/0x90
[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970764] new_sync_write+0x125/0x1c0
[ 3290.970777] vfs_write+0x360/0x3c0
[ 3290.970785] ksys_write+0xa7/0xe0
[ 3290.970794] do_syscall_64+0x3a/0x80
[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970811] RIP: 0033:0x7f41b1328164
[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-11-04 17:26:26 +00:00
|
|
|
|
2007-09-21 19:36:56 +00:00
|
|
|
mutex_unlock(&dpm_list_mtx);
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
|
PM: Asynchronous suspend and resume of devices
Theoretically, the total time of system sleep transitions (suspend
to RAM, hibernation) can be reduced by running suspend and resume
callbacks of device drivers in parallel with each other. However,
there are dependencies between devices such that we're not allowed
to suspend the parent of a device before suspending the device
itself. Analogously, we're not allowed to resume a device before
resuming its parent.
The most straightforward way to take these dependencies into accout
is to start the async threads used for suspending and resuming
devices at the core level, so that async_schedule() is called for
each suspend and resume callback supposed to be executed
asynchronously.
For this purpose, introduce a new device flag, power.async_suspend,
used to mark the devices whose suspend and resume callbacks are to be
executed asynchronously (ie. in parallel with the main suspend/resume
thread and possibly in parallel with each other) and helper function
device_enable_async_suspend() allowing one to set power.async_suspend
for given device (power.async_suspend is unset by default for all
devices). For each device with the power.async_suspend flag set the
PM core will use async_schedule() to execute its suspend and resume
callbacks.
The async threads started for different devices as a result of
calling async_schedule() are synchronized with each other and with
the main suspend/resume thread with the help of completions, in the
following way:
(1) There is a completion, power.completion, for each device object.
(2) Each device's completion is reset before calling async_schedule()
for the device or, in the case of devices with the
power.async_suspend flags unset, before executing the device's
suspend and resume callbacks.
(3) During suspend, right before running the bus type, device type
and device class suspend callbacks for the device, the PM core
waits for the completions of all the device's children to be
completed.
(4) During resume, right before running the bus type, device type and
device class resume callbacks for the device, the PM core waits
for the completion of the device's parent to be completed.
(5) The PM core completes power.completion for each device right
after the bus type, device type and device class suspend (or
resume) callbacks executed for the device have returned.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-01-23 21:23:32 +00:00
|
|
|
error = device_suspend(dev);
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
|
2008-02-29 16:50:22 +00:00
|
|
|
mutex_lock(&dpm_list_mtx);
|
PM: sleep: Avoid calling put_device() under dpm_list_mtx
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
[ 3290.969514] ======================================================
[ 3290.969517] WARNING: possible circular locking dependency detected
[ 3290.969519] 5.15.0+ #2420 Tainted: G S
[ 3290.969523] ------------------------------------------------------
[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
[ 3290.969554]
but task is already holding lock:
[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.969571]
which lock already depends on the new lock.
[ 3290.969573]
the existing dependency chain (in reverse order) is:
[ 3290.969575]
-> #3 (dpm_list_mtx){+.+.}-{3:3}:
[ 3290.969583] __mutex_lock+0x9d/0xa30
[ 3290.969591] device_pm_add+0x2e/0xe0
[ 3290.969597] device_add+0x4d5/0x8f0
[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969842] process_one_work+0x2aa/0x650
[ 3290.969851] worker_thread+0x39/0x400
[ 3290.969859] kthread+0x142/0x170
[ 3290.969865] ret_from_fork+0x22/0x30
[ 3290.969872]
-> #2 (&hdev->lock){+.+.}-{3:3}:
[ 3290.969881] __mutex_lock+0x9d/0xa30
[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969978] process_one_work+0x2aa/0x650
[ 3290.969985] worker_thread+0x39/0x400
[ 3290.969993] kthread+0x142/0x170
[ 3290.969999] ret_from_fork+0x22/0x30
[ 3290.970004]
-> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
[ 3290.970013] process_one_work+0x27d/0x650
[ 3290.970020] worker_thread+0x39/0x400
[ 3290.970028] kthread+0x142/0x170
[ 3290.970033] ret_from_fork+0x22/0x30
[ 3290.970038]
-> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
[ 3290.970047] __lock_acquire+0x15cb/0x1b50
[ 3290.970054] lock_acquire+0x26c/0x300
[ 3290.970059] flush_workqueue+0xae/0x4a0
[ 3290.970066] drain_workqueue+0xa1/0x130
[ 3290.970073] destroy_workqueue+0x34/0x1f0
[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970195] device_release+0x33/0x90
[ 3290.970201] kobject_release+0x63/0x160
[ 3290.970211] dpm_resume+0x164/0x3e0
[ 3290.970215] dpm_resume_end+0xd/0x20
[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970229] pm_suspend+0x26b/0x310
[ 3290.970236] state_store+0x42/0x90
[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970251] new_sync_write+0x125/0x1c0
[ 3290.970257] vfs_write+0x360/0x3c0
[ 3290.970263] ksys_write+0xa7/0xe0
[ 3290.970269] do_syscall_64+0x3a/0x80
[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970284]
other info that might help us debug this:
[ 3290.970285] Chain exists of:
(wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
[ 3290.970297] Possible unsafe locking scenario:
[ 3290.970299] CPU0 CPU1
[ 3290.970300] ---- ----
[ 3290.970302] lock(dpm_list_mtx);
[ 3290.970306] lock(&hdev->lock);
[ 3290.970310] lock(dpm_list_mtx);
[ 3290.970314] lock((wq_completion)hci0#2);
[ 3290.970319]
*** DEADLOCK ***
[ 3290.970321] 7 locks held by systemd-sleep/4553:
[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.970428]
stack backtrace:
[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
[ 3290.970441] Call Trace:
[ 3290.970446] dump_stack_lvl+0x44/0x57
[ 3290.970454] check_noncircular+0x105/0x120
[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
[ 3290.970474] __lock_acquire+0x15cb/0x1b50
[ 3290.970487] lock_acquire+0x26c/0x300
[ 3290.970493] ? flush_workqueue+0x87/0x4a0
[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
[ 3290.970519] flush_workqueue+0xae/0x4a0
[ 3290.970526] ? flush_workqueue+0x87/0x4a0
[ 3290.970544] ? drain_workqueue+0xa1/0x130
[ 3290.970552] drain_workqueue+0xa1/0x130
[ 3290.970561] destroy_workqueue+0x34/0x1f0
[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970687] device_release+0x33/0x90
[ 3290.970695] kobject_release+0x63/0x160
[ 3290.970705] dpm_resume+0x164/0x3e0
[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
[ 3290.970718] dpm_resume_end+0xd/0x20
[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970737] pm_suspend+0x26b/0x310
[ 3290.970746] state_store+0x42/0x90
[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970764] new_sync_write+0x125/0x1c0
[ 3290.970777] vfs_write+0x360/0x3c0
[ 3290.970785] ksys_write+0xa7/0xe0
[ 3290.970794] do_syscall_64+0x3a/0x80
[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970811] RIP: 0033:0x7f41b1328164
[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-11-04 17:26:26 +00:00
|
|
|
|
2008-01-12 19:40:46 +00:00
|
|
|
if (error) {
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
pm_dev_err(dev, state, "", error);
|
PM / Suspend: Add statistics debugfs file for suspend to RAM
Record S3 failure time about each reason and the latest two failed
devices' names in S3 progress.
We can check it through 'suspend_stats' entry in debugfs.
The motivation of the patch:
We are enabling power features on Medfield. Comparing with PC/notebook,
a mobile enters/exits suspend-2-ram (we call it s3 on Medfield) far
more frequently. If it can't enter suspend-2-ram in time, the power
might be used up soon.
We often find sometimes, a device suspend fails. Then, system retries
s3 over and over again. As display is off, testers and developers
don't know what happens.
Some testers and developers complain they don't know if system
tries suspend-2-ram, and what device fails to suspend. They need
such info for a quick check. The patch adds suspend_stats under
debugfs for users to check suspend to RAM statistics quickly.
If not using this patch, we have other methods to get info about
what device fails. One is to turn on CONFIG_PM_DEBUG, but users
would get too much info and testers need recompile the system.
In addition, dynamic debug is another good tool to dump debug info.
But it still doesn't match our utilization scenario closely.
1) user need write a user space parser to process the syslog output;
2) Our testing scenario is we leave the mobile for at least hours.
Then, check its status. No serial console available during the
testing. One is because console would be suspended, and the other
is serial console connecting with spi or HSU devices would consume
power. These devices are powered off at suspend-2-ram.
Signed-off-by: ShuoX Liu <shuox.liu@intel.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-08-10 21:01:26 +00:00
|
|
|
dpm_save_failed_dev(dev_name(dev));
|
PM: sleep: Avoid calling put_device() under dpm_list_mtx
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
[ 3290.969514] ======================================================
[ 3290.969517] WARNING: possible circular locking dependency detected
[ 3290.969519] 5.15.0+ #2420 Tainted: G S
[ 3290.969523] ------------------------------------------------------
[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
[ 3290.969554]
but task is already holding lock:
[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.969571]
which lock already depends on the new lock.
[ 3290.969573]
the existing dependency chain (in reverse order) is:
[ 3290.969575]
-> #3 (dpm_list_mtx){+.+.}-{3:3}:
[ 3290.969583] __mutex_lock+0x9d/0xa30
[ 3290.969591] device_pm_add+0x2e/0xe0
[ 3290.969597] device_add+0x4d5/0x8f0
[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969842] process_one_work+0x2aa/0x650
[ 3290.969851] worker_thread+0x39/0x400
[ 3290.969859] kthread+0x142/0x170
[ 3290.969865] ret_from_fork+0x22/0x30
[ 3290.969872]
-> #2 (&hdev->lock){+.+.}-{3:3}:
[ 3290.969881] __mutex_lock+0x9d/0xa30
[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969978] process_one_work+0x2aa/0x650
[ 3290.969985] worker_thread+0x39/0x400
[ 3290.969993] kthread+0x142/0x170
[ 3290.969999] ret_from_fork+0x22/0x30
[ 3290.970004]
-> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
[ 3290.970013] process_one_work+0x27d/0x650
[ 3290.970020] worker_thread+0x39/0x400
[ 3290.970028] kthread+0x142/0x170
[ 3290.970033] ret_from_fork+0x22/0x30
[ 3290.970038]
-> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
[ 3290.970047] __lock_acquire+0x15cb/0x1b50
[ 3290.970054] lock_acquire+0x26c/0x300
[ 3290.970059] flush_workqueue+0xae/0x4a0
[ 3290.970066] drain_workqueue+0xa1/0x130
[ 3290.970073] destroy_workqueue+0x34/0x1f0
[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970195] device_release+0x33/0x90
[ 3290.970201] kobject_release+0x63/0x160
[ 3290.970211] dpm_resume+0x164/0x3e0
[ 3290.970215] dpm_resume_end+0xd/0x20
[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970229] pm_suspend+0x26b/0x310
[ 3290.970236] state_store+0x42/0x90
[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970251] new_sync_write+0x125/0x1c0
[ 3290.970257] vfs_write+0x360/0x3c0
[ 3290.970263] ksys_write+0xa7/0xe0
[ 3290.970269] do_syscall_64+0x3a/0x80
[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970284]
other info that might help us debug this:
[ 3290.970285] Chain exists of:
(wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
[ 3290.970297] Possible unsafe locking scenario:
[ 3290.970299] CPU0 CPU1
[ 3290.970300] ---- ----
[ 3290.970302] lock(dpm_list_mtx);
[ 3290.970306] lock(&hdev->lock);
[ 3290.970310] lock(dpm_list_mtx);
[ 3290.970314] lock((wq_completion)hci0#2);
[ 3290.970319]
*** DEADLOCK ***
[ 3290.970321] 7 locks held by systemd-sleep/4553:
[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.970428]
stack backtrace:
[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
[ 3290.970441] Call Trace:
[ 3290.970446] dump_stack_lvl+0x44/0x57
[ 3290.970454] check_noncircular+0x105/0x120
[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
[ 3290.970474] __lock_acquire+0x15cb/0x1b50
[ 3290.970487] lock_acquire+0x26c/0x300
[ 3290.970493] ? flush_workqueue+0x87/0x4a0
[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
[ 3290.970519] flush_workqueue+0xae/0x4a0
[ 3290.970526] ? flush_workqueue+0x87/0x4a0
[ 3290.970544] ? drain_workqueue+0xa1/0x130
[ 3290.970552] drain_workqueue+0xa1/0x130
[ 3290.970561] destroy_workqueue+0x34/0x1f0
[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970687] device_release+0x33/0x90
[ 3290.970695] kobject_release+0x63/0x160
[ 3290.970705] dpm_resume+0x164/0x3e0
[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
[ 3290.970718] dpm_resume_end+0xd/0x20
[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970737] pm_suspend+0x26b/0x310
[ 3290.970746] state_store+0x42/0x90
[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970764] new_sync_write+0x125/0x1c0
[ 3290.970777] vfs_write+0x360/0x3c0
[ 3290.970785] ksys_write+0xa7/0xe0
[ 3290.970794] do_syscall_64+0x3a/0x80
[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970811] RIP: 0033:0x7f41b1328164
[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-11-04 17:26:26 +00:00
|
|
|
} else if (!list_empty(&dev->power.entry)) {
|
2010-12-15 23:50:30 +00:00
|
|
|
list_move(&dev->power.entry, &dpm_suspended_list);
|
PM: sleep: Avoid calling put_device() under dpm_list_mtx
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
[ 3290.969514] ======================================================
[ 3290.969517] WARNING: possible circular locking dependency detected
[ 3290.969519] 5.15.0+ #2420 Tainted: G S
[ 3290.969523] ------------------------------------------------------
[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
[ 3290.969554]
but task is already holding lock:
[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.969571]
which lock already depends on the new lock.
[ 3290.969573]
the existing dependency chain (in reverse order) is:
[ 3290.969575]
-> #3 (dpm_list_mtx){+.+.}-{3:3}:
[ 3290.969583] __mutex_lock+0x9d/0xa30
[ 3290.969591] device_pm_add+0x2e/0xe0
[ 3290.969597] device_add+0x4d5/0x8f0
[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969842] process_one_work+0x2aa/0x650
[ 3290.969851] worker_thread+0x39/0x400
[ 3290.969859] kthread+0x142/0x170
[ 3290.969865] ret_from_fork+0x22/0x30
[ 3290.969872]
-> #2 (&hdev->lock){+.+.}-{3:3}:
[ 3290.969881] __mutex_lock+0x9d/0xa30
[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969978] process_one_work+0x2aa/0x650
[ 3290.969985] worker_thread+0x39/0x400
[ 3290.969993] kthread+0x142/0x170
[ 3290.969999] ret_from_fork+0x22/0x30
[ 3290.970004]
-> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
[ 3290.970013] process_one_work+0x27d/0x650
[ 3290.970020] worker_thread+0x39/0x400
[ 3290.970028] kthread+0x142/0x170
[ 3290.970033] ret_from_fork+0x22/0x30
[ 3290.970038]
-> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
[ 3290.970047] __lock_acquire+0x15cb/0x1b50
[ 3290.970054] lock_acquire+0x26c/0x300
[ 3290.970059] flush_workqueue+0xae/0x4a0
[ 3290.970066] drain_workqueue+0xa1/0x130
[ 3290.970073] destroy_workqueue+0x34/0x1f0
[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970195] device_release+0x33/0x90
[ 3290.970201] kobject_release+0x63/0x160
[ 3290.970211] dpm_resume+0x164/0x3e0
[ 3290.970215] dpm_resume_end+0xd/0x20
[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970229] pm_suspend+0x26b/0x310
[ 3290.970236] state_store+0x42/0x90
[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970251] new_sync_write+0x125/0x1c0
[ 3290.970257] vfs_write+0x360/0x3c0
[ 3290.970263] ksys_write+0xa7/0xe0
[ 3290.970269] do_syscall_64+0x3a/0x80
[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970284]
other info that might help us debug this:
[ 3290.970285] Chain exists of:
(wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
[ 3290.970297] Possible unsafe locking scenario:
[ 3290.970299] CPU0 CPU1
[ 3290.970300] ---- ----
[ 3290.970302] lock(dpm_list_mtx);
[ 3290.970306] lock(&hdev->lock);
[ 3290.970310] lock(dpm_list_mtx);
[ 3290.970314] lock((wq_completion)hci0#2);
[ 3290.970319]
*** DEADLOCK ***
[ 3290.970321] 7 locks held by systemd-sleep/4553:
[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.970428]
stack backtrace:
[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
[ 3290.970441] Call Trace:
[ 3290.970446] dump_stack_lvl+0x44/0x57
[ 3290.970454] check_noncircular+0x105/0x120
[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
[ 3290.970474] __lock_acquire+0x15cb/0x1b50
[ 3290.970487] lock_acquire+0x26c/0x300
[ 3290.970493] ? flush_workqueue+0x87/0x4a0
[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
[ 3290.970519] flush_workqueue+0xae/0x4a0
[ 3290.970526] ? flush_workqueue+0x87/0x4a0
[ 3290.970544] ? drain_workqueue+0xa1/0x130
[ 3290.970552] drain_workqueue+0xa1/0x130
[ 3290.970561] destroy_workqueue+0x34/0x1f0
[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970687] device_release+0x33/0x90
[ 3290.970695] kobject_release+0x63/0x160
[ 3290.970705] dpm_resume+0x164/0x3e0
[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
[ 3290.970718] dpm_resume_end+0xd/0x20
[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970737] pm_suspend+0x26b/0x310
[ 3290.970746] state_store+0x42/0x90
[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970764] new_sync_write+0x125/0x1c0
[ 3290.970777] vfs_write+0x360/0x3c0
[ 3290.970785] ksys_write+0xa7/0xe0
[ 3290.970794] do_syscall_64+0x3a/0x80
[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970811] RIP: 0033:0x7f41b1328164
[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-11-04 17:26:26 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
mutex_unlock(&dpm_list_mtx);
|
|
|
|
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
put_device(dev);
|
PM: sleep: Avoid calling put_device() under dpm_list_mtx
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
[ 3290.969514] ======================================================
[ 3290.969517] WARNING: possible circular locking dependency detected
[ 3290.969519] 5.15.0+ #2420 Tainted: G S
[ 3290.969523] ------------------------------------------------------
[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
[ 3290.969554]
but task is already holding lock:
[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.969571]
which lock already depends on the new lock.
[ 3290.969573]
the existing dependency chain (in reverse order) is:
[ 3290.969575]
-> #3 (dpm_list_mtx){+.+.}-{3:3}:
[ 3290.969583] __mutex_lock+0x9d/0xa30
[ 3290.969591] device_pm_add+0x2e/0xe0
[ 3290.969597] device_add+0x4d5/0x8f0
[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969842] process_one_work+0x2aa/0x650
[ 3290.969851] worker_thread+0x39/0x400
[ 3290.969859] kthread+0x142/0x170
[ 3290.969865] ret_from_fork+0x22/0x30
[ 3290.969872]
-> #2 (&hdev->lock){+.+.}-{3:3}:
[ 3290.969881] __mutex_lock+0x9d/0xa30
[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969978] process_one_work+0x2aa/0x650
[ 3290.969985] worker_thread+0x39/0x400
[ 3290.969993] kthread+0x142/0x170
[ 3290.969999] ret_from_fork+0x22/0x30
[ 3290.970004]
-> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
[ 3290.970013] process_one_work+0x27d/0x650
[ 3290.970020] worker_thread+0x39/0x400
[ 3290.970028] kthread+0x142/0x170
[ 3290.970033] ret_from_fork+0x22/0x30
[ 3290.970038]
-> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
[ 3290.970047] __lock_acquire+0x15cb/0x1b50
[ 3290.970054] lock_acquire+0x26c/0x300
[ 3290.970059] flush_workqueue+0xae/0x4a0
[ 3290.970066] drain_workqueue+0xa1/0x130
[ 3290.970073] destroy_workqueue+0x34/0x1f0
[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970195] device_release+0x33/0x90
[ 3290.970201] kobject_release+0x63/0x160
[ 3290.970211] dpm_resume+0x164/0x3e0
[ 3290.970215] dpm_resume_end+0xd/0x20
[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970229] pm_suspend+0x26b/0x310
[ 3290.970236] state_store+0x42/0x90
[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970251] new_sync_write+0x125/0x1c0
[ 3290.970257] vfs_write+0x360/0x3c0
[ 3290.970263] ksys_write+0xa7/0xe0
[ 3290.970269] do_syscall_64+0x3a/0x80
[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970284]
other info that might help us debug this:
[ 3290.970285] Chain exists of:
(wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
[ 3290.970297] Possible unsafe locking scenario:
[ 3290.970299] CPU0 CPU1
[ 3290.970300] ---- ----
[ 3290.970302] lock(dpm_list_mtx);
[ 3290.970306] lock(&hdev->lock);
[ 3290.970310] lock(dpm_list_mtx);
[ 3290.970314] lock((wq_completion)hci0#2);
[ 3290.970319]
*** DEADLOCK ***
[ 3290.970321] 7 locks held by systemd-sleep/4553:
[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.970428]
stack backtrace:
[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
[ 3290.970441] Call Trace:
[ 3290.970446] dump_stack_lvl+0x44/0x57
[ 3290.970454] check_noncircular+0x105/0x120
[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
[ 3290.970474] __lock_acquire+0x15cb/0x1b50
[ 3290.970487] lock_acquire+0x26c/0x300
[ 3290.970493] ? flush_workqueue+0x87/0x4a0
[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
[ 3290.970519] flush_workqueue+0xae/0x4a0
[ 3290.970526] ? flush_workqueue+0x87/0x4a0
[ 3290.970544] ? drain_workqueue+0xa1/0x130
[ 3290.970552] drain_workqueue+0xa1/0x130
[ 3290.970561] destroy_workqueue+0x34/0x1f0
[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970687] device_release+0x33/0x90
[ 3290.970695] kobject_release+0x63/0x160
[ 3290.970705] dpm_resume+0x164/0x3e0
[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
[ 3290.970718] dpm_resume_end+0xd/0x20
[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970737] pm_suspend+0x26b/0x310
[ 3290.970746] state_store+0x42/0x90
[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970764] new_sync_write+0x125/0x1c0
[ 3290.970777] vfs_write+0x360/0x3c0
[ 3290.970785] ksys_write+0xa7/0xe0
[ 3290.970794] do_syscall_64+0x3a/0x80
[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970811] RIP: 0033:0x7f41b1328164
[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-11-04 17:26:26 +00:00
|
|
|
|
|
|
|
mutex_lock(&dpm_list_mtx);
|
|
|
|
|
|
|
|
if (error || async_error)
|
PM: Asynchronous suspend and resume of devices
Theoretically, the total time of system sleep transitions (suspend
to RAM, hibernation) can be reduced by running suspend and resume
callbacks of device drivers in parallel with each other. However,
there are dependencies between devices such that we're not allowed
to suspend the parent of a device before suspending the device
itself. Analogously, we're not allowed to resume a device before
resuming its parent.
The most straightforward way to take these dependencies into accout
is to start the async threads used for suspending and resuming
devices at the core level, so that async_schedule() is called for
each suspend and resume callback supposed to be executed
asynchronously.
For this purpose, introduce a new device flag, power.async_suspend,
used to mark the devices whose suspend and resume callbacks are to be
executed asynchronously (ie. in parallel with the main suspend/resume
thread and possibly in parallel with each other) and helper function
device_enable_async_suspend() allowing one to set power.async_suspend
for given device (power.async_suspend is unset by default for all
devices). For each device with the power.async_suspend flag set the
PM core will use async_schedule() to execute its suspend and resume
callbacks.
The async threads started for different devices as a result of
calling async_schedule() are synchronized with each other and with
the main suspend/resume thread with the help of completions, in the
following way:
(1) There is a completion, power.completion, for each device object.
(2) Each device's completion is reset before calling async_schedule()
for the device or, in the case of devices with the
power.async_suspend flags unset, before executing the device's
suspend and resume callbacks.
(3) During suspend, right before running the bus type, device type
and device class suspend callbacks for the device, the PM core
waits for the completions of all the device's children to be
completed.
(4) During resume, right before running the bus type, device type and
device class resume callbacks for the device, the PM core waits
for the completion of the device's parent to be completed.
(5) The PM core completes power.completion for each device right
after the bus type, device type and device class suspend (or
resume) callbacks executed for the device have returned.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-01-23 21:23:32 +00:00
|
|
|
break;
|
2007-09-21 19:36:56 +00:00
|
|
|
}
|
|
|
|
mutex_unlock(&dpm_list_mtx);
|
PM: Asynchronous suspend and resume of devices
Theoretically, the total time of system sleep transitions (suspend
to RAM, hibernation) can be reduced by running suspend and resume
callbacks of device drivers in parallel with each other. However,
there are dependencies between devices such that we're not allowed
to suspend the parent of a device before suspending the device
itself. Analogously, we're not allowed to resume a device before
resuming its parent.
The most straightforward way to take these dependencies into accout
is to start the async threads used for suspending and resuming
devices at the core level, so that async_schedule() is called for
each suspend and resume callback supposed to be executed
asynchronously.
For this purpose, introduce a new device flag, power.async_suspend,
used to mark the devices whose suspend and resume callbacks are to be
executed asynchronously (ie. in parallel with the main suspend/resume
thread and possibly in parallel with each other) and helper function
device_enable_async_suspend() allowing one to set power.async_suspend
for given device (power.async_suspend is unset by default for all
devices). For each device with the power.async_suspend flag set the
PM core will use async_schedule() to execute its suspend and resume
callbacks.
The async threads started for different devices as a result of
calling async_schedule() are synchronized with each other and with
the main suspend/resume thread with the help of completions, in the
following way:
(1) There is a completion, power.completion, for each device object.
(2) Each device's completion is reset before calling async_schedule()
for the device or, in the case of devices with the
power.async_suspend flags unset, before executing the device's
suspend and resume callbacks.
(3) During suspend, right before running the bus type, device type
and device class suspend callbacks for the device, the PM core
waits for the completions of all the device's children to be
completed.
(4) During resume, right before running the bus type, device type and
device class resume callbacks for the device, the PM core waits
for the completion of the device's parent to be completed.
(5) The PM core completes power.completion for each device right
after the bus type, device type and device class suspend (or
resume) callbacks executed for the device have returned.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-01-23 21:23:32 +00:00
|
|
|
async_synchronize_full();
|
|
|
|
if (!error)
|
|
|
|
error = async_error;
|
PM / Suspend: Add statistics debugfs file for suspend to RAM
Record S3 failure time about each reason and the latest two failed
devices' names in S3 progress.
We can check it through 'suspend_stats' entry in debugfs.
The motivation of the patch:
We are enabling power features on Medfield. Comparing with PC/notebook,
a mobile enters/exits suspend-2-ram (we call it s3 on Medfield) far
more frequently. If it can't enter suspend-2-ram in time, the power
might be used up soon.
We often find sometimes, a device suspend fails. Then, system retries
s3 over and over again. As display is off, testers and developers
don't know what happens.
Some testers and developers complain they don't know if system
tries suspend-2-ram, and what device fails to suspend. They need
such info for a quick check. The patch adds suspend_stats under
debugfs for users to check suspend to RAM statistics quickly.
If not using this patch, we have other methods to get info about
what device fails. One is to turn on CONFIG_PM_DEBUG, but users
would get too much info and testers need recompile the system.
In addition, dynamic debug is another good tool to dump debug info.
But it still doesn't match our utilization scenario closely.
1) user need write a user space parser to process the syslog output;
2) Our testing scenario is we leave the mobile for at least hours.
Then, check its status. No serial console available during the
testing. One is because console would be suspended, and the other
is serial console connecting with spi or HSU devices would consume
power. These devices are powered off at suspend-2-ram.
Signed-off-by: ShuoX Liu <shuox.liu@intel.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-08-10 21:01:26 +00:00
|
|
|
if (error) {
|
|
|
|
suspend_stats.failed_suspend++;
|
|
|
|
dpm_save_failed_step(SUSPEND_SUSPEND);
|
2017-07-21 00:10:22 +00:00
|
|
|
}
|
|
|
|
dpm_show_time(starttime, state, error, NULL);
|
2014-06-06 12:40:17 +00:00
|
|
|
trace_suspend_resume(TPS("dpm_suspend"), state.event, false);
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2009-08-20 18:25:52 +00:00
|
|
|
* device_prepare - Prepare a device for system power transition.
|
|
|
|
* @dev: Device to handle.
|
|
|
|
* @state: PM transition of the system being carried out.
|
|
|
|
*
|
|
|
|
* Execute the ->prepare() callback(s) for given device. No new children of the
|
|
|
|
* device may be registered after this function has returned.
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
*/
|
2009-05-24 20:05:42 +00:00
|
|
|
static int device_prepare(struct device *dev, pm_message_t state)
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
{
|
2011-12-17 23:34:13 +00:00
|
|
|
int (*callback)(struct device *) = NULL;
|
PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily
Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
resume all runtime-suspended devices during system suspend, mostly
because those devices may need to be reprogrammed due to different
wakeup settings for system sleep and for runtime PM.
For some devices, though, it's OK to remain in runtime suspend
throughout a complete system suspend/resume cycle (if the device was in
runtime suspend at the start of the cycle). We would like to do this
whenever possible, to avoid the overhead of extra power-up and power-down
events.
However, problems may arise because the device's descendants may require
it to be at full power at various points during the cycle. Therefore the
most straightforward way to do this safely is if the device and all its
descendants can remain runtime suspended until the complete stage of
system resume.
To this end, introduce a new device PM flag, power.direct_complete
and modify the PM core to use that flag as follows.
If the ->prepare() callback of a device returns a positive number,
the PM core will regard that as an indication that it may leave the
device runtime-suspended. It will then check if the system power
transition in progress is a suspend (and not hibernation in particular)
and if the device is, indeed, runtime-suspended. In that case, the PM
core will set the device's power.direct_complete flag. Otherwise it
will clear power.direct_complete for the device and it also will later
clear it for the device's parent (if there's one).
Next, the PM core will not invoke the ->suspend() ->suspend_late(),
->suspend_irq(), ->resume_irq(), ->resume_early(), or ->resume()
callbacks for all devices having power.direct_complete set. It
will invoke their ->complete() callbacks, however, and those
callbacks are then responsible for resuming the devices as
appropriate, if necessary. For example, in some cases they may
need to queue up runtime resume requests for the devices using
pm_request_resume().
Changelog partly based on an Alan Stern's description of the idea
(http://marc.info/?l=linux-pm&m=139940466625569&w=2).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
2014-05-16 00:46:50 +00:00
|
|
|
int ret = 0;
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
|
2012-09-19 19:59:02 +00:00
|
|
|
/*
|
|
|
|
* 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
|
|
|
|
* block runtime suspend here, during the prepare phase, and allow
|
|
|
|
* it again during the complete phase.
|
|
|
|
*/
|
|
|
|
pm_runtime_get_noresume(dev);
|
|
|
|
|
2021-10-22 12:58:23 +00:00
|
|
|
if (dev->power.syscore)
|
|
|
|
return 0;
|
|
|
|
|
2010-02-17 18:57:05 +00:00
|
|
|
device_lock(dev);
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
|
2018-01-02 16:08:50 +00:00
|
|
|
dev->power.wakeup_path = false;
|
2011-10-16 21:34:36 +00:00
|
|
|
|
2018-05-22 11:02:17 +00:00
|
|
|
if (dev->power.no_pm_callbacks)
|
2016-01-07 15:46:14 +00:00
|
|
|
goto unlock;
|
|
|
|
|
2016-04-28 12:42:34 +00:00
|
|
|
if (dev->pm_domain)
|
2011-12-17 23:34:13 +00:00
|
|
|
callback = dev->pm_domain->ops.prepare;
|
2016-04-28 12:42:34 +00:00
|
|
|
else if (dev->type && dev->type->pm)
|
2011-12-17 23:34:13 +00:00
|
|
|
callback = dev->type->pm->prepare;
|
2016-04-28 12:42:34 +00:00
|
|
|
else if (dev->class && dev->class->pm)
|
2011-12-17 23:34:13 +00:00
|
|
|
callback = dev->class->pm->prepare;
|
2016-04-28 12:42:34 +00:00
|
|
|
else if (dev->bus && dev->bus->pm)
|
2011-12-17 23:34:13 +00:00
|
|
|
callback = dev->bus->pm->prepare;
|
|
|
|
|
2016-04-28 12:42:34 +00:00
|
|
|
if (!callback && dev->driver && dev->driver->pm)
|
2011-12-17 23:34:13 +00:00
|
|
|
callback = dev->driver->pm->prepare;
|
|
|
|
|
2015-05-28 19:55:53 +00:00
|
|
|
if (callback)
|
PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily
Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
resume all runtime-suspended devices during system suspend, mostly
because those devices may need to be reprogrammed due to different
wakeup settings for system sleep and for runtime PM.
For some devices, though, it's OK to remain in runtime suspend
throughout a complete system suspend/resume cycle (if the device was in
runtime suspend at the start of the cycle). We would like to do this
whenever possible, to avoid the overhead of extra power-up and power-down
events.
However, problems may arise because the device's descendants may require
it to be at full power at various points during the cycle. Therefore the
most straightforward way to do this safely is if the device and all its
descendants can remain runtime suspended until the complete stage of
system resume.
To this end, introduce a new device PM flag, power.direct_complete
and modify the PM core to use that flag as follows.
If the ->prepare() callback of a device returns a positive number,
the PM core will regard that as an indication that it may leave the
device runtime-suspended. It will then check if the system power
transition in progress is a suspend (and not hibernation in particular)
and if the device is, indeed, runtime-suspended. In that case, the PM
core will set the device's power.direct_complete flag. Otherwise it
will clear power.direct_complete for the device and it also will later
clear it for the device's parent (if there's one).
Next, the PM core will not invoke the ->suspend() ->suspend_late(),
->suspend_irq(), ->resume_irq(), ->resume_early(), or ->resume()
callbacks for all devices having power.direct_complete set. It
will invoke their ->complete() callbacks, however, and those
callbacks are then responsible for resuming the devices as
appropriate, if necessary. For example, in some cases they may
need to queue up runtime resume requests for the devices using
pm_request_resume().
Changelog partly based on an Alan Stern's description of the idea
(http://marc.info/?l=linux-pm&m=139940466625569&w=2).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
2014-05-16 00:46:50 +00:00
|
|
|
ret = callback(dev);
|
2011-02-16 20:53:17 +00:00
|
|
|
|
2016-01-07 15:46:14 +00:00
|
|
|
unlock:
|
2010-02-17 18:57:05 +00:00
|
|
|
device_unlock(dev);
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
|
PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily
Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
resume all runtime-suspended devices during system suspend, mostly
because those devices may need to be reprogrammed due to different
wakeup settings for system sleep and for runtime PM.
For some devices, though, it's OK to remain in runtime suspend
throughout a complete system suspend/resume cycle (if the device was in
runtime suspend at the start of the cycle). We would like to do this
whenever possible, to avoid the overhead of extra power-up and power-down
events.
However, problems may arise because the device's descendants may require
it to be at full power at various points during the cycle. Therefore the
most straightforward way to do this safely is if the device and all its
descendants can remain runtime suspended until the complete stage of
system resume.
To this end, introduce a new device PM flag, power.direct_complete
and modify the PM core to use that flag as follows.
If the ->prepare() callback of a device returns a positive number,
the PM core will regard that as an indication that it may leave the
device runtime-suspended. It will then check if the system power
transition in progress is a suspend (and not hibernation in particular)
and if the device is, indeed, runtime-suspended. In that case, the PM
core will set the device's power.direct_complete flag. Otherwise it
will clear power.direct_complete for the device and it also will later
clear it for the device's parent (if there's one).
Next, the PM core will not invoke the ->suspend() ->suspend_late(),
->suspend_irq(), ->resume_irq(), ->resume_early(), or ->resume()
callbacks for all devices having power.direct_complete set. It
will invoke their ->complete() callbacks, however, and those
callbacks are then responsible for resuming the devices as
appropriate, if necessary. For example, in some cases they may
need to queue up runtime resume requests for the devices using
pm_request_resume().
Changelog partly based on an Alan Stern's description of the idea
(http://marc.info/?l=linux-pm&m=139940466625569&w=2).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
2014-05-16 00:46:50 +00:00
|
|
|
if (ret < 0) {
|
2022-03-07 19:07:39 +00:00
|
|
|
suspend_report_result(dev, callback, ret);
|
2013-11-13 14:45:03 +00:00
|
|
|
pm_runtime_put(dev);
|
PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily
Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
resume all runtime-suspended devices during system suspend, mostly
because those devices may need to be reprogrammed due to different
wakeup settings for system sleep and for runtime PM.
For some devices, though, it's OK to remain in runtime suspend
throughout a complete system suspend/resume cycle (if the device was in
runtime suspend at the start of the cycle). We would like to do this
whenever possible, to avoid the overhead of extra power-up and power-down
events.
However, problems may arise because the device's descendants may require
it to be at full power at various points during the cycle. Therefore the
most straightforward way to do this safely is if the device and all its
descendants can remain runtime suspended until the complete stage of
system resume.
To this end, introduce a new device PM flag, power.direct_complete
and modify the PM core to use that flag as follows.
If the ->prepare() callback of a device returns a positive number,
the PM core will regard that as an indication that it may leave the
device runtime-suspended. It will then check if the system power
transition in progress is a suspend (and not hibernation in particular)
and if the device is, indeed, runtime-suspended. In that case, the PM
core will set the device's power.direct_complete flag. Otherwise it
will clear power.direct_complete for the device and it also will later
clear it for the device's parent (if there's one).
Next, the PM core will not invoke the ->suspend() ->suspend_late(),
->suspend_irq(), ->resume_irq(), ->resume_early(), or ->resume()
callbacks for all devices having power.direct_complete set. It
will invoke their ->complete() callbacks, however, and those
callbacks are then responsible for resuming the devices as
appropriate, if necessary. For example, in some cases they may
need to queue up runtime resume requests for the devices using
pm_request_resume().
Changelog partly based on an Alan Stern's description of the idea
(http://marc.info/?l=linux-pm&m=139940466625569&w=2).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
2014-05-16 00:46:50 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* A positive return value from ->prepare() means "this device appears
|
|
|
|
* to be runtime-suspended and its state is fine, so if it really is
|
|
|
|
* runtime-suspended, you can leave it in that state provided that you
|
|
|
|
* will do the same thing with all of its descendants". This only
|
|
|
|
* applies to suspend transitions, however.
|
|
|
|
*/
|
|
|
|
spin_lock_irq(&dev->power.lock);
|
PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags
The motivation for this change is to provide a way to work around
a problem with the direct-complete mechanism used for avoiding
system suspend/resume handling for devices in runtime suspend.
The problem is that some middle layer code (the PCI bus type and
the ACPI PM domain in particular) returns positive values from its
system suspend ->prepare callbacks regardless of whether the driver's
->prepare returns a positive value or 0, which effectively prevents
drivers from being able to control the direct-complete feature.
Some drivers need that control, however, and the PCI bus type has
grown its own flag to deal with this issue, but since it is not
limited to PCI, it is better to address it by adding driver flags at
the core level.
To that end, add a driver_flags field to struct dev_pm_info for flags
that can be set by device drivers at the probe time to inform the PM
core and/or bus types, PM domains and so on on the capabilities and/or
preferences of device drivers. Also add two static inline helpers
for setting that field and testing it against a given set of flags
and make the driver core clear it automatically on driver remove
and probe failures.
Define and document two PM driver flags related to the direct-
complete feature: NEVER_SKIP and SMART_PREPARE that can be used,
respectively, to indicate to the PM core that the direct-complete
mechanism should never be used for the device and to inform the
middle layer code (bus types, PM domains etc) that it can only
request the PM core to use the direct-complete mechanism for
the device (by returning a positive value from its ->prepare
callback) if it also has been requested by the driver.
While at it, make the core check pm_runtime_suspended() when
setting power.direct_complete so that it doesn't need to be
checked by ->prepare callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-10-25 12:12:29 +00:00
|
|
|
dev->power.direct_complete = state.event == PM_EVENT_SUSPEND &&
|
2020-03-29 14:11:18 +00:00
|
|
|
(ret > 0 || dev->power.no_pm_callbacks) &&
|
2020-04-18 16:53:01 +00:00
|
|
|
!dev_pm_test_driver_flags(dev, DPM_FLAG_NO_DIRECT_COMPLETE);
|
PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily
Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
resume all runtime-suspended devices during system suspend, mostly
because those devices may need to be reprogrammed due to different
wakeup settings for system sleep and for runtime PM.
For some devices, though, it's OK to remain in runtime suspend
throughout a complete system suspend/resume cycle (if the device was in
runtime suspend at the start of the cycle). We would like to do this
whenever possible, to avoid the overhead of extra power-up and power-down
events.
However, problems may arise because the device's descendants may require
it to be at full power at various points during the cycle. Therefore the
most straightforward way to do this safely is if the device and all its
descendants can remain runtime suspended until the complete stage of
system resume.
To this end, introduce a new device PM flag, power.direct_complete
and modify the PM core to use that flag as follows.
If the ->prepare() callback of a device returns a positive number,
the PM core will regard that as an indication that it may leave the
device runtime-suspended. It will then check if the system power
transition in progress is a suspend (and not hibernation in particular)
and if the device is, indeed, runtime-suspended. In that case, the PM
core will set the device's power.direct_complete flag. Otherwise it
will clear power.direct_complete for the device and it also will later
clear it for the device's parent (if there's one).
Next, the PM core will not invoke the ->suspend() ->suspend_late(),
->suspend_irq(), ->resume_irq(), ->resume_early(), or ->resume()
callbacks for all devices having power.direct_complete set. It
will invoke their ->complete() callbacks, however, and those
callbacks are then responsible for resuming the devices as
appropriate, if necessary. For example, in some cases they may
need to queue up runtime resume requests for the devices using
pm_request_resume().
Changelog partly based on an Alan Stern's description of the idea
(http://marc.info/?l=linux-pm&m=139940466625569&w=2).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
2014-05-16 00:46:50 +00:00
|
|
|
spin_unlock_irq(&dev->power.lock);
|
|
|
|
return 0;
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
}
|
2007-09-21 19:36:56 +00:00
|
|
|
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
/**
|
2009-08-20 18:25:52 +00:00
|
|
|
* dpm_prepare - Prepare all non-sysdev devices for a system PM transition.
|
|
|
|
* @state: PM transition of the system being carried out.
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
*
|
2009-08-20 18:25:52 +00:00
|
|
|
* Execute the ->prepare() callback(s) for all devices.
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
*/
|
2011-05-17 21:26:00 +00:00
|
|
|
int dpm_prepare(pm_message_t state)
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
{
|
|
|
|
int error = 0;
|
|
|
|
|
2014-06-06 12:40:17 +00:00
|
|
|
trace_suspend_resume(TPS("dpm_prepare"), state.event, true);
|
2011-05-17 21:26:00 +00:00
|
|
|
might_sleep();
|
|
|
|
|
2015-11-10 09:42:34 +00:00
|
|
|
/*
|
|
|
|
* Give a chance for the known devices to complete their probes, before
|
|
|
|
* disable probing of devices. This sync point is important at least
|
|
|
|
* at boot time + hibernation restore.
|
|
|
|
*/
|
|
|
|
wait_for_device_probe();
|
|
|
|
/*
|
|
|
|
* It is unsafe if probing of devices will happen during suspend or
|
|
|
|
* hibernation and system behavior will be unpredictable in this case.
|
|
|
|
* So, let's prohibit device's probing here and defer their probes
|
|
|
|
* instead. The normal behavior will be restored in dpm_complete().
|
|
|
|
*/
|
|
|
|
device_block_probing();
|
|
|
|
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
mutex_lock(&dpm_list_mtx);
|
2021-12-16 19:30:18 +00:00
|
|
|
while (!list_empty(&dpm_list) && !error) {
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
struct device *dev = to_device(dpm_list.next);
|
|
|
|
|
|
|
|
get_device(dev);
|
PM: sleep: Avoid calling put_device() under dpm_list_mtx
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
[ 3290.969514] ======================================================
[ 3290.969517] WARNING: possible circular locking dependency detected
[ 3290.969519] 5.15.0+ #2420 Tainted: G S
[ 3290.969523] ------------------------------------------------------
[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
[ 3290.969554]
but task is already holding lock:
[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.969571]
which lock already depends on the new lock.
[ 3290.969573]
the existing dependency chain (in reverse order) is:
[ 3290.969575]
-> #3 (dpm_list_mtx){+.+.}-{3:3}:
[ 3290.969583] __mutex_lock+0x9d/0xa30
[ 3290.969591] device_pm_add+0x2e/0xe0
[ 3290.969597] device_add+0x4d5/0x8f0
[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969842] process_one_work+0x2aa/0x650
[ 3290.969851] worker_thread+0x39/0x400
[ 3290.969859] kthread+0x142/0x170
[ 3290.969865] ret_from_fork+0x22/0x30
[ 3290.969872]
-> #2 (&hdev->lock){+.+.}-{3:3}:
[ 3290.969881] __mutex_lock+0x9d/0xa30
[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969978] process_one_work+0x2aa/0x650
[ 3290.969985] worker_thread+0x39/0x400
[ 3290.969993] kthread+0x142/0x170
[ 3290.969999] ret_from_fork+0x22/0x30
[ 3290.970004]
-> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
[ 3290.970013] process_one_work+0x27d/0x650
[ 3290.970020] worker_thread+0x39/0x400
[ 3290.970028] kthread+0x142/0x170
[ 3290.970033] ret_from_fork+0x22/0x30
[ 3290.970038]
-> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
[ 3290.970047] __lock_acquire+0x15cb/0x1b50
[ 3290.970054] lock_acquire+0x26c/0x300
[ 3290.970059] flush_workqueue+0xae/0x4a0
[ 3290.970066] drain_workqueue+0xa1/0x130
[ 3290.970073] destroy_workqueue+0x34/0x1f0
[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970195] device_release+0x33/0x90
[ 3290.970201] kobject_release+0x63/0x160
[ 3290.970211] dpm_resume+0x164/0x3e0
[ 3290.970215] dpm_resume_end+0xd/0x20
[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970229] pm_suspend+0x26b/0x310
[ 3290.970236] state_store+0x42/0x90
[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970251] new_sync_write+0x125/0x1c0
[ 3290.970257] vfs_write+0x360/0x3c0
[ 3290.970263] ksys_write+0xa7/0xe0
[ 3290.970269] do_syscall_64+0x3a/0x80
[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970284]
other info that might help us debug this:
[ 3290.970285] Chain exists of:
(wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
[ 3290.970297] Possible unsafe locking scenario:
[ 3290.970299] CPU0 CPU1
[ 3290.970300] ---- ----
[ 3290.970302] lock(dpm_list_mtx);
[ 3290.970306] lock(&hdev->lock);
[ 3290.970310] lock(dpm_list_mtx);
[ 3290.970314] lock((wq_completion)hci0#2);
[ 3290.970319]
*** DEADLOCK ***
[ 3290.970321] 7 locks held by systemd-sleep/4553:
[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.970428]
stack backtrace:
[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
[ 3290.970441] Call Trace:
[ 3290.970446] dump_stack_lvl+0x44/0x57
[ 3290.970454] check_noncircular+0x105/0x120
[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
[ 3290.970474] __lock_acquire+0x15cb/0x1b50
[ 3290.970487] lock_acquire+0x26c/0x300
[ 3290.970493] ? flush_workqueue+0x87/0x4a0
[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
[ 3290.970519] flush_workqueue+0xae/0x4a0
[ 3290.970526] ? flush_workqueue+0x87/0x4a0
[ 3290.970544] ? drain_workqueue+0xa1/0x130
[ 3290.970552] drain_workqueue+0xa1/0x130
[ 3290.970561] destroy_workqueue+0x34/0x1f0
[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970687] device_release+0x33/0x90
[ 3290.970695] kobject_release+0x63/0x160
[ 3290.970705] dpm_resume+0x164/0x3e0
[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
[ 3290.970718] dpm_resume_end+0xd/0x20
[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970737] pm_suspend+0x26b/0x310
[ 3290.970746] state_store+0x42/0x90
[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970764] new_sync_write+0x125/0x1c0
[ 3290.970777] vfs_write+0x360/0x3c0
[ 3290.970785] ksys_write+0xa7/0xe0
[ 3290.970794] do_syscall_64+0x3a/0x80
[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970811] RIP: 0033:0x7f41b1328164
[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-11-04 17:26:26 +00:00
|
|
|
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
mutex_unlock(&dpm_list_mtx);
|
|
|
|
|
2015-05-28 19:55:53 +00:00
|
|
|
trace_device_pm_callback_start(dev, "", state.event);
|
PM: Limit race conditions between runtime PM and system sleep (v2)
One of the roles of the PM core is to prevent different PM callbacks
executed for the same device object from racing with each other.
Unfortunately, after commit e8665002477f0278f84f898145b1f141ba26ee26
(PM: Allow pm_runtime_suspend() to succeed during system suspend)
runtime PM callbacks may be executed concurrently with system
suspend/resume callbacks for the same device.
The main reason for commit e8665002477f0278f84f898145b1f141ba26ee26
was that some subsystems and device drivers wanted to use runtime PM
helpers, pm_runtime_suspend() and pm_runtime_put_sync() in
particular, for carrying out the suspend of devices in their
.suspend() callbacks. However, as it's been determined recently,
there are multiple reasons not to do so, inlcuding:
* The caller really doesn't control the runtime PM usage counters,
because user space can access them through sysfs and effectively
block runtime PM. That means using pm_runtime_suspend() or
pm_runtime_get_sync() to suspend devices during system suspend
may or may not work.
* If a driver calls pm_runtime_suspend() from its .suspend()
callback, it causes the subsystem's .runtime_suspend() callback to
be executed, which leads to the call sequence:
subsys->suspend(dev)
driver->suspend(dev)
pm_runtime_suspend(dev)
subsys->runtime_suspend(dev)
recursive from the subsystem's point of view. For some subsystems
that may actually work (e.g. the platform bus type), but for some
it will fail in a rather spectacular fashion (e.g. PCI). In each
case it means a layering violation.
* Both the subsystem and the driver can provide .suspend_noirq()
callbacks for system suspend that can do whatever the
.runtime_suspend() callbacks do just fine, so it really isn't
necessary to call pm_runtime_suspend() during system suspend.
* The runtime PM's handling of wakeup devices is usually different
from the system suspend's one, so .runtime_suspend() may simply be
inappropriate for system suspend.
* System suspend is supposed to work even if CONFIG_PM_RUNTIME is
unset.
* The runtime PM workqueue is frozen before system suspend, so if
whatever the driver is going to do during system suspend depends
on it, that simply won't work.
Still, there is a good reason to allow pm_runtime_resume() to
succeed during system suspend and resume (for instance, some
subsystems and device drivers may legitimately use it to ensure that
their devices are in full-power states before suspending them).
Moreover, there is no reason to prevent runtime PM callbacks from
being executed in parallel with the system suspend/resume .prepare()
and .complete() callbacks and the code removed by commit
e8665002477f0278f84f898145b1f141ba26ee26 went too far in this
respect. On the other hand, runtime PM callbacks, including
.runtime_resume(), must not be executed during system suspend's
"late" stage of suspending devices and during system resume's "early"
device resume stage.
Taking all of the above into consideration, make the PM core
acquire a runtime PM reference to every device and resume it if
there's a runtime PM resume request pending right before executing
the subsystem-level .suspend() callback for it. Make the PM core
drop references to all devices right after executing the
subsystem-level .resume() callbacks for them. Additionally,
make the PM core disable the runtime PM framework for all devices
during system suspend, after executing the subsystem-level .suspend()
callbacks for them, and enable the runtime PM framework for all
devices during system resume, right before executing the
subsystem-level .resume() callbacks for them.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Kevin Hilman <khilman@ti.com>
2011-07-06 08:51:58 +00:00
|
|
|
error = device_prepare(dev, state);
|
2015-05-28 19:55:53 +00:00
|
|
|
trace_device_pm_callback_end(dev, error);
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
|
|
|
|
mutex_lock(&dpm_list_mtx);
|
PM: sleep: Avoid calling put_device() under dpm_list_mtx
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
[ 3290.969514] ======================================================
[ 3290.969517] WARNING: possible circular locking dependency detected
[ 3290.969519] 5.15.0+ #2420 Tainted: G S
[ 3290.969523] ------------------------------------------------------
[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
[ 3290.969554]
but task is already holding lock:
[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.969571]
which lock already depends on the new lock.
[ 3290.969573]
the existing dependency chain (in reverse order) is:
[ 3290.969575]
-> #3 (dpm_list_mtx){+.+.}-{3:3}:
[ 3290.969583] __mutex_lock+0x9d/0xa30
[ 3290.969591] device_pm_add+0x2e/0xe0
[ 3290.969597] device_add+0x4d5/0x8f0
[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969842] process_one_work+0x2aa/0x650
[ 3290.969851] worker_thread+0x39/0x400
[ 3290.969859] kthread+0x142/0x170
[ 3290.969865] ret_from_fork+0x22/0x30
[ 3290.969872]
-> #2 (&hdev->lock){+.+.}-{3:3}:
[ 3290.969881] __mutex_lock+0x9d/0xa30
[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969978] process_one_work+0x2aa/0x650
[ 3290.969985] worker_thread+0x39/0x400
[ 3290.969993] kthread+0x142/0x170
[ 3290.969999] ret_from_fork+0x22/0x30
[ 3290.970004]
-> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
[ 3290.970013] process_one_work+0x27d/0x650
[ 3290.970020] worker_thread+0x39/0x400
[ 3290.970028] kthread+0x142/0x170
[ 3290.970033] ret_from_fork+0x22/0x30
[ 3290.970038]
-> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
[ 3290.970047] __lock_acquire+0x15cb/0x1b50
[ 3290.970054] lock_acquire+0x26c/0x300
[ 3290.970059] flush_workqueue+0xae/0x4a0
[ 3290.970066] drain_workqueue+0xa1/0x130
[ 3290.970073] destroy_workqueue+0x34/0x1f0
[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970195] device_release+0x33/0x90
[ 3290.970201] kobject_release+0x63/0x160
[ 3290.970211] dpm_resume+0x164/0x3e0
[ 3290.970215] dpm_resume_end+0xd/0x20
[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970229] pm_suspend+0x26b/0x310
[ 3290.970236] state_store+0x42/0x90
[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970251] new_sync_write+0x125/0x1c0
[ 3290.970257] vfs_write+0x360/0x3c0
[ 3290.970263] ksys_write+0xa7/0xe0
[ 3290.970269] do_syscall_64+0x3a/0x80
[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970284]
other info that might help us debug this:
[ 3290.970285] Chain exists of:
(wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
[ 3290.970297] Possible unsafe locking scenario:
[ 3290.970299] CPU0 CPU1
[ 3290.970300] ---- ----
[ 3290.970302] lock(dpm_list_mtx);
[ 3290.970306] lock(&hdev->lock);
[ 3290.970310] lock(dpm_list_mtx);
[ 3290.970314] lock((wq_completion)hci0#2);
[ 3290.970319]
*** DEADLOCK ***
[ 3290.970321] 7 locks held by systemd-sleep/4553:
[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.970428]
stack backtrace:
[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
[ 3290.970441] Call Trace:
[ 3290.970446] dump_stack_lvl+0x44/0x57
[ 3290.970454] check_noncircular+0x105/0x120
[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
[ 3290.970474] __lock_acquire+0x15cb/0x1b50
[ 3290.970487] lock_acquire+0x26c/0x300
[ 3290.970493] ? flush_workqueue+0x87/0x4a0
[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
[ 3290.970519] flush_workqueue+0xae/0x4a0
[ 3290.970526] ? flush_workqueue+0x87/0x4a0
[ 3290.970544] ? drain_workqueue+0xa1/0x130
[ 3290.970552] drain_workqueue+0xa1/0x130
[ 3290.970561] destroy_workqueue+0x34/0x1f0
[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970687] device_release+0x33/0x90
[ 3290.970695] kobject_release+0x63/0x160
[ 3290.970705] dpm_resume+0x164/0x3e0
[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
[ 3290.970718] dpm_resume_end+0xd/0x20
[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970737] pm_suspend+0x26b/0x310
[ 3290.970746] state_store+0x42/0x90
[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970764] new_sync_write+0x125/0x1c0
[ 3290.970777] vfs_write+0x360/0x3c0
[ 3290.970785] ksys_write+0xa7/0xe0
[ 3290.970794] do_syscall_64+0x3a/0x80
[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970811] RIP: 0033:0x7f41b1328164
[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-11-04 17:26:26 +00:00
|
|
|
|
|
|
|
if (!error) {
|
|
|
|
dev->power.is_prepared = true;
|
|
|
|
if (!list_empty(&dev->power.entry))
|
|
|
|
list_move_tail(&dev->power.entry, &dpm_prepared_list);
|
|
|
|
} else if (error == -EAGAIN) {
|
|
|
|
error = 0;
|
|
|
|
} else {
|
2021-01-26 21:29:40 +00:00
|
|
|
dev_info(dev, "not prepared for power transition: code %d\n",
|
|
|
|
error);
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
}
|
PM: sleep: Avoid calling put_device() under dpm_list_mtx
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
[ 3290.969514] ======================================================
[ 3290.969517] WARNING: possible circular locking dependency detected
[ 3290.969519] 5.15.0+ #2420 Tainted: G S
[ 3290.969523] ------------------------------------------------------
[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
[ 3290.969554]
but task is already holding lock:
[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.969571]
which lock already depends on the new lock.
[ 3290.969573]
the existing dependency chain (in reverse order) is:
[ 3290.969575]
-> #3 (dpm_list_mtx){+.+.}-{3:3}:
[ 3290.969583] __mutex_lock+0x9d/0xa30
[ 3290.969591] device_pm_add+0x2e/0xe0
[ 3290.969597] device_add+0x4d5/0x8f0
[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969842] process_one_work+0x2aa/0x650
[ 3290.969851] worker_thread+0x39/0x400
[ 3290.969859] kthread+0x142/0x170
[ 3290.969865] ret_from_fork+0x22/0x30
[ 3290.969872]
-> #2 (&hdev->lock){+.+.}-{3:3}:
[ 3290.969881] __mutex_lock+0x9d/0xa30
[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969978] process_one_work+0x2aa/0x650
[ 3290.969985] worker_thread+0x39/0x400
[ 3290.969993] kthread+0x142/0x170
[ 3290.969999] ret_from_fork+0x22/0x30
[ 3290.970004]
-> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
[ 3290.970013] process_one_work+0x27d/0x650
[ 3290.970020] worker_thread+0x39/0x400
[ 3290.970028] kthread+0x142/0x170
[ 3290.970033] ret_from_fork+0x22/0x30
[ 3290.970038]
-> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
[ 3290.970047] __lock_acquire+0x15cb/0x1b50
[ 3290.970054] lock_acquire+0x26c/0x300
[ 3290.970059] flush_workqueue+0xae/0x4a0
[ 3290.970066] drain_workqueue+0xa1/0x130
[ 3290.970073] destroy_workqueue+0x34/0x1f0
[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970195] device_release+0x33/0x90
[ 3290.970201] kobject_release+0x63/0x160
[ 3290.970211] dpm_resume+0x164/0x3e0
[ 3290.970215] dpm_resume_end+0xd/0x20
[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970229] pm_suspend+0x26b/0x310
[ 3290.970236] state_store+0x42/0x90
[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970251] new_sync_write+0x125/0x1c0
[ 3290.970257] vfs_write+0x360/0x3c0
[ 3290.970263] ksys_write+0xa7/0xe0
[ 3290.970269] do_syscall_64+0x3a/0x80
[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970284]
other info that might help us debug this:
[ 3290.970285] Chain exists of:
(wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
[ 3290.970297] Possible unsafe locking scenario:
[ 3290.970299] CPU0 CPU1
[ 3290.970300] ---- ----
[ 3290.970302] lock(dpm_list_mtx);
[ 3290.970306] lock(&hdev->lock);
[ 3290.970310] lock(dpm_list_mtx);
[ 3290.970314] lock((wq_completion)hci0#2);
[ 3290.970319]
*** DEADLOCK ***
[ 3290.970321] 7 locks held by systemd-sleep/4553:
[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.970428]
stack backtrace:
[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
[ 3290.970441] Call Trace:
[ 3290.970446] dump_stack_lvl+0x44/0x57
[ 3290.970454] check_noncircular+0x105/0x120
[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
[ 3290.970474] __lock_acquire+0x15cb/0x1b50
[ 3290.970487] lock_acquire+0x26c/0x300
[ 3290.970493] ? flush_workqueue+0x87/0x4a0
[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
[ 3290.970519] flush_workqueue+0xae/0x4a0
[ 3290.970526] ? flush_workqueue+0x87/0x4a0
[ 3290.970544] ? drain_workqueue+0xa1/0x130
[ 3290.970552] drain_workqueue+0xa1/0x130
[ 3290.970561] destroy_workqueue+0x34/0x1f0
[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970687] device_release+0x33/0x90
[ 3290.970695] kobject_release+0x63/0x160
[ 3290.970705] dpm_resume+0x164/0x3e0
[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
[ 3290.970718] dpm_resume_end+0xd/0x20
[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970737] pm_suspend+0x26b/0x310
[ 3290.970746] state_store+0x42/0x90
[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970764] new_sync_write+0x125/0x1c0
[ 3290.970777] vfs_write+0x360/0x3c0
[ 3290.970785] ksys_write+0xa7/0xe0
[ 3290.970794] do_syscall_64+0x3a/0x80
[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970811] RIP: 0033:0x7f41b1328164
[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-11-04 17:26:26 +00:00
|
|
|
|
|
|
|
mutex_unlock(&dpm_list_mtx);
|
|
|
|
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
put_device(dev);
|
PM: sleep: Avoid calling put_device() under dpm_list_mtx
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
[ 3290.969514] ======================================================
[ 3290.969517] WARNING: possible circular locking dependency detected
[ 3290.969519] 5.15.0+ #2420 Tainted: G S
[ 3290.969523] ------------------------------------------------------
[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
[ 3290.969554]
but task is already holding lock:
[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.969571]
which lock already depends on the new lock.
[ 3290.969573]
the existing dependency chain (in reverse order) is:
[ 3290.969575]
-> #3 (dpm_list_mtx){+.+.}-{3:3}:
[ 3290.969583] __mutex_lock+0x9d/0xa30
[ 3290.969591] device_pm_add+0x2e/0xe0
[ 3290.969597] device_add+0x4d5/0x8f0
[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969842] process_one_work+0x2aa/0x650
[ 3290.969851] worker_thread+0x39/0x400
[ 3290.969859] kthread+0x142/0x170
[ 3290.969865] ret_from_fork+0x22/0x30
[ 3290.969872]
-> #2 (&hdev->lock){+.+.}-{3:3}:
[ 3290.969881] __mutex_lock+0x9d/0xa30
[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969978] process_one_work+0x2aa/0x650
[ 3290.969985] worker_thread+0x39/0x400
[ 3290.969993] kthread+0x142/0x170
[ 3290.969999] ret_from_fork+0x22/0x30
[ 3290.970004]
-> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
[ 3290.970013] process_one_work+0x27d/0x650
[ 3290.970020] worker_thread+0x39/0x400
[ 3290.970028] kthread+0x142/0x170
[ 3290.970033] ret_from_fork+0x22/0x30
[ 3290.970038]
-> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
[ 3290.970047] __lock_acquire+0x15cb/0x1b50
[ 3290.970054] lock_acquire+0x26c/0x300
[ 3290.970059] flush_workqueue+0xae/0x4a0
[ 3290.970066] drain_workqueue+0xa1/0x130
[ 3290.970073] destroy_workqueue+0x34/0x1f0
[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970195] device_release+0x33/0x90
[ 3290.970201] kobject_release+0x63/0x160
[ 3290.970211] dpm_resume+0x164/0x3e0
[ 3290.970215] dpm_resume_end+0xd/0x20
[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970229] pm_suspend+0x26b/0x310
[ 3290.970236] state_store+0x42/0x90
[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970251] new_sync_write+0x125/0x1c0
[ 3290.970257] vfs_write+0x360/0x3c0
[ 3290.970263] ksys_write+0xa7/0xe0
[ 3290.970269] do_syscall_64+0x3a/0x80
[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970284]
other info that might help us debug this:
[ 3290.970285] Chain exists of:
(wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
[ 3290.970297] Possible unsafe locking scenario:
[ 3290.970299] CPU0 CPU1
[ 3290.970300] ---- ----
[ 3290.970302] lock(dpm_list_mtx);
[ 3290.970306] lock(&hdev->lock);
[ 3290.970310] lock(dpm_list_mtx);
[ 3290.970314] lock((wq_completion)hci0#2);
[ 3290.970319]
*** DEADLOCK ***
[ 3290.970321] 7 locks held by systemd-sleep/4553:
[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.970428]
stack backtrace:
[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
[ 3290.970441] Call Trace:
[ 3290.970446] dump_stack_lvl+0x44/0x57
[ 3290.970454] check_noncircular+0x105/0x120
[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
[ 3290.970474] __lock_acquire+0x15cb/0x1b50
[ 3290.970487] lock_acquire+0x26c/0x300
[ 3290.970493] ? flush_workqueue+0x87/0x4a0
[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
[ 3290.970519] flush_workqueue+0xae/0x4a0
[ 3290.970526] ? flush_workqueue+0x87/0x4a0
[ 3290.970544] ? drain_workqueue+0xa1/0x130
[ 3290.970552] drain_workqueue+0xa1/0x130
[ 3290.970561] destroy_workqueue+0x34/0x1f0
[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970687] device_release+0x33/0x90
[ 3290.970695] kobject_release+0x63/0x160
[ 3290.970705] dpm_resume+0x164/0x3e0
[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
[ 3290.970718] dpm_resume_end+0xd/0x20
[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970737] pm_suspend+0x26b/0x310
[ 3290.970746] state_store+0x42/0x90
[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970764] new_sync_write+0x125/0x1c0
[ 3290.970777] vfs_write+0x360/0x3c0
[ 3290.970785] ksys_write+0xa7/0xe0
[ 3290.970794] do_syscall_64+0x3a/0x80
[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970811] RIP: 0033:0x7f41b1328164
[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-11-04 17:26:26 +00:00
|
|
|
|
|
|
|
mutex_lock(&dpm_list_mtx);
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
}
|
|
|
|
mutex_unlock(&dpm_list_mtx);
|
2014-06-06 12:40:17 +00:00
|
|
|
trace_suspend_resume(TPS("dpm_prepare"), state.event, false);
|
2007-09-21 19:36:56 +00:00
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
2008-01-12 19:40:46 +00:00
|
|
|
/**
|
2009-08-20 18:25:52 +00:00
|
|
|
* dpm_suspend_start - Prepare devices for PM transition and suspend them.
|
|
|
|
* @state: PM transition of the system being carried out.
|
2008-01-12 19:40:46 +00:00
|
|
|
*
|
2009-08-20 18:25:52 +00:00
|
|
|
* Prepare all non-sysdev devices for system PM transition and execute "suspend"
|
|
|
|
* callbacks for them.
|
2008-01-12 19:40:46 +00:00
|
|
|
*/
|
2009-05-24 20:05:42 +00:00
|
|
|
int dpm_suspend_start(pm_message_t state)
|
2008-01-12 19:40:46 +00:00
|
|
|
{
|
2019-06-05 16:12:37 +00:00
|
|
|
ktime_t starttime = ktime_get();
|
2008-01-12 19:40:46 +00:00
|
|
|
int error;
|
2007-09-21 19:36:56 +00:00
|
|
|
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
error = dpm_prepare(state);
|
PM / Suspend: Add statistics debugfs file for suspend to RAM
Record S3 failure time about each reason and the latest two failed
devices' names in S3 progress.
We can check it through 'suspend_stats' entry in debugfs.
The motivation of the patch:
We are enabling power features on Medfield. Comparing with PC/notebook,
a mobile enters/exits suspend-2-ram (we call it s3 on Medfield) far
more frequently. If it can't enter suspend-2-ram in time, the power
might be used up soon.
We often find sometimes, a device suspend fails. Then, system retries
s3 over and over again. As display is off, testers and developers
don't know what happens.
Some testers and developers complain they don't know if system
tries suspend-2-ram, and what device fails to suspend. They need
such info for a quick check. The patch adds suspend_stats under
debugfs for users to check suspend to RAM statistics quickly.
If not using this patch, we have other methods to get info about
what device fails. One is to turn on CONFIG_PM_DEBUG, but users
would get too much info and testers need recompile the system.
In addition, dynamic debug is another good tool to dump debug info.
But it still doesn't match our utilization scenario closely.
1) user need write a user space parser to process the syslog output;
2) Our testing scenario is we leave the mobile for at least hours.
Then, check its status. No serial console available during the
testing. One is because console would be suspended, and the other
is serial console connecting with spi or HSU devices would consume
power. These devices are powered off at suspend-2-ram.
Signed-off-by: ShuoX Liu <shuox.liu@intel.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-08-10 21:01:26 +00:00
|
|
|
if (error) {
|
|
|
|
suspend_stats.failed_prepare++;
|
|
|
|
dpm_save_failed_step(SUSPEND_PREPARE);
|
|
|
|
} else
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 21:00:01 +00:00
|
|
|
error = dpm_suspend(state);
|
2019-06-05 16:12:37 +00:00
|
|
|
dpm_show_time(starttime, state, error, "start");
|
2007-09-21 19:36:56 +00:00
|
|
|
return error;
|
|
|
|
}
|
2009-05-24 20:05:42 +00:00
|
|
|
EXPORT_SYMBOL_GPL(dpm_suspend_start);
|
2007-09-21 19:36:56 +00:00
|
|
|
|
2022-03-07 19:07:39 +00:00
|
|
|
void __suspend_report_result(const char *function, struct device *dev, void *fn, int ret)
|
2007-09-21 19:36:56 +00:00
|
|
|
{
|
2008-10-16 05:01:35 +00:00
|
|
|
if (ret)
|
2022-03-07 19:07:39 +00:00
|
|
|
dev_err(dev, "%s(): %pS returns %d\n", function, fn, ret);
|
2007-09-21 19:36:56 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(__suspend_report_result);
|
2010-01-27 22:47:38 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* device_pm_wait_for_dev - Wait for suspend/resume of a device to complete.
|
|
|
|
* @subordinate: Device that needs to wait for @dev.
|
2019-03-16 03:48:41 +00:00
|
|
|
* @dev: Device to wait for.
|
2010-01-27 22:47:38 +00:00
|
|
|
*/
|
2010-09-22 20:10:57 +00:00
|
|
|
int device_pm_wait_for_dev(struct device *subordinate, struct device *dev)
|
2010-01-27 22:47:38 +00:00
|
|
|
{
|
|
|
|
dpm_wait(dev, subordinate->power.async_suspend);
|
2010-09-22 20:10:57 +00:00
|
|
|
return async_error;
|
2010-01-27 22:47:38 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(device_pm_wait_for_dev);
|
2012-08-17 14:06:59 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* dpm_for_each_dev - device iterator.
|
|
|
|
* @data: data for the callback.
|
|
|
|
* @fn: function to be called for each device.
|
|
|
|
*
|
|
|
|
* Iterate over devices in dpm_list, and call @fn for each device,
|
|
|
|
* passing it @data.
|
|
|
|
*/
|
|
|
|
void dpm_for_each_dev(void *data, void (*fn)(struct device *, void *))
|
|
|
|
{
|
|
|
|
struct device *dev;
|
|
|
|
|
|
|
|
if (!fn)
|
|
|
|
return;
|
|
|
|
|
|
|
|
device_pm_lock();
|
|
|
|
list_for_each_entry(dev, &dpm_list, power.entry)
|
|
|
|
fn(dev, data);
|
|
|
|
device_pm_unlock();
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(dpm_for_each_dev);
|
2016-01-07 15:46:14 +00:00
|
|
|
|
|
|
|
static bool pm_ops_is_empty(const struct dev_pm_ops *ops)
|
|
|
|
{
|
|
|
|
if (!ops)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return !ops->prepare &&
|
|
|
|
!ops->suspend &&
|
|
|
|
!ops->suspend_late &&
|
|
|
|
!ops->suspend_noirq &&
|
|
|
|
!ops->resume_noirq &&
|
|
|
|
!ops->resume_early &&
|
|
|
|
!ops->resume &&
|
|
|
|
!ops->complete;
|
|
|
|
}
|
|
|
|
|
|
|
|
void device_pm_check_callbacks(struct device *dev)
|
|
|
|
{
|
2022-03-05 11:02:14 +00:00
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&dev->power.lock, flags);
|
2016-01-07 15:46:14 +00:00
|
|
|
dev->power.no_pm_callbacks =
|
2017-09-19 00:22:39 +00:00
|
|
|
(!dev->bus || (pm_ops_is_empty(dev->bus->pm) &&
|
|
|
|
!dev->bus->suspend && !dev->bus->resume)) &&
|
2017-09-25 12:56:44 +00:00
|
|
|
(!dev->class || pm_ops_is_empty(dev->class->pm)) &&
|
2016-01-07 15:46:14 +00:00
|
|
|
(!dev->type || pm_ops_is_empty(dev->type->pm)) &&
|
|
|
|
(!dev->pm_domain || pm_ops_is_empty(&dev->pm_domain->ops)) &&
|
2017-09-19 00:22:39 +00:00
|
|
|
(!dev->driver || (pm_ops_is_empty(dev->driver->pm) &&
|
|
|
|
!dev->driver->suspend && !dev->driver->resume));
|
2022-03-05 11:02:14 +00:00
|
|
|
spin_unlock_irqrestore(&dev->power.lock, flags);
|
2016-01-07 15:46:14 +00:00
|
|
|
}
|
PCI / PM: Take SMART_SUSPEND driver flag into account
Make the PCI bus type take DPM_FLAG_SMART_SUSPEND into account in its
system-wide PM callbacks and make sure that all code that should not
run in parallel with pci_pm_runtime_resume() is executed in the "late"
phases of system suspend, freeze and poweroff transitions.
[Note that the pm_runtime_suspended() check in pci_dev_keep_suspended()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add checks
for that in pci_pm_suspend_late/noirq(), pci_pm_freeze_late/noirq()
and pci_pm_poweroff_late/noirq().
Moreover, if pci_pm_resume_noirq() or pci_pm_restore_noirq() is
called during the subsequent system-wide resume transition and if
the device was left in runtime suspend previously, its runtime PM
status needs to be changed to "active" as it is going to be put
into the full-power state, so add checks for that too to these
functions.
In turn, if pci_pm_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
In addition to the above add a core helper for checking if
DPM_FLAG_SMART_SUSPEND is set and the device runtime PM status is
"suspended" at the same time, which is done quite often in the new
code (and will be done elsewhere going forward too).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2017-10-26 10:12:22 +00:00
|
|
|
|
2020-04-18 16:52:48 +00:00
|
|
|
bool dev_pm_skip_suspend(struct device *dev)
|
PCI / PM: Take SMART_SUSPEND driver flag into account
Make the PCI bus type take DPM_FLAG_SMART_SUSPEND into account in its
system-wide PM callbacks and make sure that all code that should not
run in parallel with pci_pm_runtime_resume() is executed in the "late"
phases of system suspend, freeze and poweroff transitions.
[Note that the pm_runtime_suspended() check in pci_dev_keep_suspended()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]
Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add checks
for that in pci_pm_suspend_late/noirq(), pci_pm_freeze_late/noirq()
and pci_pm_poweroff_late/noirq().
Moreover, if pci_pm_resume_noirq() or pci_pm_restore_noirq() is
called during the subsequent system-wide resume transition and if
the device was left in runtime suspend previously, its runtime PM
status needs to be changed to "active" as it is going to be put
into the full-power state, so add checks for that too to these
functions.
In turn, if pci_pm_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.
In addition to the above add a core helper for checking if
DPM_FLAG_SMART_SUSPEND is set and the device runtime PM status is
"suspended" at the same time, which is done quite often in the new
code (and will be done elsewhere going forward too).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2017-10-26 10:12:22 +00:00
|
|
|
{
|
|
|
|
return dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_SUSPEND) &&
|
|
|
|
pm_runtime_status_suspended(dev);
|
|
|
|
}
|