2005-04-16 16:20:36 -06:00
|
|
|
/*
|
|
|
|
* acpi_power.c - ACPI Bus Power Management ($Revision: 39 $)
|
|
|
|
*
|
|
|
|
* Copyright (C) 2001, 2002 Andy Grover <andrew.grover@intel.com>
|
|
|
|
* Copyright (C) 2001, 2002 Paul Diefenbaugh <paul.s.diefenbaugh@intel.com>
|
|
|
|
*
|
|
|
|
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or (at
|
|
|
|
* your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful, but
|
|
|
|
* WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
|
|
|
* with this program; if not, write to the Free Software Foundation, Inc.,
|
|
|
|
* 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
|
|
|
|
*
|
|
|
|
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ACPI power-managed devices may be controlled in two ways:
|
|
|
|
* 1. via "Device Specific (D-State) Control"
|
|
|
|
* 2. via "Power Resource Control".
|
|
|
|
* This module is used to manage devices relying on Power Resource Control.
|
|
|
|
*
|
|
|
|
* An ACPI "power resource object" describes a software controllable power
|
|
|
|
* plane, clock plane, or other resource used by a power managed device.
|
|
|
|
* A device may rely on multiple power resources, and a power resource
|
|
|
|
* may be shared by multiple devices.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#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 02:04:11 -06:00
|
|
|
#include <linux/slab.h>
|
2012-03-29 00:09:39 -06:00
|
|
|
#include <linux/pm_runtime.h>
|
2013-01-25 13:51:32 -07:00
|
|
|
#include <linux/sysfs.h>
|
2013-12-02 17:49:16 -07:00
|
|
|
#include <linux/acpi.h>
|
2009-09-08 15:15:31 -06:00
|
|
|
#include "sleep.h"
|
2012-03-29 00:09:39 -06:00
|
|
|
#include "internal.h"
|
2009-09-08 15:15:31 -06:00
|
|
|
|
2008-11-07 16:57:45 -07:00
|
|
|
#define _COMPONENT ACPI_POWER_COMPONENT
|
2007-02-12 20:42:12 -07:00
|
|
|
ACPI_MODULE_NAME("power");
|
2005-04-16 16:20:36 -06:00
|
|
|
#define ACPI_POWER_CLASS "power_resource"
|
|
|
|
#define ACPI_POWER_DEVICE_NAME "Power Resource"
|
|
|
|
#define ACPI_POWER_FILE_INFO "info"
|
|
|
|
#define ACPI_POWER_FILE_STATUS "state"
|
|
|
|
#define ACPI_POWER_RESOURCE_STATE_OFF 0x00
|
|
|
|
#define ACPI_POWER_RESOURCE_STATE_ON 0x01
|
|
|
|
#define ACPI_POWER_RESOURCE_STATE_UNKNOWN 0xFF
|
2008-08-11 00:57:50 -06:00
|
|
|
|
2005-08-04 22:44:28 -06:00
|
|
|
struct acpi_power_resource {
|
2013-01-17 06:11:05 -07:00
|
|
|
struct acpi_device device;
|
2013-01-17 06:11:06 -07:00
|
|
|
struct list_head list_node;
|
2013-01-17 06:11:05 -07:00
|
|
|
char *name;
|
2005-08-04 22:44:28 -06:00
|
|
|
u32 system_level;
|
|
|
|
u32 order;
|
2010-10-21 18:35:54 -06:00
|
|
|
unsigned int ref_count;
|
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-23 15:15:21 -07:00
|
|
|
bool wakeup_enabled;
|
2007-02-15 23:47:06 -07:00
|
|
|
struct mutex resource_lock;
|
2005-04-16 16:20:36 -06:00
|
|
|
};
|
|
|
|
|
2013-01-17 06:11:06 -07:00
|
|
|
struct acpi_power_resource_entry {
|
|
|
|
struct list_head node;
|
|
|
|
struct acpi_power_resource *resource;
|
|
|
|
};
|
|
|
|
|
2013-01-17 06:11:06 -07:00
|
|
|
static LIST_HEAD(acpi_power_resource_list);
|
|
|
|
static DEFINE_MUTEX(power_resource_list_lock);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
/* --------------------------------------------------------------------------
|
|
|
|
Power Resource Management
|
|
|
|
-------------------------------------------------------------------------- */
|
|
|
|
|
2013-01-24 04:50:09 -07: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 06:11:05 -07:00
|
|
|
static struct acpi_power_resource *acpi_power_get_context(acpi_handle handle)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2013-01-17 06:11:05 -07:00
|
|
|
struct acpi_device *device;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2013-01-17 06:11:05 -07:00
|
|
|
if (acpi_bus_get_device(handle, &device))
|
|
|
|
return NULL;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2013-01-24 04:50:09 -07:00
|
|
|
return to_power_resource(device);
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2013-01-17 06:11:07 -07:00
|
|
|
static int acpi_power_resources_list_add(acpi_handle handle,
|
|
|
|
struct list_head *list)
|
2013-01-17 06:11:06 -07:00
|
|
|
{
|
|
|
|
struct acpi_power_resource *resource = acpi_power_get_context(handle);
|
|
|
|
struct acpi_power_resource_entry *entry;
|
|
|
|
|
|
|
|
if (!resource || !list)
|
2013-01-17 06:11:07 -07:00
|
|
|
return -EINVAL;
|
2013-01-17 06:11:06 -07:00
|
|
|
|
|
|
|
entry = kzalloc(sizeof(*entry), GFP_KERNEL);
|
|
|
|
if (!entry)
|
2013-01-17 06:11:07 -07:00
|
|
|
return -ENOMEM;
|
2013-01-17 06:11:06 -07: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 06:11:07 -07:00
|
|
|
return 0;
|
2013-01-17 06:11:06 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
list_add_tail(&entry->node, list);
|
2013-01-17 06:11:07 -07:00
|
|
|
return 0;
|
2013-01-17 06:11:06 -07: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);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-01-17 06:11:07 -07:00
|
|
|
int acpi_extract_power_resources(union acpi_object *package, unsigned int start,
|
|
|
|
struct list_head *list)
|
2013-01-17 06:11:07 -07:00
|
|
|
{
|
|
|
|
unsigned int i;
|
2013-01-17 06:11:07 -07:00
|
|
|
int err = 0;
|
2013-01-17 06:11:07 -07:00
|
|
|
|
|
|
|
for (i = start; i < package->package.count; i++) {
|
|
|
|
union acpi_object *element = &package->package.elements[i];
|
|
|
|
acpi_handle rhandle;
|
|
|
|
|
|
|
|
if (element->type != ACPI_TYPE_LOCAL_REFERENCE) {
|
2013-01-17 06:11:07 -07:00
|
|
|
err = -ENODATA;
|
2013-01-17 06:11:07 -07:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
rhandle = element->reference.handle;
|
|
|
|
if (!rhandle) {
|
2013-01-17 06:11:07 -07:00
|
|
|
err = -ENODEV;
|
2013-01-17 06:11:07 -07:00
|
|
|
break;
|
|
|
|
}
|
2013-01-17 06:11:07 -07:00
|
|
|
err = acpi_add_power_resource(rhandle);
|
|
|
|
if (err)
|
|
|
|
break;
|
|
|
|
|
|
|
|
err = acpi_power_resources_list_add(rhandle, list);
|
|
|
|
if (err)
|
|
|
|
break;
|
2013-01-17 06:11:07 -07:00
|
|
|
}
|
2013-01-17 06:11:07 -07:00
|
|
|
if (err)
|
2013-01-17 06:11:07 -07:00
|
|
|
acpi_power_resources_list_free(list);
|
|
|
|
|
2013-01-17 06:11:07 -07:00
|
|
|
return err;
|
2013-01-17 06:11:07 -07:00
|
|
|
}
|
|
|
|
|
2008-08-11 00:55:05 -06:00
|
|
|
static int acpi_power_get_state(acpi_handle handle, int *state)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2005-08-04 22:44:28 -06:00
|
|
|
acpi_status status = AE_OK;
|
2008-10-10 00:22:59 -06:00
|
|
|
unsigned long long sta = 0;
|
2008-12-16 02:02:22 -07:00
|
|
|
char node_name[5];
|
|
|
|
struct acpi_buffer buffer = { sizeof(node_name), node_name };
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
|
2008-08-11 00:55:05 -06:00
|
|
|
if (!handle || !state)
|
2006-06-26 22:41:40 -06:00
|
|
|
return -EINVAL;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2008-08-11 00:55:05 -06:00
|
|
|
status = acpi_evaluate_integer(handle, "_STA", NULL, &sta);
|
2005-04-16 16:20:36 -06:00
|
|
|
if (ACPI_FAILURE(status))
|
2006-06-26 22:41:40 -06:00
|
|
|
return -ENODEV;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2007-10-22 04:19:09 -06:00
|
|
|
*state = (sta & 0x01)?ACPI_POWER_RESOURCE_STATE_ON:
|
|
|
|
ACPI_POWER_RESOURCE_STATE_OFF;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2008-12-16 02:02:22 -07:00
|
|
|
acpi_get_name(handle, ACPI_SINGLE_NAME, &buffer);
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Resource [%s] is %s\n",
|
2008-12-16 02:02:22 -07:00
|
|
|
node_name,
|
2008-10-27 02:04:53 -06:00
|
|
|
*state ? "on" : "off"));
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2006-06-26 22:41:40 -06:00
|
|
|
return 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2013-01-17 06:11:06 -07:00
|
|
|
static int acpi_power_get_list_state(struct list_head *list, int *state)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2013-01-17 06:11:06 -07:00
|
|
|
struct acpi_power_resource_entry *entry;
|
2011-01-06 15:38:57 -07:00
|
|
|
int cur_state;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
if (!list || !state)
|
2006-06-26 22:41:40 -06:00
|
|
|
return -EINVAL;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
/* The state of the list is 'on' IFF all resources are 'on'. */
|
2013-01-17 06:11:06 -07:00
|
|
|
list_for_each_entry(entry, list, node) {
|
|
|
|
struct acpi_power_resource *resource = entry->resource;
|
|
|
|
acpi_handle handle = resource->device.handle;
|
2011-01-06 15:38:57 -07:00
|
|
|
int result;
|
|
|
|
|
|
|
|
mutex_lock(&resource->resource_lock);
|
|
|
|
result = acpi_power_get_state(handle, &cur_state);
|
|
|
|
mutex_unlock(&resource->resource_lock);
|
|
|
|
if (result)
|
|
|
|
return result;
|
|
|
|
|
|
|
|
if (cur_state != ACPI_POWER_RESOURCE_STATE_ON)
|
2005-04-16 16:20:36 -06:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Resource list is %s\n",
|
2011-01-06 15:38:57 -07:00
|
|
|
cur_state ? "on" : "off"));
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2011-01-06 15:38:57 -07:00
|
|
|
*state = cur_state;
|
|
|
|
return 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2010-10-21 18:35:54 -06:00
|
|
|
static int __acpi_power_on(struct acpi_power_resource *resource)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2005-08-04 22:44:28 -06:00
|
|
|
acpi_status status = AE_OK;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2013-01-17 06:11:05 -07:00
|
|
|
status = acpi_evaluate_object(resource->device.handle, "_ON", NULL, NULL);
|
2010-10-21 18:35:54 -06:00
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Power resource [%s] turned on\n",
|
|
|
|
resource->name));
|
|
|
|
|
|
|
|
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-23 15:15:21 -07:00
|
|
|
static int acpi_power_on_unlocked(struct acpi_power_resource *resource)
|
2010-10-21 18:35:54 -06: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-23 15:15:21 -07:00
|
|
|
int result = 0;
|
2007-02-15 23:47:06 -07:00
|
|
|
|
2010-10-21 18:35:54 -06:00
|
|
|
if (resource->ref_count++) {
|
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
|
2013-07-05 03:15:56 -06:00
|
|
|
"Power resource [%s] already on\n",
|
2010-10-21 18:35:54 -06:00
|
|
|
resource->name));
|
|
|
|
} 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-16 15:05:42 -06:00
|
|
|
if (result)
|
2010-11-24 16:03:32 -07:00
|
|
|
resource->ref_count--;
|
2012-09-13 16:26:33 -06: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-23 15:15:21 -07:00
|
|
|
return result;
|
|
|
|
}
|
2012-09-13 16:26:33 -06: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-23 15:15:21 -07:00
|
|
|
static int acpi_power_on(struct acpi_power_resource *resource)
|
|
|
|
{
|
|
|
|
int result;
|
2012-09-13 16:26:33 -06: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-23 15:15:21 -07:00
|
|
|
mutex_lock(&resource->resource_lock);
|
|
|
|
result = acpi_power_on_unlocked(resource);
|
|
|
|
mutex_unlock(&resource->resource_lock);
|
2010-11-24 16:03:32 -07:00
|
|
|
return result;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2013-01-25 13:51:57 -07:00
|
|
|
static int __acpi_power_off(struct acpi_power_resource *resource)
|
|
|
|
{
|
|
|
|
acpi_status status;
|
|
|
|
|
|
|
|
status = acpi_evaluate_object(resource->device.handle, "_OFF",
|
|
|
|
NULL, NULL);
|
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Power resource [%s] turned off\n",
|
|
|
|
resource->name));
|
|
|
|
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-23 15:15:21 -07:00
|
|
|
static int acpi_power_off_unlocked(struct acpi_power_resource *resource)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2013-01-17 06:11:06 -07:00
|
|
|
int result = 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2010-10-21 18:35:54 -06:00
|
|
|
if (!resource->ref_count) {
|
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
|
2013-07-05 03:15:56 -06:00
|
|
|
"Power resource [%s] already off\n",
|
2010-10-21 18:35:54 -06:00
|
|
|
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-23 15:15:21 -07:00
|
|
|
return 0;
|
2007-02-15 23:47:06 -07:00
|
|
|
}
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2010-10-21 18:35:54 -06:00
|
|
|
if (--resource->ref_count) {
|
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
|
|
|
|
"Power resource [%s] still in use\n",
|
|
|
|
resource->name));
|
2013-01-25 13:51:57 -07:00
|
|
|
} else {
|
|
|
|
result = __acpi_power_off(resource);
|
|
|
|
if (result)
|
|
|
|
resource->ref_count++;
|
2005-04-16 16:20:36 -06: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-23 15:15:21 -07:00
|
|
|
return result;
|
|
|
|
}
|
2005-04-16 16:20:36 -06: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-23 15:15:21 -07:00
|
|
|
static int acpi_power_off(struct acpi_power_resource *resource)
|
|
|
|
{
|
|
|
|
int result;
|
2005-04-16 16:20:36 -06: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-23 15:15:21 -07:00
|
|
|
mutex_lock(&resource->resource_lock);
|
|
|
|
result = acpi_power_off_unlocked(resource);
|
|
|
|
mutex_unlock(&resource->resource_lock);
|
2010-10-21 18:35:54 -06:00
|
|
|
return result;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2013-01-17 06:11:06 -07:00
|
|
|
static int acpi_power_off_list(struct list_head *list)
|
2010-11-24 16:06:09 -07:00
|
|
|
{
|
2013-01-17 06:11:06 -07:00
|
|
|
struct acpi_power_resource_entry *entry;
|
|
|
|
int result = 0;
|
2010-11-24 16:06:09 -07:00
|
|
|
|
2013-01-17 06:11:06 -07:00
|
|
|
list_for_each_entry_reverse(entry, list, node) {
|
|
|
|
result = acpi_power_off(entry->resource);
|
|
|
|
if (result)
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
return 0;
|
2010-11-24 16:06:09 -07:00
|
|
|
|
2013-01-17 06:11:06 -07:00
|
|
|
err:
|
|
|
|
list_for_each_entry_continue(entry, list, node)
|
|
|
|
acpi_power_on(entry->resource);
|
|
|
|
|
|
|
|
return result;
|
2010-11-24 16:06:09 -07:00
|
|
|
}
|
|
|
|
|
2013-01-17 06:11:06 -07:00
|
|
|
static int acpi_power_on_list(struct list_head *list)
|
2010-11-24 16:06:09 -07:00
|
|
|
{
|
2013-01-17 06:11:06 -07:00
|
|
|
struct acpi_power_resource_entry *entry;
|
2010-11-24 16:06:09 -07:00
|
|
|
int result = 0;
|
|
|
|
|
2013-01-17 06:11:06 -07:00
|
|
|
list_for_each_entry(entry, list, node) {
|
|
|
|
result = acpi_power_on(entry->resource);
|
|
|
|
if (result)
|
|
|
|
goto err;
|
2010-11-24 16:06:09 -07:00
|
|
|
}
|
2013-01-17 06:11:06 -07:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
err:
|
|
|
|
list_for_each_entry_continue_reverse(entry, list, node)
|
|
|
|
acpi_power_off(entry->resource);
|
2010-11-24 16:06:09 -07:00
|
|
|
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2013-01-25 13:51:32 -07:00
|
|
|
static struct attribute *attrs[] = {
|
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct attribute_group attr_groups[] = {
|
|
|
|
[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,
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2013-04-11 14:41:48 -06:00
|
|
|
static struct attribute_group wakeup_attr_group = {
|
|
|
|
.name = "power_resources_wakeup",
|
|
|
|
.attrs = attrs,
|
|
|
|
};
|
|
|
|
|
|
|
|
static void acpi_power_hide_list(struct acpi_device *adev,
|
|
|
|
struct list_head *resources,
|
|
|
|
struct attribute_group *attr_group)
|
2013-01-25 13:51:32 -07:00
|
|
|
{
|
|
|
|
struct acpi_power_resource_entry *entry;
|
|
|
|
|
2013-04-11 14:41:48 -06:00
|
|
|
if (list_empty(resources))
|
2013-01-25 13:51:32 -07:00
|
|
|
return;
|
|
|
|
|
2013-04-11 14:41:48 -06:00
|
|
|
list_for_each_entry_reverse(entry, resources, node) {
|
2013-01-25 13:51:32 -07:00
|
|
|
struct acpi_device *res_dev = &entry->resource->device;
|
|
|
|
|
|
|
|
sysfs_remove_link_from_group(&adev->dev.kobj,
|
2013-04-11 14:41:48 -06:00
|
|
|
attr_group->name,
|
2013-01-25 13:51:32 -07:00
|
|
|
dev_name(&res_dev->dev));
|
|
|
|
}
|
2013-04-11 14:41:48 -06:00
|
|
|
sysfs_remove_group(&adev->dev.kobj, attr_group);
|
2013-01-25 13:51:32 -07:00
|
|
|
}
|
|
|
|
|
2013-04-11 14:41:48 -06:00
|
|
|
static void acpi_power_expose_list(struct acpi_device *adev,
|
|
|
|
struct list_head *resources,
|
|
|
|
struct attribute_group *attr_group)
|
2012-03-29 00:09:39 -06:00
|
|
|
{
|
2013-01-25 13:51:32 -07:00
|
|
|
struct acpi_power_resource_entry *entry;
|
|
|
|
int ret;
|
|
|
|
|
2013-04-11 14:41:48 -06:00
|
|
|
if (list_empty(resources))
|
2013-01-25 13:51:32 -07:00
|
|
|
return;
|
|
|
|
|
2013-04-11 14:41:48 -06:00
|
|
|
ret = sysfs_create_group(&adev->dev.kobj, attr_group);
|
2013-01-25 13:51:32 -07:00
|
|
|
if (ret)
|
|
|
|
return;
|
|
|
|
|
2013-04-11 14:41:48 -06:00
|
|
|
list_for_each_entry(entry, resources, node) {
|
2013-01-25 13:51:32 -07:00
|
|
|
struct acpi_device *res_dev = &entry->resource->device;
|
|
|
|
|
|
|
|
ret = sysfs_add_link_to_group(&adev->dev.kobj,
|
2013-04-11 14:41:48 -06:00
|
|
|
attr_group->name,
|
2013-01-25 13:51:32 -07:00
|
|
|
&res_dev->dev.kobj,
|
|
|
|
dev_name(&res_dev->dev));
|
|
|
|
if (ret) {
|
2013-04-11 14:41:48 -06:00
|
|
|
acpi_power_hide_list(adev, resources, attr_group);
|
2013-01-25 13:51:32 -07:00
|
|
|
break;
|
2012-03-29 00:09:39 -06: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 06:11:05 -07:00
|
|
|
|
2013-04-11 14:41:48 -06:00
|
|
|
static void acpi_power_expose_hide(struct acpi_device *adev,
|
|
|
|
struct list_head *resources,
|
|
|
|
struct attribute_group *attr_group,
|
|
|
|
bool expose)
|
|
|
|
{
|
|
|
|
if (expose)
|
|
|
|
acpi_power_expose_list(adev, resources, attr_group);
|
|
|
|
else
|
|
|
|
acpi_power_hide_list(adev, resources, attr_group);
|
|
|
|
}
|
|
|
|
|
2013-01-25 13:51:32 -07:00
|
|
|
void acpi_power_add_remove_device(struct acpi_device *adev, bool add)
|
|
|
|
{
|
|
|
|
int state;
|
|
|
|
|
2013-04-11 14:41:48 -06:00
|
|
|
if (adev->wakeup.flags.valid)
|
|
|
|
acpi_power_expose_hide(adev, &adev->wakeup.resources,
|
|
|
|
&wakeup_attr_group, add);
|
|
|
|
|
2013-01-25 13:51:32 -07:00
|
|
|
if (!adev->power.flags.power_resources)
|
|
|
|
return;
|
|
|
|
|
2013-04-11 14:41:48 -06: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-25 13:51:32 -07: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-23 15:15:21 -07:00
|
|
|
int acpi_power_wakeup_list_init(struct list_head *list, int *system_level_p)
|
2013-01-17 06:11:07 -07: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-23 15:15:21 -07:00
|
|
|
acpi_handle handle = resource->device.handle;
|
|
|
|
int result;
|
|
|
|
int state;
|
2013-01-17 06:11:07 -07: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-23 15:15:21 -07:00
|
|
|
mutex_lock(&resource->resource_lock);
|
|
|
|
|
|
|
|
result = acpi_power_get_state(handle, &state);
|
|
|
|
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 06:11:07 -07: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-23 15:15:21 -07:00
|
|
|
|
|
|
|
mutex_unlock(&resource->resource_lock);
|
2013-01-17 06:11:07 -07: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-23 15:15:21 -07:00
|
|
|
*system_level_p = system_level;
|
|
|
|
return 0;
|
2013-01-17 06:11:07 -07: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 06:11:05 -07:00
|
|
|
/* --------------------------------------------------------------------------
|
|
|
|
Device Power Management
|
|
|
|
-------------------------------------------------------------------------- */
|
2012-03-29 00:09:39 -06:00
|
|
|
|
2008-07-06 19:33:34 -06: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,
|
|
|
|
int enable, int sleep_state, int dev_state)
|
|
|
|
{
|
|
|
|
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.
|
|
|
|
*
|
|
|
|
* Three agruments are needed for the _DSW object:
|
|
|
|
* 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
|
|
|
|
* the first argument is filled. The values of the other two agruments
|
|
|
|
* 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) {
|
|
|
|
printk(KERN_ERR PREFIX "_DSW execution failed\n");
|
|
|
|
dev->wakeup.flags.valid = 0;
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Execute _PSW */
|
2013-06-28 10:24:39 -06:00
|
|
|
status = acpi_execute_simple_method(dev->handle, "_PSW", enable);
|
2008-07-06 19:33:34 -06:00
|
|
|
if (ACPI_FAILURE(status) && (status != AE_NOT_FOUND)) {
|
|
|
|
printk(KERN_ERR PREFIX "_PSW execution failed\n");
|
|
|
|
dev->wakeup.flags.valid = 0;
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
/*
|
|
|
|
* Prepare a wakeup device, two steps (Ref ACPI 2.0:P229):
|
|
|
|
* 1. Power on the power resources required for the wakeup device
|
2008-07-06 19:33:34 -06:00
|
|
|
* 2. Execute _DSW (Device Sleep Wake) or (deprecated in ACPI 3.0) _PSW (Power
|
|
|
|
* State Wake) for the device, if present
|
2005-04-16 16:20:36 -06:00
|
|
|
*/
|
2008-07-06 19:33:34 -06:00
|
|
|
int acpi_enable_wakeup_device_power(struct acpi_device *dev, int sleep_state)
|
2005-04-16 16:20:36 -06: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-23 15:15:21 -07:00
|
|
|
struct acpi_power_resource_entry *entry;
|
2013-01-17 06:11:06 -07:00
|
|
|
int err = 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
if (!dev || !dev->wakeup.flags.valid)
|
2008-07-06 19:33:34 -06:00
|
|
|
return -EINVAL;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2009-09-08 15:15:31 -06:00
|
|
|
mutex_lock(&acpi_device_lock);
|
|
|
|
|
|
|
|
if (dev->wakeup.prepare_count++)
|
|
|
|
goto out;
|
2008-07-06 19:34:11 -06: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-23 15:15:21 -07: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-16 16:20:36 -06: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-23 15:15:21 -07: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-08 15:15:31 -06:00
|
|
|
if (err)
|
|
|
|
dev->wakeup.prepare_count = 0;
|
|
|
|
|
|
|
|
out:
|
|
|
|
mutex_unlock(&acpi_device_lock);
|
2008-07-06 19:34:11 -06:00
|
|
|
return err;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Shutdown a wakeup device, counterpart of above method
|
2008-07-06 19:33:34 -06:00
|
|
|
* 1. Execute _DSW (Device Sleep Wake) or (deprecated in ACPI 3.0) _PSW (Power
|
|
|
|
* State Wake) for the device, if present
|
2005-04-16 16:20:36 -06:00
|
|
|
* 2. Shutdown down the power resources
|
|
|
|
*/
|
2005-08-04 22:44:28 -06:00
|
|
|
int acpi_disable_wakeup_device_power(struct acpi_device *dev)
|
2005-04-16 16:20:36 -06: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-23 15:15:21 -07:00
|
|
|
struct acpi_power_resource_entry *entry;
|
2013-01-17 06:11:06 -07:00
|
|
|
int err = 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
if (!dev || !dev->wakeup.flags.valid)
|
2008-07-06 19:33:34 -06:00
|
|
|
return -EINVAL;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2009-09-08 15:15:31 -06:00
|
|
|
mutex_lock(&acpi_device_lock);
|
|
|
|
|
|
|
|
if (--dev->wakeup.prepare_count > 0)
|
|
|
|
goto out;
|
|
|
|
|
2008-07-06 19:34:11 -06:00
|
|
|
/*
|
2009-09-08 15:15:31 -06: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-06 19:34:11 -06:00
|
|
|
*/
|
2009-09-08 15:15:31 -06:00
|
|
|
if (dev->wakeup.prepare_count < 0)
|
|
|
|
dev->wakeup.prepare_count = 0;
|
2008-07-06 19:34:11 -06:00
|
|
|
|
2009-09-08 15:15:31 -06:00
|
|
|
err = acpi_device_sleep_wake(dev, 0, 0, 0);
|
|
|
|
if (err)
|
|
|
|
goto out;
|
2005-04-16 16:20:36 -06: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-23 15:15:21 -07: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-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2009-09-08 15:15:31 -06:00
|
|
|
out:
|
|
|
|
mutex_unlock(&acpi_device_lock);
|
|
|
|
return err;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2010-11-24 16:05:17 -07:00
|
|
|
int acpi_power_get_inferred_state(struct acpi_device *device, int *state)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2005-08-04 22:44:28 -06:00
|
|
|
int result = 0;
|
|
|
|
int list_state = 0;
|
|
|
|
int i = 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2010-11-24 16:05:17 -07:00
|
|
|
if (!device || !state)
|
2006-06-26 22:41:40 -06:00
|
|
|
return -EINVAL;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We know a device's inferred power state when all the resources
|
|
|
|
* required for a given D-state are 'on'.
|
|
|
|
*/
|
2012-05-20 05:58:00 -06:00
|
|
|
for (i = ACPI_STATE_D0; i <= ACPI_STATE_D3_HOT; i++) {
|
2013-01-17 06:11:06 -07:00
|
|
|
struct list_head *list = &device->power.states[i].resources;
|
|
|
|
|
|
|
|
if (list_empty(list))
|
2005-04-16 16:20:36 -06:00
|
|
|
continue;
|
|
|
|
|
|
|
|
result = acpi_power_get_list_state(list, &list_state);
|
|
|
|
if (result)
|
2006-06-26 22:41:40 -06:00
|
|
|
return result;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
if (list_state == ACPI_POWER_RESOURCE_STATE_ON) {
|
2010-11-24 16:05:17 -07:00
|
|
|
*state = i;
|
2006-06-26 22:41:40 -06:00
|
|
|
return 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-07-30 06:36:20 -06:00
|
|
|
*state = ACPI_STATE_D3_COLD;
|
2006-06-26 22:41:40 -06:00
|
|
|
return 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2010-11-24 16:06:55 -07:00
|
|
|
int acpi_power_on_resources(struct acpi_device *device, int state)
|
|
|
|
{
|
2013-01-22 04:56:16 -07:00
|
|
|
if (!device || state < ACPI_STATE_D0 || state > ACPI_STATE_D3_HOT)
|
2010-11-24 16:06:55 -07:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
return acpi_power_on_list(&device->power.states[state].resources);
|
|
|
|
}
|
|
|
|
|
2005-08-04 22:44:28 -06:00
|
|
|
int acpi_power_transition(struct acpi_device *device, int state)
|
2005-04-16 16:20:36 -06: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-17 16:39:35 -06:00
|
|
|
int result = 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2012-03-29 00:09:38 -06:00
|
|
|
if (!device || (state < ACPI_STATE_D0) || (state > ACPI_STATE_D3_COLD))
|
2006-06-26 22:41:40 -06:00
|
|
|
return -EINVAL;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2013-01-17 06:11:06 -07:00
|
|
|
if (device->power.state == state || !device->flags.power_manageable)
|
2010-11-24 16:02:36 -07:00
|
|
|
return 0;
|
|
|
|
|
2005-08-04 22:44:28 -06:00
|
|
|
if ((device->power.state < ACPI_STATE_D0)
|
2012-03-29 00:09:38 -06:00
|
|
|
|| (device->power.state > ACPI_STATE_D3_COLD))
|
2006-06-26 22:41:40 -06:00
|
|
|
return -ENODEV;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
/* TBD: Resources must be ordered. */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* First we reference all power resources required in the target list
|
2010-11-24 16:06:09 -07: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-16 16:20:36 -06: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-17 16:39:35 -06: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-24 16:06:09 -07:00
|
|
|
acpi_power_off_list(
|
|
|
|
&device->power.states[device->power.state].resources);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2010-11-24 16:06:09 -07:00
|
|
|
/* We shouldn't change the state unless the above operations succeed. */
|
|
|
|
device->power.state = result ? ACPI_STATE_UNKNOWN : state;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2006-06-26 22:41:40 -06:00
|
|
|
return result;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2013-01-17 06:11:05 -07: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 06:11:06 -07:00
|
|
|
|
|
|
|
mutex_lock(&power_resource_list_lock);
|
|
|
|
list_del(&resource->list_node);
|
|
|
|
mutex_unlock(&power_resource_list_lock);
|
|
|
|
|
2013-03-04 14:30:42 -07:00
|
|
|
acpi_free_pnp_ids(&device->pnp);
|
2013-01-17 06:11:05 -07:00
|
|
|
kfree(resource);
|
|
|
|
}
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2013-01-24 04:50:09 -07:00
|
|
|
static ssize_t acpi_power_in_use_show(struct device *dev,
|
|
|
|
struct device_attribute *attr,
|
|
|
|
char *buf) {
|
|
|
|
struct acpi_power_resource *resource;
|
|
|
|
|
|
|
|
resource = to_power_resource(to_acpi_device(dev));
|
|
|
|
return sprintf(buf, "%u\n", !!resource->ref_count);
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR(resource_in_use, 0444, acpi_power_in_use_show, NULL);
|
|
|
|
|
|
|
|
static void acpi_power_sysfs_remove(struct acpi_device *device)
|
|
|
|
{
|
|
|
|
device_remove_file(&device->dev, &dev_attr_resource_in_use);
|
|
|
|
}
|
|
|
|
|
2013-01-17 06:11:07 -07:00
|
|
|
int acpi_add_power_resource(acpi_handle handle)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2013-01-17 06:11:05 -07:00
|
|
|
struct acpi_power_resource *resource;
|
|
|
|
struct acpi_device *device = NULL;
|
2005-08-04 22:44:28 -06:00
|
|
|
union acpi_object acpi_object;
|
|
|
|
struct acpi_buffer buffer = { sizeof(acpi_object), &acpi_object };
|
2013-01-17 06:11:05 -07:00
|
|
|
acpi_status status;
|
|
|
|
int state, result = -ENODEV;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2013-01-17 06:11:05 -07:00
|
|
|
acpi_bus_get_device(handle, &device);
|
|
|
|
if (device)
|
2013-01-17 06:11:07 -07:00
|
|
|
return 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2013-01-17 06:11:05 -07:00
|
|
|
resource = kzalloc(sizeof(*resource), GFP_KERNEL);
|
2005-04-16 16:20:36 -06:00
|
|
|
if (!resource)
|
2013-01-17 06:11:07 -07:00
|
|
|
return -ENOMEM;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2013-01-17 06:11:05 -07:00
|
|
|
device = &resource->device;
|
|
|
|
acpi_init_device_object(device, handle, ACPI_BUS_TYPE_POWER,
|
|
|
|
ACPI_STA_DEFAULT);
|
2007-02-15 23:47:06 -07:00
|
|
|
mutex_init(&resource->resource_lock);
|
2013-06-18 16:44:45 -06:00
|
|
|
INIT_LIST_HEAD(&resource->list_node);
|
2013-01-17 06:11:05 -07:00
|
|
|
resource->name = device->pnp.bus_id;
|
2005-04-16 16:20:36 -06:00
|
|
|
strcpy(acpi_device_name(device), ACPI_POWER_DEVICE_NAME);
|
|
|
|
strcpy(acpi_device_class(device), ACPI_POWER_CLASS);
|
2013-01-17 06:11:06 -07:00
|
|
|
device->power.state = ACPI_STATE_UNKNOWN;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
/* Evalute the object to get the system level and resource order. */
|
2013-01-17 06:11:05 -07:00
|
|
|
status = acpi_evaluate_object(handle, NULL, NULL, &buffer);
|
|
|
|
if (ACPI_FAILURE(status))
|
2013-01-17 06:11:06 -07:00
|
|
|
goto err;
|
2013-01-17 06:11:05 -07:00
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
resource->system_level = acpi_object.power_resource.system_level;
|
|
|
|
resource->order = acpi_object.power_resource.resource_order;
|
|
|
|
|
2013-01-17 06:11:05 -07:00
|
|
|
result = acpi_power_get_state(handle, &state);
|
2005-04-16 16:20:36 -06:00
|
|
|
if (result)
|
2013-01-17 06:11:06 -07:00
|
|
|
goto err;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
printk(KERN_INFO PREFIX "%s [%s] (%s)\n", acpi_device_name(device),
|
2007-10-22 04:19:09 -06:00
|
|
|
acpi_device_bid(device), state ? "on" : "off");
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2013-01-17 06:11:05 -07:00
|
|
|
device->flags.match_driver = true;
|
2013-01-24 04:49:49 -07:00
|
|
|
result = acpi_device_add(device, acpi_release_power_resource);
|
2005-04-16 16:20:36 -06:00
|
|
|
if (result)
|
2013-01-17 06:11:06 -07:00
|
|
|
goto err;
|
2005-08-04 22:44:28 -06:00
|
|
|
|
2013-01-24 04:50:09 -07:00
|
|
|
if (!device_create_file(&device->dev, &dev_attr_resource_in_use))
|
|
|
|
device->remove = acpi_power_sysfs_remove;
|
|
|
|
|
2013-01-17 06:11:06 -07:00
|
|
|
mutex_lock(&power_resource_list_lock);
|
|
|
|
list_add(&resource->list_node, &acpi_power_resource_list);
|
|
|
|
mutex_unlock(&power_resource_list_lock);
|
2013-01-24 04:49:49 -07:00
|
|
|
acpi_device_add_finalize(device);
|
2013-01-17 06:11:07 -07:00
|
|
|
return 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2013-01-17 06:11:06 -07:00
|
|
|
err:
|
|
|
|
acpi_release_power_resource(&device->dev);
|
2013-01-17 06:11:07 -07:00
|
|
|
return result;
|
2013-01-17 06:11:06 -07:00
|
|
|
}
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2013-01-17 06:11:06 -07:00
|
|
|
#ifdef CONFIG_ACPI_SLEEP
|
|
|
|
void acpi_resume_power_resources(void)
|
2007-02-15 23:47:06 -07:00
|
|
|
{
|
2010-10-21 18:35:54 -06:00
|
|
|
struct acpi_power_resource *resource;
|
2007-02-15 23:47:06 -07:00
|
|
|
|
2013-01-17 06:11:06 -07:00
|
|
|
mutex_lock(&power_resource_list_lock);
|
2007-02-15 23:47:06 -07:00
|
|
|
|
2013-01-17 06:11:06 -07:00
|
|
|
list_for_each_entry(resource, &acpi_power_resource_list, list_node) {
|
|
|
|
int result, state;
|
2007-02-15 23:47:06 -07:00
|
|
|
|
2013-01-17 06:11:06 -07:00
|
|
|
mutex_lock(&resource->resource_lock);
|
2007-02-15 23:47:06 -07:00
|
|
|
|
2013-01-17 06:11:06 -07:00
|
|
|
result = acpi_power_get_state(resource->device.handle, &state);
|
2013-10-15 05:48:11 -06:00
|
|
|
if (result) {
|
|
|
|
mutex_unlock(&resource->resource_lock);
|
2013-01-25 13:51:57 -07:00
|
|
|
continue;
|
2013-10-15 05:48:11 -06:00
|
|
|
}
|
2013-01-25 13:51:57 -07:00
|
|
|
|
|
|
|
if (state == ACPI_POWER_RESOURCE_STATE_OFF
|
2013-01-17 06:11:06 -07:00
|
|
|
&& resource->ref_count) {
|
|
|
|
dev_info(&resource->device.dev, "Turning ON\n");
|
|
|
|
__acpi_power_on(resource);
|
2013-01-25 13:51:57 -07:00
|
|
|
} else if (state == ACPI_POWER_RESOURCE_STATE_ON
|
|
|
|
&& !resource->ref_count) {
|
|
|
|
dev_info(&resource->device.dev, "Turning OFF\n");
|
|
|
|
__acpi_power_off(resource);
|
2013-01-17 06:11:06 -07:00
|
|
|
}
|
2007-02-15 23:47:06 -07:00
|
|
|
|
2013-01-17 06:11:06 -07:00
|
|
|
mutex_unlock(&resource->resource_lock);
|
|
|
|
}
|
2010-10-21 18:35:54 -06:00
|
|
|
|
2013-01-17 06:11:06 -07:00
|
|
|
mutex_unlock(&power_resource_list_lock);
|
2007-02-15 23:47:06 -07:00
|
|
|
}
|
2012-08-09 15:00:02 -06:00
|
|
|
#endif
|