2005-04-17 02:20:36 +04:00
|
|
|
/*
|
|
|
|
* scan.c - support for transforming the ACPI namespace into individual objects
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/init.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>
|
2006-07-12 10:08:00 +04:00
|
|
|
#include <linux/kernel.h>
|
2005-04-17 02:20:36 +04:00
|
|
|
#include <linux/acpi.h>
|
2008-06-13 20:54:24 +04:00
|
|
|
#include <linux/signal.h>
|
|
|
|
#include <linux/kthread.h>
|
2010-03-24 16:38:37 +03:00
|
|
|
#include <linux/dmi.h>
|
2012-10-02 22:43:23 +04:00
|
|
|
#include <linux/nls.h>
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
#include <acpi/acpi_drivers.h>
|
|
|
|
|
2009-03-13 21:08:26 +03:00
|
|
|
#include "internal.h"
|
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
#define _COMPONENT ACPI_BUS_COMPONENT
|
2007-02-13 06:42:12 +03:00
|
|
|
ACPI_MODULE_NAME("scan");
|
2005-04-17 02:20:36 +04:00
|
|
|
#define STRUCT_TO_INT(s) (*((int*)&s))
|
2005-08-05 08:44:28 +04:00
|
|
|
extern struct acpi_device *acpi_root;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
#define ACPI_BUS_CLASS "system_bus"
|
2007-07-23 16:43:51 +04:00
|
|
|
#define ACPI_BUS_HID "LNXSYBUS"
|
2005-04-17 02:20:36 +04:00
|
|
|
#define ACPI_BUS_DEVICE_NAME "System Bus"
|
|
|
|
|
2009-09-21 23:29:50 +04:00
|
|
|
#define ACPI_IS_ROOT_DEVICE(device) (!(device)->parent)
|
|
|
|
|
2013-05-03 02:26:16 +04:00
|
|
|
/*
|
|
|
|
* If set, devices will be hot-removed even if they cannot be put offline
|
|
|
|
* gracefully (from the kernel's standpoint).
|
|
|
|
*/
|
|
|
|
bool acpi_force_hot_remove;
|
|
|
|
|
2010-10-01 12:54:00 +04:00
|
|
|
static const char *dummy_hid = "device";
|
2010-10-01 12:53:59 +04:00
|
|
|
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
static LIST_HEAD(acpi_bus_id_list);
|
2013-01-28 00:17:29 +04:00
|
|
|
static DEFINE_MUTEX(acpi_scan_lock);
|
2013-01-30 17:27:29 +04:00
|
|
|
static LIST_HEAD(acpi_scan_handlers_list);
|
2009-04-07 06:24:29 +04:00
|
|
|
DEFINE_MUTEX(acpi_device_lock);
|
2005-04-17 02:20:36 +04:00
|
|
|
LIST_HEAD(acpi_wakeup_device_list);
|
|
|
|
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
struct acpi_device_bus_id{
|
2007-01-04 10:03:18 +03:00
|
|
|
char bus_id[15];
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
unsigned int instance_no;
|
|
|
|
struct list_head node;
|
2005-04-17 02:20:36 +04:00
|
|
|
};
|
2007-07-23 16:43:51 +04:00
|
|
|
|
ACPI / hotplug: Fix concurrency issues and memory leaks
This changeset is aimed at fixing a few different but related
problems in the ACPI hotplug infrastructure.
First of all, since notify handlers may be run in parallel with
acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
and some of them are installed for ACPI handles that have no struct
acpi_device objects attached (i.e. before those objects are created),
those notify handlers have to take acpi_scan_lock to prevent races
from taking place (e.g. a struct acpi_device is found to be present
for the given ACPI handle, but right after that it is removed by
acpi_bus_trim() running in parallel to the given notify handler).
Moreover, since some of them call acpi_bus_scan() and
acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
should be acquired by the callers of these two funtions rather by
these functions themselves.
For these reasons, make all notify handlers that can handle device
addition and eject events take acpi_scan_lock and remove the
acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
Accordingly, update all of their users to make sure that they
are always called under acpi_scan_lock.
Furthermore, since eject operations are carried out asynchronously
with respect to the notify events that trigger them, with the help
of acpi_bus_hot_remove_device(), even if notify handlers take the
ACPI scan lock, it still is possible that, for example,
acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
the notify handler that scheduled its execution and that
acpi_bus_trim() will remove the device node passed to
acpi_bus_hot_remove_device() for ejection. In that case, the struct
acpi_device object obtained by acpi_bus_hot_remove_device() will be
invalid and not-so-funny things will ensue. To protect agaist that,
make the users of acpi_bus_hot_remove_device() run get_device() on
ACPI device node objects that are about to be passed to it and make
acpi_bus_hot_remove_device() run put_device() on them and check if
their ACPI handles are not NULL (make acpi_device_unregister() clear
the device nodes' ACPI handles for that check to work).
Finally, observe that acpi_os_hotplug_execute() actually can fail,
in which case its caller ought to free memory allocated for the
context object to prevent leaks from happening. It also needs to
run put_device() on the device node that it ran get_device() on
previously in that case. Modify the code accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
2013-02-13 17:36:47 +04:00
|
|
|
void acpi_scan_lock_acquire(void)
|
|
|
|
{
|
|
|
|
mutex_lock(&acpi_scan_lock);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_scan_lock_acquire);
|
|
|
|
|
|
|
|
void acpi_scan_lock_release(void)
|
|
|
|
{
|
|
|
|
mutex_unlock(&acpi_scan_lock);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_scan_lock_release);
|
|
|
|
|
2013-01-30 17:27:29 +04:00
|
|
|
int acpi_scan_add_handler(struct acpi_scan_handler *handler)
|
|
|
|
{
|
|
|
|
if (!handler || !handler->attach)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
list_add_tail(&handler->list_node, &acpi_scan_handlers_list);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-03-04 02:08:16 +04:00
|
|
|
int acpi_scan_add_handler_with_hotplug(struct acpi_scan_handler *handler,
|
|
|
|
const char *hotplug_profile_name)
|
|
|
|
{
|
|
|
|
int error;
|
|
|
|
|
|
|
|
error = acpi_scan_add_handler(handler);
|
|
|
|
if (error)
|
|
|
|
return error;
|
|
|
|
|
|
|
|
acpi_sysfs_add_hotplug_profile(&handler->hotplug, hotplug_profile_name);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-07-23 16:43:51 +04:00
|
|
|
/*
|
|
|
|
* Creates hid/cid(s) string needed for modalias and uevent
|
|
|
|
* e.g. on a device with hid:IBM0001 and cid:ACPI0001 you get:
|
|
|
|
* char *modalias: "acpi:IBM0001:ACPI0001"
|
|
|
|
*/
|
2007-08-15 01:22:35 +04:00
|
|
|
static int create_modalias(struct acpi_device *acpi_dev, char *modalias,
|
|
|
|
int size)
|
|
|
|
{
|
2007-07-23 16:43:51 +04:00
|
|
|
int len;
|
2008-03-20 11:40:32 +03:00
|
|
|
int count;
|
2009-09-21 23:35:19 +04:00
|
|
|
struct acpi_hardware_id *id;
|
2007-07-23 16:43:51 +04:00
|
|
|
|
2010-10-01 12:53:59 +04:00
|
|
|
if (list_empty(&acpi_dev->pnp.ids))
|
|
|
|
return 0;
|
|
|
|
|
2008-03-20 11:40:32 +03:00
|
|
|
len = snprintf(modalias, size, "acpi:");
|
2007-07-23 16:43:51 +04:00
|
|
|
size -= len;
|
|
|
|
|
2009-09-21 23:35:19 +04:00
|
|
|
list_for_each_entry(id, &acpi_dev->pnp.ids, list) {
|
|
|
|
count = snprintf(&modalias[len], size, "%s:", id->id);
|
2008-03-20 11:40:32 +03:00
|
|
|
if (count < 0 || count >= size)
|
|
|
|
return -EINVAL;
|
|
|
|
len += count;
|
|
|
|
size -= count;
|
|
|
|
}
|
|
|
|
|
2007-07-23 16:43:51 +04:00
|
|
|
modalias[len] = '\0';
|
|
|
|
return len;
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t
|
|
|
|
acpi_device_modalias_show(struct device *dev, struct device_attribute *attr, char *buf) {
|
|
|
|
struct acpi_device *acpi_dev = to_acpi_device(dev);
|
|
|
|
int len;
|
|
|
|
|
|
|
|
/* Device has no HID and no CID or string is >1024 */
|
|
|
|
len = create_modalias(acpi_dev, buf, 1024);
|
|
|
|
if (len <= 0)
|
|
|
|
return 0;
|
|
|
|
buf[len++] = '\n';
|
|
|
|
return len;
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR(modalias, 0444, acpi_device_modalias_show, NULL);
|
|
|
|
|
2013-11-07 04:41:14 +04:00
|
|
|
static acpi_status acpi_bus_offline(acpi_handle handle, u32 lvl, void *data,
|
|
|
|
void **ret_p)
|
2013-05-03 02:26:16 +04:00
|
|
|
{
|
|
|
|
struct acpi_device *device = NULL;
|
|
|
|
struct acpi_device_physical_node *pn;
|
2013-05-23 12:43:13 +04:00
|
|
|
bool second_pass = (bool)data;
|
2013-05-03 02:26:16 +04:00
|
|
|
acpi_status status = AE_OK;
|
|
|
|
|
|
|
|
if (acpi_bus_get_device(handle, &device))
|
|
|
|
return AE_OK;
|
|
|
|
|
2013-11-07 04:41:14 +04:00
|
|
|
if (device->handler && !device->handler->hotplug.enabled) {
|
|
|
|
*ret_p = &device->dev;
|
|
|
|
return AE_SUPPORT;
|
|
|
|
}
|
|
|
|
|
2013-05-03 02:26:16 +04:00
|
|
|
mutex_lock(&device->physical_node_lock);
|
|
|
|
|
|
|
|
list_for_each_entry(pn, &device->physical_node_list, node) {
|
|
|
|
int ret;
|
|
|
|
|
2013-05-23 12:43:13 +04:00
|
|
|
if (second_pass) {
|
|
|
|
/* Skip devices offlined by the first pass. */
|
|
|
|
if (pn->put_online)
|
|
|
|
continue;
|
|
|
|
} else {
|
|
|
|
pn->put_online = false;
|
|
|
|
}
|
2013-05-03 02:26:16 +04:00
|
|
|
ret = device_offline(pn->dev);
|
|
|
|
if (acpi_force_hot_remove)
|
|
|
|
continue;
|
|
|
|
|
2013-05-23 12:43:13 +04:00
|
|
|
if (ret >= 0) {
|
|
|
|
pn->put_online = !ret;
|
|
|
|
} else {
|
|
|
|
*ret_p = pn->dev;
|
|
|
|
if (second_pass) {
|
|
|
|
status = AE_ERROR;
|
|
|
|
break;
|
|
|
|
}
|
2013-05-03 02:26:16 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
mutex_unlock(&device->physical_node_lock);
|
|
|
|
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2013-11-07 04:41:14 +04:00
|
|
|
static acpi_status acpi_bus_online(acpi_handle handle, u32 lvl, void *data,
|
|
|
|
void **ret_p)
|
2013-05-03 02:26:16 +04:00
|
|
|
{
|
|
|
|
struct acpi_device *device = NULL;
|
|
|
|
struct acpi_device_physical_node *pn;
|
|
|
|
|
|
|
|
if (acpi_bus_get_device(handle, &device))
|
|
|
|
return AE_OK;
|
|
|
|
|
|
|
|
mutex_lock(&device->physical_node_lock);
|
|
|
|
|
|
|
|
list_for_each_entry(pn, &device->physical_node_list, node)
|
|
|
|
if (pn->put_online) {
|
|
|
|
device_online(pn->dev);
|
|
|
|
pn->put_online = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
mutex_unlock(&device->physical_node_lock);
|
|
|
|
|
|
|
|
return AE_OK;
|
|
|
|
}
|
|
|
|
|
2013-03-04 02:05:29 +04:00
|
|
|
static int acpi_scan_hot_remove(struct acpi_device *device)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2013-01-12 02:40:41 +04:00
|
|
|
acpi_handle handle = device->handle;
|
2013-05-23 12:43:13 +04:00
|
|
|
struct device *errdev;
|
2013-03-04 02:05:29 +04:00
|
|
|
acpi_status status;
|
2013-03-13 23:29:26 +04:00
|
|
|
unsigned long long sta;
|
2013-02-09 18:29:11 +04:00
|
|
|
|
ACPI / hotplug: Fix concurrency issues and memory leaks
This changeset is aimed at fixing a few different but related
problems in the ACPI hotplug infrastructure.
First of all, since notify handlers may be run in parallel with
acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
and some of them are installed for ACPI handles that have no struct
acpi_device objects attached (i.e. before those objects are created),
those notify handlers have to take acpi_scan_lock to prevent races
from taking place (e.g. a struct acpi_device is found to be present
for the given ACPI handle, but right after that it is removed by
acpi_bus_trim() running in parallel to the given notify handler).
Moreover, since some of them call acpi_bus_scan() and
acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
should be acquired by the callers of these two funtions rather by
these functions themselves.
For these reasons, make all notify handlers that can handle device
addition and eject events take acpi_scan_lock and remove the
acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
Accordingly, update all of their users to make sure that they
are always called under acpi_scan_lock.
Furthermore, since eject operations are carried out asynchronously
with respect to the notify events that trigger them, with the help
of acpi_bus_hot_remove_device(), even if notify handlers take the
ACPI scan lock, it still is possible that, for example,
acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
the notify handler that scheduled its execution and that
acpi_bus_trim() will remove the device node passed to
acpi_bus_hot_remove_device() for ejection. In that case, the struct
acpi_device object obtained by acpi_bus_hot_remove_device() will be
invalid and not-so-funny things will ensue. To protect agaist that,
make the users of acpi_bus_hot_remove_device() run get_device() on
ACPI device node objects that are about to be passed to it and make
acpi_bus_hot_remove_device() run put_device() on them and check if
their ACPI handles are not NULL (make acpi_device_unregister() clear
the device nodes' ACPI handles for that check to work).
Finally, observe that acpi_os_hotplug_execute() actually can fail,
in which case its caller ought to free memory allocated for the
context object to prevent leaks from happening. It also needs to
run put_device() on the device node that it ran get_device() on
previously in that case. Modify the code accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
2013-02-13 17:36:47 +04:00
|
|
|
/* If there is no handle, the device node has been unregistered. */
|
2013-03-04 02:05:29 +04:00
|
|
|
if (!handle) {
|
ACPI / hotplug: Fix concurrency issues and memory leaks
This changeset is aimed at fixing a few different but related
problems in the ACPI hotplug infrastructure.
First of all, since notify handlers may be run in parallel with
acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
and some of them are installed for ACPI handles that have no struct
acpi_device objects attached (i.e. before those objects are created),
those notify handlers have to take acpi_scan_lock to prevent races
from taking place (e.g. a struct acpi_device is found to be present
for the given ACPI handle, but right after that it is removed by
acpi_bus_trim() running in parallel to the given notify handler).
Moreover, since some of them call acpi_bus_scan() and
acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
should be acquired by the callers of these two funtions rather by
these functions themselves.
For these reasons, make all notify handlers that can handle device
addition and eject events take acpi_scan_lock and remove the
acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
Accordingly, update all of their users to make sure that they
are always called under acpi_scan_lock.
Furthermore, since eject operations are carried out asynchronously
with respect to the notify events that trigger them, with the help
of acpi_bus_hot_remove_device(), even if notify handlers take the
ACPI scan lock, it still is possible that, for example,
acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
the notify handler that scheduled its execution and that
acpi_bus_trim() will remove the device node passed to
acpi_bus_hot_remove_device() for ejection. In that case, the struct
acpi_device object obtained by acpi_bus_hot_remove_device() will be
invalid and not-so-funny things will ensue. To protect agaist that,
make the users of acpi_bus_hot_remove_device() run get_device() on
ACPI device node objects that are about to be passed to it and make
acpi_bus_hot_remove_device() run put_device() on them and check if
their ACPI handles are not NULL (make acpi_device_unregister() clear
the device nodes' ACPI handles for that check to work).
Finally, observe that acpi_os_hotplug_execute() actually can fail,
in which case its caller ought to free memory allocated for the
context object to prevent leaks from happening. It also needs to
run put_device() on the device node that it ran get_device() on
previously in that case. Modify the code accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
2013-02-13 17:36:47 +04:00
|
|
|
dev_dbg(&device->dev, "ACPI handle missing\n");
|
|
|
|
put_device(&device->dev);
|
2013-03-04 02:05:29 +04:00
|
|
|
return -EINVAL;
|
ACPI / hotplug: Fix concurrency issues and memory leaks
This changeset is aimed at fixing a few different but related
problems in the ACPI hotplug infrastructure.
First of all, since notify handlers may be run in parallel with
acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
and some of them are installed for ACPI handles that have no struct
acpi_device objects attached (i.e. before those objects are created),
those notify handlers have to take acpi_scan_lock to prevent races
from taking place (e.g. a struct acpi_device is found to be present
for the given ACPI handle, but right after that it is removed by
acpi_bus_trim() running in parallel to the given notify handler).
Moreover, since some of them call acpi_bus_scan() and
acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
should be acquired by the callers of these two funtions rather by
these functions themselves.
For these reasons, make all notify handlers that can handle device
addition and eject events take acpi_scan_lock and remove the
acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
Accordingly, update all of their users to make sure that they
are always called under acpi_scan_lock.
Furthermore, since eject operations are carried out asynchronously
with respect to the notify events that trigger them, with the help
of acpi_bus_hot_remove_device(), even if notify handlers take the
ACPI scan lock, it still is possible that, for example,
acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
the notify handler that scheduled its execution and that
acpi_bus_trim() will remove the device node passed to
acpi_bus_hot_remove_device() for ejection. In that case, the struct
acpi_device object obtained by acpi_bus_hot_remove_device() will be
invalid and not-so-funny things will ensue. To protect agaist that,
make the users of acpi_bus_hot_remove_device() run get_device() on
ACPI device node objects that are about to be passed to it and make
acpi_bus_hot_remove_device() run put_device() on them and check if
their ACPI handles are not NULL (make acpi_device_unregister() clear
the device nodes' ACPI handles for that check to work).
Finally, observe that acpi_os_hotplug_execute() actually can fail,
in which case its caller ought to free memory allocated for the
context object to prevent leaks from happening. It also needs to
run put_device() on the device node that it ran get_device() on
previously in that case. Modify the code accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
2013-02-13 17:36:47 +04:00
|
|
|
}
|
|
|
|
|
2013-05-23 12:43:13 +04:00
|
|
|
/*
|
|
|
|
* Carry out two passes here and ignore errors in the first pass,
|
|
|
|
* because if the devices in question are memory blocks and
|
|
|
|
* CONFIG_MEMCG is set, one of the blocks may hold data structures
|
|
|
|
* that the other blocks depend on, but it is not known in advance which
|
|
|
|
* block holds them.
|
|
|
|
*
|
|
|
|
* If the first pass is successful, the second one isn't needed, though.
|
|
|
|
*/
|
|
|
|
errdev = NULL;
|
2013-11-07 04:41:14 +04:00
|
|
|
status = acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
|
|
|
|
NULL, acpi_bus_offline, (void *)false,
|
|
|
|
(void **)&errdev);
|
|
|
|
if (status == AE_SUPPORT) {
|
|
|
|
dev_warn(errdev, "Offline disabled.\n");
|
|
|
|
acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
|
|
|
|
acpi_bus_online, NULL, NULL, NULL);
|
|
|
|
put_device(&device->dev);
|
|
|
|
return -EPERM;
|
|
|
|
}
|
|
|
|
acpi_bus_offline(handle, 0, (void *)false, (void **)&errdev);
|
2013-05-23 12:43:13 +04:00
|
|
|
if (errdev) {
|
|
|
|
errdev = NULL;
|
2013-05-03 02:26:16 +04:00
|
|
|
acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
|
2013-11-07 04:41:14 +04:00
|
|
|
NULL, acpi_bus_offline, (void *)true,
|
|
|
|
(void **)&errdev);
|
2013-05-23 12:43:13 +04:00
|
|
|
if (!errdev || acpi_force_hot_remove)
|
2013-11-07 04:41:14 +04:00
|
|
|
acpi_bus_offline(handle, 0, (void *)true,
|
|
|
|
(void **)&errdev);
|
2013-05-23 12:43:13 +04:00
|
|
|
|
|
|
|
if (errdev && !acpi_force_hot_remove) {
|
|
|
|
dev_warn(errdev, "Offline failed.\n");
|
2013-11-07 04:41:14 +04:00
|
|
|
acpi_bus_online(handle, 0, NULL, NULL);
|
2013-05-23 12:43:13 +04:00
|
|
|
acpi_walk_namespace(ACPI_TYPE_ANY, handle,
|
2013-11-07 04:41:14 +04:00
|
|
|
ACPI_UINT32_MAX, acpi_bus_online,
|
|
|
|
NULL, NULL, NULL);
|
2013-05-23 12:43:13 +04:00
|
|
|
put_device(&device->dev);
|
|
|
|
return -EBUSY;
|
|
|
|
}
|
2013-05-03 02:26:16 +04:00
|
|
|
}
|
|
|
|
|
2008-04-29 10:35:48 +04:00
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
|
ACPI: struct device - replace bus_id with dev_name(), dev_set_name()
This patch is part of a larger patch series which will remove
the "char bus_id[20]" name string from struct device. The device
name is managed in the kobject anyway, and without any size
limitation, and just needlessly copied into "struct device".
To set and read the device name dev_name(dev) and dev_set_name(dev)
must be used. If your code uses static kobjects, which it shouldn't
do, "const char *init_name" can be used to statically provide the
name the registered device should have. At registration time, the
init_name field is cleared, to enforce the use of dev_name(dev) to
access the device name at a later time.
We need to get rid of all occurrences of bus_id in the entire tree
to be able to enable the new interface. Please apply this patch,
and possibly convert any remaining remaining occurrences of bus_id.
We want to submit a patch to -next, which will remove bus_id from
"struct device", to find the remaining pieces to convert, and finally
switch over to the new api, which will remove the 20 bytes array
and does no longer have a size limitation.
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-Off-By: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-10-30 03:18:59 +03:00
|
|
|
"Hot-removing device %s...\n", dev_name(&device->dev)));
|
2008-04-29 10:35:48 +04:00
|
|
|
|
2013-01-26 03:27:44 +04:00
|
|
|
acpi_bus_trim(device);
|
2013-05-03 02:26:16 +04:00
|
|
|
|
ACPI / hotplug: Fix concurrency issues and memory leaks
This changeset is aimed at fixing a few different but related
problems in the ACPI hotplug infrastructure.
First of all, since notify handlers may be run in parallel with
acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
and some of them are installed for ACPI handles that have no struct
acpi_device objects attached (i.e. before those objects are created),
those notify handlers have to take acpi_scan_lock to prevent races
from taking place (e.g. a struct acpi_device is found to be present
for the given ACPI handle, but right after that it is removed by
acpi_bus_trim() running in parallel to the given notify handler).
Moreover, since some of them call acpi_bus_scan() and
acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
should be acquired by the callers of these two funtions rather by
these functions themselves.
For these reasons, make all notify handlers that can handle device
addition and eject events take acpi_scan_lock and remove the
acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
Accordingly, update all of their users to make sure that they
are always called under acpi_scan_lock.
Furthermore, since eject operations are carried out asynchronously
with respect to the notify events that trigger them, with the help
of acpi_bus_hot_remove_device(), even if notify handlers take the
ACPI scan lock, it still is possible that, for example,
acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
the notify handler that scheduled its execution and that
acpi_bus_trim() will remove the device node passed to
acpi_bus_hot_remove_device() for ejection. In that case, the struct
acpi_device object obtained by acpi_bus_hot_remove_device() will be
invalid and not-so-funny things will ensue. To protect agaist that,
make the users of acpi_bus_hot_remove_device() run get_device() on
ACPI device node objects that are about to be passed to it and make
acpi_bus_hot_remove_device() run put_device() on them and check if
their ACPI handles are not NULL (make acpi_device_unregister() clear
the device nodes' ACPI handles for that check to work).
Finally, observe that acpi_os_hotplug_execute() actually can fail,
in which case its caller ought to free memory allocated for the
context object to prevent leaks from happening. It also needs to
run put_device() on the device node that it ran get_device() on
previously in that case. Modify the code accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
2013-02-13 17:36:47 +04:00
|
|
|
/* Device node has been unregistered. */
|
|
|
|
put_device(&device->dev);
|
2012-10-26 15:38:57 +04:00
|
|
|
device = NULL;
|
|
|
|
|
2013-06-28 20:24:40 +04:00
|
|
|
acpi_evaluate_lck(handle, 0);
|
2005-04-17 02:20:36 +04:00
|
|
|
/*
|
|
|
|
* TBD: _EJD support.
|
|
|
|
*/
|
2013-06-28 20:24:40 +04:00
|
|
|
status = acpi_evaluate_ej0(handle);
|
|
|
|
if (status == AE_NOT_FOUND)
|
|
|
|
return -ENODEV;
|
|
|
|
else if (ACPI_FAILURE(status))
|
|
|
|
return -EIO;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2013-03-13 23:29:26 +04:00
|
|
|
/*
|
|
|
|
* Verify if eject was indeed successful. If not, log an error
|
|
|
|
* message. No need to call _OST since _EJ0 call was made OK.
|
|
|
|
*/
|
|
|
|
status = acpi_evaluate_integer(handle, "_STA", NULL, &sta);
|
|
|
|
if (ACPI_FAILURE(status)) {
|
|
|
|
acpi_handle_warn(handle,
|
|
|
|
"Status check after eject failed (0x%x)\n", status);
|
|
|
|
} else if (sta & ACPI_STA_DEVICE_ENABLED) {
|
|
|
|
acpi_handle_warn(handle,
|
|
|
|
"Eject incomplete - status 0x%llx\n", sta);
|
|
|
|
}
|
|
|
|
|
2013-03-04 02:05:29 +04:00
|
|
|
return 0;
|
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routines
There are two different interfaces for queuing up work items on the
ACPI hotplug workqueue, alloc_acpi_hp_work() used by PCI and PCI host
bridge hotplug code and acpi_os_hotplug_execute() used by the common
ACPI hotplug code and docking stations. They both are somewhat
cumbersome to use and work slightly differently.
The users of alloc_acpi_hp_work() have to submit a work function that
will extract the necessary data items from a struct acpi_hp_work
object allocated by alloc_acpi_hp_work() and then will free that
object, while it would be more straightforward to simply use a work
function with one more argument and let the interface take care of
the execution details.
The users of acpi_os_hotplug_execute() also have to deal with the
fact that it takes only one argument in addition to the work function
pointer, although acpi_os_execute_deferred() actually takes care of
the allocation and freeing of memory, so it would have been able to
pass more arguments to the work function if it hadn't been
constrained by the connection with acpi_os_execute().
Moreover, while alloc_acpi_hp_work() makes GFP_KERNEL memory
allocations, which is correct, because hotplug work items are
always queued up from process context, acpi_os_hotplug_execute()
uses GFP_ATOMIC, as that is needed by acpi_os_execute(). Also,
acpi_os_execute_deferred() queued up by it waits for the ACPI event
workqueues to flush before executing the work function, whereas
alloc_acpi_hp_work() can't do anything similar. That leads to
somewhat arbitrary differences in behavior between various ACPI
hotplug code paths and has to be straightened up.
For this reason, replace both alloc_acpi_hp_work() and
acpi_os_hotplug_execute() with a single interface,
acpi_hotplug_execute(), combining their behavior and being more
friendly to its users than any of the two.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-07 04:45:40 +04:00
|
|
|
void acpi_bus_device_eject(void *data, u32 ost_src)
|
2013-03-04 02:05:29 +04:00
|
|
|
{
|
ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routines
There are two different interfaces for queuing up work items on the
ACPI hotplug workqueue, alloc_acpi_hp_work() used by PCI and PCI host
bridge hotplug code and acpi_os_hotplug_execute() used by the common
ACPI hotplug code and docking stations. They both are somewhat
cumbersome to use and work slightly differently.
The users of alloc_acpi_hp_work() have to submit a work function that
will extract the necessary data items from a struct acpi_hp_work
object allocated by alloc_acpi_hp_work() and then will free that
object, while it would be more straightforward to simply use a work
function with one more argument and let the interface take care of
the execution details.
The users of acpi_os_hotplug_execute() also have to deal with the
fact that it takes only one argument in addition to the work function
pointer, although acpi_os_execute_deferred() actually takes care of
the allocation and freeing of memory, so it would have been able to
pass more arguments to the work function if it hadn't been
constrained by the connection with acpi_os_execute().
Moreover, while alloc_acpi_hp_work() makes GFP_KERNEL memory
allocations, which is correct, because hotplug work items are
always queued up from process context, acpi_os_hotplug_execute()
uses GFP_ATOMIC, as that is needed by acpi_os_execute(). Also,
acpi_os_execute_deferred() queued up by it waits for the ACPI event
workqueues to flush before executing the work function, whereas
alloc_acpi_hp_work() can't do anything similar. That leads to
somewhat arbitrary differences in behavior between various ACPI
hotplug code paths and has to be straightened up.
For this reason, replace both alloc_acpi_hp_work() and
acpi_os_hotplug_execute() with a single interface,
acpi_hotplug_execute(), combining their behavior and being more
friendly to its users than any of the two.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-07 04:45:40 +04:00
|
|
|
struct acpi_device *device = data;
|
2013-11-07 04:41:58 +04:00
|
|
|
acpi_handle handle = device->handle;
|
2013-03-04 02:05:29 +04:00
|
|
|
u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE;
|
2013-08-28 23:41:07 +04:00
|
|
|
int error;
|
2013-03-04 02:05:29 +04:00
|
|
|
|
2013-08-30 16:19:29 +04:00
|
|
|
lock_device_hotplug();
|
2013-03-04 02:05:29 +04:00
|
|
|
mutex_lock(&acpi_scan_lock);
|
|
|
|
|
2013-11-07 04:41:58 +04:00
|
|
|
if (ost_src == ACPI_NOTIFY_EJECT_REQUEST)
|
|
|
|
acpi_evaluate_hotplug_ost(handle, ACPI_NOTIFY_EJECT_REQUEST,
|
|
|
|
ACPI_OST_SC_EJECT_IN_PROGRESS, NULL);
|
2013-11-07 04:41:14 +04:00
|
|
|
|
2013-11-14 03:54:08 +04:00
|
|
|
if (device->handler && device->handler->hotplug.mode == AHM_CONTAINER)
|
2013-03-04 02:05:29 +04:00
|
|
|
kobject_uevent(&device->dev.kobj, KOBJ_OFFLINE);
|
|
|
|
|
2013-08-28 23:41:07 +04:00
|
|
|
error = acpi_scan_hot_remove(device);
|
2013-11-07 04:41:14 +04:00
|
|
|
if (error == -EPERM) {
|
|
|
|
goto err_support;
|
|
|
|
} else if (error) {
|
2013-08-28 23:41:07 +04:00
|
|
|
goto err_out;
|
2013-11-07 04:41:14 +04:00
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
ACPI / hotplug: Fix concurrency issues and memory leaks
This changeset is aimed at fixing a few different but related
problems in the ACPI hotplug infrastructure.
First of all, since notify handlers may be run in parallel with
acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
and some of them are installed for ACPI handles that have no struct
acpi_device objects attached (i.e. before those objects are created),
those notify handlers have to take acpi_scan_lock to prevent races
from taking place (e.g. a struct acpi_device is found to be present
for the given ACPI handle, but right after that it is removed by
acpi_bus_trim() running in parallel to the given notify handler).
Moreover, since some of them call acpi_bus_scan() and
acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
should be acquired by the callers of these two funtions rather by
these functions themselves.
For these reasons, make all notify handlers that can handle device
addition and eject events take acpi_scan_lock and remove the
acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
Accordingly, update all of their users to make sure that they
are always called under acpi_scan_lock.
Furthermore, since eject operations are carried out asynchronously
with respect to the notify events that trigger them, with the help
of acpi_bus_hot_remove_device(), even if notify handlers take the
ACPI scan lock, it still is possible that, for example,
acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
the notify handler that scheduled its execution and that
acpi_bus_trim() will remove the device node passed to
acpi_bus_hot_remove_device() for ejection. In that case, the struct
acpi_device object obtained by acpi_bus_hot_remove_device() will be
invalid and not-so-funny things will ensue. To protect agaist that,
make the users of acpi_bus_hot_remove_device() run get_device() on
ACPI device node objects that are about to be passed to it and make
acpi_bus_hot_remove_device() run put_device() on them and check if
their ACPI handles are not NULL (make acpi_device_unregister() clear
the device nodes' ACPI handles for that check to work).
Finally, observe that acpi_os_hotplug_execute() actually can fail,
in which case its caller ought to free memory allocated for the
context object to prevent leaks from happening. It also needs to
run put_device() on the device node that it ran get_device() on
previously in that case. Modify the code accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
2013-02-13 17:36:47 +04:00
|
|
|
out:
|
2013-02-09 18:29:11 +04:00
|
|
|
mutex_unlock(&acpi_scan_lock);
|
2013-08-30 16:19:29 +04:00
|
|
|
unlock_device_hotplug();
|
2009-06-22 07:31:16 +04:00
|
|
|
return;
|
2013-03-04 02:05:29 +04:00
|
|
|
|
2013-11-07 04:41:14 +04:00
|
|
|
err_support:
|
|
|
|
ost_code = ACPI_OST_SC_EJECT_NOT_SUPPORTED;
|
2013-03-04 02:05:29 +04:00
|
|
|
err_out:
|
2013-11-07 04:41:58 +04:00
|
|
|
acpi_evaluate_hotplug_ost(handle, ost_src, ost_code, NULL);
|
2013-03-04 02:05:29 +04:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routines
There are two different interfaces for queuing up work items on the
ACPI hotplug workqueue, alloc_acpi_hp_work() used by PCI and PCI host
bridge hotplug code and acpi_os_hotplug_execute() used by the common
ACPI hotplug code and docking stations. They both are somewhat
cumbersome to use and work slightly differently.
The users of alloc_acpi_hp_work() have to submit a work function that
will extract the necessary data items from a struct acpi_hp_work
object allocated by alloc_acpi_hp_work() and then will free that
object, while it would be more straightforward to simply use a work
function with one more argument and let the interface take care of
the execution details.
The users of acpi_os_hotplug_execute() also have to deal with the
fact that it takes only one argument in addition to the work function
pointer, although acpi_os_execute_deferred() actually takes care of
the allocation and freeing of memory, so it would have been able to
pass more arguments to the work function if it hadn't been
constrained by the connection with acpi_os_execute().
Moreover, while alloc_acpi_hp_work() makes GFP_KERNEL memory
allocations, which is correct, because hotplug work items are
always queued up from process context, acpi_os_hotplug_execute()
uses GFP_ATOMIC, as that is needed by acpi_os_execute(). Also,
acpi_os_execute_deferred() queued up by it waits for the ACPI event
workqueues to flush before executing the work function, whereas
alloc_acpi_hp_work() can't do anything similar. That leads to
somewhat arbitrary differences in behavior between various ACPI
hotplug code paths and has to be straightened up.
For this reason, replace both alloc_acpi_hp_work() and
acpi_os_hotplug_execute() with a single interface,
acpi_hotplug_execute(), combining their behavior and being more
friendly to its users than any of the two.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-07 04:45:40 +04:00
|
|
|
static void acpi_scan_bus_device_check(void *data, u32 ost_source)
|
2013-03-04 02:05:29 +04:00
|
|
|
{
|
ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routines
There are two different interfaces for queuing up work items on the
ACPI hotplug workqueue, alloc_acpi_hp_work() used by PCI and PCI host
bridge hotplug code and acpi_os_hotplug_execute() used by the common
ACPI hotplug code and docking stations. They both are somewhat
cumbersome to use and work slightly differently.
The users of alloc_acpi_hp_work() have to submit a work function that
will extract the necessary data items from a struct acpi_hp_work
object allocated by alloc_acpi_hp_work() and then will free that
object, while it would be more straightforward to simply use a work
function with one more argument and let the interface take care of
the execution details.
The users of acpi_os_hotplug_execute() also have to deal with the
fact that it takes only one argument in addition to the work function
pointer, although acpi_os_execute_deferred() actually takes care of
the allocation and freeing of memory, so it would have been able to
pass more arguments to the work function if it hadn't been
constrained by the connection with acpi_os_execute().
Moreover, while alloc_acpi_hp_work() makes GFP_KERNEL memory
allocations, which is correct, because hotplug work items are
always queued up from process context, acpi_os_hotplug_execute()
uses GFP_ATOMIC, as that is needed by acpi_os_execute(). Also,
acpi_os_execute_deferred() queued up by it waits for the ACPI event
workqueues to flush before executing the work function, whereas
alloc_acpi_hp_work() can't do anything similar. That leads to
somewhat arbitrary differences in behavior between various ACPI
hotplug code paths and has to be straightened up.
For this reason, replace both alloc_acpi_hp_work() and
acpi_os_hotplug_execute() with a single interface,
acpi_hotplug_execute(), combining their behavior and being more
friendly to its users than any of the two.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-07 04:45:40 +04:00
|
|
|
acpi_handle handle = data;
|
2013-03-04 02:05:29 +04:00
|
|
|
struct acpi_device *device = NULL;
|
|
|
|
u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE;
|
|
|
|
int error;
|
|
|
|
|
2013-05-03 02:26:16 +04:00
|
|
|
lock_device_hotplug();
|
2013-08-30 16:19:29 +04:00
|
|
|
mutex_lock(&acpi_scan_lock);
|
2013-03-04 02:05:29 +04:00
|
|
|
|
2013-07-08 04:01:53 +04:00
|
|
|
if (ost_source != ACPI_NOTIFY_BUS_CHECK) {
|
|
|
|
acpi_bus_get_device(handle, &device);
|
|
|
|
if (device) {
|
|
|
|
dev_warn(&device->dev, "Attempt to re-insert\n");
|
|
|
|
goto out;
|
|
|
|
}
|
2013-03-04 02:05:29 +04:00
|
|
|
}
|
|
|
|
error = acpi_bus_scan(handle);
|
|
|
|
if (error) {
|
|
|
|
acpi_handle_warn(handle, "Namespace scan failure\n");
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
error = acpi_bus_get_device(handle, &device);
|
|
|
|
if (error) {
|
|
|
|
acpi_handle_warn(handle, "Missing device node object\n");
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
ost_code = ACPI_OST_SC_SUCCESS;
|
|
|
|
if (device->handler && device->handler->hotplug.mode == AHM_CONTAINER)
|
|
|
|
kobject_uevent(&device->dev.kobj, KOBJ_ONLINE);
|
|
|
|
|
|
|
|
out:
|
|
|
|
acpi_evaluate_hotplug_ost(handle, ost_source, ost_code, NULL);
|
|
|
|
mutex_unlock(&acpi_scan_lock);
|
2013-08-30 16:19:29 +04:00
|
|
|
unlock_device_hotplug();
|
2013-03-04 02:05:29 +04:00
|
|
|
}
|
|
|
|
|
2013-03-06 02:33:31 +04:00
|
|
|
static void acpi_hotplug_unsupported(acpi_handle handle, u32 type)
|
|
|
|
{
|
|
|
|
u32 ost_status;
|
|
|
|
|
|
|
|
switch (type) {
|
|
|
|
case ACPI_NOTIFY_BUS_CHECK:
|
|
|
|
acpi_handle_debug(handle,
|
|
|
|
"ACPI_NOTIFY_BUS_CHECK event: unsupported\n");
|
|
|
|
ost_status = ACPI_OST_SC_INSERT_NOT_SUPPORTED;
|
|
|
|
break;
|
|
|
|
case ACPI_NOTIFY_DEVICE_CHECK:
|
|
|
|
acpi_handle_debug(handle,
|
|
|
|
"ACPI_NOTIFY_DEVICE_CHECK event: unsupported\n");
|
|
|
|
ost_status = ACPI_OST_SC_INSERT_NOT_SUPPORTED;
|
|
|
|
break;
|
|
|
|
case ACPI_NOTIFY_EJECT_REQUEST:
|
|
|
|
acpi_handle_debug(handle,
|
|
|
|
"ACPI_NOTIFY_EJECT_REQUEST event: unsupported\n");
|
|
|
|
ost_status = ACPI_OST_SC_EJECT_NOT_SUPPORTED;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
/* non-hotplug event; possibly handled by other handler */
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
acpi_evaluate_hotplug_ost(handle, type, ost_status, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void acpi_hotplug_notify_cb(acpi_handle handle, u32 type, void *data)
|
2013-03-04 02:05:29 +04:00
|
|
|
{
|
2013-03-06 02:33:31 +04:00
|
|
|
struct acpi_scan_handler *handler = data;
|
2013-11-07 04:41:58 +04:00
|
|
|
struct acpi_device *adev;
|
2013-03-04 02:05:29 +04:00
|
|
|
acpi_status status;
|
|
|
|
|
2013-03-06 02:33:31 +04:00
|
|
|
if (!handler->hotplug.enabled)
|
|
|
|
return acpi_hotplug_unsupported(handle, type);
|
|
|
|
|
2013-03-04 02:05:29 +04:00
|
|
|
switch (type) {
|
|
|
|
case ACPI_NOTIFY_BUS_CHECK:
|
|
|
|
acpi_handle_debug(handle, "ACPI_NOTIFY_BUS_CHECK event\n");
|
|
|
|
break;
|
|
|
|
case ACPI_NOTIFY_DEVICE_CHECK:
|
|
|
|
acpi_handle_debug(handle, "ACPI_NOTIFY_DEVICE_CHECK event\n");
|
|
|
|
break;
|
|
|
|
case ACPI_NOTIFY_EJECT_REQUEST:
|
|
|
|
acpi_handle_debug(handle, "ACPI_NOTIFY_EJECT_REQUEST event\n");
|
2013-11-14 03:54:00 +04:00
|
|
|
if (acpi_bus_get_device(handle, &adev))
|
2013-11-07 04:41:58 +04:00
|
|
|
goto err_out;
|
|
|
|
|
|
|
|
get_device(&adev->dev);
|
ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routines
There are two different interfaces for queuing up work items on the
ACPI hotplug workqueue, alloc_acpi_hp_work() used by PCI and PCI host
bridge hotplug code and acpi_os_hotplug_execute() used by the common
ACPI hotplug code and docking stations. They both are somewhat
cumbersome to use and work slightly differently.
The users of alloc_acpi_hp_work() have to submit a work function that
will extract the necessary data items from a struct acpi_hp_work
object allocated by alloc_acpi_hp_work() and then will free that
object, while it would be more straightforward to simply use a work
function with one more argument and let the interface take care of
the execution details.
The users of acpi_os_hotplug_execute() also have to deal with the
fact that it takes only one argument in addition to the work function
pointer, although acpi_os_execute_deferred() actually takes care of
the allocation and freeing of memory, so it would have been able to
pass more arguments to the work function if it hadn't been
constrained by the connection with acpi_os_execute().
Moreover, while alloc_acpi_hp_work() makes GFP_KERNEL memory
allocations, which is correct, because hotplug work items are
always queued up from process context, acpi_os_hotplug_execute()
uses GFP_ATOMIC, as that is needed by acpi_os_execute(). Also,
acpi_os_execute_deferred() queued up by it waits for the ACPI event
workqueues to flush before executing the work function, whereas
alloc_acpi_hp_work() can't do anything similar. That leads to
somewhat arbitrary differences in behavior between various ACPI
hotplug code paths and has to be straightened up.
For this reason, replace both alloc_acpi_hp_work() and
acpi_os_hotplug_execute() with a single interface,
acpi_hotplug_execute(), combining their behavior and being more
friendly to its users than any of the two.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-07 04:45:40 +04:00
|
|
|
status = acpi_hotplug_execute(acpi_bus_device_eject, adev, type);
|
2013-11-07 04:41:58 +04:00
|
|
|
if (ACPI_SUCCESS(status))
|
|
|
|
return;
|
|
|
|
|
|
|
|
put_device(&adev->dev);
|
|
|
|
goto err_out;
|
2013-03-04 02:05:29 +04:00
|
|
|
default:
|
|
|
|
/* non-hotplug event; possibly handled by other handler */
|
|
|
|
return;
|
|
|
|
}
|
ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routines
There are two different interfaces for queuing up work items on the
ACPI hotplug workqueue, alloc_acpi_hp_work() used by PCI and PCI host
bridge hotplug code and acpi_os_hotplug_execute() used by the common
ACPI hotplug code and docking stations. They both are somewhat
cumbersome to use and work slightly differently.
The users of alloc_acpi_hp_work() have to submit a work function that
will extract the necessary data items from a struct acpi_hp_work
object allocated by alloc_acpi_hp_work() and then will free that
object, while it would be more straightforward to simply use a work
function with one more argument and let the interface take care of
the execution details.
The users of acpi_os_hotplug_execute() also have to deal with the
fact that it takes only one argument in addition to the work function
pointer, although acpi_os_execute_deferred() actually takes care of
the allocation and freeing of memory, so it would have been able to
pass more arguments to the work function if it hadn't been
constrained by the connection with acpi_os_execute().
Moreover, while alloc_acpi_hp_work() makes GFP_KERNEL memory
allocations, which is correct, because hotplug work items are
always queued up from process context, acpi_os_hotplug_execute()
uses GFP_ATOMIC, as that is needed by acpi_os_execute(). Also,
acpi_os_execute_deferred() queued up by it waits for the ACPI event
workqueues to flush before executing the work function, whereas
alloc_acpi_hp_work() can't do anything similar. That leads to
somewhat arbitrary differences in behavior between various ACPI
hotplug code paths and has to be straightened up.
For this reason, replace both alloc_acpi_hp_work() and
acpi_os_hotplug_execute() with a single interface,
acpi_hotplug_execute(), combining their behavior and being more
friendly to its users than any of the two.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-07 04:45:40 +04:00
|
|
|
status = acpi_hotplug_execute(acpi_scan_bus_device_check, handle, type);
|
2013-11-07 04:41:58 +04:00
|
|
|
if (ACPI_SUCCESS(status))
|
|
|
|
return;
|
2013-03-04 02:05:29 +04:00
|
|
|
|
2013-11-07 04:41:58 +04:00
|
|
|
err_out:
|
|
|
|
acpi_evaluate_hotplug_ost(handle, type,
|
|
|
|
ACPI_OST_SC_NON_SPECIFIC_FAILURE, NULL);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2013-01-24 15:49:59 +04:00
|
|
|
static ssize_t real_power_state_show(struct device *dev,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct acpi_device *adev = to_acpi_device(dev);
|
|
|
|
int state;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = acpi_device_get_power(adev, &state);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
return sprintf(buf, "%s\n", acpi_power_state_string(state));
|
|
|
|
}
|
|
|
|
|
|
|
|
static DEVICE_ATTR(real_power_state, 0444, real_power_state_show, NULL);
|
|
|
|
|
|
|
|
static ssize_t power_state_show(struct device *dev,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct acpi_device *adev = to_acpi_device(dev);
|
|
|
|
|
|
|
|
return sprintf(buf, "%s\n", acpi_power_state_string(adev->power.state));
|
|
|
|
}
|
|
|
|
|
|
|
|
static DEVICE_ATTR(power_state, 0444, power_state_show, NULL);
|
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
static ssize_t
|
2006-12-07 15:56:38 +03:00
|
|
|
acpi_eject_store(struct device *d, struct device_attribute *attr,
|
|
|
|
const char *buf, size_t count)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2006-12-07 15:56:38 +03:00
|
|
|
struct acpi_device *acpi_device = to_acpi_device(d);
|
2013-03-04 02:05:29 +04:00
|
|
|
acpi_object_type not_used;
|
|
|
|
acpi_status status;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2013-03-04 02:05:29 +04:00
|
|
|
if (!count || buf[0] != '1')
|
2005-04-17 02:20:36 +04:00
|
|
|
return -EINVAL;
|
|
|
|
|
2013-03-04 02:05:29 +04:00
|
|
|
if ((!acpi_device->handler || !acpi_device->handler->hotplug.enabled)
|
|
|
|
&& !acpi_device->driver)
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
status = acpi_get_type(acpi_device->handle, ¬_used);
|
|
|
|
if (ACPI_FAILURE(status) || !acpi_device->flags.ejectable)
|
|
|
|
return -ENODEV;
|
|
|
|
|
2013-08-28 23:41:07 +04:00
|
|
|
acpi_evaluate_hotplug_ost(acpi_device->handle, ACPI_OST_EC_OSPM_EJECT,
|
2013-03-04 02:05:29 +04:00
|
|
|
ACPI_OST_SC_EJECT_IN_PROGRESS, NULL);
|
|
|
|
get_device(&acpi_device->dev);
|
ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routines
There are two different interfaces for queuing up work items on the
ACPI hotplug workqueue, alloc_acpi_hp_work() used by PCI and PCI host
bridge hotplug code and acpi_os_hotplug_execute() used by the common
ACPI hotplug code and docking stations. They both are somewhat
cumbersome to use and work slightly differently.
The users of alloc_acpi_hp_work() have to submit a work function that
will extract the necessary data items from a struct acpi_hp_work
object allocated by alloc_acpi_hp_work() and then will free that
object, while it would be more straightforward to simply use a work
function with one more argument and let the interface take care of
the execution details.
The users of acpi_os_hotplug_execute() also have to deal with the
fact that it takes only one argument in addition to the work function
pointer, although acpi_os_execute_deferred() actually takes care of
the allocation and freeing of memory, so it would have been able to
pass more arguments to the work function if it hadn't been
constrained by the connection with acpi_os_execute().
Moreover, while alloc_acpi_hp_work() makes GFP_KERNEL memory
allocations, which is correct, because hotplug work items are
always queued up from process context, acpi_os_hotplug_execute()
uses GFP_ATOMIC, as that is needed by acpi_os_execute(). Also,
acpi_os_execute_deferred() queued up by it waits for the ACPI event
workqueues to flush before executing the work function, whereas
alloc_acpi_hp_work() can't do anything similar. That leads to
somewhat arbitrary differences in behavior between various ACPI
hotplug code paths and has to be straightened up.
For this reason, replace both alloc_acpi_hp_work() and
acpi_os_hotplug_execute() with a single interface,
acpi_hotplug_execute(), combining their behavior and being more
friendly to its users than any of the two.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-07 04:45:40 +04:00
|
|
|
status = acpi_hotplug_execute(acpi_bus_device_eject, acpi_device,
|
|
|
|
ACPI_OST_EC_OSPM_EJECT);
|
2013-08-28 23:41:07 +04:00
|
|
|
if (ACPI_SUCCESS(status))
|
|
|
|
return count;
|
2013-03-04 02:05:29 +04:00
|
|
|
|
2013-08-28 23:41:07 +04:00
|
|
|
put_device(&acpi_device->dev);
|
|
|
|
acpi_evaluate_hotplug_ost(acpi_device->handle, ACPI_OST_EC_OSPM_EJECT,
|
2013-03-04 02:05:29 +04:00
|
|
|
ACPI_OST_SC_NON_SPECIFIC_FAILURE, NULL);
|
2013-11-07 04:41:39 +04:00
|
|
|
return status == AE_NO_MEMORY ? -ENOMEM : -EAGAIN;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2006-12-07 15:56:38 +03:00
|
|
|
static DEVICE_ATTR(eject, 0200, NULL, acpi_eject_store);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
static ssize_t
|
|
|
|
acpi_device_hid_show(struct device *dev, struct device_attribute *attr, char *buf) {
|
|
|
|
struct acpi_device *acpi_dev = to_acpi_device(dev);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2009-09-21 23:35:09 +04:00
|
|
|
return sprintf(buf, "%s\n", acpi_device_hid(acpi_dev));
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
static DEVICE_ATTR(hid, 0444, acpi_device_hid_show, NULL);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2012-10-30 17:43:26 +04:00
|
|
|
static ssize_t acpi_device_uid_show(struct device *dev,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct acpi_device *acpi_dev = to_acpi_device(dev);
|
|
|
|
|
|
|
|
return sprintf(buf, "%s\n", acpi_dev->pnp.unique_id);
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR(uid, 0444, acpi_device_uid_show, NULL);
|
|
|
|
|
|
|
|
static ssize_t acpi_device_adr_show(struct device *dev,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct acpi_device *acpi_dev = to_acpi_device(dev);
|
|
|
|
|
|
|
|
return sprintf(buf, "0x%08x\n",
|
|
|
|
(unsigned int)(acpi_dev->pnp.bus_address));
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR(adr, 0444, acpi_device_adr_show, NULL);
|
|
|
|
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
static ssize_t
|
|
|
|
acpi_device_path_show(struct device *dev, struct device_attribute *attr, char *buf) {
|
|
|
|
struct acpi_device *acpi_dev = to_acpi_device(dev);
|
|
|
|
struct acpi_buffer path = {ACPI_ALLOCATE_BUFFER, NULL};
|
|
|
|
int result;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
result = acpi_get_name(acpi_dev->handle, ACPI_FULL_PATHNAME, &path);
|
2009-05-14 18:31:37 +04:00
|
|
|
if (result)
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
goto end;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
result = sprintf(buf, "%s\n", (char*)path.pointer);
|
|
|
|
kfree(path.pointer);
|
2009-05-14 18:31:37 +04:00
|
|
|
end:
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
return result;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
static DEVICE_ATTR(path, 0444, acpi_device_path_show, NULL);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2012-10-02 22:43:23 +04:00
|
|
|
/* sysfs file that shows description text from the ACPI _STR method */
|
|
|
|
static ssize_t description_show(struct device *dev,
|
|
|
|
struct device_attribute *attr,
|
|
|
|
char *buf) {
|
|
|
|
struct acpi_device *acpi_dev = to_acpi_device(dev);
|
|
|
|
int result;
|
|
|
|
|
|
|
|
if (acpi_dev->pnp.str_obj == NULL)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The _STR object contains a Unicode identifier for a device.
|
|
|
|
* We need to convert to utf-8 so it can be displayed.
|
|
|
|
*/
|
|
|
|
result = utf16s_to_utf8s(
|
|
|
|
(wchar_t *)acpi_dev->pnp.str_obj->buffer.pointer,
|
|
|
|
acpi_dev->pnp.str_obj->buffer.length,
|
|
|
|
UTF16_LITTLE_ENDIAN, buf,
|
|
|
|
PAGE_SIZE);
|
|
|
|
|
|
|
|
buf[result++] = '\n';
|
|
|
|
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR(description, 0444, description_show, NULL);
|
|
|
|
|
2012-11-16 05:56:59 +04:00
|
|
|
static ssize_t
|
|
|
|
acpi_device_sun_show(struct device *dev, struct device_attribute *attr,
|
|
|
|
char *buf) {
|
|
|
|
struct acpi_device *acpi_dev = to_acpi_device(dev);
|
|
|
|
|
|
|
|
return sprintf(buf, "%lu\n", acpi_dev->pnp.sun);
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR(sun, 0444, acpi_device_sun_show, NULL);
|
|
|
|
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
static int acpi_device_setup_files(struct acpi_device *dev)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2012-10-02 22:43:23 +04:00
|
|
|
struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};
|
2006-12-07 15:56:38 +03:00
|
|
|
acpi_status status;
|
2012-11-16 05:56:59 +04:00
|
|
|
unsigned long long sun;
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
int result = 0;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
/*
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
* Devices gotten from FADT don't have a "path" attribute
|
2005-04-17 02:20:36 +04:00
|
|
|
*/
|
2009-05-14 18:31:37 +04:00
|
|
|
if (dev->handle) {
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
result = device_create_file(&dev->dev, &dev_attr_path);
|
2009-05-14 18:31:37 +04:00
|
|
|
if (result)
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
goto end;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2010-10-01 12:53:59 +04:00
|
|
|
if (!list_empty(&dev->pnp.ids)) {
|
|
|
|
result = device_create_file(&dev->dev, &dev_attr_hid);
|
|
|
|
if (result)
|
|
|
|
goto end;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2010-10-01 12:53:59 +04:00
|
|
|
result = device_create_file(&dev->dev, &dev_attr_modalias);
|
|
|
|
if (result)
|
|
|
|
goto end;
|
|
|
|
}
|
2007-07-23 16:43:51 +04:00
|
|
|
|
2012-10-02 22:43:23 +04:00
|
|
|
/*
|
|
|
|
* If device has _STR, 'description' file is created
|
|
|
|
*/
|
2013-06-28 20:24:38 +04:00
|
|
|
if (acpi_has_method(dev->handle, "_STR")) {
|
2012-10-02 22:43:23 +04:00
|
|
|
status = acpi_evaluate_object(dev->handle, "_STR",
|
|
|
|
NULL, &buffer);
|
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
buffer.pointer = NULL;
|
|
|
|
dev->pnp.str_obj = buffer.pointer;
|
|
|
|
result = device_create_file(&dev->dev, &dev_attr_description);
|
|
|
|
if (result)
|
|
|
|
goto end;
|
|
|
|
}
|
|
|
|
|
2013-03-05 01:30:41 +04:00
|
|
|
if (dev->pnp.type.bus_address)
|
2012-10-30 17:43:26 +04:00
|
|
|
result = device_create_file(&dev->dev, &dev_attr_adr);
|
|
|
|
if (dev->pnp.unique_id)
|
|
|
|
result = device_create_file(&dev->dev, &dev_attr_uid);
|
|
|
|
|
2012-11-16 05:56:59 +04:00
|
|
|
status = acpi_evaluate_integer(dev->handle, "_SUN", NULL, &sun);
|
|
|
|
if (ACPI_SUCCESS(status)) {
|
|
|
|
dev->pnp.sun = (unsigned long)sun;
|
|
|
|
result = device_create_file(&dev->dev, &dev_attr_sun);
|
|
|
|
if (result)
|
|
|
|
goto end;
|
|
|
|
} else {
|
|
|
|
dev->pnp.sun = (unsigned long)-1;
|
|
|
|
}
|
|
|
|
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
/*
|
|
|
|
* If device has _EJ0, 'eject' file is created that is used to trigger
|
|
|
|
* hot-removal function from userland.
|
|
|
|
*/
|
2013-06-28 20:24:38 +04:00
|
|
|
if (acpi_has_method(dev->handle, "_EJ0")) {
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
result = device_create_file(&dev->dev, &dev_attr_eject);
|
2013-01-24 15:49:59 +04:00
|
|
|
if (result)
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (dev->flags.power_manageable) {
|
|
|
|
result = device_create_file(&dev->dev, &dev_attr_power_state);
|
|
|
|
if (result)
|
|
|
|
return result;
|
|
|
|
|
|
|
|
if (dev->power.flags.power_resources)
|
|
|
|
result = device_create_file(&dev->dev,
|
|
|
|
&dev_attr_real_power_state);
|
|
|
|
}
|
|
|
|
|
2009-05-14 18:31:37 +04:00
|
|
|
end:
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
return result;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2006-12-07 15:56:38 +03:00
|
|
|
static void acpi_device_remove_files(struct acpi_device *dev)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2013-01-24 15:49:59 +04:00
|
|
|
if (dev->flags.power_manageable) {
|
|
|
|
device_remove_file(&dev->dev, &dev_attr_power_state);
|
|
|
|
if (dev->power.flags.power_resources)
|
|
|
|
device_remove_file(&dev->dev,
|
|
|
|
&dev_attr_real_power_state);
|
|
|
|
}
|
|
|
|
|
2006-12-07 15:56:38 +03:00
|
|
|
/*
|
2012-10-02 22:43:23 +04:00
|
|
|
* If device has _STR, remove 'description' file
|
|
|
|
*/
|
2013-06-28 20:24:38 +04:00
|
|
|
if (acpi_has_method(dev->handle, "_STR")) {
|
2012-10-02 22:43:23 +04:00
|
|
|
kfree(dev->pnp.str_obj);
|
|
|
|
device_remove_file(&dev->dev, &dev_attr_description);
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* If device has _EJ0, remove 'eject' file.
|
2006-12-07 15:56:38 +03:00
|
|
|
*/
|
2013-06-28 20:24:38 +04:00
|
|
|
if (acpi_has_method(dev->handle, "_EJ0"))
|
2006-12-07 15:56:38 +03:00
|
|
|
device_remove_file(&dev->dev, &dev_attr_eject);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2013-06-28 20:24:38 +04:00
|
|
|
if (acpi_has_method(dev->handle, "_SUN"))
|
2012-11-16 05:56:59 +04:00
|
|
|
device_remove_file(&dev->dev, &dev_attr_sun);
|
|
|
|
|
2012-10-30 17:43:26 +04:00
|
|
|
if (dev->pnp.unique_id)
|
|
|
|
device_remove_file(&dev->dev, &dev_attr_uid);
|
2013-03-05 01:30:41 +04:00
|
|
|
if (dev->pnp.type.bus_address)
|
2012-10-30 17:43:26 +04:00
|
|
|
device_remove_file(&dev->dev, &dev_attr_adr);
|
2009-09-21 23:35:29 +04:00
|
|
|
device_remove_file(&dev->dev, &dev_attr_modalias);
|
|
|
|
device_remove_file(&dev->dev, &dev_attr_hid);
|
2009-05-14 18:31:37 +04:00
|
|
|
if (dev->handle)
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
device_remove_file(&dev->dev, &dev_attr_path);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
/* --------------------------------------------------------------------------
|
2006-12-07 15:56:16 +03:00
|
|
|
ACPI Bus operations
|
2005-04-17 02:20:36 +04:00
|
|
|
-------------------------------------------------------------------------- */
|
2007-07-23 16:43:51 +04:00
|
|
|
|
2012-11-01 01:44:41 +04:00
|
|
|
static const struct acpi_device_id *__acpi_match_device(
|
|
|
|
struct acpi_device *device, const struct acpi_device_id *ids)
|
2007-07-23 16:43:51 +04:00
|
|
|
{
|
|
|
|
const struct acpi_device_id *id;
|
2009-09-21 23:35:19 +04:00
|
|
|
struct acpi_hardware_id *hwid;
|
2007-07-23 16:43:51 +04:00
|
|
|
|
2008-08-11 09:40:22 +04:00
|
|
|
/*
|
|
|
|
* If the device is not present, it is unnecessary to load device
|
|
|
|
* driver for it.
|
|
|
|
*/
|
|
|
|
if (!device->status.present)
|
2012-11-01 01:44:41 +04:00
|
|
|
return NULL;
|
2008-08-11 09:40:22 +04:00
|
|
|
|
2009-09-21 23:35:19 +04:00
|
|
|
for (id = ids; id->id[0]; id++)
|
|
|
|
list_for_each_entry(hwid, &device->pnp.ids, list)
|
|
|
|
if (!strcmp((char *) id->id, hwid->id))
|
2012-11-01 01:44:41 +04:00
|
|
|
return id;
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_match_device - Match a struct device against a given list of ACPI IDs
|
|
|
|
* @ids: Array of struct acpi_device_id object to match against.
|
|
|
|
* @dev: The device structure to match.
|
|
|
|
*
|
|
|
|
* Check if @dev has a valid ACPI handle and if there is a struct acpi_device
|
|
|
|
* object for that handle and use that object to match against a given list of
|
|
|
|
* device IDs.
|
|
|
|
*
|
|
|
|
* Return a pointer to the first matching ID on success or %NULL on failure.
|
|
|
|
*/
|
|
|
|
const struct acpi_device_id *acpi_match_device(const struct acpi_device_id *ids,
|
|
|
|
const struct device *dev)
|
|
|
|
{
|
|
|
|
struct acpi_device *adev;
|
2013-01-31 23:54:05 +04:00
|
|
|
acpi_handle handle = ACPI_HANDLE(dev);
|
2012-11-01 01:44:41 +04:00
|
|
|
|
2013-01-31 23:54:05 +04:00
|
|
|
if (!ids || !handle || acpi_bus_get_device(handle, &adev))
|
2012-11-01 01:44:41 +04:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return __acpi_match_device(adev, ids);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_match_device);
|
2007-07-23 16:43:51 +04:00
|
|
|
|
2012-11-01 01:44:41 +04:00
|
|
|
int acpi_match_device_ids(struct acpi_device *device,
|
|
|
|
const struct acpi_device_id *ids)
|
|
|
|
{
|
|
|
|
return __acpi_match_device(device, ids) ? 0 : -ENOENT;
|
2007-07-23 16:43:51 +04:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(acpi_match_device_ids);
|
|
|
|
|
2013-01-17 17:11:06 +04:00
|
|
|
static void acpi_free_power_resources_lists(struct acpi_device *device)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2013-01-17 17:11:06 +04:00
|
|
|
if (device->wakeup.flags.valid)
|
|
|
|
acpi_power_resources_list_free(&device->wakeup.resources);
|
|
|
|
|
2013-01-17 17:11:06 +04:00
|
|
|
if (!device->flags.power_manageable)
|
|
|
|
return;
|
|
|
|
|
|
|
|
for (i = ACPI_STATE_D0; i <= ACPI_STATE_D3_HOT; i++) {
|
|
|
|
struct acpi_device_power_state *ps = &device->power.states[i];
|
|
|
|
acpi_power_resources_list_free(&ps->resources);
|
|
|
|
}
|
2009-09-21 23:35:19 +04:00
|
|
|
}
|
|
|
|
|
2006-12-07 15:56:31 +03:00
|
|
|
static void acpi_device_release(struct device *dev)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2006-12-07 15:56:31 +03:00
|
|
|
struct acpi_device *acpi_dev = to_acpi_device(dev);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2013-03-05 01:30:42 +04:00
|
|
|
acpi_free_pnp_ids(&acpi_dev->pnp);
|
2013-01-17 17:11:06 +04:00
|
|
|
acpi_free_power_resources_lists(acpi_dev);
|
2006-12-07 15:56:31 +03:00
|
|
|
kfree(acpi_dev);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2006-12-07 15:56:27 +03:00
|
|
|
static int acpi_bus_match(struct device *dev, struct device_driver *drv)
|
2006-12-07 15:56:16 +03:00
|
|
|
{
|
2006-12-07 15:56:27 +03:00
|
|
|
struct acpi_device *acpi_dev = to_acpi_device(dev);
|
|
|
|
struct acpi_driver *acpi_drv = to_acpi_driver(drv);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2012-12-21 03:36:48 +04:00
|
|
|
return acpi_dev->flags.match_driver
|
ACPI: Separate adding ACPI device objects from probing ACPI drivers
Split the ACPI namespace scanning for devices into two passes, such
that struct acpi_device objects are registerd in the first pass
without probing ACPI drivers and the drivers are probed against them
directly in the second pass.
There are two main reasons for doing that.
First, the ACPI PCI root bridge driver's .add() routine,
acpi_pci_root_add(), causes struct pci_dev objects to be created for
all PCI devices under the given root bridge. Usually, there are
corresponding ACPI device nodes in the ACPI namespace for some of
those devices and therefore there should be "companion" struct
acpi_device objects to attach those struct pci_dev objects to. These
struct acpi_device objects should exist when the corresponding
struct pci_dev objects are created, but that is only guaranteed
during boot and not during hotplug. This leads to a number of
functional differences between the boot and the hotplug cases which
are not strictly necessary and make the code more complicated.
For example, this forces the ACPI PCI root bridge driver to defer the
registration of the just created struct pci_dev objects and to use a
special .start() callback routine, acpi_pci_root_start(), to make
sure that all of the "companion" struct acpi_device objects will be
present at PCI devices registration time during hotplug.
If those differences can be eliminated, we will be able to
consolidate the boot and hotplug code paths for the enumeration and
registration of PCI devices and to reduce the complexity of that
code quite a bit.
The second reason is that, in general, it should be possible to
resolve conflicts of resources assigned by the BIOS to different
devices represented by ACPI namespace nodes before any drivers bind
to them and before they are attached to "companion" objects
representing physical devices (such as struct pci_dev). However, for
this purpose we first need to enumerate all ACPI device nodes in the
given namespace scope.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Toshi Kani <toshi.kani@hp.com>
2012-12-21 03:36:39 +04:00
|
|
|
&& !acpi_match_device_ids(acpi_dev, acpi_drv->ids);
|
2006-12-07 15:56:27 +03:00
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2007-08-14 17:15:12 +04:00
|
|
|
static int acpi_device_uevent(struct device *dev, struct kobj_uevent_env *env)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2006-12-07 15:56:27 +03:00
|
|
|
struct acpi_device *acpi_dev = to_acpi_device(dev);
|
2007-08-14 17:15:12 +04:00
|
|
|
int len;
|
2006-12-07 15:56:27 +03:00
|
|
|
|
2010-10-01 12:53:59 +04:00
|
|
|
if (list_empty(&acpi_dev->pnp.ids))
|
|
|
|
return 0;
|
|
|
|
|
2007-08-14 17:15:12 +04:00
|
|
|
if (add_uevent_var(env, "MODALIAS="))
|
|
|
|
return -ENOMEM;
|
|
|
|
len = create_modalias(acpi_dev, &env->buf[env->buflen - 1],
|
|
|
|
sizeof(env->buf) - env->buflen);
|
|
|
|
if (len >= (sizeof(env->buf) - env->buflen))
|
|
|
|
return -ENOMEM;
|
|
|
|
env->buflen += len;
|
2006-12-07 15:56:16 +03:00
|
|
|
return 0;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2009-03-30 21:48:13 +04:00
|
|
|
static void acpi_device_notify(acpi_handle handle, u32 event, void *data)
|
|
|
|
{
|
|
|
|
struct acpi_device *device = data;
|
|
|
|
|
|
|
|
device->driver->ops.notify(device, event);
|
|
|
|
}
|
|
|
|
|
|
|
|
static acpi_status acpi_device_notify_fixed(void *data)
|
|
|
|
{
|
|
|
|
struct acpi_device *device = data;
|
|
|
|
|
2009-09-01 02:32:20 +04:00
|
|
|
/* Fixed hardware devices have no handles */
|
|
|
|
acpi_device_notify(NULL, ACPI_FIXED_HARDWARE_EVENT, device);
|
2009-03-30 21:48:13 +04:00
|
|
|
return AE_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int acpi_device_install_notify_handler(struct acpi_device *device)
|
|
|
|
{
|
|
|
|
acpi_status status;
|
|
|
|
|
2009-09-21 23:29:15 +04:00
|
|
|
if (device->device_type == ACPI_BUS_TYPE_POWER_BUTTON)
|
2009-03-30 21:48:13 +04:00
|
|
|
status =
|
|
|
|
acpi_install_fixed_event_handler(ACPI_EVENT_POWER_BUTTON,
|
|
|
|
acpi_device_notify_fixed,
|
|
|
|
device);
|
2009-09-21 23:29:15 +04:00
|
|
|
else if (device->device_type == ACPI_BUS_TYPE_SLEEP_BUTTON)
|
2009-03-30 21:48:13 +04:00
|
|
|
status =
|
|
|
|
acpi_install_fixed_event_handler(ACPI_EVENT_SLEEP_BUTTON,
|
|
|
|
acpi_device_notify_fixed,
|
|
|
|
device);
|
|
|
|
else
|
|
|
|
status = acpi_install_notify_handler(device->handle,
|
|
|
|
ACPI_DEVICE_NOTIFY,
|
|
|
|
acpi_device_notify,
|
|
|
|
device);
|
|
|
|
|
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
return -EINVAL;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void acpi_device_remove_notify_handler(struct acpi_device *device)
|
|
|
|
{
|
2009-09-21 23:29:15 +04:00
|
|
|
if (device->device_type == ACPI_BUS_TYPE_POWER_BUTTON)
|
2009-03-30 21:48:13 +04:00
|
|
|
acpi_remove_fixed_event_handler(ACPI_EVENT_POWER_BUTTON,
|
|
|
|
acpi_device_notify_fixed);
|
2009-09-21 23:29:15 +04:00
|
|
|
else if (device->device_type == ACPI_BUS_TYPE_SLEEP_BUTTON)
|
2009-03-30 21:48:13 +04:00
|
|
|
acpi_remove_fixed_event_handler(ACPI_EVENT_SLEEP_BUTTON,
|
|
|
|
acpi_device_notify_fixed);
|
|
|
|
else
|
|
|
|
acpi_remove_notify_handler(device->handle, ACPI_DEVICE_NOTIFY,
|
|
|
|
acpi_device_notify);
|
|
|
|
}
|
|
|
|
|
2013-06-10 15:00:50 +04:00
|
|
|
static int acpi_device_probe(struct device *dev)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2006-12-07 15:56:27 +03:00
|
|
|
struct acpi_device *acpi_dev = to_acpi_device(dev);
|
|
|
|
struct acpi_driver *acpi_drv = to_acpi_driver(dev->driver);
|
|
|
|
int ret;
|
|
|
|
|
2013-06-16 02:36:41 +04:00
|
|
|
if (acpi_dev->handler)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2013-06-10 15:00:50 +04:00
|
|
|
if (!acpi_drv->ops.add)
|
|
|
|
return -ENOSYS;
|
2009-03-30 21:48:13 +04:00
|
|
|
|
2013-06-10 15:00:50 +04:00
|
|
|
ret = acpi_drv->ops.add(acpi_dev);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2009-03-30 21:48:13 +04:00
|
|
|
|
2013-06-10 15:00:50 +04:00
|
|
|
acpi_dev->driver = acpi_drv;
|
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
|
|
|
|
"Driver [%s] successfully bound to device [%s]\n",
|
|
|
|
acpi_drv->name, acpi_dev->pnp.bus_id));
|
|
|
|
|
|
|
|
if (acpi_drv->ops.notify) {
|
|
|
|
ret = acpi_device_install_notify_handler(acpi_dev);
|
|
|
|
if (ret) {
|
|
|
|
if (acpi_drv->ops.remove)
|
|
|
|
acpi_drv->ops.remove(acpi_dev);
|
|
|
|
|
|
|
|
acpi_dev->driver = NULL;
|
|
|
|
acpi_dev->driver_data = NULL;
|
|
|
|
return ret;
|
|
|
|
}
|
2006-12-07 15:56:27 +03:00
|
|
|
}
|
2013-06-10 15:00:50 +04:00
|
|
|
|
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Found driver [%s] for device [%s]\n",
|
|
|
|
acpi_drv->name, acpi_dev->pnp.bus_id));
|
|
|
|
get_device(dev);
|
|
|
|
return 0;
|
2006-12-07 15:56:27 +03:00
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2006-12-07 15:56:27 +03:00
|
|
|
static int acpi_device_remove(struct device * dev)
|
|
|
|
{
|
|
|
|
struct acpi_device *acpi_dev = to_acpi_device(dev);
|
|
|
|
struct acpi_driver *acpi_drv = acpi_dev->driver;
|
|
|
|
|
|
|
|
if (acpi_drv) {
|
2009-03-30 21:48:13 +04:00
|
|
|
if (acpi_drv->ops.notify)
|
|
|
|
acpi_device_remove_notify_handler(acpi_dev);
|
2006-12-07 15:56:27 +03:00
|
|
|
if (acpi_drv->ops.remove)
|
2013-01-24 03:24:48 +04:00
|
|
|
acpi_drv->ops.remove(acpi_dev);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
2006-12-07 15:56:27 +03:00
|
|
|
acpi_dev->driver = NULL;
|
2008-09-23 01:37:34 +04:00
|
|
|
acpi_dev->driver_data = NULL;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2006-12-07 15:56:27 +03:00
|
|
|
put_device(dev);
|
2006-12-07 15:56:16 +03:00
|
|
|
return 0;
|
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2007-05-08 11:28:35 +04:00
|
|
|
struct bus_type acpi_bus_type = {
|
2006-12-07 15:56:16 +03:00
|
|
|
.name = "acpi",
|
2006-12-07 15:56:27 +03:00
|
|
|
.match = acpi_bus_match,
|
|
|
|
.probe = acpi_device_probe,
|
|
|
|
.remove = acpi_device_remove,
|
|
|
|
.uevent = acpi_device_uevent,
|
2006-12-07 15:56:16 +03:00
|
|
|
};
|
|
|
|
|
2013-07-30 16:38:34 +04:00
|
|
|
static void acpi_bus_data_handler(acpi_handle handle, void *context)
|
|
|
|
{
|
|
|
|
/* Intentionally empty. */
|
|
|
|
}
|
|
|
|
|
|
|
|
int acpi_bus_get_device(acpi_handle handle, struct acpi_device **device)
|
|
|
|
{
|
|
|
|
acpi_status status;
|
|
|
|
|
|
|
|
if (!device)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
status = acpi_get_data(handle, acpi_bus_data_handler, (void **)device);
|
|
|
|
if (ACPI_FAILURE(status) || !*device) {
|
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "No context for object [%p]\n",
|
|
|
|
handle));
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
2013-10-02 01:02:43 +04:00
|
|
|
EXPORT_SYMBOL(acpi_bus_get_device);
|
2013-07-30 16:38:34 +04:00
|
|
|
|
2013-01-24 15:49:49 +04:00
|
|
|
int acpi_device_add(struct acpi_device *device,
|
|
|
|
void (*release)(struct device *))
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2005-08-05 08:44:28 +04:00
|
|
|
int result;
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
struct acpi_device_bus_id *acpi_device_bus_id, *new_bus_id;
|
|
|
|
int found = 0;
|
2009-09-21 23:29:05 +04:00
|
|
|
|
2013-01-17 17:11:05 +04:00
|
|
|
if (device->handle) {
|
|
|
|
acpi_status status;
|
|
|
|
|
|
|
|
status = acpi_attach_data(device->handle, acpi_bus_data_handler,
|
|
|
|
device);
|
|
|
|
if (ACPI_FAILURE(status)) {
|
|
|
|
acpi_handle_err(device->handle,
|
|
|
|
"Unable to attach device data\n");
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-12-07 15:56:16 +03:00
|
|
|
/*
|
|
|
|
* Linkage
|
|
|
|
* -------
|
|
|
|
* Link this device to its parent and siblings.
|
|
|
|
*/
|
|
|
|
INIT_LIST_HEAD(&device->children);
|
|
|
|
INIT_LIST_HEAD(&device->node);
|
|
|
|
INIT_LIST_HEAD(&device->wakeup_list);
|
2012-08-17 10:44:09 +04:00
|
|
|
INIT_LIST_HEAD(&device->physical_node_list);
|
|
|
|
mutex_init(&device->physical_node_lock);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
new_bus_id = kzalloc(sizeof(struct acpi_device_bus_id), GFP_KERNEL);
|
|
|
|
if (!new_bus_id) {
|
2013-01-17 17:11:05 +04:00
|
|
|
pr_err(PREFIX "Memory allocation error\n");
|
|
|
|
result = -ENOMEM;
|
|
|
|
goto err_detach;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
|
2009-04-07 06:24:29 +04:00
|
|
|
mutex_lock(&acpi_device_lock);
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
/*
|
|
|
|
* Find suitable bus_id and instance number in acpi_bus_id_list
|
|
|
|
* If failed, create one and link it into acpi_bus_id_list
|
|
|
|
*/
|
|
|
|
list_for_each_entry(acpi_device_bus_id, &acpi_bus_id_list, node) {
|
2009-09-21 23:35:29 +04:00
|
|
|
if (!strcmp(acpi_device_bus_id->bus_id,
|
|
|
|
acpi_device_hid(device))) {
|
|
|
|
acpi_device_bus_id->instance_no++;
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
found = 1;
|
|
|
|
kfree(new_bus_id);
|
|
|
|
break;
|
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
2009-05-14 18:31:37 +04:00
|
|
|
if (!found) {
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
acpi_device_bus_id = new_bus_id;
|
2009-09-21 23:35:29 +04:00
|
|
|
strcpy(acpi_device_bus_id->bus_id, acpi_device_hid(device));
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
acpi_device_bus_id->instance_no = 0;
|
|
|
|
list_add_tail(&acpi_device_bus_id->node, &acpi_bus_id_list);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
ACPI: struct device - replace bus_id with dev_name(), dev_set_name()
This patch is part of a larger patch series which will remove
the "char bus_id[20]" name string from struct device. The device
name is managed in the kobject anyway, and without any size
limitation, and just needlessly copied into "struct device".
To set and read the device name dev_name(dev) and dev_set_name(dev)
must be used. If your code uses static kobjects, which it shouldn't
do, "const char *init_name" can be used to statically provide the
name the registered device should have. At registration time, the
init_name field is cleared, to enforce the use of dev_name(dev) to
access the device name at a later time.
We need to get rid of all occurrences of bus_id in the entire tree
to be able to enable the new interface. Please apply this patch,
and possibly convert any remaining remaining occurrences of bus_id.
We want to submit a patch to -next, which will remove bus_id from
"struct device", to find the remaining pieces to convert, and finally
switch over to the new api, which will remove the 20 bytes array
and does no longer have a size limitation.
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-Off-By: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-10-30 03:18:59 +03:00
|
|
|
dev_set_name(&device->dev, "%s:%02x", acpi_device_bus_id->bus_id, acpi_device_bus_id->instance_no);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2008-12-16 06:09:26 +03:00
|
|
|
if (device->parent)
|
2006-12-07 15:56:16 +03:00
|
|
|
list_add_tail(&device->node, &device->parent->children);
|
2008-12-16 06:09:26 +03:00
|
|
|
|
2006-12-07 15:56:16 +03:00
|
|
|
if (device->wakeup.flags.valid)
|
|
|
|
list_add_tail(&device->wakeup_list, &acpi_wakeup_device_list);
|
2009-04-07 06:24:29 +04:00
|
|
|
mutex_unlock(&acpi_device_lock);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2006-12-07 15:56:31 +03:00
|
|
|
if (device->parent)
|
2009-09-21 23:29:05 +04:00
|
|
|
device->dev.parent = &device->parent->dev;
|
2006-12-07 15:56:31 +03:00
|
|
|
device->dev.bus = &acpi_bus_type;
|
2013-01-17 17:11:05 +04:00
|
|
|
device->dev.release = release;
|
2013-01-24 15:49:49 +04:00
|
|
|
result = device_add(&device->dev);
|
2009-05-14 18:31:37 +04:00
|
|
|
if (result) {
|
2009-05-14 18:31:32 +04:00
|
|
|
dev_err(&device->dev, "Error registering device\n");
|
2013-01-17 17:11:05 +04:00
|
|
|
goto err;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
result = acpi_device_setup_files(device);
|
2009-05-14 18:31:37 +04:00
|
|
|
if (result)
|
ACPI: struct device - replace bus_id with dev_name(), dev_set_name()
This patch is part of a larger patch series which will remove
the "char bus_id[20]" name string from struct device. The device
name is managed in the kobject anyway, and without any size
limitation, and just needlessly copied into "struct device".
To set and read the device name dev_name(dev) and dev_set_name(dev)
must be used. If your code uses static kobjects, which it shouldn't
do, "const char *init_name" can be used to statically provide the
name the registered device should have. At registration time, the
init_name field is cleared, to enforce the use of dev_name(dev) to
access the device name at a later time.
We need to get rid of all occurrences of bus_id in the entire tree
to be able to enable the new interface. Please apply this patch,
and possibly convert any remaining remaining occurrences of bus_id.
We want to submit a patch to -next, which will remove bus_id from
"struct device", to find the remaining pieces to convert, and finally
switch over to the new api, which will remove the 20 bytes array
and does no longer have a size limitation.
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-Off-By: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-10-30 03:18:59 +03:00
|
|
|
printk(KERN_ERR PREFIX "Error creating sysfs interface for device %s\n",
|
|
|
|
dev_name(&device->dev));
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
return 0;
|
2013-01-17 17:11:05 +04:00
|
|
|
|
|
|
|
err:
|
2009-04-07 06:24:29 +04:00
|
|
|
mutex_lock(&acpi_device_lock);
|
2008-12-16 06:09:26 +03:00
|
|
|
if (device->parent)
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
list_del(&device->node);
|
|
|
|
list_del(&device->wakeup_list);
|
2009-04-07 06:24:29 +04:00
|
|
|
mutex_unlock(&acpi_device_lock);
|
2013-01-17 17:11:05 +04:00
|
|
|
|
|
|
|
err_detach:
|
|
|
|
acpi_detach_data(device->handle, acpi_bus_data_handler);
|
ACPI: use PNPID:instance_no as bus_id of ACPI device
Previously we used the device name in the DSDT, but would
crash upon encountering a duplicate. Also, exposing the
DSDT device name to the user in a patch isn't a good idea,
because it is arbitrary.
After some discussion, we finally decided to use
"PNPID:instance_no" as the bus_id of ACPI devices.
Two attributes for each device are added at the same time,
the full pathname in ACPI namespace and hardware_id if it has.
NOTE: acpi_bus_id_list is used to keep the information of PNPID
and instance number of the given PNPID. Loop the
acpi_bus_id_list to find the instance_no of the same PNPID
when register a device. If failed, i.e. we don't have a
node with this PNPID, allocate one and link it to this list.
NOTE: Now I don't take the memory free work in charge.
If necessary, I can add a reference count in
struct acpi_device_bus_id, and check the reference and
when unregister a device, i.e. memory is freed when
the reference count of a given PNPID is 0.
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-12-08 12:23:43 +03:00
|
|
|
return result;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2013-01-15 16:23:44 +04:00
|
|
|
static void acpi_device_unregister(struct acpi_device *device)
|
2006-12-07 15:56:16 +03:00
|
|
|
{
|
2009-04-07 06:24:29 +04:00
|
|
|
mutex_lock(&acpi_device_lock);
|
2008-12-16 06:09:26 +03:00
|
|
|
if (device->parent)
|
2006-12-07 15:56:16 +03:00
|
|
|
list_del(&device->node);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2006-12-07 15:56:16 +03:00
|
|
|
list_del(&device->wakeup_list);
|
2009-04-07 06:24:29 +04:00
|
|
|
mutex_unlock(&acpi_device_lock);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2006-12-07 15:56:16 +03:00
|
|
|
acpi_detach_data(device->handle, acpi_bus_data_handler);
|
2006-12-07 15:56:31 +03: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
|
|
|
acpi_power_add_remove_device(device, false);
|
2006-12-07 15:56:38 +03:00
|
|
|
acpi_device_remove_files(device);
|
2013-01-24 15:50:09 +04:00
|
|
|
if (device->remove)
|
|
|
|
device->remove(device);
|
|
|
|
|
2013-01-24 15:49:49 +04:00
|
|
|
device_del(&device->dev);
|
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-02-09 18:29:20 +04:00
|
|
|
* Transition the device to D3cold to drop the reference counts of all
|
|
|
|
* power resources the device depends on and turn off the ones that have
|
|
|
|
* no more references.
|
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-02-09 18:29:20 +04:00
|
|
|
acpi_device_set_power(device, ACPI_STATE_D3_COLD);
|
ACPI / hotplug: Fix concurrency issues and memory leaks
This changeset is aimed at fixing a few different but related
problems in the ACPI hotplug infrastructure.
First of all, since notify handlers may be run in parallel with
acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
and some of them are installed for ACPI handles that have no struct
acpi_device objects attached (i.e. before those objects are created),
those notify handlers have to take acpi_scan_lock to prevent races
from taking place (e.g. a struct acpi_device is found to be present
for the given ACPI handle, but right after that it is removed by
acpi_bus_trim() running in parallel to the given notify handler).
Moreover, since some of them call acpi_bus_scan() and
acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
should be acquired by the callers of these two funtions rather by
these functions themselves.
For these reasons, make all notify handlers that can handle device
addition and eject events take acpi_scan_lock and remove the
acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
Accordingly, update all of their users to make sure that they
are always called under acpi_scan_lock.
Furthermore, since eject operations are carried out asynchronously
with respect to the notify events that trigger them, with the help
of acpi_bus_hot_remove_device(), even if notify handlers take the
ACPI scan lock, it still is possible that, for example,
acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
the notify handler that scheduled its execution and that
acpi_bus_trim() will remove the device node passed to
acpi_bus_hot_remove_device() for ejection. In that case, the struct
acpi_device object obtained by acpi_bus_hot_remove_device() will be
invalid and not-so-funny things will ensue. To protect agaist that,
make the users of acpi_bus_hot_remove_device() run get_device() on
ACPI device node objects that are about to be passed to it and make
acpi_bus_hot_remove_device() run put_device() on them and check if
their ACPI handles are not NULL (make acpi_device_unregister() clear
the device nodes' ACPI handles for that check to work).
Finally, observe that acpi_os_hotplug_execute() actually can fail,
in which case its caller ought to free memory allocated for the
context object to prevent leaks from happening. It also needs to
run put_device() on the device node that it ran get_device() on
previously in that case. Modify the code accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
2013-02-13 17:36:47 +04:00
|
|
|
device->handle = NULL;
|
2013-01-24 15:49:49 +04:00
|
|
|
put_device(&device->dev);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2006-12-07 15:56:16 +03:00
|
|
|
/* --------------------------------------------------------------------------
|
|
|
|
Driver Management
|
|
|
|
-------------------------------------------------------------------------- */
|
|
|
|
/**
|
|
|
|
* acpi_bus_register_driver - register a driver with the ACPI bus
|
|
|
|
* @driver: driver being registered
|
|
|
|
*
|
|
|
|
* Registers a driver with the ACPI bus. Searches the namespace for all
|
|
|
|
* devices that match the driver's criteria and binds. Returns zero for
|
|
|
|
* success or a negative error status for failure.
|
|
|
|
*/
|
|
|
|
int acpi_bus_register_driver(struct acpi_driver *driver)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2006-12-07 15:56:31 +03:00
|
|
|
int ret;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2006-12-07 15:56:16 +03:00
|
|
|
if (acpi_disabled)
|
|
|
|
return -ENODEV;
|
2006-12-07 15:56:31 +03:00
|
|
|
driver->drv.name = driver->name;
|
|
|
|
driver->drv.bus = &acpi_bus_type;
|
|
|
|
driver->drv.owner = driver->owner;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2006-12-07 15:56:31 +03:00
|
|
|
ret = driver_register(&driver->drv);
|
|
|
|
return ret;
|
2006-12-07 15:56:16 +03:00
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2006-12-07 15:56:16 +03:00
|
|
|
EXPORT_SYMBOL(acpi_bus_register_driver);
|
|
|
|
|
|
|
|
/**
|
2013-09-22 11:42:41 +04:00
|
|
|
* acpi_bus_unregister_driver - unregisters a driver with the ACPI bus
|
2006-12-07 15:56:16 +03:00
|
|
|
* @driver: driver to unregister
|
|
|
|
*
|
|
|
|
* Unregisters a driver with the ACPI bus. Searches the namespace for all
|
|
|
|
* devices that match the driver's criteria and unbinds.
|
|
|
|
*/
|
|
|
|
void acpi_bus_unregister_driver(struct acpi_driver *driver)
|
|
|
|
{
|
2006-12-07 15:56:31 +03:00
|
|
|
driver_unregister(&driver->drv);
|
2006-12-07 15:56:16 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
EXPORT_SYMBOL(acpi_bus_unregister_driver);
|
|
|
|
|
|
|
|
/* --------------------------------------------------------------------------
|
|
|
|
Device Enumeration
|
|
|
|
-------------------------------------------------------------------------- */
|
2009-09-21 23:29:35 +04:00
|
|
|
static struct acpi_device *acpi_bus_get_parent(acpi_handle handle)
|
|
|
|
{
|
2013-01-31 23:57:40 +04:00
|
|
|
struct acpi_device *device = NULL;
|
2009-09-21 23:29:35 +04:00
|
|
|
acpi_status status;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Fixed hardware devices do not appear in the namespace and do not
|
|
|
|
* have handles, but we fabricate acpi_devices for them, so we have
|
|
|
|
* to deal with them specially.
|
|
|
|
*/
|
2013-01-31 23:57:40 +04:00
|
|
|
if (!handle)
|
2009-09-21 23:29:35 +04:00
|
|
|
return acpi_root;
|
|
|
|
|
|
|
|
do {
|
|
|
|
status = acpi_get_parent(handle, &handle);
|
|
|
|
if (ACPI_FAILURE(status))
|
2013-01-31 23:57:40 +04:00
|
|
|
return status == AE_NULL_ENTRY ? NULL : acpi_root;
|
|
|
|
} while (acpi_bus_get_device(handle, &device));
|
|
|
|
return device;
|
2009-09-21 23:29:35 +04:00
|
|
|
}
|
|
|
|
|
2006-12-07 15:56:16 +03:00
|
|
|
acpi_status
|
|
|
|
acpi_bus_get_ejd(acpi_handle handle, acpi_handle *ejd)
|
|
|
|
{
|
|
|
|
acpi_status status;
|
|
|
|
acpi_handle tmp;
|
|
|
|
struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};
|
|
|
|
union acpi_object *obj;
|
|
|
|
|
|
|
|
status = acpi_get_handle(handle, "_EJD", &tmp);
|
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
return status;
|
|
|
|
|
|
|
|
status = acpi_evaluate_object(handle, "_EJD", NULL, &buffer);
|
|
|
|
if (ACPI_SUCCESS(status)) {
|
|
|
|
obj = buffer.pointer;
|
2008-02-14 15:40:34 +03:00
|
|
|
status = acpi_get_handle(ACPI_ROOT_OBJECT, obj->string.pointer,
|
|
|
|
ejd);
|
2006-12-07 15:56:16 +03:00
|
|
|
kfree(buffer.pointer);
|
|
|
|
}
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_bus_get_ejd);
|
|
|
|
|
2013-01-17 17:11:07 +04:00
|
|
|
static int acpi_bus_extract_wakeup_device_power_package(acpi_handle handle,
|
|
|
|
struct acpi_device_wakeup *wakeup)
|
2006-12-07 15:56:16 +03:00
|
|
|
{
|
2010-12-18 00:34:01 +03:00
|
|
|
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
|
|
|
|
union acpi_object *package = NULL;
|
2006-12-07 15:56:16 +03:00
|
|
|
union acpi_object *element = NULL;
|
2010-12-18 00:34:01 +03:00
|
|
|
acpi_status status;
|
2013-01-17 17:11:07 +04:00
|
|
|
int err = -ENODATA;
|
2006-12-07 15:56:16 +03:00
|
|
|
|
2010-12-18 00:34:01 +03:00
|
|
|
if (!wakeup)
|
2013-01-17 17:11:07 +04:00
|
|
|
return -EINVAL;
|
2006-12-07 15:56:16 +03:00
|
|
|
|
2013-01-17 17:11:06 +04:00
|
|
|
INIT_LIST_HEAD(&wakeup->resources);
|
2006-12-07 15:56:16 +03:00
|
|
|
|
2010-12-18 00:34:01 +03:00
|
|
|
/* _PRW */
|
|
|
|
status = acpi_evaluate_object(handle, "_PRW", NULL, &buffer);
|
|
|
|
if (ACPI_FAILURE(status)) {
|
|
|
|
ACPI_EXCEPTION((AE_INFO, status, "Evaluating _PRW"));
|
2013-01-17 17:11:07 +04:00
|
|
|
return err;
|
2010-12-18 00:34:01 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
package = (union acpi_object *)buffer.pointer;
|
|
|
|
|
2013-01-17 17:11:07 +04:00
|
|
|
if (!package || package->package.count < 2)
|
2010-12-18 00:34:01 +03:00
|
|
|
goto out;
|
|
|
|
|
2006-12-07 15:56:16 +03:00
|
|
|
element = &(package->package.elements[0]);
|
2013-01-17 17:11:07 +04:00
|
|
|
if (!element)
|
2010-12-18 00:34:01 +03:00
|
|
|
goto out;
|
2013-01-17 17:11:07 +04:00
|
|
|
|
2006-12-07 15:56:16 +03:00
|
|
|
if (element->type == ACPI_TYPE_PACKAGE) {
|
|
|
|
if ((element->package.count < 2) ||
|
|
|
|
(element->package.elements[0].type !=
|
|
|
|
ACPI_TYPE_LOCAL_REFERENCE)
|
2013-01-17 17:11:07 +04:00
|
|
|
|| (element->package.elements[1].type != ACPI_TYPE_INTEGER))
|
2010-12-18 00:34:01 +03:00
|
|
|
goto out;
|
2013-01-17 17:11:07 +04:00
|
|
|
|
2010-12-18 00:34:01 +03:00
|
|
|
wakeup->gpe_device =
|
2006-12-07 15:56:16 +03:00
|
|
|
element->package.elements[0].reference.handle;
|
2010-12-18 00:34:01 +03:00
|
|
|
wakeup->gpe_number =
|
2006-12-07 15:56:16 +03:00
|
|
|
(u32) element->package.elements[1].integer.value;
|
|
|
|
} else if (element->type == ACPI_TYPE_INTEGER) {
|
2010-12-18 00:34:01 +03:00
|
|
|
wakeup->gpe_device = NULL;
|
|
|
|
wakeup->gpe_number = element->integer.value;
|
|
|
|
} else {
|
|
|
|
goto out;
|
|
|
|
}
|
2006-12-07 15:56:16 +03:00
|
|
|
|
|
|
|
element = &(package->package.elements[1]);
|
2013-01-17 17:11:07 +04:00
|
|
|
if (element->type != ACPI_TYPE_INTEGER)
|
2010-12-18 00:34:01 +03:00
|
|
|
goto out;
|
2013-01-17 17:11:07 +04:00
|
|
|
|
2010-12-18 00:34:01 +03:00
|
|
|
wakeup->sleep_state = element->integer.value;
|
2006-12-07 15:56:16 +03:00
|
|
|
|
2013-01-17 17:11:07 +04:00
|
|
|
err = acpi_extract_power_resources(package, 2, &wakeup->resources);
|
|
|
|
if (err)
|
2010-12-18 00:34:01 +03:00
|
|
|
goto out;
|
2006-12-07 15:56:16 +03:00
|
|
|
|
2013-01-17 17:11:07 +04:00
|
|
|
if (!list_empty(&wakeup->resources)) {
|
|
|
|
int sleep_state;
|
2006-12-07 15:56:16 +03: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
|
|
|
err = acpi_power_wakeup_list_init(&wakeup->resources,
|
|
|
|
&sleep_state);
|
|
|
|
if (err) {
|
|
|
|
acpi_handle_warn(handle, "Retrieving current states "
|
|
|
|
"of wakeup power resources failed\n");
|
|
|
|
acpi_power_resources_list_free(&wakeup->resources);
|
|
|
|
goto out;
|
|
|
|
}
|
2013-01-17 17:11:07 +04:00
|
|
|
if (sleep_state < wakeup->sleep_state) {
|
|
|
|
acpi_handle_warn(handle, "Overriding _PRW sleep state "
|
|
|
|
"(S%d) by S%d from power resources\n",
|
|
|
|
(int)wakeup->sleep_state, sleep_state);
|
|
|
|
wakeup->sleep_state = sleep_state;
|
|
|
|
}
|
|
|
|
}
|
2010-12-13 08:39:17 +03:00
|
|
|
acpi_setup_gpe_for_wake(handle, wakeup->gpe_device, wakeup->gpe_number);
|
ACPI / ACPICA: Do not execute _PRW methods during initialization
Currently, during initialization ACPICA walks the entire ACPI
namespace in search of any device objects with assciated _PRW
methods. All of the _PRW methods found are executed in the process
to extract the GPE information returned by them, so that the GPEs in
question can be marked as "able to wakeup" (more precisely, the
ACPI_GPE_CAN_WAKE flag is set for them). The only purpose of this
exercise is to avoid enabling the CAN_WAKE GPEs automatically, even
if there are _Lxx/_Exx methods associated with them. However, it is
both costly and unnecessary, because the host OS has to execute the
_PRW methods anyway to check which devices can wake up the system
from sleep states. Moreover, it then uses full information
returned by _PRW, including the GPE information, so it can take care
of disabling the GPEs if necessary.
Remove the code that walks the namespace and executes _PRW from
ACPICA and modify comments to reflect that change. Make
acpi_bus_set_run_wake_flags() disable GPEs for wakeup devices
so that they don't cause spurious wakeup events to be signaled.
This not only reduces the complexity of the ACPICA initialization
code, but in some cases it should reduce the kernel boot time as
well.
Unfortunately, for this purpose we need a new ACPICA function,
acpi_gpe_can_wake(), to be called by the host OS in order to disable
the GPEs that can wake up the system and were previously enabled by
acpi_ev_initialize_gpe_block() or acpi_ev_update_gpes() (such a GPE
should be disabled only once, because the initialization code enables
it only once, but it may be pointed to by _PRW for multiple devices
and that's why the additional function is necessary).
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-07-08 02:43:36 +04:00
|
|
|
|
2010-12-18 00:34:01 +03:00
|
|
|
out:
|
|
|
|
kfree(buffer.pointer);
|
2013-01-17 17:11:07 +04:00
|
|
|
return err;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2010-02-18 01:41:49 +03:00
|
|
|
static void acpi_bus_set_run_wake_flags(struct acpi_device *device)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2007-07-23 16:43:51 +04:00
|
|
|
struct acpi_device_id button_device_ids[] = {
|
|
|
|
{"PNP0C0C", 0},
|
2012-12-05 02:23:16 +04:00
|
|
|
{"PNP0C0D", 0},
|
2007-07-23 16:43:51 +04:00
|
|
|
{"PNP0C0E", 0},
|
|
|
|
{"", 0},
|
|
|
|
};
|
2010-02-18 01:41:49 +03:00
|
|
|
acpi_status status;
|
|
|
|
acpi_event_status event_status;
|
|
|
|
|
2010-02-18 01:44:09 +03:00
|
|
|
device->wakeup.flags.notifier_present = 0;
|
2010-02-18 01:41:49 +03:00
|
|
|
|
|
|
|
/* Power button, Lid switch always enable wakeup */
|
|
|
|
if (!acpi_match_device_ids(device, button_device_ids)) {
|
|
|
|
device->wakeup.flags.run_wake = 1;
|
2012-12-05 02:23:16 +04:00
|
|
|
if (!acpi_match_device_ids(device, &button_device_ids[1])) {
|
|
|
|
/* Do not use Lid/sleep button for S5 wakeup */
|
|
|
|
if (device->wakeup.sleep_state == ACPI_STATE_S5)
|
|
|
|
device->wakeup.sleep_state = ACPI_STATE_S4;
|
|
|
|
}
|
2011-01-07 01:34:22 +03:00
|
|
|
device_set_wakeup_capable(&device->dev, true);
|
2010-02-18 01:41:49 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2010-07-08 02:42:51 +04:00
|
|
|
status = acpi_get_gpe_status(device->wakeup.gpe_device,
|
|
|
|
device->wakeup.gpe_number,
|
|
|
|
&event_status);
|
2010-02-18 01:41:49 +03:00
|
|
|
if (status == AE_OK)
|
|
|
|
device->wakeup.flags.run_wake =
|
|
|
|
!!(event_status & ACPI_EVENT_FLAG_HANDLE);
|
|
|
|
}
|
|
|
|
|
2011-01-07 01:41:27 +03:00
|
|
|
static void acpi_bus_get_wakeup_device_flags(struct acpi_device *device)
|
2010-02-18 01:41:49 +03:00
|
|
|
{
|
2013-01-17 17:11:07 +04:00
|
|
|
int err;
|
2007-07-23 16:43:51 +04:00
|
|
|
|
2011-01-07 01:41:27 +03:00
|
|
|
/* Presence of _PRW indicates wake capable */
|
2013-06-28 20:24:38 +04:00
|
|
|
if (!acpi_has_method(device->handle, "_PRW"))
|
2011-01-07 01:41:27 +03:00
|
|
|
return;
|
|
|
|
|
2013-01-17 17:11:07 +04:00
|
|
|
err = acpi_bus_extract_wakeup_device_power_package(device->handle,
|
|
|
|
&device->wakeup);
|
|
|
|
if (err) {
|
|
|
|
dev_err(&device->dev, "_PRW evaluation error: %d\n", err);
|
2011-01-07 01:41:27 +03:00
|
|
|
return;
|
2006-12-07 15:56:16 +03:00
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2006-12-07 15:56:16 +03:00
|
|
|
device->wakeup.flags.valid = 1;
|
2009-09-09 01:15:31 +04:00
|
|
|
device->wakeup.prepare_count = 0;
|
2010-02-18 01:41:49 +03:00
|
|
|
acpi_bus_set_run_wake_flags(device);
|
2008-03-19 08:26:54 +03:00
|
|
|
/* Call _PSW/_DSW object to disable its ability to wake the sleeping
|
|
|
|
* system for the ACPI device with the _PRW object.
|
|
|
|
* The _PSW object is depreciated in ACPI 3.0 and is replaced by _DSW.
|
|
|
|
* So it is necessary to call _DSW object first. Only when it is not
|
|
|
|
* present will the _PSW object used.
|
|
|
|
*/
|
2013-01-17 17:11:07 +04:00
|
|
|
err = acpi_device_sleep_wake(device, 0, 0, 0);
|
|
|
|
if (err)
|
2008-07-07 05:33:34 +04:00
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
|
|
|
|
"error in _DSW or _PSW evaluation\n"));
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2013-01-17 17:11:06 +04:00
|
|
|
static void acpi_bus_init_power_state(struct acpi_device *device, int state)
|
|
|
|
{
|
|
|
|
struct acpi_device_power_state *ps = &device->power.states[state];
|
2013-01-17 17:11:07 +04:00
|
|
|
char pathname[5] = { '_', 'P', 'R', '0' + state, '\0' };
|
|
|
|
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
|
2013-01-17 17:11:06 +04:00
|
|
|
acpi_status status;
|
2010-11-25 02:10:44 +03:00
|
|
|
|
2013-01-17 17:11:06 +04:00
|
|
|
INIT_LIST_HEAD(&ps->resources);
|
|
|
|
|
2013-01-17 17:11:07 +04:00
|
|
|
/* Evaluate "_PRx" to get referenced power resources */
|
|
|
|
status = acpi_evaluate_object(device->handle, pathname, NULL, &buffer);
|
|
|
|
if (ACPI_SUCCESS(status)) {
|
|
|
|
union acpi_object *package = buffer.pointer;
|
|
|
|
|
|
|
|
if (buffer.length && package
|
|
|
|
&& package->type == ACPI_TYPE_PACKAGE
|
|
|
|
&& package->package.count) {
|
2013-01-17 17:11:07 +04:00
|
|
|
int err = acpi_extract_power_resources(package, 0,
|
|
|
|
&ps->resources);
|
|
|
|
if (!err)
|
2013-01-17 17:11:07 +04:00
|
|
|
device->power.flags.power_resources = 1;
|
2013-01-17 17:11:06 +04:00
|
|
|
}
|
2013-01-17 17:11:07 +04:00
|
|
|
ACPI_FREE(buffer.pointer);
|
2013-01-17 17:11:06 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Evaluate "_PSx" to see if we can do explicit sets */
|
2013-01-17 17:11:07 +04:00
|
|
|
pathname[2] = 'S';
|
2013-06-28 20:24:38 +04:00
|
|
|
if (acpi_has_method(device->handle, pathname))
|
2013-01-17 17:11:06 +04:00
|
|
|
ps->flags.explicit_set = 1;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* State is valid if there are means to put the device into it.
|
|
|
|
* D3hot is only valid if _PR3 present.
|
|
|
|
*/
|
2013-01-17 17:11:07 +04:00
|
|
|
if (!list_empty(&ps->resources)
|
2013-01-17 17:11:06 +04:00
|
|
|
|| (ps->flags.explicit_set && state < ACPI_STATE_D3_HOT)) {
|
|
|
|
ps->flags.valid = 1;
|
|
|
|
ps->flags.os_accessible = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
ps->power = -1; /* Unknown - driver assigned */
|
|
|
|
ps->latency = -1; /* Unknown - driver assigned */
|
|
|
|
}
|
|
|
|
|
2013-01-17 17:11:05 +04:00
|
|
|
static void acpi_bus_get_power_flags(struct acpi_device *device)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2013-01-17 17:11:07 +04:00
|
|
|
u32 i;
|
2006-03-29 02:04:00 +04:00
|
|
|
|
2013-01-17 17:11:05 +04:00
|
|
|
/* Presence of _PS0|_PR0 indicates 'power manageable' */
|
2013-06-28 20:24:38 +04:00
|
|
|
if (!acpi_has_method(device->handle, "_PS0") &&
|
|
|
|
!acpi_has_method(device->handle, "_PR0"))
|
|
|
|
return;
|
2006-03-29 02:04:00 +04:00
|
|
|
|
2013-01-17 17:11:05 +04:00
|
|
|
device->flags.power_manageable = 1;
|
2005-08-05 08:44:28 +04:00
|
|
|
|
2006-12-07 15:56:16 +03:00
|
|
|
/*
|
|
|
|
* Power Management Flags
|
|
|
|
*/
|
2013-06-28 20:24:38 +04:00
|
|
|
if (acpi_has_method(device->handle, "_PSC"))
|
2006-12-07 15:56:16 +03:00
|
|
|
device->power.flags.explicit_get = 1;
|
2013-06-28 20:24:38 +04:00
|
|
|
if (acpi_has_method(device->handle, "_IRC"))
|
2006-12-07 15:56:16 +03:00
|
|
|
device->power.flags.inrush_current = 1;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2006-12-07 15:56:16 +03:00
|
|
|
/*
|
|
|
|
* Enumerate supported power management states
|
|
|
|
*/
|
2013-01-17 17:11:06 +04:00
|
|
|
for (i = ACPI_STATE_D0; i <= ACPI_STATE_D3_HOT; i++)
|
|
|
|
acpi_bus_init_power_state(device, i);
|
2010-11-25 02:10:44 +03:00
|
|
|
|
2013-01-17 17:11:06 +04:00
|
|
|
INIT_LIST_HEAD(&device->power.states[ACPI_STATE_D3_COLD].resources);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2006-12-07 15:56:16 +03:00
|
|
|
/* Set defaults for D0 and D3 states (always valid) */
|
|
|
|
device->power.states[ACPI_STATE_D0].flags.valid = 1;
|
|
|
|
device->power.states[ACPI_STATE_D0].power = 100;
|
2013-07-30 16:36:20 +04:00
|
|
|
device->power.states[ACPI_STATE_D3_COLD].flags.valid = 1;
|
|
|
|
device->power.states[ACPI_STATE_D3_COLD].power = 0;
|
2006-07-10 01:22:28 +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
|
|
|
/* Set D3cold's explicit_set flag if _PS3 exists. */
|
|
|
|
if (device->power.states[ACPI_STATE_D3_HOT].flags.explicit_set)
|
|
|
|
device->power.states[ACPI_STATE_D3_COLD].flags.explicit_set = 1;
|
|
|
|
|
2012-11-22 02:33:40 +04:00
|
|
|
/* Presence of _PS3 or _PRx means we can put the device into D3 cold */
|
|
|
|
if (device->power.states[ACPI_STATE_D3_HOT].flags.explicit_set ||
|
|
|
|
device->power.flags.power_resources)
|
|
|
|
device->power.states[ACPI_STATE_D3_COLD].flags.os_accessible = 1;
|
|
|
|
|
2013-02-02 02:43:02 +04:00
|
|
|
if (acpi_bus_init_power(device)) {
|
|
|
|
acpi_free_power_resources_lists(device);
|
|
|
|
device->flags.power_manageable = 0;
|
|
|
|
}
|
2006-12-07 15:56:16 +03:00
|
|
|
}
|
2006-07-10 01:22:28 +04:00
|
|
|
|
2013-01-17 17:11:05 +04:00
|
|
|
static void acpi_bus_get_flags(struct acpi_device *device)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
|
|
|
/* Presence of _STA indicates 'dynamic_status' */
|
2013-06-28 20:24:38 +04:00
|
|
|
if (acpi_has_method(device->handle, "_STA"))
|
2005-04-17 02:20:36 +04:00
|
|
|
device->flags.dynamic_status = 1;
|
|
|
|
|
|
|
|
/* Presence of _RMV indicates 'removable' */
|
2013-06-28 20:24:38 +04:00
|
|
|
if (acpi_has_method(device->handle, "_RMV"))
|
2005-04-17 02:20:36 +04:00
|
|
|
device->flags.removable = 1;
|
|
|
|
|
|
|
|
/* Presence of _EJD|_EJ0 indicates 'ejectable' */
|
2013-06-28 20:24:38 +04:00
|
|
|
if (acpi_has_method(device->handle, "_EJD") ||
|
|
|
|
acpi_has_method(device->handle, "_EJ0"))
|
2005-04-17 02:20:36 +04:00
|
|
|
device->flags.ejectable = 1;
|
|
|
|
}
|
|
|
|
|
2009-09-21 23:29:25 +04:00
|
|
|
static void acpi_device_get_busid(struct acpi_device *device)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2005-08-05 08:44:28 +04:00
|
|
|
char bus_id[5] = { '?', 0 };
|
|
|
|
struct acpi_buffer buffer = { sizeof(bus_id), bus_id };
|
|
|
|
int i = 0;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Bus ID
|
|
|
|
* ------
|
|
|
|
* The device's Bus ID is simply the object name.
|
|
|
|
* TBD: Shouldn't this value be unique (within the ACPI namespace)?
|
|
|
|
*/
|
2009-09-21 23:29:50 +04:00
|
|
|
if (ACPI_IS_ROOT_DEVICE(device)) {
|
2005-04-17 02:20:36 +04:00
|
|
|
strcpy(device->pnp.bus_id, "ACPI");
|
2009-09-21 23:29:50 +04:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (device->device_type) {
|
2005-04-17 02:20:36 +04:00
|
|
|
case ACPI_BUS_TYPE_POWER_BUTTON:
|
|
|
|
strcpy(device->pnp.bus_id, "PWRF");
|
|
|
|
break;
|
|
|
|
case ACPI_BUS_TYPE_SLEEP_BUTTON:
|
|
|
|
strcpy(device->pnp.bus_id, "SLPF");
|
|
|
|
break;
|
|
|
|
default:
|
2009-09-21 23:29:05 +04:00
|
|
|
acpi_get_name(device->handle, ACPI_SINGLE_NAME, &buffer);
|
2005-04-17 02:20:36 +04:00
|
|
|
/* Clean up trailing underscores (if any) */
|
|
|
|
for (i = 3; i > 1; i--) {
|
|
|
|
if (bus_id[i] == '_')
|
|
|
|
bus_id[i] = '\0';
|
|
|
|
else
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
strcpy(device->pnp.bus_id, bus_id);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-06-28 20:24:41 +04:00
|
|
|
/*
|
|
|
|
* acpi_ata_match - see if an acpi object is an ATA device
|
|
|
|
*
|
|
|
|
* If an acpi object has one of the ACPI ATA methods defined,
|
|
|
|
* then we can safely call it an ATA device.
|
|
|
|
*/
|
|
|
|
bool acpi_ata_match(acpi_handle handle)
|
|
|
|
{
|
|
|
|
return acpi_has_method(handle, "_GTF") ||
|
|
|
|
acpi_has_method(handle, "_GTM") ||
|
|
|
|
acpi_has_method(handle, "_STM") ||
|
|
|
|
acpi_has_method(handle, "_SDD");
|
|
|
|
}
|
|
|
|
|
2007-01-11 10:09:09 +03:00
|
|
|
/*
|
2013-03-05 01:30:41 +04:00
|
|
|
* acpi_bay_match - see if an acpi object is an ejectable driver bay
|
2007-01-11 10:09:09 +03:00
|
|
|
*
|
|
|
|
* If an acpi object is ejectable and has one of the ACPI ATA methods defined,
|
|
|
|
* then we can safely call it an ejectable drive bay
|
|
|
|
*/
|
2013-06-28 20:24:41 +04:00
|
|
|
bool acpi_bay_match(acpi_handle handle)
|
2013-03-05 01:30:41 +04:00
|
|
|
{
|
2007-01-11 10:09:09 +03:00
|
|
|
acpi_handle phandle;
|
|
|
|
|
2013-06-28 20:24:38 +04:00
|
|
|
if (!acpi_has_method(handle, "_EJ0"))
|
2013-06-28 20:24:41 +04:00
|
|
|
return false;
|
|
|
|
if (acpi_ata_match(handle))
|
|
|
|
return true;
|
|
|
|
if (ACPI_FAILURE(acpi_get_parent(handle, &phandle)))
|
|
|
|
return false;
|
2007-01-11 10:09:09 +03:00
|
|
|
|
2013-06-28 20:24:41 +04:00
|
|
|
return acpi_ata_match(phandle);
|
2007-01-11 10:09:09 +03:00
|
|
|
}
|
|
|
|
|
2007-12-07 15:20:34 +03:00
|
|
|
/*
|
2013-03-05 01:30:41 +04:00
|
|
|
* acpi_dock_match - see if an acpi object has a _DCK method
|
2007-12-07 15:20:34 +03:00
|
|
|
*/
|
2013-06-28 20:24:41 +04:00
|
|
|
bool acpi_dock_match(acpi_handle handle)
|
2007-12-07 15:20:34 +03:00
|
|
|
{
|
2013-06-28 20:24:41 +04:00
|
|
|
return acpi_has_method(handle, "_DCK");
|
2007-12-07 15:20:34 +03:00
|
|
|
}
|
|
|
|
|
2010-10-01 12:54:00 +04:00
|
|
|
const char *acpi_device_hid(struct acpi_device *device)
|
2009-06-29 09:39:29 +04:00
|
|
|
{
|
2009-09-21 23:35:19 +04:00
|
|
|
struct acpi_hardware_id *hid;
|
2009-06-29 09:39:29 +04:00
|
|
|
|
2010-10-01 12:53:59 +04:00
|
|
|
if (list_empty(&device->pnp.ids))
|
|
|
|
return dummy_hid;
|
|
|
|
|
2009-09-21 23:35:19 +04:00
|
|
|
hid = list_first_entry(&device->pnp.ids, struct acpi_hardware_id, list);
|
|
|
|
return hid->id;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(acpi_device_hid);
|
2009-06-29 09:39:29 +04:00
|
|
|
|
2013-03-05 01:30:41 +04:00
|
|
|
static void acpi_add_id(struct acpi_device_pnp *pnp, const char *dev_id)
|
2009-09-21 23:35:19 +04:00
|
|
|
{
|
|
|
|
struct acpi_hardware_id *id;
|
2009-06-29 09:39:29 +04:00
|
|
|
|
2009-09-21 23:35:19 +04:00
|
|
|
id = kmalloc(sizeof(*id), GFP_KERNEL);
|
|
|
|
if (!id)
|
|
|
|
return;
|
2009-06-29 09:39:29 +04:00
|
|
|
|
2011-08-06 13:32:56 +04:00
|
|
|
id->id = kstrdup(dev_id, GFP_KERNEL);
|
2009-09-21 23:35:19 +04:00
|
|
|
if (!id->id) {
|
|
|
|
kfree(id);
|
|
|
|
return;
|
2009-06-29 09:39:29 +04:00
|
|
|
}
|
|
|
|
|
2013-03-05 01:30:41 +04:00
|
|
|
list_add_tail(&id->list, &pnp->ids);
|
|
|
|
pnp->type.hardware_id = 1;
|
2009-06-29 09:39:29 +04:00
|
|
|
}
|
|
|
|
|
2010-03-24 16:38:37 +03:00
|
|
|
/*
|
|
|
|
* Old IBM workstations have a DSDT bug wherein the SMBus object
|
|
|
|
* lacks the SMBUS01 HID and the methods do not have the necessary "_"
|
|
|
|
* prefix. Work around this.
|
|
|
|
*/
|
2013-06-28 20:24:41 +04:00
|
|
|
static bool acpi_ibm_smbus_match(acpi_handle handle)
|
2010-03-24 16:38:37 +03:00
|
|
|
{
|
2013-06-28 20:24:41 +04:00
|
|
|
char node_name[ACPI_PATH_SEGMENT_LENGTH];
|
|
|
|
struct acpi_buffer path = { sizeof(node_name), node_name };
|
2010-03-24 16:38:37 +03:00
|
|
|
|
|
|
|
if (!dmi_name_in_vendors("IBM"))
|
2013-06-28 20:24:41 +04:00
|
|
|
return false;
|
2010-03-24 16:38:37 +03:00
|
|
|
|
|
|
|
/* Look for SMBS object */
|
2013-06-28 20:24:41 +04:00
|
|
|
if (ACPI_FAILURE(acpi_get_name(handle, ACPI_SINGLE_NAME, &path)) ||
|
|
|
|
strcmp("SMBS", path.pointer))
|
|
|
|
return false;
|
2010-03-24 16:38:37 +03:00
|
|
|
|
|
|
|
/* Does it have the necessary (but misnamed) methods? */
|
2013-06-28 20:24:38 +04:00
|
|
|
if (acpi_has_method(handle, "SBI") &&
|
|
|
|
acpi_has_method(handle, "SBR") &&
|
|
|
|
acpi_has_method(handle, "SBW"))
|
2013-06-28 20:24:41 +04:00
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
2010-03-24 16:38:37 +03:00
|
|
|
}
|
|
|
|
|
2013-03-05 01:30:42 +04:00
|
|
|
static void acpi_set_pnp_ids(acpi_handle handle, struct acpi_device_pnp *pnp,
|
|
|
|
int device_type)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2005-08-05 08:44:28 +04:00
|
|
|
acpi_status status;
|
2009-09-21 23:35:40 +04:00
|
|
|
struct acpi_device_info *info;
|
2012-10-31 06:25:24 +04:00
|
|
|
struct acpi_pnp_device_id_list *cid_list;
|
2009-09-21 23:35:19 +04:00
|
|
|
int i;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2013-03-05 01:30:42 +04:00
|
|
|
switch (device_type) {
|
2005-04-17 02:20:36 +04:00
|
|
|
case ACPI_BUS_TYPE_DEVICE:
|
2013-03-05 01:30:42 +04:00
|
|
|
if (handle == ACPI_ROOT_OBJECT) {
|
|
|
|
acpi_add_id(pnp, ACPI_SYSTEM_HID);
|
2009-09-21 23:29:50 +04:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2013-03-05 01:30:42 +04:00
|
|
|
status = acpi_get_object_info(handle, &info);
|
2005-04-17 02:20:36 +04:00
|
|
|
if (ACPI_FAILURE(status)) {
|
2013-03-05 01:30:42 +04:00
|
|
|
pr_err(PREFIX "%s: Error reading device info\n",
|
|
|
|
__func__);
|
2005-04-17 02:20:36 +04:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (info->valid & ACPI_VALID_HID)
|
2013-03-05 01:30:42 +04:00
|
|
|
acpi_add_id(pnp, info->hardware_id.string);
|
2009-09-21 23:35:40 +04:00
|
|
|
if (info->valid & ACPI_VALID_CID) {
|
2009-06-29 09:39:29 +04:00
|
|
|
cid_list = &info->compatible_id_list;
|
2009-09-21 23:35:40 +04:00
|
|
|
for (i = 0; i < cid_list->count; i++)
|
2013-03-05 01:30:42 +04:00
|
|
|
acpi_add_id(pnp, cid_list->ids[i].string);
|
2009-09-21 23:35:40 +04:00
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
if (info->valid & ACPI_VALID_ADR) {
|
2013-03-05 01:30:42 +04:00
|
|
|
pnp->bus_address = info->address;
|
|
|
|
pnp->type.bus_address = 1;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
2012-10-30 17:41:07 +04:00
|
|
|
if (info->valid & ACPI_VALID_UID)
|
2013-03-05 01:30:42 +04:00
|
|
|
pnp->unique_id = kstrdup(info->unique_id.string,
|
2012-10-30 17:41:07 +04:00
|
|
|
GFP_KERNEL);
|
2006-12-07 15:57:10 +03:00
|
|
|
|
2009-10-02 19:03:12 +04:00
|
|
|
kfree(info);
|
|
|
|
|
2009-09-21 23:35:40 +04:00
|
|
|
/*
|
|
|
|
* Some devices don't reliably have _HIDs & _CIDs, so add
|
|
|
|
* synthetic HIDs to make sure drivers can find them.
|
|
|
|
*/
|
2013-03-05 01:30:42 +04:00
|
|
|
if (acpi_is_video_device(handle))
|
|
|
|
acpi_add_id(pnp, ACPI_VIDEO_HID);
|
2013-06-28 20:24:41 +04:00
|
|
|
else if (acpi_bay_match(handle))
|
2013-03-05 01:30:42 +04:00
|
|
|
acpi_add_id(pnp, ACPI_BAY_HID);
|
2013-06-28 20:24:41 +04:00
|
|
|
else if (acpi_dock_match(handle))
|
2013-03-05 01:30:42 +04:00
|
|
|
acpi_add_id(pnp, ACPI_DOCK_HID);
|
2013-06-28 20:24:41 +04:00
|
|
|
else if (acpi_ibm_smbus_match(handle))
|
2013-03-05 01:30:42 +04:00
|
|
|
acpi_add_id(pnp, ACPI_SMBUS_IBM_HID);
|
|
|
|
else if (list_empty(&pnp->ids) && handle == ACPI_ROOT_OBJECT) {
|
|
|
|
acpi_add_id(pnp, ACPI_BUS_HID); /* \_SB, LNXSYBUS */
|
|
|
|
strcpy(pnp->device_name, ACPI_BUS_DEVICE_NAME);
|
|
|
|
strcpy(pnp->device_class, ACPI_BUS_CLASS);
|
2010-03-24 19:44:33 +03:00
|
|
|
}
|
2007-01-11 10:09:09 +03:00
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
break;
|
|
|
|
case ACPI_BUS_TYPE_POWER:
|
2013-03-05 01:30:42 +04:00
|
|
|
acpi_add_id(pnp, ACPI_POWER_HID);
|
2005-04-17 02:20:36 +04:00
|
|
|
break;
|
|
|
|
case ACPI_BUS_TYPE_PROCESSOR:
|
2013-03-05 01:30:42 +04:00
|
|
|
acpi_add_id(pnp, ACPI_PROCESSOR_OBJECT_HID);
|
2005-04-17 02:20:36 +04:00
|
|
|
break;
|
|
|
|
case ACPI_BUS_TYPE_THERMAL:
|
2013-03-05 01:30:42 +04:00
|
|
|
acpi_add_id(pnp, ACPI_THERMAL_HID);
|
2005-04-17 02:20:36 +04:00
|
|
|
break;
|
|
|
|
case ACPI_BUS_TYPE_POWER_BUTTON:
|
2013-03-05 01:30:42 +04:00
|
|
|
acpi_add_id(pnp, ACPI_BUTTON_HID_POWERF);
|
2005-04-17 02:20:36 +04:00
|
|
|
break;
|
|
|
|
case ACPI_BUS_TYPE_SLEEP_BUTTON:
|
2013-03-05 01:30:42 +04:00
|
|
|
acpi_add_id(pnp, ACPI_BUTTON_HID_SLEEPF);
|
2005-04-17 02:20:36 +04:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-03-05 01:30:42 +04:00
|
|
|
void acpi_free_pnp_ids(struct acpi_device_pnp *pnp)
|
|
|
|
{
|
|
|
|
struct acpi_hardware_id *id, *tmp;
|
|
|
|
|
|
|
|
list_for_each_entry_safe(id, tmp, &pnp->ids, list) {
|
|
|
|
kfree(id->id);
|
|
|
|
kfree(id);
|
|
|
|
}
|
|
|
|
kfree(pnp->unique_id);
|
|
|
|
}
|
|
|
|
|
2013-01-17 17:11:05 +04:00
|
|
|
void acpi_init_device_object(struct acpi_device *device, acpi_handle handle,
|
|
|
|
int type, unsigned long long sta)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2013-01-17 17:11:05 +04:00
|
|
|
INIT_LIST_HEAD(&device->pnp.ids);
|
|
|
|
device->device_type = type;
|
|
|
|
device->handle = handle;
|
|
|
|
device->parent = acpi_bus_get_parent(handle);
|
|
|
|
STRUCT_TO_INT(device->status) = sta;
|
|
|
|
acpi_device_get_busid(device);
|
2013-03-05 01:30:42 +04:00
|
|
|
acpi_set_pnp_ids(handle, &device->pnp, type);
|
2013-01-17 17:11:05 +04:00
|
|
|
acpi_bus_get_flags(device);
|
2013-01-29 16:57:20 +04:00
|
|
|
device->flags.match_driver = false;
|
2013-01-24 15:49:49 +04:00
|
|
|
device_initialize(&device->dev);
|
|
|
|
dev_set_uevent_suppress(&device->dev, true);
|
|
|
|
}
|
2009-09-21 23:29:20 +04:00
|
|
|
|
2013-01-24 15:49:49 +04:00
|
|
|
void acpi_device_add_finalize(struct acpi_device *device)
|
|
|
|
{
|
|
|
|
dev_set_uevent_suppress(&device->dev, false);
|
|
|
|
kobject_uevent(&device->dev.kobj, KOBJ_ADD);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2009-09-21 23:29:35 +04:00
|
|
|
static int acpi_add_single_object(struct acpi_device **child,
|
|
|
|
acpi_handle handle, int type,
|
2013-01-29 16:57:20 +04:00
|
|
|
unsigned long long sta)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2009-09-21 23:29:30 +04:00
|
|
|
int result;
|
|
|
|
struct acpi_device *device;
|
2009-09-21 23:28:54 +04:00
|
|
|
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2006-12-19 23:56:11 +03:00
|
|
|
device = kzalloc(sizeof(struct acpi_device), GFP_KERNEL);
|
2005-04-17 02:20:36 +04:00
|
|
|
if (!device) {
|
2006-06-27 07:41:38 +04:00
|
|
|
printk(KERN_ERR PREFIX "Memory allocation error\n");
|
2006-06-27 08:41:40 +04:00
|
|
|
return -ENOMEM;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2013-01-17 17:11:05 +04:00
|
|
|
acpi_init_device_object(device, handle, type, sta);
|
|
|
|
acpi_bus_get_power_flags(device);
|
2011-01-07 01:41:27 +03:00
|
|
|
acpi_bus_get_wakeup_device_flags(device);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2013-01-24 15:49:49 +04:00
|
|
|
result = acpi_device_add(device, acpi_device_release);
|
2013-01-17 17:11:05 +04:00
|
|
|
if (result) {
|
2009-08-07 03:18:12 +04:00
|
|
|
acpi_device_release(&device->dev);
|
2013-01-17 17:11:05 +04:00
|
|
|
return result;
|
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2013-01-17 17:11:05 +04:00
|
|
|
acpi_power_add_remove_device(device, true);
|
2013-01-24 15:49:49 +04:00
|
|
|
acpi_device_add_finalize(device);
|
2013-01-17 17:11:05 +04:00
|
|
|
acpi_get_name(handle, ACPI_FULL_PATHNAME, &buffer);
|
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Added %s [%s] parent %s\n",
|
|
|
|
dev_name(&device->dev), (char *) buffer.pointer,
|
|
|
|
device->parent ? dev_name(&device->parent->dev) : "(null)"));
|
|
|
|
kfree(buffer.pointer);
|
|
|
|
*child = device;
|
|
|
|
return 0;
|
2010-11-25 02:10:44 +03:00
|
|
|
}
|
|
|
|
|
2009-09-21 23:30:06 +04:00
|
|
|
static int acpi_bus_type_and_status(acpi_handle handle, int *type,
|
|
|
|
unsigned long long *sta)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2009-09-21 23:30:06 +04:00
|
|
|
acpi_status status;
|
|
|
|
acpi_object_type acpi_type;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2009-09-21 23:30:06 +04:00
|
|
|
status = acpi_get_type(handle, &acpi_type);
|
2009-09-21 23:29:56 +04:00
|
|
|
if (ACPI_FAILURE(status))
|
2009-09-21 23:30:06 +04:00
|
|
|
return -ENODEV;
|
2005-08-05 08:44:28 +04:00
|
|
|
|
2009-09-21 23:30:06 +04:00
|
|
|
switch (acpi_type) {
|
2009-09-21 23:29:56 +04:00
|
|
|
case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
|
|
|
|
case ACPI_TYPE_DEVICE:
|
2009-09-21 23:30:06 +04:00
|
|
|
*type = ACPI_BUS_TYPE_DEVICE;
|
|
|
|
status = acpi_bus_get_status_handle(handle, sta);
|
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
return -ENODEV;
|
2009-09-21 23:29:56 +04:00
|
|
|
break;
|
|
|
|
case ACPI_TYPE_PROCESSOR:
|
2009-09-21 23:30:06 +04:00
|
|
|
*type = ACPI_BUS_TYPE_PROCESSOR;
|
|
|
|
status = acpi_bus_get_status_handle(handle, sta);
|
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
return -ENODEV;
|
2009-09-21 23:29:56 +04:00
|
|
|
break;
|
|
|
|
case ACPI_TYPE_THERMAL:
|
2009-09-21 23:30:06 +04:00
|
|
|
*type = ACPI_BUS_TYPE_THERMAL;
|
|
|
|
*sta = ACPI_STA_DEFAULT;
|
2009-09-21 23:29:56 +04:00
|
|
|
break;
|
|
|
|
case ACPI_TYPE_POWER:
|
2009-09-21 23:30:06 +04:00
|
|
|
*type = ACPI_BUS_TYPE_POWER;
|
|
|
|
*sta = ACPI_STA_DEFAULT;
|
2009-09-21 23:29:56 +04:00
|
|
|
break;
|
|
|
|
default:
|
2009-09-21 23:30:06 +04:00
|
|
|
return -ENODEV;
|
2009-09-21 23:29:56 +04:00
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2009-09-21 23:30:06 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-03-04 02:06:21 +04:00
|
|
|
static bool acpi_scan_handler_matching(struct acpi_scan_handler *handler,
|
|
|
|
char *idstr,
|
|
|
|
const struct acpi_device_id **matchid)
|
|
|
|
{
|
|
|
|
const struct acpi_device_id *devid;
|
|
|
|
|
|
|
|
for (devid = handler->ids; devid->id[0]; devid++)
|
|
|
|
if (!strcmp((char *)devid->id, idstr)) {
|
|
|
|
if (matchid)
|
|
|
|
*matchid = devid;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2013-03-05 01:30:43 +04:00
|
|
|
static struct acpi_scan_handler *acpi_scan_match_handler(char *idstr,
|
|
|
|
const struct acpi_device_id **matchid)
|
|
|
|
{
|
|
|
|
struct acpi_scan_handler *handler;
|
|
|
|
|
|
|
|
list_for_each_entry(handler, &acpi_scan_handlers_list, list_node)
|
|
|
|
if (acpi_scan_handler_matching(handler, idstr, matchid))
|
|
|
|
return handler;
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2013-03-04 02:08:16 +04:00
|
|
|
void acpi_scan_hotplug_enabled(struct acpi_hotplug_profile *hotplug, bool val)
|
|
|
|
{
|
|
|
|
if (!!hotplug->enabled == !!val)
|
|
|
|
return;
|
|
|
|
|
|
|
|
mutex_lock(&acpi_scan_lock);
|
|
|
|
|
|
|
|
hotplug->enabled = val;
|
|
|
|
|
|
|
|
mutex_unlock(&acpi_scan_lock);
|
|
|
|
}
|
|
|
|
|
2013-03-05 01:30:43 +04:00
|
|
|
static void acpi_scan_init_hotplug(acpi_handle handle, int type)
|
2013-03-04 02:05:29 +04:00
|
|
|
{
|
2013-03-05 01:30:43 +04:00
|
|
|
struct acpi_device_pnp pnp = {};
|
|
|
|
struct acpi_hardware_id *hwid;
|
2013-03-04 02:05:29 +04:00
|
|
|
struct acpi_scan_handler *handler;
|
|
|
|
|
2013-03-05 01:30:43 +04:00
|
|
|
INIT_LIST_HEAD(&pnp.ids);
|
|
|
|
acpi_set_pnp_ids(handle, &pnp, type);
|
2013-03-04 02:05:29 +04:00
|
|
|
|
2013-03-05 01:30:43 +04:00
|
|
|
if (!pnp.type.hardware_id)
|
2013-05-15 20:49:35 +04:00
|
|
|
goto out;
|
2013-03-04 02:05:29 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* This relies on the fact that acpi_install_notify_handler() will not
|
|
|
|
* install the same notify handler routine twice for the same handle.
|
|
|
|
*/
|
2013-03-05 01:30:43 +04:00
|
|
|
list_for_each_entry(hwid, &pnp.ids, list) {
|
|
|
|
handler = acpi_scan_match_handler(hwid->id, NULL);
|
|
|
|
if (handler) {
|
2013-03-06 02:33:31 +04:00
|
|
|
acpi_install_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
|
|
|
|
acpi_hotplug_notify_cb, handler);
|
2013-03-05 01:30:43 +04:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-05-15 20:49:35 +04:00
|
|
|
out:
|
2013-03-05 01:30:43 +04:00
|
|
|
acpi_free_pnp_ids(&pnp);
|
2013-03-04 02:05:29 +04:00
|
|
|
}
|
|
|
|
|
2012-12-21 03:36:47 +04:00
|
|
|
static acpi_status acpi_bus_check_add(acpi_handle handle, u32 lvl_not_used,
|
|
|
|
void *not_used, void **return_value)
|
2009-09-21 23:30:06 +04:00
|
|
|
{
|
ACPI: Separate adding ACPI device objects from probing ACPI drivers
Split the ACPI namespace scanning for devices into two passes, such
that struct acpi_device objects are registerd in the first pass
without probing ACPI drivers and the drivers are probed against them
directly in the second pass.
There are two main reasons for doing that.
First, the ACPI PCI root bridge driver's .add() routine,
acpi_pci_root_add(), causes struct pci_dev objects to be created for
all PCI devices under the given root bridge. Usually, there are
corresponding ACPI device nodes in the ACPI namespace for some of
those devices and therefore there should be "companion" struct
acpi_device objects to attach those struct pci_dev objects to. These
struct acpi_device objects should exist when the corresponding
struct pci_dev objects are created, but that is only guaranteed
during boot and not during hotplug. This leads to a number of
functional differences between the boot and the hotplug cases which
are not strictly necessary and make the code more complicated.
For example, this forces the ACPI PCI root bridge driver to defer the
registration of the just created struct pci_dev objects and to use a
special .start() callback routine, acpi_pci_root_start(), to make
sure that all of the "companion" struct acpi_device objects will be
present at PCI devices registration time during hotplug.
If those differences can be eliminated, we will be able to
consolidate the boot and hotplug code paths for the enumeration and
registration of PCI devices and to reduce the complexity of that
code quite a bit.
The second reason is that, in general, it should be possible to
resolve conflicts of resources assigned by the BIOS to different
devices represented by ACPI namespace nodes before any drivers bind
to them and before they are attached to "companion" objects
representing physical devices (such as struct pci_dev). However, for
this purpose we first need to enumerate all ACPI device nodes in the
given namespace scope.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Toshi Kani <toshi.kani@hp.com>
2012-12-21 03:36:39 +04:00
|
|
|
struct acpi_device *device = NULL;
|
2009-09-21 23:30:06 +04:00
|
|
|
int type;
|
|
|
|
unsigned long long sta;
|
|
|
|
int result;
|
|
|
|
|
2012-12-21 03:36:44 +04:00
|
|
|
acpi_bus_get_device(handle, &device);
|
|
|
|
if (device)
|
|
|
|
goto out;
|
|
|
|
|
2009-09-21 23:30:06 +04:00
|
|
|
result = acpi_bus_type_and_status(handle, &type, &sta);
|
|
|
|
if (result)
|
|
|
|
return AE_OK;
|
|
|
|
|
2013-01-17 17:11:05 +04:00
|
|
|
if (type == ACPI_BUS_TYPE_POWER) {
|
|
|
|
acpi_add_power_resource(handle);
|
|
|
|
return AE_OK;
|
|
|
|
}
|
|
|
|
|
2013-03-05 01:30:43 +04:00
|
|
|
acpi_scan_init_hotplug(handle, type);
|
2013-03-04 02:05:29 +04:00
|
|
|
|
2009-09-21 23:30:06 +04:00
|
|
|
if (!(sta & ACPI_STA_DEVICE_PRESENT) &&
|
2010-12-18 00:34:01 +03:00
|
|
|
!(sta & ACPI_STA_DEVICE_FUNCTIONING)) {
|
2011-01-07 01:40:00 +03:00
|
|
|
struct acpi_device_wakeup wakeup;
|
|
|
|
|
2013-06-28 20:24:38 +04:00
|
|
|
if (acpi_has_method(handle, "_PRW")) {
|
2011-01-07 01:40:00 +03:00
|
|
|
acpi_bus_extract_wakeup_device_power_package(handle,
|
|
|
|
&wakeup);
|
2013-01-17 17:11:06 +04:00
|
|
|
acpi_power_resources_list_free(&wakeup.resources);
|
|
|
|
}
|
2009-09-21 23:30:06 +04:00
|
|
|
return AE_CTRL_DEPTH;
|
2010-12-18 00:34:01 +03:00
|
|
|
}
|
2009-09-21 23:30:06 +04:00
|
|
|
|
2013-01-29 16:57:20 +04:00
|
|
|
acpi_add_single_object(&device, handle, type, sta);
|
2009-09-21 23:30:11 +04:00
|
|
|
if (!device)
|
2009-09-21 23:29:56 +04:00
|
|
|
return AE_CTRL_DEPTH;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2012-12-21 03:36:44 +04:00
|
|
|
out:
|
2009-09-21 23:29:56 +04:00
|
|
|
if (!*return_value)
|
|
|
|
*return_value = device;
|
ACPI: Separate adding ACPI device objects from probing ACPI drivers
Split the ACPI namespace scanning for devices into two passes, such
that struct acpi_device objects are registerd in the first pass
without probing ACPI drivers and the drivers are probed against them
directly in the second pass.
There are two main reasons for doing that.
First, the ACPI PCI root bridge driver's .add() routine,
acpi_pci_root_add(), causes struct pci_dev objects to be created for
all PCI devices under the given root bridge. Usually, there are
corresponding ACPI device nodes in the ACPI namespace for some of
those devices and therefore there should be "companion" struct
acpi_device objects to attach those struct pci_dev objects to. These
struct acpi_device objects should exist when the corresponding
struct pci_dev objects are created, but that is only guaranteed
during boot and not during hotplug. This leads to a number of
functional differences between the boot and the hotplug cases which
are not strictly necessary and make the code more complicated.
For example, this forces the ACPI PCI root bridge driver to defer the
registration of the just created struct pci_dev objects and to use a
special .start() callback routine, acpi_pci_root_start(), to make
sure that all of the "companion" struct acpi_device objects will be
present at PCI devices registration time during hotplug.
If those differences can be eliminated, we will be able to
consolidate the boot and hotplug code paths for the enumeration and
registration of PCI devices and to reduce the complexity of that
code quite a bit.
The second reason is that, in general, it should be possible to
resolve conflicts of resources assigned by the BIOS to different
devices represented by ACPI namespace nodes before any drivers bind
to them and before they are attached to "companion" objects
representing physical devices (such as struct pci_dev). However, for
this purpose we first need to enumerate all ACPI device nodes in the
given namespace scope.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Toshi Kani <toshi.kani@hp.com>
2012-12-21 03:36:39 +04:00
|
|
|
|
2009-09-21 23:29:56 +04:00
|
|
|
return AE_OK;
|
|
|
|
}
|
2005-04-28 11:25:52 +04:00
|
|
|
|
2013-03-04 02:05:14 +04:00
|
|
|
static int acpi_scan_attach_handler(struct acpi_device *device)
|
2013-01-30 17:27:29 +04:00
|
|
|
{
|
2013-03-04 02:05:14 +04:00
|
|
|
struct acpi_hardware_id *hwid;
|
|
|
|
int ret = 0;
|
2013-01-30 17:27:29 +04:00
|
|
|
|
2013-03-04 02:05:14 +04:00
|
|
|
list_for_each_entry(hwid, &device->pnp.ids, list) {
|
2013-02-06 16:05:22 +04:00
|
|
|
const struct acpi_device_id *devid;
|
2013-03-04 02:05:14 +04:00
|
|
|
struct acpi_scan_handler *handler;
|
2013-01-30 17:27:29 +04:00
|
|
|
|
2013-03-04 02:05:14 +04:00
|
|
|
handler = acpi_scan_match_handler(hwid->id, &devid);
|
|
|
|
if (handler) {
|
2013-02-06 16:05:22 +04:00
|
|
|
ret = handler->attach(device, devid);
|
|
|
|
if (ret > 0) {
|
|
|
|
device->handler = handler;
|
2013-03-04 02:05:14 +04:00
|
|
|
break;
|
2013-02-06 16:05:22 +04:00
|
|
|
} else if (ret < 0) {
|
2013-03-04 02:05:14 +04:00
|
|
|
break;
|
2013-02-06 16:05:22 +04:00
|
|
|
}
|
2013-01-30 17:27:29 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-12-21 03:36:41 +04:00
|
|
|
static acpi_status acpi_bus_device_attach(acpi_handle handle, u32 lvl_not_used,
|
|
|
|
void *not_used, void **ret_not_used)
|
2009-09-21 23:29:56 +04:00
|
|
|
{
|
ACPI: Separate adding ACPI device objects from probing ACPI drivers
Split the ACPI namespace scanning for devices into two passes, such
that struct acpi_device objects are registerd in the first pass
without probing ACPI drivers and the drivers are probed against them
directly in the second pass.
There are two main reasons for doing that.
First, the ACPI PCI root bridge driver's .add() routine,
acpi_pci_root_add(), causes struct pci_dev objects to be created for
all PCI devices under the given root bridge. Usually, there are
corresponding ACPI device nodes in the ACPI namespace for some of
those devices and therefore there should be "companion" struct
acpi_device objects to attach those struct pci_dev objects to. These
struct acpi_device objects should exist when the corresponding
struct pci_dev objects are created, but that is only guaranteed
during boot and not during hotplug. This leads to a number of
functional differences between the boot and the hotplug cases which
are not strictly necessary and make the code more complicated.
For example, this forces the ACPI PCI root bridge driver to defer the
registration of the just created struct pci_dev objects and to use a
special .start() callback routine, acpi_pci_root_start(), to make
sure that all of the "companion" struct acpi_device objects will be
present at PCI devices registration time during hotplug.
If those differences can be eliminated, we will be able to
consolidate the boot and hotplug code paths for the enumeration and
registration of PCI devices and to reduce the complexity of that
code quite a bit.
The second reason is that, in general, it should be possible to
resolve conflicts of resources assigned by the BIOS to different
devices represented by ACPI namespace nodes before any drivers bind
to them and before they are attached to "companion" objects
representing physical devices (such as struct pci_dev). However, for
this purpose we first need to enumerate all ACPI device nodes in the
given namespace scope.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Toshi Kani <toshi.kani@hp.com>
2012-12-21 03:36:39 +04:00
|
|
|
struct acpi_device *device;
|
|
|
|
unsigned long long sta_not_used;
|
2013-01-30 17:27:29 +04:00
|
|
|
int ret;
|
2005-04-28 11:25:52 +04:00
|
|
|
|
ACPI: Separate adding ACPI device objects from probing ACPI drivers
Split the ACPI namespace scanning for devices into two passes, such
that struct acpi_device objects are registerd in the first pass
without probing ACPI drivers and the drivers are probed against them
directly in the second pass.
There are two main reasons for doing that.
First, the ACPI PCI root bridge driver's .add() routine,
acpi_pci_root_add(), causes struct pci_dev objects to be created for
all PCI devices under the given root bridge. Usually, there are
corresponding ACPI device nodes in the ACPI namespace for some of
those devices and therefore there should be "companion" struct
acpi_device objects to attach those struct pci_dev objects to. These
struct acpi_device objects should exist when the corresponding
struct pci_dev objects are created, but that is only guaranteed
during boot and not during hotplug. This leads to a number of
functional differences between the boot and the hotplug cases which
are not strictly necessary and make the code more complicated.
For example, this forces the ACPI PCI root bridge driver to defer the
registration of the just created struct pci_dev objects and to use a
special .start() callback routine, acpi_pci_root_start(), to make
sure that all of the "companion" struct acpi_device objects will be
present at PCI devices registration time during hotplug.
If those differences can be eliminated, we will be able to
consolidate the boot and hotplug code paths for the enumeration and
registration of PCI devices and to reduce the complexity of that
code quite a bit.
The second reason is that, in general, it should be possible to
resolve conflicts of resources assigned by the BIOS to different
devices represented by ACPI namespace nodes before any drivers bind
to them and before they are attached to "companion" objects
representing physical devices (such as struct pci_dev). However, for
this purpose we first need to enumerate all ACPI device nodes in the
given namespace scope.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Toshi Kani <toshi.kani@hp.com>
2012-12-21 03:36:39 +04:00
|
|
|
/*
|
|
|
|
* Ignore errors ignored by acpi_bus_check_add() to avoid terminating
|
|
|
|
* namespace walks prematurely.
|
|
|
|
*/
|
2013-01-30 17:27:29 +04:00
|
|
|
if (acpi_bus_type_and_status(handle, &ret, &sta_not_used))
|
ACPI: Separate adding ACPI device objects from probing ACPI drivers
Split the ACPI namespace scanning for devices into two passes, such
that struct acpi_device objects are registerd in the first pass
without probing ACPI drivers and the drivers are probed against them
directly in the second pass.
There are two main reasons for doing that.
First, the ACPI PCI root bridge driver's .add() routine,
acpi_pci_root_add(), causes struct pci_dev objects to be created for
all PCI devices under the given root bridge. Usually, there are
corresponding ACPI device nodes in the ACPI namespace for some of
those devices and therefore there should be "companion" struct
acpi_device objects to attach those struct pci_dev objects to. These
struct acpi_device objects should exist when the corresponding
struct pci_dev objects are created, but that is only guaranteed
during boot and not during hotplug. This leads to a number of
functional differences between the boot and the hotplug cases which
are not strictly necessary and make the code more complicated.
For example, this forces the ACPI PCI root bridge driver to defer the
registration of the just created struct pci_dev objects and to use a
special .start() callback routine, acpi_pci_root_start(), to make
sure that all of the "companion" struct acpi_device objects will be
present at PCI devices registration time during hotplug.
If those differences can be eliminated, we will be able to
consolidate the boot and hotplug code paths for the enumeration and
registration of PCI devices and to reduce the complexity of that
code quite a bit.
The second reason is that, in general, it should be possible to
resolve conflicts of resources assigned by the BIOS to different
devices represented by ACPI namespace nodes before any drivers bind
to them and before they are attached to "companion" objects
representing physical devices (such as struct pci_dev). However, for
this purpose we first need to enumerate all ACPI device nodes in the
given namespace scope.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Toshi Kani <toshi.kani@hp.com>
2012-12-21 03:36:39 +04:00
|
|
|
return AE_OK;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
ACPI: Separate adding ACPI device objects from probing ACPI drivers
Split the ACPI namespace scanning for devices into two passes, such
that struct acpi_device objects are registerd in the first pass
without probing ACPI drivers and the drivers are probed against them
directly in the second pass.
There are two main reasons for doing that.
First, the ACPI PCI root bridge driver's .add() routine,
acpi_pci_root_add(), causes struct pci_dev objects to be created for
all PCI devices under the given root bridge. Usually, there are
corresponding ACPI device nodes in the ACPI namespace for some of
those devices and therefore there should be "companion" struct
acpi_device objects to attach those struct pci_dev objects to. These
struct acpi_device objects should exist when the corresponding
struct pci_dev objects are created, but that is only guaranteed
during boot and not during hotplug. This leads to a number of
functional differences between the boot and the hotplug cases which
are not strictly necessary and make the code more complicated.
For example, this forces the ACPI PCI root bridge driver to defer the
registration of the just created struct pci_dev objects and to use a
special .start() callback routine, acpi_pci_root_start(), to make
sure that all of the "companion" struct acpi_device objects will be
present at PCI devices registration time during hotplug.
If those differences can be eliminated, we will be able to
consolidate the boot and hotplug code paths for the enumeration and
registration of PCI devices and to reduce the complexity of that
code quite a bit.
The second reason is that, in general, it should be possible to
resolve conflicts of resources assigned by the BIOS to different
devices represented by ACPI namespace nodes before any drivers bind
to them and before they are attached to "companion" objects
representing physical devices (such as struct pci_dev). However, for
this purpose we first need to enumerate all ACPI device nodes in the
given namespace scope.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Toshi Kani <toshi.kani@hp.com>
2012-12-21 03:36:39 +04:00
|
|
|
if (acpi_bus_get_device(handle, &device))
|
|
|
|
return AE_CTRL_DEPTH;
|
2010-01-29 19:48:52 +03:00
|
|
|
|
2013-07-12 15:45:59 +04:00
|
|
|
if (device->handler)
|
|
|
|
return AE_OK;
|
|
|
|
|
2013-01-30 17:27:29 +04:00
|
|
|
ret = acpi_scan_attach_handler(device);
|
2013-11-07 04:41:01 +04:00
|
|
|
if (ret < 0)
|
|
|
|
return AE_CTRL_DEPTH;
|
|
|
|
|
|
|
|
device->flags.match_driver = true;
|
|
|
|
if (ret > 0)
|
|
|
|
return AE_OK;
|
2013-01-30 17:27:29 +04:00
|
|
|
|
|
|
|
ret = device_attach(&device->dev);
|
|
|
|
return ret >= 0 ? AE_OK : AE_CTRL_DEPTH;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2012-12-21 03:36:47 +04:00
|
|
|
/**
|
2013-01-19 04:27:35 +04:00
|
|
|
* acpi_bus_scan - Add ACPI device node objects in a given namespace scope.
|
2012-12-21 03:36:47 +04:00
|
|
|
* @handle: Root of the namespace scope to scan.
|
2010-01-29 19:48:52 +03:00
|
|
|
*
|
2012-12-21 03:36:47 +04:00
|
|
|
* Scan a given ACPI tree (probably recently hot-plugged) and create and add
|
|
|
|
* found devices.
|
2010-01-29 19:48:52 +03:00
|
|
|
*
|
2012-12-21 03:36:47 +04:00
|
|
|
* If no devices were found, -ENODEV is returned, but it does not mean that
|
|
|
|
* there has been a real error. There just have been no suitable ACPI objects
|
|
|
|
* in the table trunk from which the kernel could create a device and add an
|
|
|
|
* appropriate driver.
|
ACPI / hotplug: Fix concurrency issues and memory leaks
This changeset is aimed at fixing a few different but related
problems in the ACPI hotplug infrastructure.
First of all, since notify handlers may be run in parallel with
acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
and some of them are installed for ACPI handles that have no struct
acpi_device objects attached (i.e. before those objects are created),
those notify handlers have to take acpi_scan_lock to prevent races
from taking place (e.g. a struct acpi_device is found to be present
for the given ACPI handle, but right after that it is removed by
acpi_bus_trim() running in parallel to the given notify handler).
Moreover, since some of them call acpi_bus_scan() and
acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
should be acquired by the callers of these two funtions rather by
these functions themselves.
For these reasons, make all notify handlers that can handle device
addition and eject events take acpi_scan_lock and remove the
acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
Accordingly, update all of their users to make sure that they
are always called under acpi_scan_lock.
Furthermore, since eject operations are carried out asynchronously
with respect to the notify events that trigger them, with the help
of acpi_bus_hot_remove_device(), even if notify handlers take the
ACPI scan lock, it still is possible that, for example,
acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
the notify handler that scheduled its execution and that
acpi_bus_trim() will remove the device node passed to
acpi_bus_hot_remove_device() for ejection. In that case, the struct
acpi_device object obtained by acpi_bus_hot_remove_device() will be
invalid and not-so-funny things will ensue. To protect agaist that,
make the users of acpi_bus_hot_remove_device() run get_device() on
ACPI device node objects that are about to be passed to it and make
acpi_bus_hot_remove_device() run put_device() on them and check if
their ACPI handles are not NULL (make acpi_device_unregister() clear
the device nodes' ACPI handles for that check to work).
Finally, observe that acpi_os_hotplug_execute() actually can fail,
in which case its caller ought to free memory allocated for the
context object to prevent leaks from happening. It also needs to
run put_device() on the device node that it ran get_device() on
previously in that case. Modify the code accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
2013-02-13 17:36:47 +04:00
|
|
|
*
|
|
|
|
* Must be called under acpi_scan_lock.
|
2010-01-29 19:48:52 +03:00
|
|
|
*/
|
2013-01-19 04:27:35 +04:00
|
|
|
int acpi_bus_scan(acpi_handle handle)
|
2005-04-28 11:25:52 +04:00
|
|
|
{
|
2013-01-19 04:27:35 +04:00
|
|
|
void *device = NULL;
|
2013-01-28 00:17:29 +04:00
|
|
|
int error = 0;
|
2005-04-28 11:25:52 +04:00
|
|
|
|
2013-01-19 04:27:35 +04:00
|
|
|
if (ACPI_SUCCESS(acpi_bus_check_add(handle, 0, NULL, &device)))
|
|
|
|
acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
|
|
|
|
acpi_bus_check_add, NULL, NULL, &device);
|
2005-04-28 11:25:52 +04:00
|
|
|
|
2010-01-29 19:48:51 +03:00
|
|
|
if (!device)
|
2013-01-28 00:17:29 +04:00
|
|
|
error = -ENODEV;
|
|
|
|
else if (ACPI_SUCCESS(acpi_bus_device_attach(handle, 0, NULL, NULL)))
|
2013-01-19 04:27:35 +04:00
|
|
|
acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
|
|
|
|
acpi_bus_device_attach, NULL, NULL, NULL);
|
2005-04-28 11:25:52 +04:00
|
|
|
|
2013-01-28 00:17:29 +04:00
|
|
|
return error;
|
2005-04-28 11:25:52 +04:00
|
|
|
}
|
2013-01-19 04:27:35 +04:00
|
|
|
EXPORT_SYMBOL(acpi_bus_scan);
|
2010-09-16 02:30:43 +04:00
|
|
|
|
2013-01-15 16:24:13 +04:00
|
|
|
static acpi_status acpi_bus_device_detach(acpi_handle handle, u32 lvl_not_used,
|
|
|
|
void *not_used, void **ret_not_used)
|
|
|
|
{
|
|
|
|
struct acpi_device *device = NULL;
|
2010-09-16 02:30:43 +04:00
|
|
|
|
2013-01-15 16:24:13 +04:00
|
|
|
if (!acpi_bus_get_device(handle, &device)) {
|
2013-01-30 17:27:29 +04:00
|
|
|
struct acpi_scan_handler *dev_handler = device->handler;
|
|
|
|
|
|
|
|
if (dev_handler) {
|
|
|
|
if (dev_handler->detach)
|
|
|
|
dev_handler->detach(device);
|
|
|
|
|
|
|
|
device->handler = NULL;
|
|
|
|
} else {
|
|
|
|
device_release_driver(&device->dev);
|
|
|
|
}
|
2013-01-15 16:24:13 +04:00
|
|
|
}
|
|
|
|
return AE_OK;
|
2005-04-28 11:25:52 +04:00
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2013-01-15 16:24:13 +04:00
|
|
|
static acpi_status acpi_bus_remove(acpi_handle handle, u32 lvl_not_used,
|
|
|
|
void *not_used, void **ret_not_used)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2013-01-15 16:24:13 +04:00
|
|
|
struct acpi_device *device = NULL;
|
2005-08-05 08:44:28 +04:00
|
|
|
|
2013-01-15 16:24:13 +04:00
|
|
|
if (!acpi_bus_get_device(handle, &device))
|
|
|
|
acpi_device_unregister(device);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2013-01-15 16:24:13 +04:00
|
|
|
return AE_OK;
|
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
ACPI / hotplug: Fix concurrency issues and memory leaks
This changeset is aimed at fixing a few different but related
problems in the ACPI hotplug infrastructure.
First of all, since notify handlers may be run in parallel with
acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
and some of them are installed for ACPI handles that have no struct
acpi_device objects attached (i.e. before those objects are created),
those notify handlers have to take acpi_scan_lock to prevent races
from taking place (e.g. a struct acpi_device is found to be present
for the given ACPI handle, but right after that it is removed by
acpi_bus_trim() running in parallel to the given notify handler).
Moreover, since some of them call acpi_bus_scan() and
acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
should be acquired by the callers of these two funtions rather by
these functions themselves.
For these reasons, make all notify handlers that can handle device
addition and eject events take acpi_scan_lock and remove the
acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
Accordingly, update all of their users to make sure that they
are always called under acpi_scan_lock.
Furthermore, since eject operations are carried out asynchronously
with respect to the notify events that trigger them, with the help
of acpi_bus_hot_remove_device(), even if notify handlers take the
ACPI scan lock, it still is possible that, for example,
acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
the notify handler that scheduled its execution and that
acpi_bus_trim() will remove the device node passed to
acpi_bus_hot_remove_device() for ejection. In that case, the struct
acpi_device object obtained by acpi_bus_hot_remove_device() will be
invalid and not-so-funny things will ensue. To protect agaist that,
make the users of acpi_bus_hot_remove_device() run get_device() on
ACPI device node objects that are about to be passed to it and make
acpi_bus_hot_remove_device() run put_device() on them and check if
their ACPI handles are not NULL (make acpi_device_unregister() clear
the device nodes' ACPI handles for that check to work).
Finally, observe that acpi_os_hotplug_execute() actually can fail,
in which case its caller ought to free memory allocated for the
context object to prevent leaks from happening. It also needs to
run put_device() on the device node that it ran get_device() on
previously in that case. Modify the code accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
2013-02-13 17:36:47 +04:00
|
|
|
/**
|
|
|
|
* acpi_bus_trim - Remove ACPI device node and all of its descendants
|
|
|
|
* @start: Root of the ACPI device nodes subtree to remove.
|
|
|
|
*
|
|
|
|
* Must be called under acpi_scan_lock.
|
|
|
|
*/
|
2013-01-26 03:27:44 +04:00
|
|
|
void acpi_bus_trim(struct acpi_device *start)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2013-01-15 16:24:13 +04:00
|
|
|
/*
|
|
|
|
* Execute acpi_bus_device_detach() as a post-order callback to detach
|
|
|
|
* all ACPI drivers from the device nodes being removed.
|
|
|
|
*/
|
|
|
|
acpi_walk_namespace(ACPI_TYPE_ANY, start->handle, ACPI_UINT32_MAX, NULL,
|
|
|
|
acpi_bus_device_detach, NULL, NULL);
|
|
|
|
acpi_bus_device_detach(start->handle, 0, NULL, NULL);
|
2013-01-15 16:24:02 +04:00
|
|
|
/*
|
|
|
|
* Execute acpi_bus_remove() as a post-order callback to remove device
|
|
|
|
* nodes in the given namespace scope.
|
|
|
|
*/
|
|
|
|
acpi_walk_namespace(ACPI_TYPE_ANY, start->handle, ACPI_UINT32_MAX, NULL,
|
|
|
|
acpi_bus_remove, NULL, NULL);
|
|
|
|
acpi_bus_remove(start->handle, 0, NULL, NULL);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
2006-02-24 04:56:01 +03:00
|
|
|
EXPORT_SYMBOL_GPL(acpi_bus_trim);
|
|
|
|
|
2009-09-21 23:28:59 +04:00
|
|
|
static int acpi_bus_scan_fixed(void)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2005-08-05 08:44:28 +04:00
|
|
|
int result = 0;
|
2006-12-07 15:56:41 +03:00
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
/*
|
|
|
|
* Enumerate all fixed-feature devices.
|
|
|
|
*/
|
2013-01-29 16:57:20 +04:00
|
|
|
if (!(acpi_gbl_FADT.flags & ACPI_FADT_POWER_BUTTON)) {
|
|
|
|
struct acpi_device *device = NULL;
|
|
|
|
|
2009-09-21 23:29:35 +04:00
|
|
|
result = acpi_add_single_object(&device, NULL,
|
2006-12-07 15:56:41 +03:00
|
|
|
ACPI_BUS_TYPE_POWER_BUTTON,
|
2013-01-29 16:57:20 +04:00
|
|
|
ACPI_STA_DEFAULT);
|
|
|
|
if (result)
|
|
|
|
return result;
|
|
|
|
|
2013-11-18 17:18:47 +04:00
|
|
|
device->flags.match_driver = true;
|
2013-01-29 16:57:20 +04:00
|
|
|
result = device_attach(&device->dev);
|
|
|
|
if (result < 0)
|
|
|
|
return result;
|
|
|
|
|
2012-05-10 03:08:43 +04:00
|
|
|
device_init_wakeup(&device->dev, true);
|
2005-04-28 11:25:52 +04:00
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2013-01-29 16:57:20 +04:00
|
|
|
if (!(acpi_gbl_FADT.flags & ACPI_FADT_SLEEP_BUTTON)) {
|
|
|
|
struct acpi_device *device = NULL;
|
|
|
|
|
2009-09-21 23:29:35 +04:00
|
|
|
result = acpi_add_single_object(&device, NULL,
|
2006-12-07 15:56:41 +03:00
|
|
|
ACPI_BUS_TYPE_SLEEP_BUTTON,
|
2013-01-29 16:57:20 +04:00
|
|
|
ACPI_STA_DEFAULT);
|
|
|
|
if (result)
|
|
|
|
return result;
|
|
|
|
|
2013-11-18 17:18:47 +04:00
|
|
|
device->flags.match_driver = true;
|
2013-01-29 16:57:20 +04:00
|
|
|
result = device_attach(&device->dev);
|
2005-04-28 11:25:52 +04:00
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2013-01-29 16:57:20 +04:00
|
|
|
return result < 0 ? result : 0;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2009-03-25 01:49:43 +03:00
|
|
|
int __init acpi_scan_init(void)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
|
|
|
int result;
|
|
|
|
|
2006-05-10 18:33:00 +04:00
|
|
|
result = bus_register(&acpi_bus_type);
|
|
|
|
if (result) {
|
|
|
|
/* We don't want to quit even if we failed to add suspend/resume */
|
|
|
|
printk(KERN_ERR PREFIX "Could not register bus type\n");
|
|
|
|
}
|
|
|
|
|
2012-12-21 03:36:40 +04:00
|
|
|
acpi_pci_root_init();
|
2013-01-30 17:27:37 +04:00
|
|
|
acpi_pci_link_init();
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-03 02:26:22 +04:00
|
|
|
acpi_processor_init();
|
2013-01-30 17:27:40 +04:00
|
|
|
acpi_platform_init();
|
2013-03-07 02:46:20 +04:00
|
|
|
acpi_lpss_init();
|
2013-06-05 06:27:50 +04:00
|
|
|
acpi_cmos_rtc_init();
|
2013-02-09 02:52:39 +04:00
|
|
|
acpi_container_init();
|
2013-03-04 02:18:03 +04:00
|
|
|
acpi_memory_hotplug_init();
|
2013-06-23 02:59:55 +04:00
|
|
|
acpi_dock_init();
|
2010-11-25 02:10:02 +03:00
|
|
|
|
ACPI / hotplug: Fix concurrency issues and memory leaks
This changeset is aimed at fixing a few different but related
problems in the ACPI hotplug infrastructure.
First of all, since notify handlers may be run in parallel with
acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
and some of them are installed for ACPI handles that have no struct
acpi_device objects attached (i.e. before those objects are created),
those notify handlers have to take acpi_scan_lock to prevent races
from taking place (e.g. a struct acpi_device is found to be present
for the given ACPI handle, but right after that it is removed by
acpi_bus_trim() running in parallel to the given notify handler).
Moreover, since some of them call acpi_bus_scan() and
acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
should be acquired by the callers of these two funtions rather by
these functions themselves.
For these reasons, make all notify handlers that can handle device
addition and eject events take acpi_scan_lock and remove the
acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
Accordingly, update all of their users to make sure that they
are always called under acpi_scan_lock.
Furthermore, since eject operations are carried out asynchronously
with respect to the notify events that trigger them, with the help
of acpi_bus_hot_remove_device(), even if notify handlers take the
ACPI scan lock, it still is possible that, for example,
acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
the notify handler that scheduled its execution and that
acpi_bus_trim() will remove the device node passed to
acpi_bus_hot_remove_device() for ejection. In that case, the struct
acpi_device object obtained by acpi_bus_hot_remove_device() will be
invalid and not-so-funny things will ensue. To protect agaist that,
make the users of acpi_bus_hot_remove_device() run get_device() on
ACPI device node objects that are about to be passed to it and make
acpi_bus_hot_remove_device() run put_device() on them and check if
their ACPI handles are not NULL (make acpi_device_unregister() clear
the device nodes' ACPI handles for that check to work).
Finally, observe that acpi_os_hotplug_execute() actually can fail,
in which case its caller ought to free memory allocated for the
context object to prevent leaks from happening. It also needs to
run put_device() on the device node that it ran get_device() on
previously in that case. Modify the code accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
2013-02-13 17:36:47 +04:00
|
|
|
mutex_lock(&acpi_scan_lock);
|
2005-04-17 02:20:36 +04:00
|
|
|
/*
|
|
|
|
* Enumerate devices in the ACPI namespace.
|
|
|
|
*/
|
2012-12-21 03:36:49 +04:00
|
|
|
result = acpi_bus_scan(ACPI_ROOT_OBJECT);
|
|
|
|
if (result)
|
ACPI / hotplug: Fix concurrency issues and memory leaks
This changeset is aimed at fixing a few different but related
problems in the ACPI hotplug infrastructure.
First of all, since notify handlers may be run in parallel with
acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
and some of them are installed for ACPI handles that have no struct
acpi_device objects attached (i.e. before those objects are created),
those notify handlers have to take acpi_scan_lock to prevent races
from taking place (e.g. a struct acpi_device is found to be present
for the given ACPI handle, but right after that it is removed by
acpi_bus_trim() running in parallel to the given notify handler).
Moreover, since some of them call acpi_bus_scan() and
acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
should be acquired by the callers of these two funtions rather by
these functions themselves.
For these reasons, make all notify handlers that can handle device
addition and eject events take acpi_scan_lock and remove the
acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
Accordingly, update all of their users to make sure that they
are always called under acpi_scan_lock.
Furthermore, since eject operations are carried out asynchronously
with respect to the notify events that trigger them, with the help
of acpi_bus_hot_remove_device(), even if notify handlers take the
ACPI scan lock, it still is possible that, for example,
acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
the notify handler that scheduled its execution and that
acpi_bus_trim() will remove the device node passed to
acpi_bus_hot_remove_device() for ejection. In that case, the struct
acpi_device object obtained by acpi_bus_hot_remove_device() will be
invalid and not-so-funny things will ensue. To protect agaist that,
make the users of acpi_bus_hot_remove_device() run get_device() on
ACPI device node objects that are about to be passed to it and make
acpi_bus_hot_remove_device() run put_device() on them and check if
their ACPI handles are not NULL (make acpi_device_unregister() clear
the device nodes' ACPI handles for that check to work).
Finally, observe that acpi_os_hotplug_execute() actually can fail,
in which case its caller ought to free memory allocated for the
context object to prevent leaks from happening. It also needs to
run put_device() on the device node that it ran get_device() on
previously in that case. Modify the code accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
2013-02-13 17:36:47 +04:00
|
|
|
goto out;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2012-12-21 03:36:49 +04:00
|
|
|
result = acpi_bus_get_device(ACPI_ROOT_OBJECT, &acpi_root);
|
2005-04-17 02:20:36 +04:00
|
|
|
if (result)
|
ACPI / hotplug: Fix concurrency issues and memory leaks
This changeset is aimed at fixing a few different but related
problems in the ACPI hotplug infrastructure.
First of all, since notify handlers may be run in parallel with
acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
and some of them are installed for ACPI handles that have no struct
acpi_device objects attached (i.e. before those objects are created),
those notify handlers have to take acpi_scan_lock to prevent races
from taking place (e.g. a struct acpi_device is found to be present
for the given ACPI handle, but right after that it is removed by
acpi_bus_trim() running in parallel to the given notify handler).
Moreover, since some of them call acpi_bus_scan() and
acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
should be acquired by the callers of these two funtions rather by
these functions themselves.
For these reasons, make all notify handlers that can handle device
addition and eject events take acpi_scan_lock and remove the
acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
Accordingly, update all of their users to make sure that they
are always called under acpi_scan_lock.
Furthermore, since eject operations are carried out asynchronously
with respect to the notify events that trigger them, with the help
of acpi_bus_hot_remove_device(), even if notify handlers take the
ACPI scan lock, it still is possible that, for example,
acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
the notify handler that scheduled its execution and that
acpi_bus_trim() will remove the device node passed to
acpi_bus_hot_remove_device() for ejection. In that case, the struct
acpi_device object obtained by acpi_bus_hot_remove_device() will be
invalid and not-so-funny things will ensue. To protect agaist that,
make the users of acpi_bus_hot_remove_device() run get_device() on
ACPI device node objects that are about to be passed to it and make
acpi_bus_hot_remove_device() run put_device() on them and check if
their ACPI handles are not NULL (make acpi_device_unregister() clear
the device nodes' ACPI handles for that check to work).
Finally, observe that acpi_os_hotplug_execute() actually can fail,
in which case its caller ought to free memory allocated for the
context object to prevent leaks from happening. It also needs to
run put_device() on the device node that it ran get_device() on
previously in that case. Modify the code accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
2013-02-13 17:36:47 +04:00
|
|
|
goto out;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2013-01-19 04:27:35 +04:00
|
|
|
result = acpi_bus_scan_fixed();
|
|
|
|
if (result) {
|
2013-01-15 16:23:44 +04:00
|
|
|
acpi_device_unregister(acpi_root);
|
ACPI / hotplug: Fix concurrency issues and memory leaks
This changeset is aimed at fixing a few different but related
problems in the ACPI hotplug infrastructure.
First of all, since notify handlers may be run in parallel with
acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
and some of them are installed for ACPI handles that have no struct
acpi_device objects attached (i.e. before those objects are created),
those notify handlers have to take acpi_scan_lock to prevent races
from taking place (e.g. a struct acpi_device is found to be present
for the given ACPI handle, but right after that it is removed by
acpi_bus_trim() running in parallel to the given notify handler).
Moreover, since some of them call acpi_bus_scan() and
acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
should be acquired by the callers of these two funtions rather by
these functions themselves.
For these reasons, make all notify handlers that can handle device
addition and eject events take acpi_scan_lock and remove the
acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
Accordingly, update all of their users to make sure that they
are always called under acpi_scan_lock.
Furthermore, since eject operations are carried out asynchronously
with respect to the notify events that trigger them, with the help
of acpi_bus_hot_remove_device(), even if notify handlers take the
ACPI scan lock, it still is possible that, for example,
acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
the notify handler that scheduled its execution and that
acpi_bus_trim() will remove the device node passed to
acpi_bus_hot_remove_device() for ejection. In that case, the struct
acpi_device object obtained by acpi_bus_hot_remove_device() will be
invalid and not-so-funny things will ensue. To protect agaist that,
make the users of acpi_bus_hot_remove_device() run get_device() on
ACPI device node objects that are about to be passed to it and make
acpi_bus_hot_remove_device() run put_device() on them and check if
their ACPI handles are not NULL (make acpi_device_unregister() clear
the device nodes' ACPI handles for that check to work).
Finally, observe that acpi_os_hotplug_execute() actually can fail,
in which case its caller ought to free memory allocated for the
context object to prevent leaks from happening. It also needs to
run put_device() on the device node that it ran get_device() on
previously in that case. Modify the code accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
2013-02-13 17:36:47 +04:00
|
|
|
goto out;
|
2013-01-19 04:27:35 +04:00
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2013-01-19 04:27:35 +04:00
|
|
|
acpi_update_all_gpes();
|
ACPI / hotplug: Fix concurrency issues and memory leaks
This changeset is aimed at fixing a few different but related
problems in the ACPI hotplug infrastructure.
First of all, since notify handlers may be run in parallel with
acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
and some of them are installed for ACPI handles that have no struct
acpi_device objects attached (i.e. before those objects are created),
those notify handlers have to take acpi_scan_lock to prevent races
from taking place (e.g. a struct acpi_device is found to be present
for the given ACPI handle, but right after that it is removed by
acpi_bus_trim() running in parallel to the given notify handler).
Moreover, since some of them call acpi_bus_scan() and
acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
should be acquired by the callers of these two funtions rather by
these functions themselves.
For these reasons, make all notify handlers that can handle device
addition and eject events take acpi_scan_lock and remove the
acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
Accordingly, update all of their users to make sure that they
are always called under acpi_scan_lock.
Furthermore, since eject operations are carried out asynchronously
with respect to the notify events that trigger them, with the help
of acpi_bus_hot_remove_device(), even if notify handlers take the
ACPI scan lock, it still is possible that, for example,
acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
the notify handler that scheduled its execution and that
acpi_bus_trim() will remove the device node passed to
acpi_bus_hot_remove_device() for ejection. In that case, the struct
acpi_device object obtained by acpi_bus_hot_remove_device() will be
invalid and not-so-funny things will ensue. To protect agaist that,
make the users of acpi_bus_hot_remove_device() run get_device() on
ACPI device node objects that are about to be passed to it and make
acpi_bus_hot_remove_device() run put_device() on them and check if
their ACPI handles are not NULL (make acpi_device_unregister() clear
the device nodes' ACPI handles for that check to work).
Finally, observe that acpi_os_hotplug_execute() actually can fail,
in which case its caller ought to free memory allocated for the
context object to prevent leaks from happening. It also needs to
run put_device() on the device node that it ran get_device() on
previously in that case. Modify the code accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
2013-02-13 17:36:47 +04:00
|
|
|
|
2013-01-22 01:20:48 +04:00
|
|
|
acpi_pci_root_hp_init();
|
|
|
|
|
ACPI / hotplug: Fix concurrency issues and memory leaks
This changeset is aimed at fixing a few different but related
problems in the ACPI hotplug infrastructure.
First of all, since notify handlers may be run in parallel with
acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
and some of them are installed for ACPI handles that have no struct
acpi_device objects attached (i.e. before those objects are created),
those notify handlers have to take acpi_scan_lock to prevent races
from taking place (e.g. a struct acpi_device is found to be present
for the given ACPI handle, but right after that it is removed by
acpi_bus_trim() running in parallel to the given notify handler).
Moreover, since some of them call acpi_bus_scan() and
acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
should be acquired by the callers of these two funtions rather by
these functions themselves.
For these reasons, make all notify handlers that can handle device
addition and eject events take acpi_scan_lock and remove the
acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
Accordingly, update all of their users to make sure that they
are always called under acpi_scan_lock.
Furthermore, since eject operations are carried out asynchronously
with respect to the notify events that trigger them, with the help
of acpi_bus_hot_remove_device(), even if notify handlers take the
ACPI scan lock, it still is possible that, for example,
acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
the notify handler that scheduled its execution and that
acpi_bus_trim() will remove the device node passed to
acpi_bus_hot_remove_device() for ejection. In that case, the struct
acpi_device object obtained by acpi_bus_hot_remove_device() will be
invalid and not-so-funny things will ensue. To protect agaist that,
make the users of acpi_bus_hot_remove_device() run get_device() on
ACPI device node objects that are about to be passed to it and make
acpi_bus_hot_remove_device() run put_device() on them and check if
their ACPI handles are not NULL (make acpi_device_unregister() clear
the device nodes' ACPI handles for that check to work).
Finally, observe that acpi_os_hotplug_execute() actually can fail,
in which case its caller ought to free memory allocated for the
context object to prevent leaks from happening. It also needs to
run put_device() on the device node that it ran get_device() on
previously in that case. Modify the code accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
2013-02-13 17:36:47 +04:00
|
|
|
out:
|
|
|
|
mutex_unlock(&acpi_scan_lock);
|
|
|
|
return result;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|