2019-05-27 09:55:06 +03:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2005-04-17 02:20:36 +04:00
|
|
|
/*
|
2015-07-16 03:01:28 +03:00
|
|
|
* drivers/acpi/power.c - ACPI Power Resources management.
|
2005-04-17 02:20:36 +04:00
|
|
|
*
|
2015-07-16 03:01:28 +03:00
|
|
|
* Copyright (C) 2001 - 2015 Intel Corp.
|
|
|
|
* Author: Andy Grover <andrew.grover@intel.com>
|
|
|
|
* Author: Paul Diefenbaugh <paul.s.diefenbaugh@intel.com>
|
|
|
|
* Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
2005-04-17 02:20:36 +04:00
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ACPI power-managed devices may be controlled in two ways:
|
|
|
|
* 1. via "Device Specific (D-State) Control"
|
|
|
|
* 2. via "Power Resource Control".
|
2015-07-16 03:01:28 +03:00
|
|
|
* The code below deals with ACPI Power Resources control.
|
2020-11-05 05:06:00 +03:00
|
|
|
*
|
2015-07-16 03:01:28 +03:00
|
|
|
* An ACPI "power resource object" represents a software controllable power
|
|
|
|
* plane, clock plane, or other resource depended on by a device.
|
|
|
|
*
|
2005-04-17 02:20:36 +04:00
|
|
|
* A device may rely on multiple power resources, and a power resource
|
|
|
|
* may be shared by multiple devices.
|
|
|
|
*/
|
|
|
|
|
2021-01-20 21:57:03 +03:00
|
|
|
#define pr_fmt(fmt) "ACPI: PM: " fmt
|
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/types.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 11:04:11 +03:00
|
|
|
#include <linux/slab.h>
|
2012-03-29 10:09:39 +04:00
|
|
|
#include <linux/pm_runtime.h>
|
2013-01-26 00:51:32 +04:00
|
|
|
#include <linux/sysfs.h>
|
2013-12-03 04:49:16 +04:00
|
|
|
#include <linux/acpi.h>
|
2009-09-09 01:15:31 +04:00
|
|
|
#include "sleep.h"
|
2012-03-29 10:09:39 +04:00
|
|
|
#include "internal.h"
|
2009-09-09 01:15:31 +04:00
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
#define ACPI_POWER_CLASS "power_resource"
|
|
|
|
#define ACPI_POWER_DEVICE_NAME "Power Resource"
|
|
|
|
#define ACPI_POWER_RESOURCE_STATE_OFF 0x00
|
|
|
|
#define ACPI_POWER_RESOURCE_STATE_ON 0x01
|
|
|
|
#define ACPI_POWER_RESOURCE_STATE_UNKNOWN 0xFF
|
2008-08-11 10:57:50 +04:00
|
|
|
|
2019-06-25 13:29:41 +03:00
|
|
|
struct acpi_power_dependent_device {
|
|
|
|
struct device *dev;
|
|
|
|
struct list_head node;
|
|
|
|
};
|
|
|
|
|
2005-08-05 08:44:28 +04:00
|
|
|
struct acpi_power_resource {
|
2013-01-17 17:11:05 +04:00
|
|
|
struct acpi_device device;
|
2013-01-17 17:11:06 +04:00
|
|
|
struct list_head list_node;
|
2013-01-17 17:11:05 +04:00
|
|
|
char *name;
|
2005-08-05 08:44:28 +04:00
|
|
|
u32 system_level;
|
|
|
|
u32 order;
|
2010-10-22 04:35:54 +04:00
|
|
|
unsigned int ref_count;
|
ACPI: power: Save the last known state of each power resource
Currently, there are two ways to check the state of an ACPI power
resource and they may not be consistent with each other. The first
one is to evaluate the power resource's _STA object and the other one
is to check its reference counter value. However, on some systems
the value returned by _STA may not be consistent with the value of
the power resource's reference counter (for example, on some systems
it returns the same value every time for certain power resources).
Moreover, evaluating _STA is unnecessary overhead for a power
resource for which it has been evaluated already or whose state is
otherwise known, because either the _ON or the _OFF method has been
executed for it.
For this reason, save the state of each power resource in its
struct acpi_power_resource object and use the saved value whenever
its state needs to be checked, except when its stats is unknown, in
which case the _STA method is evaluated for it and the value
returned by that method is saved as the last known state of
the power resource.
Moreover, drop the power resource _STA method evaluation from
acpi_add_power_resource(), so as to avoid doing that unnecessarily
for power resources that will never be used.
Tested-by: Dave Olsthoorn <dave@bewaar.me>
Tested-by: Shujun Wang <wsj20369@163.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-05-24 18:25:23 +03:00
|
|
|
u8 state;
|
ACPI / PM: Take unusual configurations of power resources into account
Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device
wakeup) moved the initial disabling of system wakeup for PCI devices
into a place where it can actually work and that exposed a hidden old
issue with crap^Wunusual system designs where the same power
resources are used for both wakeup power and device power control at
run time.
Namely, say there is one power resource such that the ACPI power
state D0 of a PCI device depends on that power resource (i.e. the
device is in D0 when that power resource is "on") and it is used
as a wakeup power resource for the same device. Then, calling
acpi_pci_sleep_wake(pci_dev, false) for the device in question will
cause the reference counter of that power resource to drop to 0,
which in turn will cause it to be turned off. As a result, the
device will go into D3cold at that point, although it should have
stayed in D0.
As it turns out, that happens to USB controllers on some laptops
and USB becomes unusable on those machines as a result, which is
a major regression from v3.8.
To fix this problem, (1) increment the reference counters of wakup
power resources during their initialization if they are "on"
initially, (2) prevent acpi_disable_wakeup_device_power() from
decrementing the reference counters of wakeup power resources that
were not enabled for wakeup power previously, and (3) prevent
acpi_enable_wakeup_device_power() from incrementing the reference
counters of wakeup power resources that already are enabled for
wakeup power.
In addition to that, if it is impossible to determine the initial
states of wakeup power resources, avoid enabling wakeup for devices
whose wakeup power depends on those power resources.
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Tested-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-02-24 02:15:21 +04:00
|
|
|
bool wakeup_enabled;
|
2007-02-16 09:47:06 +03:00
|
|
|
struct mutex resource_lock;
|
2019-06-25 13:29:41 +03:00
|
|
|
struct list_head dependents;
|
2005-04-17 02:20:36 +04:00
|
|
|
};
|
|
|
|
|
2013-01-17 17:11:06 +04:00
|
|
|
struct acpi_power_resource_entry {
|
|
|
|
struct list_head node;
|
|
|
|
struct acpi_power_resource *resource;
|
|
|
|
};
|
|
|
|
|
2013-01-17 17:11:06 +04:00
|
|
|
static LIST_HEAD(acpi_power_resource_list);
|
|
|
|
static DEFINE_MUTEX(power_resource_list_lock);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
/* --------------------------------------------------------------------------
|
|
|
|
Power Resource Management
|
|
|
|
-------------------------------------------------------------------------- */
|
|
|
|
|
2013-01-24 15:50:09 +04:00
|
|
|
static inline
|
|
|
|
struct acpi_power_resource *to_power_resource(struct acpi_device *device)
|
|
|
|
{
|
|
|
|
return container_of(device, struct acpi_power_resource, device);
|
|
|
|
}
|
|
|
|
|
2013-01-17 17:11:05 +04:00
|
|
|
static struct acpi_power_resource *acpi_power_get_context(acpi_handle handle)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2013-01-17 17:11:05 +04:00
|
|
|
struct acpi_device *device;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2013-01-17 17:11:05 +04:00
|
|
|
if (acpi_bus_get_device(handle, &device))
|
|
|
|
return NULL;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2013-01-24 15:50:09 +04:00
|
|
|
return to_power_resource(device);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2013-01-17 17:11:07 +04:00
|
|
|
static int acpi_power_resources_list_add(acpi_handle handle,
|
|
|
|
struct list_head *list)
|
2013-01-17 17:11:06 +04:00
|
|
|
{
|
|
|
|
struct acpi_power_resource *resource = acpi_power_get_context(handle);
|
|
|
|
struct acpi_power_resource_entry *entry;
|
|
|
|
|
|
|
|
if (!resource || !list)
|
2013-01-17 17:11:07 +04:00
|
|
|
return -EINVAL;
|
2013-01-17 17:11:06 +04:00
|
|
|
|
|
|
|
entry = kzalloc(sizeof(*entry), GFP_KERNEL);
|
|
|
|
if (!entry)
|
2013-01-17 17:11:07 +04:00
|
|
|
return -ENOMEM;
|
2013-01-17 17:11:06 +04:00
|
|
|
|
|
|
|
entry->resource = resource;
|
|
|
|
if (!list_empty(list)) {
|
|
|
|
struct acpi_power_resource_entry *e;
|
|
|
|
|
|
|
|
list_for_each_entry(e, list, node)
|
|
|
|
if (e->resource->order > resource->order) {
|
|
|
|
list_add_tail(&entry->node, &e->node);
|
2013-01-17 17:11:07 +04:00
|
|
|
return 0;
|
2013-01-17 17:11:06 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
list_add_tail(&entry->node, list);
|
2013-01-17 17:11:07 +04:00
|
|
|
return 0;
|
2013-01-17 17:11:06 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
void acpi_power_resources_list_free(struct list_head *list)
|
|
|
|
{
|
|
|
|
struct acpi_power_resource_entry *entry, *e;
|
|
|
|
|
|
|
|
list_for_each_entry_safe(entry, e, list, node) {
|
|
|
|
list_del(&entry->node);
|
|
|
|
kfree(entry);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-12-30 20:25:00 +03:00
|
|
|
static bool acpi_power_resource_is_dup(union acpi_object *package,
|
|
|
|
unsigned int start, unsigned int i)
|
|
|
|
{
|
|
|
|
acpi_handle rhandle, dup;
|
|
|
|
unsigned int j;
|
|
|
|
|
|
|
|
/* The caller is expected to check the package element types */
|
|
|
|
rhandle = package->package.elements[i].reference.handle;
|
|
|
|
for (j = start; j < i; j++) {
|
|
|
|
dup = package->package.elements[j].reference.handle;
|
|
|
|
if (dup == rhandle)
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2013-01-17 17:11:07 +04:00
|
|
|
int acpi_extract_power_resources(union acpi_object *package, unsigned int start,
|
|
|
|
struct list_head *list)
|
2013-01-17 17:11:07 +04:00
|
|
|
{
|
|
|
|
unsigned int i;
|
2013-01-17 17:11:07 +04:00
|
|
|
int err = 0;
|
2013-01-17 17:11:07 +04:00
|
|
|
|
|
|
|
for (i = start; i < package->package.count; i++) {
|
|
|
|
union acpi_object *element = &package->package.elements[i];
|
2021-05-21 16:13:11 +03:00
|
|
|
struct acpi_device *rdev;
|
2013-01-17 17:11:07 +04:00
|
|
|
acpi_handle rhandle;
|
|
|
|
|
|
|
|
if (element->type != ACPI_TYPE_LOCAL_REFERENCE) {
|
2013-01-17 17:11:07 +04:00
|
|
|
err = -ENODATA;
|
2013-01-17 17:11:07 +04:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
rhandle = element->reference.handle;
|
|
|
|
if (!rhandle) {
|
2013-01-17 17:11:07 +04:00
|
|
|
err = -ENODEV;
|
2013-01-17 17:11:07 +04:00
|
|
|
break;
|
|
|
|
}
|
2018-12-30 20:25:00 +03:00
|
|
|
|
|
|
|
/* Some ACPI tables contain duplicate power resource references */
|
|
|
|
if (acpi_power_resource_is_dup(package, start, i))
|
|
|
|
continue;
|
|
|
|
|
2021-05-21 16:13:11 +03:00
|
|
|
rdev = acpi_add_power_resource(rhandle);
|
|
|
|
if (!rdev) {
|
|
|
|
err = -ENODEV;
|
2013-01-17 17:11:07 +04:00
|
|
|
break;
|
2021-05-21 16:13:11 +03:00
|
|
|
}
|
2013-01-17 17:11:07 +04:00
|
|
|
err = acpi_power_resources_list_add(rhandle, list);
|
|
|
|
if (err)
|
|
|
|
break;
|
2013-01-17 17:11:07 +04:00
|
|
|
}
|
2013-01-17 17:11:07 +04:00
|
|
|
if (err)
|
2013-01-17 17:11:07 +04:00
|
|
|
acpi_power_resources_list_free(list);
|
|
|
|
|
2013-01-17 17:11:07 +04:00
|
|
|
return err;
|
2013-01-17 17:11:07 +04:00
|
|
|
}
|
|
|
|
|
ACPI: power: Save the last known state of each power resource
Currently, there are two ways to check the state of an ACPI power
resource and they may not be consistent with each other. The first
one is to evaluate the power resource's _STA object and the other one
is to check its reference counter value. However, on some systems
the value returned by _STA may not be consistent with the value of
the power resource's reference counter (for example, on some systems
it returns the same value every time for certain power resources).
Moreover, evaluating _STA is unnecessary overhead for a power
resource for which it has been evaluated already or whose state is
otherwise known, because either the _ON or the _OFF method has been
executed for it.
For this reason, save the state of each power resource in its
struct acpi_power_resource object and use the saved value whenever
its state needs to be checked, except when its stats is unknown, in
which case the _STA method is evaluated for it and the value
returned by that method is saved as the last known state of
the power resource.
Moreover, drop the power resource _STA method evaluation from
acpi_add_power_resource(), so as to avoid doing that unnecessarily
for power resources that will never be used.
Tested-by: Dave Olsthoorn <dave@bewaar.me>
Tested-by: Shujun Wang <wsj20369@163.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-05-24 18:25:23 +03:00
|
|
|
static int __get_state(acpi_handle handle, u8 *state)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2005-08-05 08:44:28 +04:00
|
|
|
acpi_status status = AE_OK;
|
2008-10-10 10:22:59 +04:00
|
|
|
unsigned long long sta = 0;
|
2021-05-24 18:24:16 +03:00
|
|
|
u8 cur_state;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2008-08-11 10:55:05 +04:00
|
|
|
status = acpi_evaluate_integer(handle, "_STA", NULL, &sta);
|
2005-04-17 02:20:36 +04:00
|
|
|
if (ACPI_FAILURE(status))
|
2006-06-27 08:41:40 +04:00
|
|
|
return -ENODEV;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2021-05-24 18:24:16 +03:00
|
|
|
cur_state = sta & ACPI_POWER_RESOURCE_STATE_ON;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2021-01-20 21:57:03 +03:00
|
|
|
acpi_handle_debug(handle, "Power resource is %s\n",
|
2021-05-24 18:24:16 +03:00
|
|
|
cur_state ? "on" : "off");
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2021-05-24 18:24:16 +03:00
|
|
|
*state = cur_state;
|
2006-06-27 08:41:40 +04:00
|
|
|
return 0;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
ACPI: power: Save the last known state of each power resource
Currently, there are two ways to check the state of an ACPI power
resource and they may not be consistent with each other. The first
one is to evaluate the power resource's _STA object and the other one
is to check its reference counter value. However, on some systems
the value returned by _STA may not be consistent with the value of
the power resource's reference counter (for example, on some systems
it returns the same value every time for certain power resources).
Moreover, evaluating _STA is unnecessary overhead for a power
resource for which it has been evaluated already or whose state is
otherwise known, because either the _ON or the _OFF method has been
executed for it.
For this reason, save the state of each power resource in its
struct acpi_power_resource object and use the saved value whenever
its state needs to be checked, except when its stats is unknown, in
which case the _STA method is evaluated for it and the value
returned by that method is saved as the last known state of
the power resource.
Moreover, drop the power resource _STA method evaluation from
acpi_add_power_resource(), so as to avoid doing that unnecessarily
for power resources that will never be used.
Tested-by: Dave Olsthoorn <dave@bewaar.me>
Tested-by: Shujun Wang <wsj20369@163.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-05-24 18:25:23 +03:00
|
|
|
static int acpi_power_get_state(struct acpi_power_resource *resource, u8 *state)
|
|
|
|
{
|
|
|
|
if (resource->state == ACPI_POWER_RESOURCE_STATE_UNKNOWN) {
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = __get_state(resource->device.handle, &resource->state);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
*state = resource->state;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-05-24 18:24:16 +03:00
|
|
|
static int acpi_power_get_list_state(struct list_head *list, u8 *state)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2013-01-17 17:11:06 +04:00
|
|
|
struct acpi_power_resource_entry *entry;
|
2021-05-24 18:24:16 +03:00
|
|
|
u8 cur_state = ACPI_POWER_RESOURCE_STATE_OFF;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
if (!list || !state)
|
2006-06-27 08:41:40 +04:00
|
|
|
return -EINVAL;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
/* The state of the list is 'on' IFF all resources are 'on'. */
|
2013-01-17 17:11:06 +04:00
|
|
|
list_for_each_entry(entry, list, node) {
|
|
|
|
struct acpi_power_resource *resource = entry->resource;
|
2011-01-07 01:38:57 +03:00
|
|
|
int result;
|
|
|
|
|
|
|
|
mutex_lock(&resource->resource_lock);
|
ACPI: power: Save the last known state of each power resource
Currently, there are two ways to check the state of an ACPI power
resource and they may not be consistent with each other. The first
one is to evaluate the power resource's _STA object and the other one
is to check its reference counter value. However, on some systems
the value returned by _STA may not be consistent with the value of
the power resource's reference counter (for example, on some systems
it returns the same value every time for certain power resources).
Moreover, evaluating _STA is unnecessary overhead for a power
resource for which it has been evaluated already or whose state is
otherwise known, because either the _ON or the _OFF method has been
executed for it.
For this reason, save the state of each power resource in its
struct acpi_power_resource object and use the saved value whenever
its state needs to be checked, except when its stats is unknown, in
which case the _STA method is evaluated for it and the value
returned by that method is saved as the last known state of
the power resource.
Moreover, drop the power resource _STA method evaluation from
acpi_add_power_resource(), so as to avoid doing that unnecessarily
for power resources that will never be used.
Tested-by: Dave Olsthoorn <dave@bewaar.me>
Tested-by: Shujun Wang <wsj20369@163.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-05-24 18:25:23 +03:00
|
|
|
result = acpi_power_get_state(resource, &cur_state);
|
2011-01-07 01:38:57 +03:00
|
|
|
mutex_unlock(&resource->resource_lock);
|
|
|
|
if (result)
|
|
|
|
return result;
|
|
|
|
|
|
|
|
if (cur_state != ACPI_POWER_RESOURCE_STATE_ON)
|
2005-04-17 02:20:36 +04:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2021-01-20 21:57:03 +03:00
|
|
|
pr_debug("Power resource list is %s\n", cur_state ? "on" : "off");
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2011-01-07 01:38:57 +03:00
|
|
|
*state = cur_state;
|
|
|
|
return 0;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2019-06-25 13:29:41 +03:00
|
|
|
static int
|
|
|
|
acpi_power_resource_add_dependent(struct acpi_power_resource *resource,
|
|
|
|
struct device *dev)
|
|
|
|
{
|
|
|
|
struct acpi_power_dependent_device *dep;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
mutex_lock(&resource->resource_lock);
|
|
|
|
list_for_each_entry(dep, &resource->dependents, node) {
|
|
|
|
/* Only add it once */
|
|
|
|
if (dep->dev == dev)
|
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
dep = kzalloc(sizeof(*dep), GFP_KERNEL);
|
|
|
|
if (!dep) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
dep->dev = dev;
|
|
|
|
list_add_tail(&dep->node, &resource->dependents);
|
|
|
|
dev_dbg(dev, "added power dependency to [%s]\n", resource->name);
|
|
|
|
|
|
|
|
unlock:
|
|
|
|
mutex_unlock(&resource->resource_lock);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
acpi_power_resource_remove_dependent(struct acpi_power_resource *resource,
|
|
|
|
struct device *dev)
|
|
|
|
{
|
|
|
|
struct acpi_power_dependent_device *dep;
|
|
|
|
|
|
|
|
mutex_lock(&resource->resource_lock);
|
|
|
|
list_for_each_entry(dep, &resource->dependents, node) {
|
|
|
|
if (dep->dev == dev) {
|
|
|
|
list_del(&dep->node);
|
|
|
|
kfree(dep);
|
|
|
|
dev_dbg(dev, "removed power dependency to [%s]\n",
|
|
|
|
resource->name);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
mutex_unlock(&resource->resource_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_device_power_add_dependent - Add dependent device of this ACPI device
|
|
|
|
* @adev: ACPI device pointer
|
|
|
|
* @dev: Dependent device
|
|
|
|
*
|
|
|
|
* If @adev has non-empty _PR0 the @dev is added as dependent device to all
|
|
|
|
* power resources returned by it. This means that whenever these power
|
|
|
|
* resources are turned _ON the dependent devices get runtime resumed. This
|
|
|
|
* is needed for devices such as PCI to allow its driver to re-initialize
|
|
|
|
* it after it went to D0uninitialized.
|
|
|
|
*
|
|
|
|
* If @adev does not have _PR0 this does nothing.
|
|
|
|
*
|
|
|
|
* Returns %0 in case of success and negative errno otherwise.
|
|
|
|
*/
|
|
|
|
int acpi_device_power_add_dependent(struct acpi_device *adev,
|
|
|
|
struct device *dev)
|
|
|
|
{
|
|
|
|
struct acpi_power_resource_entry *entry;
|
|
|
|
struct list_head *resources;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (!adev->flags.power_manageable)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
resources = &adev->power.states[ACPI_STATE_D0].resources;
|
|
|
|
list_for_each_entry(entry, resources, node) {
|
|
|
|
ret = acpi_power_resource_add_dependent(entry->resource, dev);
|
|
|
|
if (ret)
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
err:
|
|
|
|
list_for_each_entry(entry, resources, node)
|
|
|
|
acpi_power_resource_remove_dependent(entry->resource, dev);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_device_power_remove_dependent - Remove dependent device
|
|
|
|
* @adev: ACPI device pointer
|
|
|
|
* @dev: Dependent device
|
|
|
|
*
|
|
|
|
* Does the opposite of acpi_device_power_add_dependent() and removes the
|
|
|
|
* dependent device if it is found. Can be called to @adev that does not
|
|
|
|
* have _PR0 as well.
|
|
|
|
*/
|
|
|
|
void acpi_device_power_remove_dependent(struct acpi_device *adev,
|
|
|
|
struct device *dev)
|
|
|
|
{
|
|
|
|
struct acpi_power_resource_entry *entry;
|
|
|
|
struct list_head *resources;
|
|
|
|
|
|
|
|
if (!adev->flags.power_manageable)
|
|
|
|
return;
|
|
|
|
|
|
|
|
resources = &adev->power.states[ACPI_STATE_D0].resources;
|
|
|
|
list_for_each_entry_reverse(entry, resources, node)
|
|
|
|
acpi_power_resource_remove_dependent(entry->resource, dev);
|
|
|
|
}
|
|
|
|
|
2010-10-22 04:35:54 +04:00
|
|
|
static int __acpi_power_on(struct acpi_power_resource *resource)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2019-06-25 13:29:41 +03:00
|
|
|
struct acpi_power_dependent_device *dep;
|
2005-08-05 08:44:28 +04:00
|
|
|
acpi_status status = AE_OK;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2013-01-17 17:11:05 +04:00
|
|
|
status = acpi_evaluate_object(resource->device.handle, "_ON", NULL, NULL);
|
ACPI: power: Save the last known state of each power resource
Currently, there are two ways to check the state of an ACPI power
resource and they may not be consistent with each other. The first
one is to evaluate the power resource's _STA object and the other one
is to check its reference counter value. However, on some systems
the value returned by _STA may not be consistent with the value of
the power resource's reference counter (for example, on some systems
it returns the same value every time for certain power resources).
Moreover, evaluating _STA is unnecessary overhead for a power
resource for which it has been evaluated already or whose state is
otherwise known, because either the _ON or the _OFF method has been
executed for it.
For this reason, save the state of each power resource in its
struct acpi_power_resource object and use the saved value whenever
its state needs to be checked, except when its stats is unknown, in
which case the _STA method is evaluated for it and the value
returned by that method is saved as the last known state of
the power resource.
Moreover, drop the power resource _STA method evaluation from
acpi_add_power_resource(), so as to avoid doing that unnecessarily
for power resources that will never be used.
Tested-by: Dave Olsthoorn <dave@bewaar.me>
Tested-by: Shujun Wang <wsj20369@163.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-05-24 18:25:23 +03:00
|
|
|
if (ACPI_FAILURE(status)) {
|
|
|
|
resource->state = ACPI_POWER_RESOURCE_STATE_UNKNOWN;
|
2010-10-22 04:35:54 +04:00
|
|
|
return -ENODEV;
|
ACPI: power: Save the last known state of each power resource
Currently, there are two ways to check the state of an ACPI power
resource and they may not be consistent with each other. The first
one is to evaluate the power resource's _STA object and the other one
is to check its reference counter value. However, on some systems
the value returned by _STA may not be consistent with the value of
the power resource's reference counter (for example, on some systems
it returns the same value every time for certain power resources).
Moreover, evaluating _STA is unnecessary overhead for a power
resource for which it has been evaluated already or whose state is
otherwise known, because either the _ON or the _OFF method has been
executed for it.
For this reason, save the state of each power resource in its
struct acpi_power_resource object and use the saved value whenever
its state needs to be checked, except when its stats is unknown, in
which case the _STA method is evaluated for it and the value
returned by that method is saved as the last known state of
the power resource.
Moreover, drop the power resource _STA method evaluation from
acpi_add_power_resource(), so as to avoid doing that unnecessarily
for power resources that will never be used.
Tested-by: Dave Olsthoorn <dave@bewaar.me>
Tested-by: Shujun Wang <wsj20369@163.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-05-24 18:25:23 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
resource->state = ACPI_POWER_RESOURCE_STATE_ON;
|
2010-10-22 04:35:54 +04:00
|
|
|
|
2021-01-20 21:57:03 +03:00
|
|
|
pr_debug("Power resource [%s] turned on\n", resource->name);
|
2010-10-22 04:35:54 +04:00
|
|
|
|
2019-06-25 13:29:41 +03:00
|
|
|
/*
|
|
|
|
* If there are other dependents on this power resource we need to
|
|
|
|
* resume them now so that their drivers can re-initialize the
|
|
|
|
* hardware properly after it went back to D0.
|
|
|
|
*/
|
|
|
|
if (list_empty(&resource->dependents) ||
|
|
|
|
list_is_singular(&resource->dependents))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
list_for_each_entry(dep, &resource->dependents, node) {
|
|
|
|
dev_dbg(dep->dev, "runtime resuming because [%s] turned on\n",
|
|
|
|
resource->name);
|
|
|
|
pm_request_resume(dep->dev);
|
|
|
|
}
|
|
|
|
|
2010-10-22 04:35:54 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
ACPI / PM: Take unusual configurations of power resources into account
Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device
wakeup) moved the initial disabling of system wakeup for PCI devices
into a place where it can actually work and that exposed a hidden old
issue with crap^Wunusual system designs where the same power
resources are used for both wakeup power and device power control at
run time.
Namely, say there is one power resource such that the ACPI power
state D0 of a PCI device depends on that power resource (i.e. the
device is in D0 when that power resource is "on") and it is used
as a wakeup power resource for the same device. Then, calling
acpi_pci_sleep_wake(pci_dev, false) for the device in question will
cause the reference counter of that power resource to drop to 0,
which in turn will cause it to be turned off. As a result, the
device will go into D3cold at that point, although it should have
stayed in D0.
As it turns out, that happens to USB controllers on some laptops
and USB becomes unusable on those machines as a result, which is
a major regression from v3.8.
To fix this problem, (1) increment the reference counters of wakup
power resources during their initialization if they are "on"
initially, (2) prevent acpi_disable_wakeup_device_power() from
decrementing the reference counters of wakeup power resources that
were not enabled for wakeup power previously, and (3) prevent
acpi_enable_wakeup_device_power() from incrementing the reference
counters of wakeup power resources that already are enabled for
wakeup power.
In addition to that, if it is impossible to determine the initial
states of wakeup power resources, avoid enabling wakeup for devices
whose wakeup power depends on those power resources.
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Tested-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-02-24 02:15:21 +04:00
|
|
|
static int acpi_power_on_unlocked(struct acpi_power_resource *resource)
|
2010-10-22 04:35:54 +04:00
|
|
|
{
|
ACPI / PM: Take unusual configurations of power resources into account
Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device
wakeup) moved the initial disabling of system wakeup for PCI devices
into a place where it can actually work and that exposed a hidden old
issue with crap^Wunusual system designs where the same power
resources are used for both wakeup power and device power control at
run time.
Namely, say there is one power resource such that the ACPI power
state D0 of a PCI device depends on that power resource (i.e. the
device is in D0 when that power resource is "on") and it is used
as a wakeup power resource for the same device. Then, calling
acpi_pci_sleep_wake(pci_dev, false) for the device in question will
cause the reference counter of that power resource to drop to 0,
which in turn will cause it to be turned off. As a result, the
device will go into D3cold at that point, although it should have
stayed in D0.
As it turns out, that happens to USB controllers on some laptops
and USB becomes unusable on those machines as a result, which is
a major regression from v3.8.
To fix this problem, (1) increment the reference counters of wakup
power resources during their initialization if they are "on"
initially, (2) prevent acpi_disable_wakeup_device_power() from
decrementing the reference counters of wakeup power resources that
were not enabled for wakeup power previously, and (3) prevent
acpi_enable_wakeup_device_power() from incrementing the reference
counters of wakeup power resources that already are enabled for
wakeup power.
In addition to that, if it is impossible to determine the initial
states of wakeup power resources, avoid enabling wakeup for devices
whose wakeup power depends on those power resources.
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Tested-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-02-24 02:15:21 +04:00
|
|
|
int result = 0;
|
2007-02-16 09:47:06 +03:00
|
|
|
|
2010-10-22 04:35:54 +04:00
|
|
|
if (resource->ref_count++) {
|
2021-01-20 21:57:03 +03:00
|
|
|
pr_debug("Power resource [%s] already on\n", resource->name);
|
2010-10-22 04:35:54 +04:00
|
|
|
} else {
|
|
|
|
result = __acpi_power_on(resource);
|
ACPI / power: Drop automaitc resume of power resource dependent devices
The mechanism causing devices depending on a given power resource
(that is, devices that can be in D0 only if that power resource is
on) to be resumed automatically when the power resource is turned
on (and their "inferred" power state becomes D0 as a result) is
inherently racy and in fact unnecessary.
It is racy, because if the power resource is turned on and then
immediately off, the device resume triggered by the first transition
to "on" may still happen, causing the power resource to be turned
on again. That again will trigger the "resume of dependent devices"
mechanism, but if the devices in question are not in use, they will
be suspended in the meantime causing the power resource to be turned
off. However, the "resume of dependent devices" will next resume
them again and so on. In some cases (USB port PM in particular) that
leads to an endless busy loop of flipping the resource on and off
continuously.
It is needless, because whoever turns a power resource on will most
likely turn it off at some point and the devices that go into "D0"
as a result of turning it on will then go back into D3cold
(generally, the state they were in before).
Moreover, turning on all power resources a device needs to go into
D0 is not sufficient for a full transition into D0 in general.
Namely, _PS0 may need to be executed in addition to that in some
cases. This means that the whole rationale of the "resume of
dependent devices" mechanism was incorrect to begin with and it's
best to remove it entirely.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-17 01:05:42 +04:00
|
|
|
if (result)
|
2010-11-25 02:03:32 +03:00
|
|
|
resource->ref_count--;
|
2012-09-14 02:26:33 +04:00
|
|
|
}
|
ACPI / PM: Take unusual configurations of power resources into account
Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device
wakeup) moved the initial disabling of system wakeup for PCI devices
into a place where it can actually work and that exposed a hidden old
issue with crap^Wunusual system designs where the same power
resources are used for both wakeup power and device power control at
run time.
Namely, say there is one power resource such that the ACPI power
state D0 of a PCI device depends on that power resource (i.e. the
device is in D0 when that power resource is "on") and it is used
as a wakeup power resource for the same device. Then, calling
acpi_pci_sleep_wake(pci_dev, false) for the device in question will
cause the reference counter of that power resource to drop to 0,
which in turn will cause it to be turned off. As a result, the
device will go into D3cold at that point, although it should have
stayed in D0.
As it turns out, that happens to USB controllers on some laptops
and USB becomes unusable on those machines as a result, which is
a major regression from v3.8.
To fix this problem, (1) increment the reference counters of wakup
power resources during their initialization if they are "on"
initially, (2) prevent acpi_disable_wakeup_device_power() from
decrementing the reference counters of wakeup power resources that
were not enabled for wakeup power previously, and (3) prevent
acpi_enable_wakeup_device_power() from incrementing the reference
counters of wakeup power resources that already are enabled for
wakeup power.
In addition to that, if it is impossible to determine the initial
states of wakeup power resources, avoid enabling wakeup for devices
whose wakeup power depends on those power resources.
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Tested-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-02-24 02:15:21 +04:00
|
|
|
return result;
|
|
|
|
}
|
2012-09-14 02:26:33 +04:00
|
|
|
|
ACPI / PM: Take unusual configurations of power resources into account
Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device
wakeup) moved the initial disabling of system wakeup for PCI devices
into a place where it can actually work and that exposed a hidden old
issue with crap^Wunusual system designs where the same power
resources are used for both wakeup power and device power control at
run time.
Namely, say there is one power resource such that the ACPI power
state D0 of a PCI device depends on that power resource (i.e. the
device is in D0 when that power resource is "on") and it is used
as a wakeup power resource for the same device. Then, calling
acpi_pci_sleep_wake(pci_dev, false) for the device in question will
cause the reference counter of that power resource to drop to 0,
which in turn will cause it to be turned off. As a result, the
device will go into D3cold at that point, although it should have
stayed in D0.
As it turns out, that happens to USB controllers on some laptops
and USB becomes unusable on those machines as a result, which is
a major regression from v3.8.
To fix this problem, (1) increment the reference counters of wakup
power resources during their initialization if they are "on"
initially, (2) prevent acpi_disable_wakeup_device_power() from
decrementing the reference counters of wakeup power resources that
were not enabled for wakeup power previously, and (3) prevent
acpi_enable_wakeup_device_power() from incrementing the reference
counters of wakeup power resources that already are enabled for
wakeup power.
In addition to that, if it is impossible to determine the initial
states of wakeup power resources, avoid enabling wakeup for devices
whose wakeup power depends on those power resources.
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Tested-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-02-24 02:15:21 +04:00
|
|
|
static int acpi_power_on(struct acpi_power_resource *resource)
|
|
|
|
{
|
|
|
|
int result;
|
2012-09-14 02:26:33 +04:00
|
|
|
|
ACPI / PM: Take unusual configurations of power resources into account
Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device
wakeup) moved the initial disabling of system wakeup for PCI devices
into a place where it can actually work and that exposed a hidden old
issue with crap^Wunusual system designs where the same power
resources are used for both wakeup power and device power control at
run time.
Namely, say there is one power resource such that the ACPI power
state D0 of a PCI device depends on that power resource (i.e. the
device is in D0 when that power resource is "on") and it is used
as a wakeup power resource for the same device. Then, calling
acpi_pci_sleep_wake(pci_dev, false) for the device in question will
cause the reference counter of that power resource to drop to 0,
which in turn will cause it to be turned off. As a result, the
device will go into D3cold at that point, although it should have
stayed in D0.
As it turns out, that happens to USB controllers on some laptops
and USB becomes unusable on those machines as a result, which is
a major regression from v3.8.
To fix this problem, (1) increment the reference counters of wakup
power resources during their initialization if they are "on"
initially, (2) prevent acpi_disable_wakeup_device_power() from
decrementing the reference counters of wakeup power resources that
were not enabled for wakeup power previously, and (3) prevent
acpi_enable_wakeup_device_power() from incrementing the reference
counters of wakeup power resources that already are enabled for
wakeup power.
In addition to that, if it is impossible to determine the initial
states of wakeup power resources, avoid enabling wakeup for devices
whose wakeup power depends on those power resources.
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Tested-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-02-24 02:15:21 +04:00
|
|
|
mutex_lock(&resource->resource_lock);
|
|
|
|
result = acpi_power_on_unlocked(resource);
|
|
|
|
mutex_unlock(&resource->resource_lock);
|
2010-11-25 02:03:32 +03:00
|
|
|
return result;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2013-01-26 00:51:57 +04:00
|
|
|
static int __acpi_power_off(struct acpi_power_resource *resource)
|
|
|
|
{
|
|
|
|
acpi_status status;
|
|
|
|
|
|
|
|
status = acpi_evaluate_object(resource->device.handle, "_OFF",
|
|
|
|
NULL, NULL);
|
ACPI: power: Save the last known state of each power resource
Currently, there are two ways to check the state of an ACPI power
resource and they may not be consistent with each other. The first
one is to evaluate the power resource's _STA object and the other one
is to check its reference counter value. However, on some systems
the value returned by _STA may not be consistent with the value of
the power resource's reference counter (for example, on some systems
it returns the same value every time for certain power resources).
Moreover, evaluating _STA is unnecessary overhead for a power
resource for which it has been evaluated already or whose state is
otherwise known, because either the _ON or the _OFF method has been
executed for it.
For this reason, save the state of each power resource in its
struct acpi_power_resource object and use the saved value whenever
its state needs to be checked, except when its stats is unknown, in
which case the _STA method is evaluated for it and the value
returned by that method is saved as the last known state of
the power resource.
Moreover, drop the power resource _STA method evaluation from
acpi_add_power_resource(), so as to avoid doing that unnecessarily
for power resources that will never be used.
Tested-by: Dave Olsthoorn <dave@bewaar.me>
Tested-by: Shujun Wang <wsj20369@163.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-05-24 18:25:23 +03:00
|
|
|
if (ACPI_FAILURE(status)) {
|
|
|
|
resource->state = ACPI_POWER_RESOURCE_STATE_UNKNOWN;
|
2013-01-26 00:51:57 +04:00
|
|
|
return -ENODEV;
|
ACPI: power: Save the last known state of each power resource
Currently, there are two ways to check the state of an ACPI power
resource and they may not be consistent with each other. The first
one is to evaluate the power resource's _STA object and the other one
is to check its reference counter value. However, on some systems
the value returned by _STA may not be consistent with the value of
the power resource's reference counter (for example, on some systems
it returns the same value every time for certain power resources).
Moreover, evaluating _STA is unnecessary overhead for a power
resource for which it has been evaluated already or whose state is
otherwise known, because either the _ON or the _OFF method has been
executed for it.
For this reason, save the state of each power resource in its
struct acpi_power_resource object and use the saved value whenever
its state needs to be checked, except when its stats is unknown, in
which case the _STA method is evaluated for it and the value
returned by that method is saved as the last known state of
the power resource.
Moreover, drop the power resource _STA method evaluation from
acpi_add_power_resource(), so as to avoid doing that unnecessarily
for power resources that will never be used.
Tested-by: Dave Olsthoorn <dave@bewaar.me>
Tested-by: Shujun Wang <wsj20369@163.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-05-24 18:25:23 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
resource->state = ACPI_POWER_RESOURCE_STATE_OFF;
|
2013-01-26 00:51:57 +04:00
|
|
|
|
2021-01-20 21:57:03 +03:00
|
|
|
pr_debug("Power resource [%s] turned off\n", resource->name);
|
|
|
|
|
2013-01-26 00:51:57 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
ACPI / PM: Take unusual configurations of power resources into account
Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device
wakeup) moved the initial disabling of system wakeup for PCI devices
into a place where it can actually work and that exposed a hidden old
issue with crap^Wunusual system designs where the same power
resources are used for both wakeup power and device power control at
run time.
Namely, say there is one power resource such that the ACPI power
state D0 of a PCI device depends on that power resource (i.e. the
device is in D0 when that power resource is "on") and it is used
as a wakeup power resource for the same device. Then, calling
acpi_pci_sleep_wake(pci_dev, false) for the device in question will
cause the reference counter of that power resource to drop to 0,
which in turn will cause it to be turned off. As a result, the
device will go into D3cold at that point, although it should have
stayed in D0.
As it turns out, that happens to USB controllers on some laptops
and USB becomes unusable on those machines as a result, which is
a major regression from v3.8.
To fix this problem, (1) increment the reference counters of wakup
power resources during their initialization if they are "on"
initially, (2) prevent acpi_disable_wakeup_device_power() from
decrementing the reference counters of wakeup power resources that
were not enabled for wakeup power previously, and (3) prevent
acpi_enable_wakeup_device_power() from incrementing the reference
counters of wakeup power resources that already are enabled for
wakeup power.
In addition to that, if it is impossible to determine the initial
states of wakeup power resources, avoid enabling wakeup for devices
whose wakeup power depends on those power resources.
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Tested-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-02-24 02:15:21 +04:00
|
|
|
static int acpi_power_off_unlocked(struct acpi_power_resource *resource)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2013-01-17 17:11:06 +04:00
|
|
|
int result = 0;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2010-10-22 04:35:54 +04:00
|
|
|
if (!resource->ref_count) {
|
2021-01-20 21:57:03 +03:00
|
|
|
pr_debug("Power resource [%s] already off\n", resource->name);
|
ACPI / PM: Take unusual configurations of power resources into account
Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device
wakeup) moved the initial disabling of system wakeup for PCI devices
into a place where it can actually work and that exposed a hidden old
issue with crap^Wunusual system designs where the same power
resources are used for both wakeup power and device power control at
run time.
Namely, say there is one power resource such that the ACPI power
state D0 of a PCI device depends on that power resource (i.e. the
device is in D0 when that power resource is "on") and it is used
as a wakeup power resource for the same device. Then, calling
acpi_pci_sleep_wake(pci_dev, false) for the device in question will
cause the reference counter of that power resource to drop to 0,
which in turn will cause it to be turned off. As a result, the
device will go into D3cold at that point, although it should have
stayed in D0.
As it turns out, that happens to USB controllers on some laptops
and USB becomes unusable on those machines as a result, which is
a major regression from v3.8.
To fix this problem, (1) increment the reference counters of wakup
power resources during their initialization if they are "on"
initially, (2) prevent acpi_disable_wakeup_device_power() from
decrementing the reference counters of wakeup power resources that
were not enabled for wakeup power previously, and (3) prevent
acpi_enable_wakeup_device_power() from incrementing the reference
counters of wakeup power resources that already are enabled for
wakeup power.
In addition to that, if it is impossible to determine the initial
states of wakeup power resources, avoid enabling wakeup for devices
whose wakeup power depends on those power resources.
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Tested-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-02-24 02:15:21 +04:00
|
|
|
return 0;
|
2007-02-16 09:47:06 +03:00
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2010-10-22 04:35:54 +04:00
|
|
|
if (--resource->ref_count) {
|
2021-01-20 21:57:03 +03:00
|
|
|
pr_debug("Power resource [%s] still in use\n", resource->name);
|
2013-01-26 00:51:57 +04:00
|
|
|
} else {
|
|
|
|
result = __acpi_power_off(resource);
|
|
|
|
if (result)
|
|
|
|
resource->ref_count++;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
ACPI / PM: Take unusual configurations of power resources into account
Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device
wakeup) moved the initial disabling of system wakeup for PCI devices
into a place where it can actually work and that exposed a hidden old
issue with crap^Wunusual system designs where the same power
resources are used for both wakeup power and device power control at
run time.
Namely, say there is one power resource such that the ACPI power
state D0 of a PCI device depends on that power resource (i.e. the
device is in D0 when that power resource is "on") and it is used
as a wakeup power resource for the same device. Then, calling
acpi_pci_sleep_wake(pci_dev, false) for the device in question will
cause the reference counter of that power resource to drop to 0,
which in turn will cause it to be turned off. As a result, the
device will go into D3cold at that point, although it should have
stayed in D0.
As it turns out, that happens to USB controllers on some laptops
and USB becomes unusable on those machines as a result, which is
a major regression from v3.8.
To fix this problem, (1) increment the reference counters of wakup
power resources during their initialization if they are "on"
initially, (2) prevent acpi_disable_wakeup_device_power() from
decrementing the reference counters of wakeup power resources that
were not enabled for wakeup power previously, and (3) prevent
acpi_enable_wakeup_device_power() from incrementing the reference
counters of wakeup power resources that already are enabled for
wakeup power.
In addition to that, if it is impossible to determine the initial
states of wakeup power resources, avoid enabling wakeup for devices
whose wakeup power depends on those power resources.
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Tested-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-02-24 02:15:21 +04:00
|
|
|
return result;
|
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
ACPI / PM: Take unusual configurations of power resources into account
Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device
wakeup) moved the initial disabling of system wakeup for PCI devices
into a place where it can actually work and that exposed a hidden old
issue with crap^Wunusual system designs where the same power
resources are used for both wakeup power and device power control at
run time.
Namely, say there is one power resource such that the ACPI power
state D0 of a PCI device depends on that power resource (i.e. the
device is in D0 when that power resource is "on") and it is used
as a wakeup power resource for the same device. Then, calling
acpi_pci_sleep_wake(pci_dev, false) for the device in question will
cause the reference counter of that power resource to drop to 0,
which in turn will cause it to be turned off. As a result, the
device will go into D3cold at that point, although it should have
stayed in D0.
As it turns out, that happens to USB controllers on some laptops
and USB becomes unusable on those machines as a result, which is
a major regression from v3.8.
To fix this problem, (1) increment the reference counters of wakup
power resources during their initialization if they are "on"
initially, (2) prevent acpi_disable_wakeup_device_power() from
decrementing the reference counters of wakeup power resources that
were not enabled for wakeup power previously, and (3) prevent
acpi_enable_wakeup_device_power() from incrementing the reference
counters of wakeup power resources that already are enabled for
wakeup power.
In addition to that, if it is impossible to determine the initial
states of wakeup power resources, avoid enabling wakeup for devices
whose wakeup power depends on those power resources.
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Tested-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-02-24 02:15:21 +04:00
|
|
|
static int acpi_power_off(struct acpi_power_resource *resource)
|
|
|
|
{
|
|
|
|
int result;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
ACPI / PM: Take unusual configurations of power resources into account
Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device
wakeup) moved the initial disabling of system wakeup for PCI devices
into a place where it can actually work and that exposed a hidden old
issue with crap^Wunusual system designs where the same power
resources are used for both wakeup power and device power control at
run time.
Namely, say there is one power resource such that the ACPI power
state D0 of a PCI device depends on that power resource (i.e. the
device is in D0 when that power resource is "on") and it is used
as a wakeup power resource for the same device. Then, calling
acpi_pci_sleep_wake(pci_dev, false) for the device in question will
cause the reference counter of that power resource to drop to 0,
which in turn will cause it to be turned off. As a result, the
device will go into D3cold at that point, although it should have
stayed in D0.
As it turns out, that happens to USB controllers on some laptops
and USB becomes unusable on those machines as a result, which is
a major regression from v3.8.
To fix this problem, (1) increment the reference counters of wakup
power resources during their initialization if they are "on"
initially, (2) prevent acpi_disable_wakeup_device_power() from
decrementing the reference counters of wakeup power resources that
were not enabled for wakeup power previously, and (3) prevent
acpi_enable_wakeup_device_power() from incrementing the reference
counters of wakeup power resources that already are enabled for
wakeup power.
In addition to that, if it is impossible to determine the initial
states of wakeup power resources, avoid enabling wakeup for devices
whose wakeup power depends on those power resources.
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Tested-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-02-24 02:15:21 +04:00
|
|
|
mutex_lock(&resource->resource_lock);
|
|
|
|
result = acpi_power_off_unlocked(resource);
|
|
|
|
mutex_unlock(&resource->resource_lock);
|
2010-10-22 04:35:54 +04:00
|
|
|
return result;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2013-01-17 17:11:06 +04:00
|
|
|
static int acpi_power_off_list(struct list_head *list)
|
2010-11-25 02:06:09 +03:00
|
|
|
{
|
2013-01-17 17:11:06 +04:00
|
|
|
struct acpi_power_resource_entry *entry;
|
|
|
|
int result = 0;
|
2010-11-25 02:06:09 +03:00
|
|
|
|
2013-01-17 17:11:06 +04:00
|
|
|
list_for_each_entry_reverse(entry, list, node) {
|
|
|
|
result = acpi_power_off(entry->resource);
|
|
|
|
if (result)
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
return 0;
|
2010-11-25 02:06:09 +03:00
|
|
|
|
2013-01-17 17:11:06 +04:00
|
|
|
err:
|
|
|
|
list_for_each_entry_continue(entry, list, node)
|
|
|
|
acpi_power_on(entry->resource);
|
|
|
|
|
|
|
|
return result;
|
2010-11-25 02:06:09 +03:00
|
|
|
}
|
|
|
|
|
2013-01-17 17:11:06 +04:00
|
|
|
static int acpi_power_on_list(struct list_head *list)
|
2010-11-25 02:06:09 +03:00
|
|
|
{
|
2013-01-17 17:11:06 +04:00
|
|
|
struct acpi_power_resource_entry *entry;
|
2010-11-25 02:06:09 +03:00
|
|
|
int result = 0;
|
|
|
|
|
2013-01-17 17:11:06 +04:00
|
|
|
list_for_each_entry(entry, list, node) {
|
|
|
|
result = acpi_power_on(entry->resource);
|
|
|
|
if (result)
|
|
|
|
goto err;
|
2010-11-25 02:06:09 +03:00
|
|
|
}
|
2013-01-17 17:11:06 +04:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
err:
|
|
|
|
list_for_each_entry_continue_reverse(entry, list, node)
|
|
|
|
acpi_power_off(entry->resource);
|
2010-11-25 02:06:09 +03:00
|
|
|
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2013-01-26 00:51:32 +04:00
|
|
|
static struct attribute *attrs[] = {
|
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
2017-06-30 15:09:05 +03:00
|
|
|
static const struct attribute_group attr_groups[] = {
|
2013-01-26 00:51:32 +04:00
|
|
|
[ACPI_STATE_D0] = {
|
|
|
|
.name = "power_resources_D0",
|
|
|
|
.attrs = attrs,
|
|
|
|
},
|
|
|
|
[ACPI_STATE_D1] = {
|
|
|
|
.name = "power_resources_D1",
|
|
|
|
.attrs = attrs,
|
|
|
|
},
|
|
|
|
[ACPI_STATE_D2] = {
|
|
|
|
.name = "power_resources_D2",
|
|
|
|
.attrs = attrs,
|
|
|
|
},
|
|
|
|
[ACPI_STATE_D3_HOT] = {
|
|
|
|
.name = "power_resources_D3hot",
|
|
|
|
.attrs = attrs,
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2017-06-30 15:09:05 +03:00
|
|
|
static const struct attribute_group wakeup_attr_group = {
|
2013-04-12 00:41:48 +04:00
|
|
|
.name = "power_resources_wakeup",
|
|
|
|
.attrs = attrs,
|
|
|
|
};
|
|
|
|
|
|
|
|
static void acpi_power_hide_list(struct acpi_device *adev,
|
|
|
|
struct list_head *resources,
|
2017-06-30 15:09:05 +03:00
|
|
|
const struct attribute_group *attr_group)
|
2013-01-26 00:51:32 +04:00
|
|
|
{
|
|
|
|
struct acpi_power_resource_entry *entry;
|
|
|
|
|
2013-04-12 00:41:48 +04:00
|
|
|
if (list_empty(resources))
|
2013-01-26 00:51:32 +04:00
|
|
|
return;
|
|
|
|
|
2013-04-12 00:41:48 +04:00
|
|
|
list_for_each_entry_reverse(entry, resources, node) {
|
2013-01-26 00:51:32 +04:00
|
|
|
struct acpi_device *res_dev = &entry->resource->device;
|
|
|
|
|
|
|
|
sysfs_remove_link_from_group(&adev->dev.kobj,
|
2013-04-12 00:41:48 +04:00
|
|
|
attr_group->name,
|
2013-01-26 00:51:32 +04:00
|
|
|
dev_name(&res_dev->dev));
|
|
|
|
}
|
2013-04-12 00:41:48 +04:00
|
|
|
sysfs_remove_group(&adev->dev.kobj, attr_group);
|
2013-01-26 00:51:32 +04:00
|
|
|
}
|
|
|
|
|
2013-04-12 00:41:48 +04:00
|
|
|
static void acpi_power_expose_list(struct acpi_device *adev,
|
|
|
|
struct list_head *resources,
|
2017-06-30 15:09:05 +03:00
|
|
|
const struct attribute_group *attr_group)
|
2012-03-29 10:09:39 +04:00
|
|
|
{
|
2013-01-26 00:51:32 +04:00
|
|
|
struct acpi_power_resource_entry *entry;
|
|
|
|
int ret;
|
|
|
|
|
2013-04-12 00:41:48 +04:00
|
|
|
if (list_empty(resources))
|
2013-01-26 00:51:32 +04:00
|
|
|
return;
|
|
|
|
|
2013-04-12 00:41:48 +04:00
|
|
|
ret = sysfs_create_group(&adev->dev.kobj, attr_group);
|
2013-01-26 00:51:32 +04:00
|
|
|
if (ret)
|
|
|
|
return;
|
|
|
|
|
2013-04-12 00:41:48 +04:00
|
|
|
list_for_each_entry(entry, resources, node) {
|
2013-01-26 00:51:32 +04:00
|
|
|
struct acpi_device *res_dev = &entry->resource->device;
|
|
|
|
|
|
|
|
ret = sysfs_add_link_to_group(&adev->dev.kobj,
|
2013-04-12 00:41:48 +04:00
|
|
|
attr_group->name,
|
2013-01-26 00:51:32 +04:00
|
|
|
&res_dev->dev.kobj,
|
|
|
|
dev_name(&res_dev->dev));
|
|
|
|
if (ret) {
|
2013-04-12 00:41:48 +04:00
|
|
|
acpi_power_hide_list(adev, resources, attr_group);
|
2013-01-26 00:51:32 +04:00
|
|
|
break;
|
2012-03-29 10:09:39 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
ACPI / PM: Rework the handling of devices depending on power resources
Commit 0090def6 (ACPI: Add interface to register/unregister device
to/from power resources) made it possible to indicate to the ACPI
core that if the given device depends on any power resources, then
it should be resumed as soon as all of the power resources required
by it to transition to the D0 power state have been turned on.
Unfortunately, however, this was a mistake, because all devices
depending on power resources should be treated this way (i.e. they
should be resumed when all power resources required by their D0
state have been turned on) and for the majority of those devices
the ACPI core can figure out by itself which (physical) devices
depend on what power resources.
For this reason, replace the code added by commit 0090def6 with a
new, much more straightforward, mechanism that will be used
internally by the ACPI core and remove all references to that code
from kernel subsystems using ACPI.
For the cases when there are (physical) devices that should be
resumed whenever a not directly related ACPI device node goes into
D0 as a result of power resources configuration changes, like in
the SATA case, add two new routines, acpi_dev_pm_add_dependent()
and acpi_dev_pm_remove_dependent(), allowing subsystems to manage
such dependencies. Convert the SATA subsystem to use the new
functions accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-01-17 17:11:05 +04:00
|
|
|
|
2013-04-12 00:41:48 +04:00
|
|
|
static void acpi_power_expose_hide(struct acpi_device *adev,
|
|
|
|
struct list_head *resources,
|
2017-06-30 15:09:05 +03:00
|
|
|
const struct attribute_group *attr_group,
|
2013-04-12 00:41:48 +04:00
|
|
|
bool expose)
|
|
|
|
{
|
|
|
|
if (expose)
|
|
|
|
acpi_power_expose_list(adev, resources, attr_group);
|
|
|
|
else
|
|
|
|
acpi_power_hide_list(adev, resources, attr_group);
|
|
|
|
}
|
|
|
|
|
2013-01-26 00:51:32 +04:00
|
|
|
void acpi_power_add_remove_device(struct acpi_device *adev, bool add)
|
|
|
|
{
|
|
|
|
int state;
|
|
|
|
|
2013-04-12 00:41:48 +04:00
|
|
|
if (adev->wakeup.flags.valid)
|
|
|
|
acpi_power_expose_hide(adev, &adev->wakeup.resources,
|
|
|
|
&wakeup_attr_group, add);
|
|
|
|
|
2013-01-26 00:51:32 +04:00
|
|
|
if (!adev->power.flags.power_resources)
|
|
|
|
return;
|
|
|
|
|
2013-04-12 00:41:48 +04:00
|
|
|
for (state = ACPI_STATE_D0; state <= ACPI_STATE_D3_HOT; state++)
|
|
|
|
acpi_power_expose_hide(adev,
|
|
|
|
&adev->power.states[state].resources,
|
|
|
|
&attr_groups[state], add);
|
2013-01-26 00:51:32 +04:00
|
|
|
}
|
|
|
|
|
ACPI / PM: Take unusual configurations of power resources into account
Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device
wakeup) moved the initial disabling of system wakeup for PCI devices
into a place where it can actually work and that exposed a hidden old
issue with crap^Wunusual system designs where the same power
resources are used for both wakeup power and device power control at
run time.
Namely, say there is one power resource such that the ACPI power
state D0 of a PCI device depends on that power resource (i.e. the
device is in D0 when that power resource is "on") and it is used
as a wakeup power resource for the same device. Then, calling
acpi_pci_sleep_wake(pci_dev, false) for the device in question will
cause the reference counter of that power resource to drop to 0,
which in turn will cause it to be turned off. As a result, the
device will go into D3cold at that point, although it should have
stayed in D0.
As it turns out, that happens to USB controllers on some laptops
and USB becomes unusable on those machines as a result, which is
a major regression from v3.8.
To fix this problem, (1) increment the reference counters of wakup
power resources during their initialization if they are "on"
initially, (2) prevent acpi_disable_wakeup_device_power() from
decrementing the reference counters of wakeup power resources that
were not enabled for wakeup power previously, and (3) prevent
acpi_enable_wakeup_device_power() from incrementing the reference
counters of wakeup power resources that already are enabled for
wakeup power.
In addition to that, if it is impossible to determine the initial
states of wakeup power resources, avoid enabling wakeup for devices
whose wakeup power depends on those power resources.
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Tested-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-02-24 02:15:21 +04:00
|
|
|
int acpi_power_wakeup_list_init(struct list_head *list, int *system_level_p)
|
2013-01-17 17:11:07 +04:00
|
|
|
{
|
|
|
|
struct acpi_power_resource_entry *entry;
|
|
|
|
int system_level = 5;
|
|
|
|
|
|
|
|
list_for_each_entry(entry, list, node) {
|
|
|
|
struct acpi_power_resource *resource = entry->resource;
|
ACPI / PM: Take unusual configurations of power resources into account
Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device
wakeup) moved the initial disabling of system wakeup for PCI devices
into a place where it can actually work and that exposed a hidden old
issue with crap^Wunusual system designs where the same power
resources are used for both wakeup power and device power control at
run time.
Namely, say there is one power resource such that the ACPI power
state D0 of a PCI device depends on that power resource (i.e. the
device is in D0 when that power resource is "on") and it is used
as a wakeup power resource for the same device. Then, calling
acpi_pci_sleep_wake(pci_dev, false) for the device in question will
cause the reference counter of that power resource to drop to 0,
which in turn will cause it to be turned off. As a result, the
device will go into D3cold at that point, although it should have
stayed in D0.
As it turns out, that happens to USB controllers on some laptops
and USB becomes unusable on those machines as a result, which is
a major regression from v3.8.
To fix this problem, (1) increment the reference counters of wakup
power resources during their initialization if they are "on"
initially, (2) prevent acpi_disable_wakeup_device_power() from
decrementing the reference counters of wakeup power resources that
were not enabled for wakeup power previously, and (3) prevent
acpi_enable_wakeup_device_power() from incrementing the reference
counters of wakeup power resources that already are enabled for
wakeup power.
In addition to that, if it is impossible to determine the initial
states of wakeup power resources, avoid enabling wakeup for devices
whose wakeup power depends on those power resources.
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Tested-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-02-24 02:15:21 +04:00
|
|
|
int result;
|
2021-05-24 18:24:16 +03:00
|
|
|
u8 state;
|
2013-01-17 17:11:07 +04:00
|
|
|
|
ACPI / PM: Take unusual configurations of power resources into account
Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device
wakeup) moved the initial disabling of system wakeup for PCI devices
into a place where it can actually work and that exposed a hidden old
issue with crap^Wunusual system designs where the same power
resources are used for both wakeup power and device power control at
run time.
Namely, say there is one power resource such that the ACPI power
state D0 of a PCI device depends on that power resource (i.e. the
device is in D0 when that power resource is "on") and it is used
as a wakeup power resource for the same device. Then, calling
acpi_pci_sleep_wake(pci_dev, false) for the device in question will
cause the reference counter of that power resource to drop to 0,
which in turn will cause it to be turned off. As a result, the
device will go into D3cold at that point, although it should have
stayed in D0.
As it turns out, that happens to USB controllers on some laptops
and USB becomes unusable on those machines as a result, which is
a major regression from v3.8.
To fix this problem, (1) increment the reference counters of wakup
power resources during their initialization if they are "on"
initially, (2) prevent acpi_disable_wakeup_device_power() from
decrementing the reference counters of wakeup power resources that
were not enabled for wakeup power previously, and (3) prevent
acpi_enable_wakeup_device_power() from incrementing the reference
counters of wakeup power resources that already are enabled for
wakeup power.
In addition to that, if it is impossible to determine the initial
states of wakeup power resources, avoid enabling wakeup for devices
whose wakeup power depends on those power resources.
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Tested-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-02-24 02:15:21 +04:00
|
|
|
mutex_lock(&resource->resource_lock);
|
|
|
|
|
ACPI: power: Save the last known state of each power resource
Currently, there are two ways to check the state of an ACPI power
resource and they may not be consistent with each other. The first
one is to evaluate the power resource's _STA object and the other one
is to check its reference counter value. However, on some systems
the value returned by _STA may not be consistent with the value of
the power resource's reference counter (for example, on some systems
it returns the same value every time for certain power resources).
Moreover, evaluating _STA is unnecessary overhead for a power
resource for which it has been evaluated already or whose state is
otherwise known, because either the _ON or the _OFF method has been
executed for it.
For this reason, save the state of each power resource in its
struct acpi_power_resource object and use the saved value whenever
its state needs to be checked, except when its stats is unknown, in
which case the _STA method is evaluated for it and the value
returned by that method is saved as the last known state of
the power resource.
Moreover, drop the power resource _STA method evaluation from
acpi_add_power_resource(), so as to avoid doing that unnecessarily
for power resources that will never be used.
Tested-by: Dave Olsthoorn <dave@bewaar.me>
Tested-by: Shujun Wang <wsj20369@163.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-05-24 18:25:23 +03:00
|
|
|
result = acpi_power_get_state(resource, &state);
|
ACPI / PM: Take unusual configurations of power resources into account
Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device
wakeup) moved the initial disabling of system wakeup for PCI devices
into a place where it can actually work and that exposed a hidden old
issue with crap^Wunusual system designs where the same power
resources are used for both wakeup power and device power control at
run time.
Namely, say there is one power resource such that the ACPI power
state D0 of a PCI device depends on that power resource (i.e. the
device is in D0 when that power resource is "on") and it is used
as a wakeup power resource for the same device. Then, calling
acpi_pci_sleep_wake(pci_dev, false) for the device in question will
cause the reference counter of that power resource to drop to 0,
which in turn will cause it to be turned off. As a result, the
device will go into D3cold at that point, although it should have
stayed in D0.
As it turns out, that happens to USB controllers on some laptops
and USB becomes unusable on those machines as a result, which is
a major regression from v3.8.
To fix this problem, (1) increment the reference counters of wakup
power resources during their initialization if they are "on"
initially, (2) prevent acpi_disable_wakeup_device_power() from
decrementing the reference counters of wakeup power resources that
were not enabled for wakeup power previously, and (3) prevent
acpi_enable_wakeup_device_power() from incrementing the reference
counters of wakeup power resources that already are enabled for
wakeup power.
In addition to that, if it is impossible to determine the initial
states of wakeup power resources, avoid enabling wakeup for devices
whose wakeup power depends on those power resources.
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Tested-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-02-24 02:15:21 +04:00
|
|
|
if (result) {
|
|
|
|
mutex_unlock(&resource->resource_lock);
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
if (state == ACPI_POWER_RESOURCE_STATE_ON) {
|
|
|
|
resource->ref_count++;
|
|
|
|
resource->wakeup_enabled = true;
|
|
|
|
}
|
2013-01-17 17:11:07 +04:00
|
|
|
if (system_level > resource->system_level)
|
|
|
|
system_level = resource->system_level;
|
ACPI / PM: Take unusual configurations of power resources into account
Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device
wakeup) moved the initial disabling of system wakeup for PCI devices
into a place where it can actually work and that exposed a hidden old
issue with crap^Wunusual system designs where the same power
resources are used for both wakeup power and device power control at
run time.
Namely, say there is one power resource such that the ACPI power
state D0 of a PCI device depends on that power resource (i.e. the
device is in D0 when that power resource is "on") and it is used
as a wakeup power resource for the same device. Then, calling
acpi_pci_sleep_wake(pci_dev, false) for the device in question will
cause the reference counter of that power resource to drop to 0,
which in turn will cause it to be turned off. As a result, the
device will go into D3cold at that point, although it should have
stayed in D0.
As it turns out, that happens to USB controllers on some laptops
and USB becomes unusable on those machines as a result, which is
a major regression from v3.8.
To fix this problem, (1) increment the reference counters of wakup
power resources during their initialization if they are "on"
initially, (2) prevent acpi_disable_wakeup_device_power() from
decrementing the reference counters of wakeup power resources that
were not enabled for wakeup power previously, and (3) prevent
acpi_enable_wakeup_device_power() from incrementing the reference
counters of wakeup power resources that already are enabled for
wakeup power.
In addition to that, if it is impossible to determine the initial
states of wakeup power resources, avoid enabling wakeup for devices
whose wakeup power depends on those power resources.
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Tested-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-02-24 02:15:21 +04:00
|
|
|
|
|
|
|
mutex_unlock(&resource->resource_lock);
|
2013-01-17 17:11:07 +04:00
|
|
|
}
|
ACPI / PM: Take unusual configurations of power resources into account
Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device
wakeup) moved the initial disabling of system wakeup for PCI devices
into a place where it can actually work and that exposed a hidden old
issue with crap^Wunusual system designs where the same power
resources are used for both wakeup power and device power control at
run time.
Namely, say there is one power resource such that the ACPI power
state D0 of a PCI device depends on that power resource (i.e. the
device is in D0 when that power resource is "on") and it is used
as a wakeup power resource for the same device. Then, calling
acpi_pci_sleep_wake(pci_dev, false) for the device in question will
cause the reference counter of that power resource to drop to 0,
which in turn will cause it to be turned off. As a result, the
device will go into D3cold at that point, although it should have
stayed in D0.
As it turns out, that happens to USB controllers on some laptops
and USB becomes unusable on those machines as a result, which is
a major regression from v3.8.
To fix this problem, (1) increment the reference counters of wakup
power resources during their initialization if they are "on"
initially, (2) prevent acpi_disable_wakeup_device_power() from
decrementing the reference counters of wakeup power resources that
were not enabled for wakeup power previously, and (3) prevent
acpi_enable_wakeup_device_power() from incrementing the reference
counters of wakeup power resources that already are enabled for
wakeup power.
In addition to that, if it is impossible to determine the initial
states of wakeup power resources, avoid enabling wakeup for devices
whose wakeup power depends on those power resources.
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Tested-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-02-24 02:15:21 +04:00
|
|
|
*system_level_p = system_level;
|
|
|
|
return 0;
|
2013-01-17 17:11:07 +04:00
|
|
|
}
|
|
|
|
|
ACPI / PM: Rework the handling of devices depending on power resources
Commit 0090def6 (ACPI: Add interface to register/unregister device
to/from power resources) made it possible to indicate to the ACPI
core that if the given device depends on any power resources, then
it should be resumed as soon as all of the power resources required
by it to transition to the D0 power state have been turned on.
Unfortunately, however, this was a mistake, because all devices
depending on power resources should be treated this way (i.e. they
should be resumed when all power resources required by their D0
state have been turned on) and for the majority of those devices
the ACPI core can figure out by itself which (physical) devices
depend on what power resources.
For this reason, replace the code added by commit 0090def6 with a
new, much more straightforward, mechanism that will be used
internally by the ACPI core and remove all references to that code
from kernel subsystems using ACPI.
For the cases when there are (physical) devices that should be
resumed whenever a not directly related ACPI device node goes into
D0 as a result of power resources configuration changes, like in
the SATA case, add two new routines, acpi_dev_pm_add_dependent()
and acpi_dev_pm_remove_dependent(), allowing subsystems to manage
such dependencies. Convert the SATA subsystem to use the new
functions accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-01-17 17:11:05 +04:00
|
|
|
/* --------------------------------------------------------------------------
|
|
|
|
Device Power Management
|
|
|
|
-------------------------------------------------------------------------- */
|
2012-03-29 10:09:39 +04:00
|
|
|
|
2008-07-07 05:33:34 +04:00
|
|
|
/**
|
|
|
|
* acpi_device_sleep_wake - execute _DSW (Device Sleep Wake) or (deprecated in
|
|
|
|
* ACPI 3.0) _PSW (Power State Wake)
|
|
|
|
* @dev: Device to handle.
|
|
|
|
* @enable: 0 - disable, 1 - enable the wake capabilities of the device.
|
|
|
|
* @sleep_state: Target sleep state of the system.
|
|
|
|
* @dev_state: Target power state of the device.
|
|
|
|
*
|
|
|
|
* Execute _DSW (Device Sleep Wake) or (deprecated in ACPI 3.0) _PSW (Power
|
|
|
|
* State Wake) for the device, if present. On failure reset the device's
|
|
|
|
* wakeup.flags.valid flag.
|
|
|
|
*
|
|
|
|
* RETURN VALUE:
|
|
|
|
* 0 if either _DSW or _PSW has been successfully executed
|
|
|
|
* 0 if neither _DSW nor _PSW has been found
|
|
|
|
* -ENODEV if the execution of either _DSW or _PSW has failed
|
|
|
|
*/
|
|
|
|
int acpi_device_sleep_wake(struct acpi_device *dev,
|
2020-11-05 05:06:00 +03:00
|
|
|
int enable, int sleep_state, int dev_state)
|
2008-07-07 05:33:34 +04:00
|
|
|
{
|
|
|
|
union acpi_object in_arg[3];
|
|
|
|
struct acpi_object_list arg_list = { 3, in_arg };
|
|
|
|
acpi_status status = AE_OK;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Try to execute _DSW first.
|
|
|
|
*
|
2019-03-25 21:34:00 +03:00
|
|
|
* Three arguments are needed for the _DSW object:
|
2008-07-07 05:33:34 +04:00
|
|
|
* Argument 0: enable/disable the wake capabilities
|
|
|
|
* Argument 1: target system state
|
|
|
|
* Argument 2: target device state
|
|
|
|
* When _DSW object is called to disable the wake capabilities, maybe
|
2019-03-25 21:34:00 +03:00
|
|
|
* the first argument is filled. The values of the other two arguments
|
2008-07-07 05:33:34 +04:00
|
|
|
* are meaningless.
|
|
|
|
*/
|
|
|
|
in_arg[0].type = ACPI_TYPE_INTEGER;
|
|
|
|
in_arg[0].integer.value = enable;
|
|
|
|
in_arg[1].type = ACPI_TYPE_INTEGER;
|
|
|
|
in_arg[1].integer.value = sleep_state;
|
|
|
|
in_arg[2].type = ACPI_TYPE_INTEGER;
|
|
|
|
in_arg[2].integer.value = dev_state;
|
|
|
|
status = acpi_evaluate_object(dev->handle, "_DSW", &arg_list, NULL);
|
|
|
|
if (ACPI_SUCCESS(status)) {
|
|
|
|
return 0;
|
|
|
|
} else if (status != AE_NOT_FOUND) {
|
2021-01-20 21:57:03 +03:00
|
|
|
acpi_handle_info(dev->handle, "_DSW execution failed\n");
|
2008-07-07 05:33:34 +04:00
|
|
|
dev->wakeup.flags.valid = 0;
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Execute _PSW */
|
2013-06-28 20:24:39 +04:00
|
|
|
status = acpi_execute_simple_method(dev->handle, "_PSW", enable);
|
2008-07-07 05:33:34 +04:00
|
|
|
if (ACPI_FAILURE(status) && (status != AE_NOT_FOUND)) {
|
2021-01-20 21:57:03 +03:00
|
|
|
acpi_handle_info(dev->handle, "_PSW execution failed\n");
|
2008-07-07 05:33:34 +04:00
|
|
|
dev->wakeup.flags.valid = 0;
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
/*
|
|
|
|
* Prepare a wakeup device, two steps (Ref ACPI 2.0:P229):
|
2020-11-05 05:06:00 +03:00
|
|
|
* 1. Power on the power resources required for the wakeup device
|
2008-07-07 05:33:34 +04:00
|
|
|
* 2. Execute _DSW (Device Sleep Wake) or (deprecated in ACPI 3.0) _PSW (Power
|
|
|
|
* State Wake) for the device, if present
|
2005-04-17 02:20:36 +04:00
|
|
|
*/
|
2008-07-07 05:33:34 +04:00
|
|
|
int acpi_enable_wakeup_device_power(struct acpi_device *dev, int sleep_state)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
ACPI / PM: Take unusual configurations of power resources into account
Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device
wakeup) moved the initial disabling of system wakeup for PCI devices
into a place where it can actually work and that exposed a hidden old
issue with crap^Wunusual system designs where the same power
resources are used for both wakeup power and device power control at
run time.
Namely, say there is one power resource such that the ACPI power
state D0 of a PCI device depends on that power resource (i.e. the
device is in D0 when that power resource is "on") and it is used
as a wakeup power resource for the same device. Then, calling
acpi_pci_sleep_wake(pci_dev, false) for the device in question will
cause the reference counter of that power resource to drop to 0,
which in turn will cause it to be turned off. As a result, the
device will go into D3cold at that point, although it should have
stayed in D0.
As it turns out, that happens to USB controllers on some laptops
and USB becomes unusable on those machines as a result, which is
a major regression from v3.8.
To fix this problem, (1) increment the reference counters of wakup
power resources during their initialization if they are "on"
initially, (2) prevent acpi_disable_wakeup_device_power() from
decrementing the reference counters of wakeup power resources that
were not enabled for wakeup power previously, and (3) prevent
acpi_enable_wakeup_device_power() from incrementing the reference
counters of wakeup power resources that already are enabled for
wakeup power.
In addition to that, if it is impossible to determine the initial
states of wakeup power resources, avoid enabling wakeup for devices
whose wakeup power depends on those power resources.
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Tested-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-02-24 02:15:21 +04:00
|
|
|
struct acpi_power_resource_entry *entry;
|
2013-01-17 17:11:06 +04:00
|
|
|
int err = 0;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
if (!dev || !dev->wakeup.flags.valid)
|
2008-07-07 05:33:34 +04:00
|
|
|
return -EINVAL;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2009-09-09 01:15:31 +04:00
|
|
|
mutex_lock(&acpi_device_lock);
|
|
|
|
|
|
|
|
if (dev->wakeup.prepare_count++)
|
|
|
|
goto out;
|
2008-07-07 05:34:11 +04:00
|
|
|
|
ACPI / PM: Take unusual configurations of power resources into account
Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device
wakeup) moved the initial disabling of system wakeup for PCI devices
into a place where it can actually work and that exposed a hidden old
issue with crap^Wunusual system designs where the same power
resources are used for both wakeup power and device power control at
run time.
Namely, say there is one power resource such that the ACPI power
state D0 of a PCI device depends on that power resource (i.e. the
device is in D0 when that power resource is "on") and it is used
as a wakeup power resource for the same device. Then, calling
acpi_pci_sleep_wake(pci_dev, false) for the device in question will
cause the reference counter of that power resource to drop to 0,
which in turn will cause it to be turned off. As a result, the
device will go into D3cold at that point, although it should have
stayed in D0.
As it turns out, that happens to USB controllers on some laptops
and USB becomes unusable on those machines as a result, which is
a major regression from v3.8.
To fix this problem, (1) increment the reference counters of wakup
power resources during their initialization if they are "on"
initially, (2) prevent acpi_disable_wakeup_device_power() from
decrementing the reference counters of wakeup power resources that
were not enabled for wakeup power previously, and (3) prevent
acpi_enable_wakeup_device_power() from incrementing the reference
counters of wakeup power resources that already are enabled for
wakeup power.
In addition to that, if it is impossible to determine the initial
states of wakeup power resources, avoid enabling wakeup for devices
whose wakeup power depends on those power resources.
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Tested-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-02-24 02:15:21 +04:00
|
|
|
list_for_each_entry(entry, &dev->wakeup.resources, node) {
|
|
|
|
struct acpi_power_resource *resource = entry->resource;
|
|
|
|
|
|
|
|
mutex_lock(&resource->resource_lock);
|
|
|
|
|
|
|
|
if (!resource->wakeup_enabled) {
|
|
|
|
err = acpi_power_on_unlocked(resource);
|
|
|
|
if (!err)
|
|
|
|
resource->wakeup_enabled = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
mutex_unlock(&resource->resource_lock);
|
|
|
|
|
|
|
|
if (err) {
|
|
|
|
dev_err(&dev->dev,
|
|
|
|
"Cannot turn wakeup power resources on\n");
|
|
|
|
dev->wakeup.flags.valid = 0;
|
|
|
|
goto out;
|
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
ACPI / PM: Take unusual configurations of power resources into account
Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device
wakeup) moved the initial disabling of system wakeup for PCI devices
into a place where it can actually work and that exposed a hidden old
issue with crap^Wunusual system designs where the same power
resources are used for both wakeup power and device power control at
run time.
Namely, say there is one power resource such that the ACPI power
state D0 of a PCI device depends on that power resource (i.e. the
device is in D0 when that power resource is "on") and it is used
as a wakeup power resource for the same device. Then, calling
acpi_pci_sleep_wake(pci_dev, false) for the device in question will
cause the reference counter of that power resource to drop to 0,
which in turn will cause it to be turned off. As a result, the
device will go into D3cold at that point, although it should have
stayed in D0.
As it turns out, that happens to USB controllers on some laptops
and USB becomes unusable on those machines as a result, which is
a major regression from v3.8.
To fix this problem, (1) increment the reference counters of wakup
power resources during their initialization if they are "on"
initially, (2) prevent acpi_disable_wakeup_device_power() from
decrementing the reference counters of wakeup power resources that
were not enabled for wakeup power previously, and (3) prevent
acpi_enable_wakeup_device_power() from incrementing the reference
counters of wakeup power resources that already are enabled for
wakeup power.
In addition to that, if it is impossible to determine the initial
states of wakeup power resources, avoid enabling wakeup for devices
whose wakeup power depends on those power resources.
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Tested-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-02-24 02:15:21 +04:00
|
|
|
/*
|
|
|
|
* Passing 3 as the third argument below means the device may be
|
|
|
|
* put into arbitrary power state afterward.
|
|
|
|
*/
|
|
|
|
err = acpi_device_sleep_wake(dev, 1, sleep_state, 3);
|
2009-09-09 01:15:31 +04:00
|
|
|
if (err)
|
|
|
|
dev->wakeup.prepare_count = 0;
|
|
|
|
|
|
|
|
out:
|
|
|
|
mutex_unlock(&acpi_device_lock);
|
2008-07-07 05:34:11 +04:00
|
|
|
return err;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Shutdown a wakeup device, counterpart of above method
|
2008-07-07 05:33:34 +04:00
|
|
|
* 1. Execute _DSW (Device Sleep Wake) or (deprecated in ACPI 3.0) _PSW (Power
|
|
|
|
* State Wake) for the device, if present
|
2005-04-17 02:20:36 +04:00
|
|
|
* 2. Shutdown down the power resources
|
|
|
|
*/
|
2005-08-05 08:44:28 +04:00
|
|
|
int acpi_disable_wakeup_device_power(struct acpi_device *dev)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
ACPI / PM: Take unusual configurations of power resources into account
Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device
wakeup) moved the initial disabling of system wakeup for PCI devices
into a place where it can actually work and that exposed a hidden old
issue with crap^Wunusual system designs where the same power
resources are used for both wakeup power and device power control at
run time.
Namely, say there is one power resource such that the ACPI power
state D0 of a PCI device depends on that power resource (i.e. the
device is in D0 when that power resource is "on") and it is used
as a wakeup power resource for the same device. Then, calling
acpi_pci_sleep_wake(pci_dev, false) for the device in question will
cause the reference counter of that power resource to drop to 0,
which in turn will cause it to be turned off. As a result, the
device will go into D3cold at that point, although it should have
stayed in D0.
As it turns out, that happens to USB controllers on some laptops
and USB becomes unusable on those machines as a result, which is
a major regression from v3.8.
To fix this problem, (1) increment the reference counters of wakup
power resources during their initialization if they are "on"
initially, (2) prevent acpi_disable_wakeup_device_power() from
decrementing the reference counters of wakeup power resources that
were not enabled for wakeup power previously, and (3) prevent
acpi_enable_wakeup_device_power() from incrementing the reference
counters of wakeup power resources that already are enabled for
wakeup power.
In addition to that, if it is impossible to determine the initial
states of wakeup power resources, avoid enabling wakeup for devices
whose wakeup power depends on those power resources.
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Tested-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-02-24 02:15:21 +04:00
|
|
|
struct acpi_power_resource_entry *entry;
|
2013-01-17 17:11:06 +04:00
|
|
|
int err = 0;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
if (!dev || !dev->wakeup.flags.valid)
|
2008-07-07 05:33:34 +04:00
|
|
|
return -EINVAL;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2009-09-09 01:15:31 +04:00
|
|
|
mutex_lock(&acpi_device_lock);
|
|
|
|
|
|
|
|
if (--dev->wakeup.prepare_count > 0)
|
|
|
|
goto out;
|
|
|
|
|
2008-07-07 05:34:11 +04:00
|
|
|
/*
|
2009-09-09 01:15:31 +04:00
|
|
|
* Executing the code below even if prepare_count is already zero when
|
|
|
|
* the function is called may be useful, for example for initialisation.
|
2008-07-07 05:34:11 +04:00
|
|
|
*/
|
2009-09-09 01:15:31 +04:00
|
|
|
if (dev->wakeup.prepare_count < 0)
|
|
|
|
dev->wakeup.prepare_count = 0;
|
2008-07-07 05:34:11 +04:00
|
|
|
|
2009-09-09 01:15:31 +04:00
|
|
|
err = acpi_device_sleep_wake(dev, 0, 0, 0);
|
|
|
|
if (err)
|
|
|
|
goto out;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
ACPI / PM: Take unusual configurations of power resources into account
Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device
wakeup) moved the initial disabling of system wakeup for PCI devices
into a place where it can actually work and that exposed a hidden old
issue with crap^Wunusual system designs where the same power
resources are used for both wakeup power and device power control at
run time.
Namely, say there is one power resource such that the ACPI power
state D0 of a PCI device depends on that power resource (i.e. the
device is in D0 when that power resource is "on") and it is used
as a wakeup power resource for the same device. Then, calling
acpi_pci_sleep_wake(pci_dev, false) for the device in question will
cause the reference counter of that power resource to drop to 0,
which in turn will cause it to be turned off. As a result, the
device will go into D3cold at that point, although it should have
stayed in D0.
As it turns out, that happens to USB controllers on some laptops
and USB becomes unusable on those machines as a result, which is
a major regression from v3.8.
To fix this problem, (1) increment the reference counters of wakup
power resources during their initialization if they are "on"
initially, (2) prevent acpi_disable_wakeup_device_power() from
decrementing the reference counters of wakeup power resources that
were not enabled for wakeup power previously, and (3) prevent
acpi_enable_wakeup_device_power() from incrementing the reference
counters of wakeup power resources that already are enabled for
wakeup power.
In addition to that, if it is impossible to determine the initial
states of wakeup power resources, avoid enabling wakeup for devices
whose wakeup power depends on those power resources.
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Tested-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-02-24 02:15:21 +04:00
|
|
|
list_for_each_entry(entry, &dev->wakeup.resources, node) {
|
|
|
|
struct acpi_power_resource *resource = entry->resource;
|
|
|
|
|
|
|
|
mutex_lock(&resource->resource_lock);
|
|
|
|
|
|
|
|
if (resource->wakeup_enabled) {
|
|
|
|
err = acpi_power_off_unlocked(resource);
|
|
|
|
if (!err)
|
|
|
|
resource->wakeup_enabled = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
mutex_unlock(&resource->resource_lock);
|
|
|
|
|
|
|
|
if (err) {
|
|
|
|
dev_err(&dev->dev,
|
|
|
|
"Cannot turn wakeup power resources off\n");
|
|
|
|
dev->wakeup.flags.valid = 0;
|
|
|
|
break;
|
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2009-09-09 01:15:31 +04:00
|
|
|
out:
|
|
|
|
mutex_unlock(&acpi_device_lock);
|
|
|
|
return err;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2010-11-25 02:05:17 +03:00
|
|
|
int acpi_power_get_inferred_state(struct acpi_device *device, int *state)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2021-05-24 18:24:16 +03:00
|
|
|
u8 list_state = ACPI_POWER_RESOURCE_STATE_OFF;
|
2005-08-05 08:44:28 +04:00
|
|
|
int result = 0;
|
|
|
|
int i = 0;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2010-11-25 02:05:17 +03:00
|
|
|
if (!device || !state)
|
2006-06-27 08:41:40 +04:00
|
|
|
return -EINVAL;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We know a device's inferred power state when all the resources
|
|
|
|
* required for a given D-state are 'on'.
|
|
|
|
*/
|
2012-05-20 15:58:00 +04:00
|
|
|
for (i = ACPI_STATE_D0; i <= ACPI_STATE_D3_HOT; i++) {
|
2013-01-17 17:11:06 +04:00
|
|
|
struct list_head *list = &device->power.states[i].resources;
|
|
|
|
|
|
|
|
if (list_empty(list))
|
2005-04-17 02:20:36 +04:00
|
|
|
continue;
|
|
|
|
|
|
|
|
result = acpi_power_get_list_state(list, &list_state);
|
|
|
|
if (result)
|
2006-06-27 08:41:40 +04:00
|
|
|
return result;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
if (list_state == ACPI_POWER_RESOURCE_STATE_ON) {
|
2010-11-25 02:05:17 +03:00
|
|
|
*state = i;
|
2006-06-27 08:41:40 +04:00
|
|
|
return 0;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-05-16 02:55:35 +03:00
|
|
|
*state = device->power.states[ACPI_STATE_D3_COLD].flags.valid ?
|
|
|
|
ACPI_STATE_D3_COLD : ACPI_STATE_D3_HOT;
|
2006-06-27 08:41:40 +04:00
|
|
|
return 0;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2010-11-25 02:06:55 +03:00
|
|
|
int acpi_power_on_resources(struct acpi_device *device, int state)
|
|
|
|
{
|
2013-01-22 15:56:16 +04:00
|
|
|
if (!device || state < ACPI_STATE_D0 || state > ACPI_STATE_D3_HOT)
|
2010-11-25 02:06:55 +03:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
return acpi_power_on_list(&device->power.states[state].resources);
|
|
|
|
}
|
|
|
|
|
2005-08-05 08:44:28 +04:00
|
|
|
int acpi_power_transition(struct acpi_device *device, int state)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
ACPI / PCI / PM: Fix device PM regression related to D3hot/D3cold
Commit 1cc0c998fdf2 ("ACPI: Fix D3hot v D3cold confusion") introduced a
bug in __acpi_bus_set_power() and changed the behavior of
acpi_pci_set_power_state() in such a way that it generally doesn't work
as expected if PCI_D3hot is passed to it as the second argument.
First off, if ACPI_STATE_D3 (equal to ACPI_STATE_D3_COLD) is passed to
__acpi_bus_set_power() and the explicit_set flag is set for the D3cold
state, the function will try to execute AML method called "_PS4", which
doesn't exist.
Fix this by adding a check to ensure that the name of the AML method
to execute for transitions to ACPI_STATE_D3_COLD is correct in
__acpi_bus_set_power(). Also make sure that the explicit_set flag
for ACPI_STATE_D3_COLD will be set if _PS3 is present and modify
acpi_power_transition() to avoid accessing power resources for
ACPI_STATE_D3_COLD, because they don't exist.
Second, if PCI_D3hot is passed to acpi_pci_set_power_state() as the
target state, the function will request a transition to
ACPI_STATE_D3_HOT instead of ACPI_STATE_D3. However,
ACPI_STATE_D3_HOT is now only marked as supported if the _PR3 AML
method is defined for the given device, which is rare. This causes
problems to happen on systems where devices were successfully put
into ACPI D3 by pci_set_power_state(PCI_D3hot) which doesn't work
now. In particular, some unused graphics adapters are not turned
off as a result.
To fix this issue restore the old behavior of
acpi_pci_set_power_state(), which is to request a transition to
ACPI_STATE_D3 (equal to ACPI_STATE_D3_COLD) if either PCI_D3hot or
PCI_D3cold is passed to it as the argument.
This approach is not ideal, because generally power should not
be removed from devices if PCI_D3hot is the target power state,
but since this behavior is relied on, we have no choice but to
restore it at the moment and spend more time on designing a
better solution in the future.
References: https://bugzilla.kernel.org/show_bug.cgi?id=43228
Reported-by: rocko <rockorequin@hotmail.com>
Reported-by: Cristian Rodríguez <crrodriguez@opensuse.org>
Reported-and-tested-by: Peter <lekensteyn@gmail.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-05-18 02:39:35 +04:00
|
|
|
int result = 0;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2012-03-29 10:09:38 +04:00
|
|
|
if (!device || (state < ACPI_STATE_D0) || (state > ACPI_STATE_D3_COLD))
|
2006-06-27 08:41:40 +04:00
|
|
|
return -EINVAL;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2013-01-17 17:11:06 +04:00
|
|
|
if (device->power.state == state || !device->flags.power_manageable)
|
2010-11-25 02:02:36 +03:00
|
|
|
return 0;
|
|
|
|
|
2005-08-05 08:44:28 +04:00
|
|
|
if ((device->power.state < ACPI_STATE_D0)
|
2012-03-29 10:09:38 +04:00
|
|
|
|| (device->power.state > ACPI_STATE_D3_COLD))
|
2006-06-27 08:41:40 +04:00
|
|
|
return -ENODEV;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* First we reference all power resources required in the target list
|
2010-11-25 02:06:09 +03:00
|
|
|
* (e.g. so the device doesn't lose power while transitioning). Then,
|
|
|
|
* we dereference all power resources used in the current list.
|
2005-04-17 02:20:36 +04:00
|
|
|
*/
|
ACPI / PCI / PM: Fix device PM regression related to D3hot/D3cold
Commit 1cc0c998fdf2 ("ACPI: Fix D3hot v D3cold confusion") introduced a
bug in __acpi_bus_set_power() and changed the behavior of
acpi_pci_set_power_state() in such a way that it generally doesn't work
as expected if PCI_D3hot is passed to it as the second argument.
First off, if ACPI_STATE_D3 (equal to ACPI_STATE_D3_COLD) is passed to
__acpi_bus_set_power() and the explicit_set flag is set for the D3cold
state, the function will try to execute AML method called "_PS4", which
doesn't exist.
Fix this by adding a check to ensure that the name of the AML method
to execute for transitions to ACPI_STATE_D3_COLD is correct in
__acpi_bus_set_power(). Also make sure that the explicit_set flag
for ACPI_STATE_D3_COLD will be set if _PS3 is present and modify
acpi_power_transition() to avoid accessing power resources for
ACPI_STATE_D3_COLD, because they don't exist.
Second, if PCI_D3hot is passed to acpi_pci_set_power_state() as the
target state, the function will request a transition to
ACPI_STATE_D3_HOT instead of ACPI_STATE_D3. However,
ACPI_STATE_D3_HOT is now only marked as supported if the _PR3 AML
method is defined for the given device, which is rare. This causes
problems to happen on systems where devices were successfully put
into ACPI D3 by pci_set_power_state(PCI_D3hot) which doesn't work
now. In particular, some unused graphics adapters are not turned
off as a result.
To fix this issue restore the old behavior of
acpi_pci_set_power_state(), which is to request a transition to
ACPI_STATE_D3 (equal to ACPI_STATE_D3_COLD) if either PCI_D3hot or
PCI_D3cold is passed to it as the argument.
This approach is not ideal, because generally power should not
be removed from devices if PCI_D3hot is the target power state,
but since this behavior is relied on, we have no choice but to
restore it at the moment and spend more time on designing a
better solution in the future.
References: https://bugzilla.kernel.org/show_bug.cgi?id=43228
Reported-by: rocko <rockorequin@hotmail.com>
Reported-by: Cristian Rodríguez <crrodriguez@opensuse.org>
Reported-and-tested-by: Peter <lekensteyn@gmail.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-05-18 02:39:35 +04:00
|
|
|
if (state < ACPI_STATE_D3_COLD)
|
|
|
|
result = acpi_power_on_list(
|
|
|
|
&device->power.states[state].resources);
|
|
|
|
|
|
|
|
if (!result && device->power.state < ACPI_STATE_D3_COLD)
|
2010-11-25 02:06:09 +03:00
|
|
|
acpi_power_off_list(
|
|
|
|
&device->power.states[device->power.state].resources);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2010-11-25 02:06:09 +03:00
|
|
|
/* We shouldn't change the state unless the above operations succeed. */
|
|
|
|
device->power.state = result ? ACPI_STATE_UNKNOWN : state;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2006-06-27 08:41:40 +04:00
|
|
|
return result;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2013-01-17 17:11:05 +04:00
|
|
|
static void acpi_release_power_resource(struct device *dev)
|
|
|
|
{
|
|
|
|
struct acpi_device *device = to_acpi_device(dev);
|
|
|
|
struct acpi_power_resource *resource;
|
|
|
|
|
|
|
|
resource = container_of(device, struct acpi_power_resource, device);
|
2013-01-17 17:11:06 +04:00
|
|
|
|
|
|
|
mutex_lock(&power_resource_list_lock);
|
|
|
|
list_del(&resource->list_node);
|
|
|
|
mutex_unlock(&power_resource_list_lock);
|
|
|
|
|
2013-03-05 01:30:42 +04:00
|
|
|
acpi_free_pnp_ids(&device->pnp);
|
2013-01-17 17:11:05 +04:00
|
|
|
kfree(resource);
|
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2020-12-17 15:45:36 +03:00
|
|
|
static ssize_t resource_in_use_show(struct device *dev,
|
|
|
|
struct device_attribute *attr,
|
|
|
|
char *buf)
|
|
|
|
{
|
2013-01-24 15:50:09 +04:00
|
|
|
struct acpi_power_resource *resource;
|
|
|
|
|
|
|
|
resource = to_power_resource(to_acpi_device(dev));
|
|
|
|
return sprintf(buf, "%u\n", !!resource->ref_count);
|
|
|
|
}
|
2020-12-17 15:45:36 +03:00
|
|
|
static DEVICE_ATTR_RO(resource_in_use);
|
2013-01-24 15:50:09 +04:00
|
|
|
|
|
|
|
static void acpi_power_sysfs_remove(struct acpi_device *device)
|
|
|
|
{
|
|
|
|
device_remove_file(&device->dev, &dev_attr_resource_in_use);
|
|
|
|
}
|
|
|
|
|
2015-05-21 05:19:49 +03:00
|
|
|
static void acpi_power_add_resource_to_list(struct acpi_power_resource *resource)
|
|
|
|
{
|
|
|
|
mutex_lock(&power_resource_list_lock);
|
|
|
|
|
|
|
|
if (!list_empty(&acpi_power_resource_list)) {
|
|
|
|
struct acpi_power_resource *r;
|
|
|
|
|
|
|
|
list_for_each_entry(r, &acpi_power_resource_list, list_node)
|
|
|
|
if (r->order > resource->order) {
|
|
|
|
list_add_tail(&resource->list_node, &r->list_node);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
list_add_tail(&resource->list_node, &acpi_power_resource_list);
|
|
|
|
|
|
|
|
out:
|
|
|
|
mutex_unlock(&power_resource_list_lock);
|
|
|
|
}
|
|
|
|
|
2021-05-21 16:13:11 +03:00
|
|
|
struct acpi_device *acpi_add_power_resource(acpi_handle handle)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2013-01-17 17:11:05 +04:00
|
|
|
struct acpi_power_resource *resource;
|
|
|
|
struct acpi_device *device = NULL;
|
2005-08-05 08:44:28 +04:00
|
|
|
union acpi_object acpi_object;
|
|
|
|
struct acpi_buffer buffer = { sizeof(acpi_object), &acpi_object };
|
2013-01-17 17:11:05 +04:00
|
|
|
acpi_status status;
|
2021-05-24 18:24:16 +03:00
|
|
|
int result;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2013-01-17 17:11:05 +04:00
|
|
|
acpi_bus_get_device(handle, &device);
|
|
|
|
if (device)
|
2021-05-21 16:13:11 +03:00
|
|
|
return device;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2013-01-17 17:11:05 +04:00
|
|
|
resource = kzalloc(sizeof(*resource), GFP_KERNEL);
|
2005-04-17 02:20:36 +04:00
|
|
|
if (!resource)
|
2021-05-21 16:13:11 +03:00
|
|
|
return NULL;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2013-01-17 17:11:05 +04:00
|
|
|
device = &resource->device;
|
2021-04-07 17:33:38 +03:00
|
|
|
acpi_init_device_object(device, handle, ACPI_BUS_TYPE_POWER);
|
2007-02-16 09:47:06 +03:00
|
|
|
mutex_init(&resource->resource_lock);
|
2013-06-19 02:44:45 +04:00
|
|
|
INIT_LIST_HEAD(&resource->list_node);
|
2019-06-25 13:29:41 +03:00
|
|
|
INIT_LIST_HEAD(&resource->dependents);
|
2013-01-17 17:11:05 +04:00
|
|
|
resource->name = device->pnp.bus_id;
|
2005-04-17 02:20:36 +04:00
|
|
|
strcpy(acpi_device_name(device), ACPI_POWER_DEVICE_NAME);
|
|
|
|
strcpy(acpi_device_class(device), ACPI_POWER_CLASS);
|
2013-01-17 17:11:06 +04:00
|
|
|
device->power.state = ACPI_STATE_UNKNOWN;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2021-03-13 04:55:35 +03:00
|
|
|
/* Evaluate the object to get the system level and resource order. */
|
2013-01-17 17:11:05 +04:00
|
|
|
status = acpi_evaluate_object(handle, NULL, NULL, &buffer);
|
|
|
|
if (ACPI_FAILURE(status))
|
2013-01-17 17:11:06 +04:00
|
|
|
goto err;
|
2013-01-17 17:11:05 +04:00
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
resource->system_level = acpi_object.power_resource.system_level;
|
|
|
|
resource->order = acpi_object.power_resource.resource_order;
|
ACPI: power: Save the last known state of each power resource
Currently, there are two ways to check the state of an ACPI power
resource and they may not be consistent with each other. The first
one is to evaluate the power resource's _STA object and the other one
is to check its reference counter value. However, on some systems
the value returned by _STA may not be consistent with the value of
the power resource's reference counter (for example, on some systems
it returns the same value every time for certain power resources).
Moreover, evaluating _STA is unnecessary overhead for a power
resource for which it has been evaluated already or whose state is
otherwise known, because either the _ON or the _OFF method has been
executed for it.
For this reason, save the state of each power resource in its
struct acpi_power_resource object and use the saved value whenever
its state needs to be checked, except when its stats is unknown, in
which case the _STA method is evaluated for it and the value
returned by that method is saved as the last known state of
the power resource.
Moreover, drop the power resource _STA method evaluation from
acpi_add_power_resource(), so as to avoid doing that unnecessarily
for power resources that will never be used.
Tested-by: Dave Olsthoorn <dave@bewaar.me>
Tested-by: Shujun Wang <wsj20369@163.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-05-24 18:25:23 +03:00
|
|
|
resource->state = ACPI_POWER_RESOURCE_STATE_UNKNOWN;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
ACPI: power: Save the last known state of each power resource
Currently, there are two ways to check the state of an ACPI power
resource and they may not be consistent with each other. The first
one is to evaluate the power resource's _STA object and the other one
is to check its reference counter value. However, on some systems
the value returned by _STA may not be consistent with the value of
the power resource's reference counter (for example, on some systems
it returns the same value every time for certain power resources).
Moreover, evaluating _STA is unnecessary overhead for a power
resource for which it has been evaluated already or whose state is
otherwise known, because either the _ON or the _OFF method has been
executed for it.
For this reason, save the state of each power resource in its
struct acpi_power_resource object and use the saved value whenever
its state needs to be checked, except when its stats is unknown, in
which case the _STA method is evaluated for it and the value
returned by that method is saved as the last known state of
the power resource.
Moreover, drop the power resource _STA method evaluation from
acpi_add_power_resource(), so as to avoid doing that unnecessarily
for power resources that will never be used.
Tested-by: Dave Olsthoorn <dave@bewaar.me>
Tested-by: Shujun Wang <wsj20369@163.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-05-24 18:25:23 +03:00
|
|
|
pr_info("%s [%s]\n", acpi_device_name(device), acpi_device_bid(device));
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2013-01-17 17:11:05 +04:00
|
|
|
device->flags.match_driver = true;
|
2013-01-24 15:49:49 +04:00
|
|
|
result = acpi_device_add(device, acpi_release_power_resource);
|
2005-04-17 02:20:36 +04:00
|
|
|
if (result)
|
2013-01-17 17:11:06 +04:00
|
|
|
goto err;
|
2005-08-05 08:44:28 +04:00
|
|
|
|
2013-01-24 15:50:09 +04:00
|
|
|
if (!device_create_file(&device->dev, &dev_attr_resource_in_use))
|
|
|
|
device->remove = acpi_power_sysfs_remove;
|
|
|
|
|
2015-05-21 05:19:49 +03:00
|
|
|
acpi_power_add_resource_to_list(resource);
|
2013-01-24 15:49:49 +04:00
|
|
|
acpi_device_add_finalize(device);
|
2021-05-21 16:13:11 +03:00
|
|
|
return device;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2013-01-17 17:11:06 +04:00
|
|
|
err:
|
|
|
|
acpi_release_power_resource(&device->dev);
|
2021-05-21 16:13:11 +03:00
|
|
|
return NULL;
|
2013-01-17 17:11:06 +04:00
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2013-01-17 17:11:06 +04:00
|
|
|
#ifdef CONFIG_ACPI_SLEEP
|
|
|
|
void acpi_resume_power_resources(void)
|
2007-02-16 09:47:06 +03:00
|
|
|
{
|
2010-10-22 04:35:54 +04:00
|
|
|
struct acpi_power_resource *resource;
|
2007-02-16 09:47:06 +03:00
|
|
|
|
2013-01-17 17:11:06 +04:00
|
|
|
mutex_lock(&power_resource_list_lock);
|
2007-02-16 09:47:06 +03:00
|
|
|
|
2013-01-17 17:11:06 +04:00
|
|
|
list_for_each_entry(resource, &acpi_power_resource_list, list_node) {
|
2021-05-24 18:24:16 +03:00
|
|
|
int result;
|
|
|
|
u8 state;
|
2007-02-16 09:47:06 +03:00
|
|
|
|
2013-01-17 17:11:06 +04:00
|
|
|
mutex_lock(&resource->resource_lock);
|
2007-02-16 09:47:06 +03:00
|
|
|
|
ACPI: power: Save the last known state of each power resource
Currently, there are two ways to check the state of an ACPI power
resource and they may not be consistent with each other. The first
one is to evaluate the power resource's _STA object and the other one
is to check its reference counter value. However, on some systems
the value returned by _STA may not be consistent with the value of
the power resource's reference counter (for example, on some systems
it returns the same value every time for certain power resources).
Moreover, evaluating _STA is unnecessary overhead for a power
resource for which it has been evaluated already or whose state is
otherwise known, because either the _ON or the _OFF method has been
executed for it.
For this reason, save the state of each power resource in its
struct acpi_power_resource object and use the saved value whenever
its state needs to be checked, except when its stats is unknown, in
which case the _STA method is evaluated for it and the value
returned by that method is saved as the last known state of
the power resource.
Moreover, drop the power resource _STA method evaluation from
acpi_add_power_resource(), so as to avoid doing that unnecessarily
for power resources that will never be used.
Tested-by: Dave Olsthoorn <dave@bewaar.me>
Tested-by: Shujun Wang <wsj20369@163.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-05-24 18:25:23 +03:00
|
|
|
resource->state = ACPI_POWER_RESOURCE_STATE_UNKNOWN;
|
|
|
|
result = acpi_power_get_state(resource, &state);
|
2013-10-15 15:48:11 +04:00
|
|
|
if (result) {
|
|
|
|
mutex_unlock(&resource->resource_lock);
|
2013-01-26 00:51:57 +04:00
|
|
|
continue;
|
2013-10-15 15:48:11 +04:00
|
|
|
}
|
2013-01-26 00:51:57 +04:00
|
|
|
|
|
|
|
if (state == ACPI_POWER_RESOURCE_STATE_OFF
|
2013-01-17 17:11:06 +04:00
|
|
|
&& resource->ref_count) {
|
2021-06-11 19:58:48 +03:00
|
|
|
dev_dbg(&resource->device.dev, "Turning ON\n");
|
2013-01-17 17:11:06 +04:00
|
|
|
__acpi_power_on(resource);
|
2015-05-21 05:19:49 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
mutex_unlock(&resource->resource_lock);
|
|
|
|
}
|
2017-04-30 23:54:16 +03:00
|
|
|
|
|
|
|
mutex_unlock(&power_resource_list_lock);
|
|
|
|
}
|
2021-05-10 15:02:17 +03:00
|
|
|
#endif
|
2017-04-30 23:54:16 +03:00
|
|
|
|
2021-05-21 16:13:11 +03:00
|
|
|
/**
|
|
|
|
* acpi_turn_off_unused_power_resources - Turn off power resources not in use.
|
|
|
|
*/
|
ACPI: power: Rework turning off unused power resources
Make turning off unused power resources (after the enumeration of
devices and during system-wide resume from S3) more straightforward
by using the observation that the power resource state stored in
struct acpi_power_resource can be used to determine whether or not
the give power resource has any users.
Namely, when the state of the power resource is unknown, its _STA
method has never been evaluated (or the evaluation of it has failed)
and its _ON and _OFF methods have never been executed (or they have
failed to execute), so for all practical purposes it can be assumed
to have no users (or to be unusable). Therefore, instead of checking
the number of power resource users, it is sufficient to check if its
state is known.
Moreover, if the last known state of a given power resource is "off",
it is not necessary to turn it off, because it has been used to
initialize the power state or the wakeup power resources list of at
least one device and either its _STA method has returned 0 ("off"),
or its _OFF method has been successfully executed already.
Accordingly, modify acpi_turn_off_unused_power_resources() to do the
above checks (which are suitable for both uses of it) instead of
using the number of power resource users or evaluating its _STA
method, drop its argument (which is not useful any more) and update
its callers.
Also drop the users field from struct acpi_power_resource as it is
not useful any more.
Tested-by: Dave Olsthoorn <dave@bewaar.me>
Tested-by: Shujun Wang <wsj20369@163.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-05-24 18:26:16 +03:00
|
|
|
void acpi_turn_off_unused_power_resources(void)
|
2017-04-30 23:54:16 +03:00
|
|
|
{
|
|
|
|
struct acpi_power_resource *resource;
|
|
|
|
|
|
|
|
mutex_lock(&power_resource_list_lock);
|
|
|
|
|
2015-05-21 05:19:49 +03:00
|
|
|
list_for_each_entry_reverse(resource, &acpi_power_resource_list, list_node) {
|
|
|
|
mutex_lock(&resource->resource_lock);
|
|
|
|
|
ACPI: power: Rework turning off unused power resources
Make turning off unused power resources (after the enumeration of
devices and during system-wide resume from S3) more straightforward
by using the observation that the power resource state stored in
struct acpi_power_resource can be used to determine whether or not
the give power resource has any users.
Namely, when the state of the power resource is unknown, its _STA
method has never been evaluated (or the evaluation of it has failed)
and its _ON and _OFF methods have never been executed (or they have
failed to execute), so for all practical purposes it can be assumed
to have no users (or to be unusable). Therefore, instead of checking
the number of power resource users, it is sufficient to check if its
state is known.
Moreover, if the last known state of a given power resource is "off",
it is not necessary to turn it off, because it has been used to
initialize the power state or the wakeup power resources list of at
least one device and either its _STA method has returned 0 ("off"),
or its _OFF method has been successfully executed already.
Accordingly, modify acpi_turn_off_unused_power_resources() to do the
above checks (which are suitable for both uses of it) instead of
using the number of power resource users or evaluating its _STA
method, drop its argument (which is not useful any more) and update
its callers.
Also drop the users field from struct acpi_power_resource as it is
not useful any more.
Tested-by: Dave Olsthoorn <dave@bewaar.me>
Tested-by: Shujun Wang <wsj20369@163.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-05-24 18:26:16 +03:00
|
|
|
/*
|
|
|
|
* Turn off power resources in an unknown state too, because the
|
|
|
|
* platform firmware on some system expects the OS to turn off
|
|
|
|
* power resources without any users unconditionally.
|
|
|
|
*/
|
|
|
|
if (!resource->ref_count &&
|
|
|
|
resource->state != ACPI_POWER_RESOURCE_STATE_OFF) {
|
2021-06-11 19:58:48 +03:00
|
|
|
dev_dbg(&resource->device.dev, "Turning OFF\n");
|
ACPI: power: Rework turning off unused power resources
Make turning off unused power resources (after the enumeration of
devices and during system-wide resume from S3) more straightforward
by using the observation that the power resource state stored in
struct acpi_power_resource can be used to determine whether or not
the give power resource has any users.
Namely, when the state of the power resource is unknown, its _STA
method has never been evaluated (or the evaluation of it has failed)
and its _ON and _OFF methods have never been executed (or they have
failed to execute), so for all practical purposes it can be assumed
to have no users (or to be unusable). Therefore, instead of checking
the number of power resource users, it is sufficient to check if its
state is known.
Moreover, if the last known state of a given power resource is "off",
it is not necessary to turn it off, because it has been used to
initialize the power state or the wakeup power resources list of at
least one device and either its _STA method has returned 0 ("off"),
or its _OFF method has been successfully executed already.
Accordingly, modify acpi_turn_off_unused_power_resources() to do the
above checks (which are suitable for both uses of it) instead of
using the number of power resource users or evaluating its _STA
method, drop its argument (which is not useful any more) and update
its callers.
Also drop the users field from struct acpi_power_resource as it is
not useful any more.
Tested-by: Dave Olsthoorn <dave@bewaar.me>
Tested-by: Shujun Wang <wsj20369@163.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-05-24 18:26:16 +03:00
|
|
|
__acpi_power_off(resource);
|
|
|
|
}
|
2007-02-16 09:47:06 +03:00
|
|
|
|
2013-01-17 17:11:06 +04:00
|
|
|
mutex_unlock(&resource->resource_lock);
|
|
|
|
}
|
2010-10-22 04:35:54 +04:00
|
|
|
|
2013-01-17 17:11:06 +04:00
|
|
|
mutex_unlock(&power_resource_list_lock);
|
2007-02-16 09:47:06 +03:00
|
|
|
}
|