2019-05-19 12:08:55 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* scan.c - support for transforming the ACPI namespace into individual objects
|
|
|
|
*/
|
|
|
|
|
2021-06-02 08:54:37 +00:00
|
|
|
#define pr_fmt(fmt) "ACPI: " fmt
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
#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 08:04:11 +00:00
|
|
|
#include <linux/slab.h>
|
2006-07-12 06:08:00 +00:00
|
|
|
#include <linux/kernel.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
#include <linux/acpi.h>
|
2016-11-21 10:01:48 +00:00
|
|
|
#include <linux/acpi_iort.h>
|
ACPI: Add driver for the VIOT table
The ACPI Virtual I/O Translation Table describes topology of
para-virtual platforms, similarly to vendor tables DMAR, IVRS and IORT.
For now it describes the relation between virtio-iommu and the endpoints
it manages.
Three steps are needed to configure DMA of endpoints:
(1) acpi_viot_init(): parse the VIOT table, find or create the fwnode
associated to each vIOMMU device. This needs to happen after
acpi_scan_init(), because it relies on the struct device and their
fwnode to be available.
(2) When probing the vIOMMU device, the driver registers its IOMMU ops
within the IOMMU subsystem. This step doesn't require any
intervention from the VIOT driver.
(3) viot_iommu_configure(): before binding the endpoint to a driver,
find the associated IOMMU ops. Register them, along with the
endpoint ID, into the device's iommu_fwspec.
If step (3) happens before step (2), it is deferred until the IOMMU is
initialized, then retried.
Tested-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Link: https://lore.kernel.org/r/20210618152059.1194210-4-jean-philippe@linaro.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2021-06-18 15:20:58 +00:00
|
|
|
#include <linux/acpi_viot.h>
|
2021-06-18 15:20:57 +00:00
|
|
|
#include <linux/iommu.h>
|
2008-06-13 16:54:24 +00:00
|
|
|
#include <linux/signal.h>
|
|
|
|
#include <linux/kthread.h>
|
2010-03-24 13:38:37 +00:00
|
|
|
#include <linux/dmi.h>
|
2020-09-22 13:31:03 +00:00
|
|
|
#include <linux/dma-map-ops.h>
|
2017-08-01 12:10:41 +00:00
|
|
|
#include <linux/platform_data/x86/apple.h>
|
2020-06-09 04:32:38 +00:00
|
|
|
#include <linux/pgtable.h>
|
2021-12-23 08:16:17 +00:00
|
|
|
#include <linux/crc32.h>
|
2013-11-22 20:52:12 +00:00
|
|
|
|
2009-03-13 18:08:26 +00:00
|
|
|
#include "internal.h"
|
|
|
|
|
2005-08-05 04:44:28 +00:00
|
|
|
extern struct acpi_device *acpi_root;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
#define ACPI_BUS_CLASS "system_bus"
|
2007-07-23 12:43:51 +00:00
|
|
|
#define ACPI_BUS_HID "LNXSYBUS"
|
2005-04-16 22:20:36 +00:00
|
|
|
#define ACPI_BUS_DEVICE_NAME "System Bus"
|
|
|
|
|
2009-09-21 19:29:50 +00:00
|
|
|
#define ACPI_IS_ROOT_DEVICE(device) (!(device)->parent)
|
|
|
|
|
2013-11-22 20:52:12 +00:00
|
|
|
#define INVALID_ACPI_HANDLE ((acpi_handle)empty_zero_page)
|
|
|
|
|
2010-10-01 08:54:00 +00:00
|
|
|
static const char *dummy_hid = "device";
|
2010-10-01 08:53:59 +00:00
|
|
|
|
2014-11-23 13:22:54 +00:00
|
|
|
static LIST_HEAD(acpi_dep_list);
|
|
|
|
static DEFINE_MUTEX(acpi_dep_list_lock);
|
2015-11-25 20:19:55 +00:00
|
|
|
LIST_HEAD(acpi_bus_id_list);
|
2013-01-27 20:17:29 +00:00
|
|
|
static DEFINE_MUTEX(acpi_scan_lock);
|
2013-01-30 13:27:29 +00:00
|
|
|
static LIST_HEAD(acpi_scan_handlers_list);
|
2009-04-07 02:24:29 +00:00
|
|
|
DEFINE_MUTEX(acpi_device_lock);
|
2005-04-16 22:20:36 +00:00
|
|
|
LIST_HEAD(acpi_wakeup_device_list);
|
2014-02-03 23:43:17 +00:00
|
|
|
static DEFINE_MUTEX(acpi_hp_context_lock);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2016-04-07 12:03:18 +00:00
|
|
|
/*
|
|
|
|
* The UART device described by the SPCR table is the only object which needs
|
|
|
|
* special-casing. Everything else is covered by ACPI namespace paths in STAO
|
|
|
|
* table.
|
|
|
|
*/
|
|
|
|
static u64 spcr_uart_addr;
|
|
|
|
|
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 13:36:47 +00: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);
|
|
|
|
|
2014-02-03 23:43:17 +00:00
|
|
|
void acpi_lock_hp_context(void)
|
|
|
|
{
|
|
|
|
mutex_lock(&acpi_hp_context_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
void acpi_unlock_hp_context(void)
|
|
|
|
{
|
|
|
|
mutex_unlock(&acpi_hp_context_lock);
|
|
|
|
}
|
|
|
|
|
2014-02-21 23:48:31 +00:00
|
|
|
void acpi_initialize_hp_context(struct acpi_device *adev,
|
|
|
|
struct acpi_hotplug_context *hp,
|
|
|
|
int (*notify)(struct acpi_device *, u32),
|
|
|
|
void (*uevent)(struct acpi_device *, u32))
|
|
|
|
{
|
|
|
|
acpi_lock_hp_context();
|
2014-07-15 20:03:22 +00:00
|
|
|
hp->notify = notify;
|
|
|
|
hp->uevent = uevent;
|
|
|
|
acpi_set_hp_context(adev, hp);
|
2014-02-21 23:48:31 +00:00
|
|
|
acpi_unlock_hp_context();
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_initialize_hp_context);
|
|
|
|
|
2013-01-30 13:27:29 +00:00
|
|
|
int acpi_scan_add_handler(struct acpi_scan_handler *handler)
|
|
|
|
{
|
2014-05-30 02:27:31 +00:00
|
|
|
if (!handler)
|
2013-01-30 13:27:29 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
list_add_tail(&handler->list_node, &acpi_scan_handlers_list);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-03-03 22:08:16 +00: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;
|
|
|
|
}
|
|
|
|
|
ACPI / hotplug / driver core: Handle containers in a special way
ACPI container devices require special hotplug handling, at least
on some systems, since generally user space needs to carry out
system-specific cleanup before it makes sense to offline devices in
the container. However, the current ACPI hotplug code for containers
first attempts to offline devices in the container and only then it
notifies user space of the container offline.
Moreover, after commit 202317a573b2 (ACPI / scan: Add acpi_device
objects for all device nodes in the namespace), ACPI device objects
representing containers are present as long as the ACPI namespace
nodes corresponding to them are present, which may be forever, even
if the container devices are physically detached from the system (the
return values of the corresponding _STA methods change in those
cases, but generally the namespace nodes themselves are still there).
Thus it is useful to introduce entities representing containers that
will go away during container hot-unplug.
The goal of this change is to address both the above issues.
The idea is to create a "companion" container system device for each
of the ACPI container device objects during the initial namespace
scan or on a hotplug event making the container present. That system
device will be unregistered on container removal. A new bus type
for container devices is added for this purpose, because device
offline and online operations need to be defined for them. The
online operation is a trivial function that is always successful
and the offline uses a callback pointed to by the container device's
offline member.
For ACPI containers that callback simply walks the list of ACPI
device objects right below the container object (its children) and
checks if all of their physical companion devices are offline. If
that's not the case, it returns -EBUSY and the container system
devivce cannot be put offline. Consequently, to put the container
system device offline, it is necessary to put all of the physical
devices depending on its ACPI companion object offline beforehand.
Container system devices created for ACPI container objects are
initially online. They are created by the container ACPI scan
handler whose hotplug.demand_offline flag is set. That causes
acpi_scan_hot_remove() to check if the companion container system
device is offline before attempting to remove an ACPI container or
any devices below it. If the check fails, a KOBJ_CHANGE uevent is
emitted for the container system device in question and user space
is expected to offline all devices below the container and the
container itself in response to it. Then, user space can finalize
the removal of the container with the help of its ACPI device
object's eject attribute in sysfs.
Tested-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-29 14:25:48 +00:00
|
|
|
bool acpi_scan_is_offline(struct acpi_device *adev, bool uevent)
|
2013-12-29 14:25:35 +00:00
|
|
|
{
|
|
|
|
struct acpi_device_physical_node *pn;
|
|
|
|
bool offline = true;
|
2018-03-20 05:51:26 +00:00
|
|
|
char *envp[] = { "EVENT=offline", NULL };
|
2013-12-29 14:25:35 +00:00
|
|
|
|
2015-04-17 23:25:46 +00:00
|
|
|
/*
|
|
|
|
* acpi_container_offline() calls this for all of the container's
|
|
|
|
* children under the container's physical_node_lock lock.
|
|
|
|
*/
|
|
|
|
mutex_lock_nested(&adev->physical_node_lock, SINGLE_DEPTH_NESTING);
|
2013-12-29 14:25:35 +00:00
|
|
|
|
|
|
|
list_for_each_entry(pn, &adev->physical_node_list, node)
|
|
|
|
if (device_supports_offline(pn->dev) && !pn->dev->offline) {
|
ACPI / hotplug / driver core: Handle containers in a special way
ACPI container devices require special hotplug handling, at least
on some systems, since generally user space needs to carry out
system-specific cleanup before it makes sense to offline devices in
the container. However, the current ACPI hotplug code for containers
first attempts to offline devices in the container and only then it
notifies user space of the container offline.
Moreover, after commit 202317a573b2 (ACPI / scan: Add acpi_device
objects for all device nodes in the namespace), ACPI device objects
representing containers are present as long as the ACPI namespace
nodes corresponding to them are present, which may be forever, even
if the container devices are physically detached from the system (the
return values of the corresponding _STA methods change in those
cases, but generally the namespace nodes themselves are still there).
Thus it is useful to introduce entities representing containers that
will go away during container hot-unplug.
The goal of this change is to address both the above issues.
The idea is to create a "companion" container system device for each
of the ACPI container device objects during the initial namespace
scan or on a hotplug event making the container present. That system
device will be unregistered on container removal. A new bus type
for container devices is added for this purpose, because device
offline and online operations need to be defined for them. The
online operation is a trivial function that is always successful
and the offline uses a callback pointed to by the container device's
offline member.
For ACPI containers that callback simply walks the list of ACPI
device objects right below the container object (its children) and
checks if all of their physical companion devices are offline. If
that's not the case, it returns -EBUSY and the container system
devivce cannot be put offline. Consequently, to put the container
system device offline, it is necessary to put all of the physical
devices depending on its ACPI companion object offline beforehand.
Container system devices created for ACPI container objects are
initially online. They are created by the container ACPI scan
handler whose hotplug.demand_offline flag is set. That causes
acpi_scan_hot_remove() to check if the companion container system
device is offline before attempting to remove an ACPI container or
any devices below it. If the check fails, a KOBJ_CHANGE uevent is
emitted for the container system device in question and user space
is expected to offline all devices below the container and the
container itself in response to it. Then, user space can finalize
the removal of the container with the help of its ACPI device
object's eject attribute in sysfs.
Tested-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-29 14:25:48 +00:00
|
|
|
if (uevent)
|
2018-03-20 05:51:26 +00:00
|
|
|
kobject_uevent_env(&pn->dev->kobj, KOBJ_CHANGE, envp);
|
ACPI / hotplug / driver core: Handle containers in a special way
ACPI container devices require special hotplug handling, at least
on some systems, since generally user space needs to carry out
system-specific cleanup before it makes sense to offline devices in
the container. However, the current ACPI hotplug code for containers
first attempts to offline devices in the container and only then it
notifies user space of the container offline.
Moreover, after commit 202317a573b2 (ACPI / scan: Add acpi_device
objects for all device nodes in the namespace), ACPI device objects
representing containers are present as long as the ACPI namespace
nodes corresponding to them are present, which may be forever, even
if the container devices are physically detached from the system (the
return values of the corresponding _STA methods change in those
cases, but generally the namespace nodes themselves are still there).
Thus it is useful to introduce entities representing containers that
will go away during container hot-unplug.
The goal of this change is to address both the above issues.
The idea is to create a "companion" container system device for each
of the ACPI container device objects during the initial namespace
scan or on a hotplug event making the container present. That system
device will be unregistered on container removal. A new bus type
for container devices is added for this purpose, because device
offline and online operations need to be defined for them. The
online operation is a trivial function that is always successful
and the offline uses a callback pointed to by the container device's
offline member.
For ACPI containers that callback simply walks the list of ACPI
device objects right below the container object (its children) and
checks if all of their physical companion devices are offline. If
that's not the case, it returns -EBUSY and the container system
devivce cannot be put offline. Consequently, to put the container
system device offline, it is necessary to put all of the physical
devices depending on its ACPI companion object offline beforehand.
Container system devices created for ACPI container objects are
initially online. They are created by the container ACPI scan
handler whose hotplug.demand_offline flag is set. That causes
acpi_scan_hot_remove() to check if the companion container system
device is offline before attempting to remove an ACPI container or
any devices below it. If the check fails, a KOBJ_CHANGE uevent is
emitted for the container system device in question and user space
is expected to offline all devices below the container and the
container itself in response to it. Then, user space can finalize
the removal of the container with the help of its ACPI device
object's eject attribute in sysfs.
Tested-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-29 14:25:48 +00:00
|
|
|
|
2013-12-29 14:25:35 +00:00
|
|
|
offline = false;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
mutex_unlock(&adev->physical_node_lock);
|
|
|
|
return offline;
|
|
|
|
}
|
|
|
|
|
2013-11-07 00:41:14 +00:00
|
|
|
static acpi_status acpi_bus_offline(acpi_handle handle, u32 lvl, void *data,
|
|
|
|
void **ret_p)
|
2013-05-02 22:26:16 +00:00
|
|
|
{
|
2021-12-03 16:36:20 +00:00
|
|
|
struct acpi_device *device = acpi_fetch_acpi_dev(handle);
|
2013-05-02 22:26:16 +00:00
|
|
|
struct acpi_device_physical_node *pn;
|
2013-05-23 08:43:13 +00:00
|
|
|
bool second_pass = (bool)data;
|
2013-05-02 22:26:16 +00:00
|
|
|
acpi_status status = AE_OK;
|
|
|
|
|
2021-12-03 16:36:20 +00:00
|
|
|
if (!device)
|
2013-05-02 22:26:16 +00:00
|
|
|
return AE_OK;
|
|
|
|
|
2013-11-07 00:41:14 +00:00
|
|
|
if (device->handler && !device->handler->hotplug.enabled) {
|
|
|
|
*ret_p = &device->dev;
|
|
|
|
return AE_SUPPORT;
|
|
|
|
}
|
|
|
|
|
2013-05-02 22:26:16 +00:00
|
|
|
mutex_lock(&device->physical_node_lock);
|
|
|
|
|
|
|
|
list_for_each_entry(pn, &device->physical_node_list, node) {
|
|
|
|
int ret;
|
|
|
|
|
2013-05-23 08:43:13 +00:00
|
|
|
if (second_pass) {
|
|
|
|
/* Skip devices offlined by the first pass. */
|
|
|
|
if (pn->put_online)
|
|
|
|
continue;
|
|
|
|
} else {
|
|
|
|
pn->put_online = false;
|
|
|
|
}
|
2013-05-02 22:26:16 +00:00
|
|
|
ret = device_offline(pn->dev);
|
2013-05-23 08:43:13 +00:00
|
|
|
if (ret >= 0) {
|
|
|
|
pn->put_online = !ret;
|
|
|
|
} else {
|
|
|
|
*ret_p = pn->dev;
|
|
|
|
if (second_pass) {
|
|
|
|
status = AE_ERROR;
|
|
|
|
break;
|
|
|
|
}
|
2013-05-02 22:26:16 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
mutex_unlock(&device->physical_node_lock);
|
|
|
|
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2013-11-07 00:41:14 +00:00
|
|
|
static acpi_status acpi_bus_online(acpi_handle handle, u32 lvl, void *data,
|
|
|
|
void **ret_p)
|
2013-05-02 22:26:16 +00:00
|
|
|
{
|
2021-12-03 16:36:20 +00:00
|
|
|
struct acpi_device *device = acpi_fetch_acpi_dev(handle);
|
2013-05-02 22:26:16 +00:00
|
|
|
struct acpi_device_physical_node *pn;
|
|
|
|
|
2021-12-03 16:36:20 +00:00
|
|
|
if (!device)
|
2013-05-02 22:26:16 +00:00
|
|
|
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-12-29 14:25:35 +00:00
|
|
|
static int acpi_scan_try_to_offline(struct acpi_device *device)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2013-01-11 22:40:41 +00:00
|
|
|
acpi_handle handle = device->handle;
|
2013-12-29 14:25:35 +00:00
|
|
|
struct device *errdev = NULL;
|
2013-03-03 22:05:29 +00:00
|
|
|
acpi_status status;
|
2013-02-09 14:29:11 +00:00
|
|
|
|
2013-05-23 08:43:13 +00: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.
|
|
|
|
*/
|
2013-11-07 00:41:14 +00: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);
|
|
|
|
return -EPERM;
|
|
|
|
}
|
|
|
|
acpi_bus_offline(handle, 0, (void *)false, (void **)&errdev);
|
2013-05-23 08:43:13 +00:00
|
|
|
if (errdev) {
|
|
|
|
errdev = NULL;
|
2013-05-02 22:26:16 +00:00
|
|
|
acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
|
2013-11-07 00:41:14 +00:00
|
|
|
NULL, acpi_bus_offline, (void *)true,
|
|
|
|
(void **)&errdev);
|
2017-04-03 07:40:23 +00:00
|
|
|
if (!errdev)
|
2013-11-07 00:41:14 +00:00
|
|
|
acpi_bus_offline(handle, 0, (void *)true,
|
|
|
|
(void **)&errdev);
|
2013-05-23 08:43:13 +00:00
|
|
|
|
2017-04-03 07:40:23 +00:00
|
|
|
if (errdev) {
|
2013-05-23 08:43:13 +00:00
|
|
|
dev_warn(errdev, "Offline failed.\n");
|
2013-11-07 00:41:14 +00:00
|
|
|
acpi_bus_online(handle, 0, NULL, NULL);
|
2013-05-23 08:43:13 +00:00
|
|
|
acpi_walk_namespace(ACPI_TYPE_ANY, handle,
|
2013-11-07 00:41:14 +00:00
|
|
|
ACPI_UINT32_MAX, acpi_bus_online,
|
|
|
|
NULL, NULL, NULL);
|
2013-05-23 08:43:13 +00:00
|
|
|
return -EBUSY;
|
|
|
|
}
|
2013-05-02 22:26:16 +00:00
|
|
|
}
|
2013-12-29 14:25:35 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int acpi_scan_hot_remove(struct acpi_device *device)
|
|
|
|
{
|
|
|
|
acpi_handle handle = device->handle;
|
|
|
|
unsigned long long sta;
|
|
|
|
acpi_status status;
|
|
|
|
|
2017-04-03 07:40:23 +00:00
|
|
|
if (device->handler && device->handler->hotplug.demand_offline) {
|
ACPI / hotplug / driver core: Handle containers in a special way
ACPI container devices require special hotplug handling, at least
on some systems, since generally user space needs to carry out
system-specific cleanup before it makes sense to offline devices in
the container. However, the current ACPI hotplug code for containers
first attempts to offline devices in the container and only then it
notifies user space of the container offline.
Moreover, after commit 202317a573b2 (ACPI / scan: Add acpi_device
objects for all device nodes in the namespace), ACPI device objects
representing containers are present as long as the ACPI namespace
nodes corresponding to them are present, which may be forever, even
if the container devices are physically detached from the system (the
return values of the corresponding _STA methods change in those
cases, but generally the namespace nodes themselves are still there).
Thus it is useful to introduce entities representing containers that
will go away during container hot-unplug.
The goal of this change is to address both the above issues.
The idea is to create a "companion" container system device for each
of the ACPI container device objects during the initial namespace
scan or on a hotplug event making the container present. That system
device will be unregistered on container removal. A new bus type
for container devices is added for this purpose, because device
offline and online operations need to be defined for them. The
online operation is a trivial function that is always successful
and the offline uses a callback pointed to by the container device's
offline member.
For ACPI containers that callback simply walks the list of ACPI
device objects right below the container object (its children) and
checks if all of their physical companion devices are offline. If
that's not the case, it returns -EBUSY and the container system
devivce cannot be put offline. Consequently, to put the container
system device offline, it is necessary to put all of the physical
devices depending on its ACPI companion object offline beforehand.
Container system devices created for ACPI container objects are
initially online. They are created by the container ACPI scan
handler whose hotplug.demand_offline flag is set. That causes
acpi_scan_hot_remove() to check if the companion container system
device is offline before attempting to remove an ACPI container or
any devices below it. If the check fails, a KOBJ_CHANGE uevent is
emitted for the container system device in question and user space
is expected to offline all devices below the container and the
container itself in response to it. Then, user space can finalize
the removal of the container with the help of its ACPI device
object's eject attribute in sysfs.
Tested-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-29 14:25:48 +00:00
|
|
|
if (!acpi_scan_is_offline(device, true))
|
2013-12-29 14:25:35 +00:00
|
|
|
return -EBUSY;
|
|
|
|
} else {
|
|
|
|
int error = acpi_scan_try_to_offline(device);
|
|
|
|
if (error)
|
|
|
|
return error;
|
|
|
|
}
|
2013-05-02 22:26:16 +00:00
|
|
|
|
2021-01-20 18:59:51 +00:00
|
|
|
acpi_handle_debug(handle, "Ejecting\n");
|
2008-04-29 06:35:48 +00:00
|
|
|
|
2013-01-25 23:27:44 +00:00
|
|
|
acpi_bus_trim(device);
|
2013-05-02 22:26:16 +00:00
|
|
|
|
2013-06-28 16:24:40 +00:00
|
|
|
acpi_evaluate_lck(handle, 0);
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* TBD: _EJD support.
|
|
|
|
*/
|
2013-06-28 16:24:40 +00:00
|
|
|
status = acpi_evaluate_ej0(handle);
|
|
|
|
if (status == AE_NOT_FOUND)
|
|
|
|
return -ENODEV;
|
|
|
|
else if (ACPI_FAILURE(status))
|
|
|
|
return -EIO;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2013-03-13 19:29:26 +00: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-03 22:05:29 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2013-11-22 20:55:43 +00:00
|
|
|
static int acpi_scan_device_not_present(struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
if (!acpi_device_enumerated(adev)) {
|
|
|
|
dev_warn(&adev->dev, "Still not present\n");
|
|
|
|
return -EALREADY;
|
|
|
|
}
|
|
|
|
acpi_bus_trim(adev);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-11-22 20:55:07 +00:00
|
|
|
static int acpi_scan_device_check(struct acpi_device *adev)
|
2013-03-03 22:05:29 +00:00
|
|
|
{
|
2013-08-28 19:41:07 +00:00
|
|
|
int error;
|
2013-03-03 22:05:29 +00:00
|
|
|
|
2013-11-22 20:55:43 +00:00
|
|
|
acpi_bus_get_status(adev);
|
|
|
|
if (adev->status.present || adev->status.functional) {
|
|
|
|
/*
|
|
|
|
* This function is only called for device objects for which
|
|
|
|
* matching scan handlers exist. The only situation in which
|
|
|
|
* the scan handler is not attached to this device object yet
|
|
|
|
* is when the device has just appeared (either it wasn't
|
|
|
|
* present at all before or it was removed and then added
|
|
|
|
* again).
|
|
|
|
*/
|
|
|
|
if (adev->handler) {
|
|
|
|
dev_warn(&adev->dev, "Already enumerated\n");
|
|
|
|
return -EALREADY;
|
|
|
|
}
|
|
|
|
error = acpi_bus_scan(adev->handle);
|
|
|
|
if (error) {
|
|
|
|
dev_warn(&adev->dev, "Namespace scan failure\n");
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
if (!adev->handler) {
|
|
|
|
dev_warn(&adev->dev, "Enumeration failure\n");
|
|
|
|
error = -ENODEV;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
error = acpi_scan_device_not_present(adev);
|
|
|
|
}
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int acpi_scan_bus_check(struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
struct acpi_scan_handler *handler = adev->handler;
|
|
|
|
struct acpi_device *child;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
acpi_bus_get_status(adev);
|
|
|
|
if (!(adev->status.present || adev->status.functional)) {
|
|
|
|
acpi_scan_device_not_present(adev);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
if (handler && handler->hotplug.scan_dependent)
|
|
|
|
return handler->hotplug.scan_dependent(adev);
|
|
|
|
|
2013-11-22 20:55:07 +00:00
|
|
|
error = acpi_bus_scan(adev->handle);
|
|
|
|
if (error) {
|
|
|
|
dev_warn(&adev->dev, "Namespace scan failure\n");
|
|
|
|
return error;
|
|
|
|
}
|
2013-11-22 20:55:43 +00:00
|
|
|
list_for_each_entry(child, &adev->children, node) {
|
|
|
|
error = acpi_scan_bus_check(child);
|
|
|
|
if (error)
|
|
|
|
return error;
|
2013-11-22 20:55:07 +00:00
|
|
|
}
|
|
|
|
return 0;
|
2013-03-03 22:05:29 +00:00
|
|
|
}
|
|
|
|
|
2014-02-06 16:31:37 +00:00
|
|
|
static int acpi_generic_hotplug_event(struct acpi_device *adev, u32 type)
|
|
|
|
{
|
|
|
|
switch (type) {
|
|
|
|
case ACPI_NOTIFY_BUS_CHECK:
|
|
|
|
return acpi_scan_bus_check(adev);
|
|
|
|
case ACPI_NOTIFY_DEVICE_CHECK:
|
|
|
|
return acpi_scan_device_check(adev);
|
|
|
|
case ACPI_NOTIFY_EJECT_REQUEST:
|
|
|
|
case ACPI_OST_EC_OSPM_EJECT:
|
2014-02-03 23:44:02 +00:00
|
|
|
if (adev->handler && !adev->handler->hotplug.enabled) {
|
|
|
|
dev_info(&adev->dev, "Eject disabled\n");
|
|
|
|
return -EPERM;
|
|
|
|
}
|
2014-02-21 00:07:17 +00:00
|
|
|
acpi_evaluate_ost(adev->handle, ACPI_NOTIFY_EJECT_REQUEST,
|
|
|
|
ACPI_OST_SC_EJECT_IN_PROGRESS, NULL);
|
2014-02-06 16:31:37 +00:00
|
|
|
return acpi_scan_hot_remove(adev);
|
|
|
|
}
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2014-03-02 23:40:38 +00:00
|
|
|
void acpi_device_hotplug(struct acpi_device *adev, u32 src)
|
2013-03-03 22:05:29 +00:00
|
|
|
{
|
|
|
|
u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE;
|
2014-02-06 16:31:37 +00:00
|
|
|
int error = -ENODEV;
|
2013-03-03 22:05:29 +00:00
|
|
|
|
2013-05-02 22:26:16 +00:00
|
|
|
lock_device_hotplug();
|
2013-08-30 12:19:29 +00:00
|
|
|
mutex_lock(&acpi_scan_lock);
|
2013-03-03 22:05:29 +00:00
|
|
|
|
2013-11-22 20:55:07 +00:00
|
|
|
/*
|
|
|
|
* The device object's ACPI handle cannot become invalid as long as we
|
2014-02-06 16:31:37 +00:00
|
|
|
* are holding acpi_scan_lock, but it might have become invalid before
|
2013-11-22 20:55:07 +00:00
|
|
|
* that lock was acquired.
|
|
|
|
*/
|
|
|
|
if (adev->handle == INVALID_ACPI_HANDLE)
|
2014-02-06 16:31:37 +00:00
|
|
|
goto err_out;
|
2013-11-22 20:55:07 +00:00
|
|
|
|
ACPI / dock: Dispatch dock notifications from the global notify handler
The ACPI dock station code carries out an extra namespace scan
before the main one in order to find and register all of the dock
device objects. Then, it registers a notify handler for each of
them for handling dock events.
However, dock device objects need not be scanned for upfront. They
very well can be enumerated and registered during the first phase
of the main namespace scan, before attaching scan handlers and ACPI
drivers to ACPI device objects. Then, the dependent devices can be
added to the in the second phase. That makes it possible to drop
the extra namespace scan, so do it.
Moreover, it is not necessary to register notify handlers for all
of the dock stations' namespace nodes, becuase notifications may
be dispatched from the global notify handler for them. Do that and
drop two functions used for dock notify handling, acpi_dock_deferred_cb()
and dock_notify_handler(), that aren't necessary any more.
Finally, some dock station objects have _HID objects matching the
ACPI container scan handler which causes it to claim those objects
and try to handle their hotplug, but that is not a good idea,
because those objects have their own special hotplug handling anyway.
For this reason, the hotplug_notify flag should not be set for ACPI
device objects representing dock stations and the container scan
handler should be made ignore those objects, so make that happen.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-16 00:51:01 +00:00
|
|
|
if (adev->flags.is_dock_station) {
|
|
|
|
error = dock_notify(adev, src);
|
|
|
|
} else if (adev->flags.hotplug_notify) {
|
2014-02-06 16:31:37 +00:00
|
|
|
error = acpi_generic_hotplug_event(adev, src);
|
|
|
|
} else {
|
2014-02-21 00:10:27 +00:00
|
|
|
int (*notify)(struct acpi_device *, u32);
|
2014-02-06 16:31:37 +00:00
|
|
|
|
|
|
|
acpi_lock_hp_context();
|
2014-02-21 00:10:27 +00:00
|
|
|
notify = adev->hp ? adev->hp->notify : NULL;
|
2014-02-06 16:31:37 +00:00
|
|
|
acpi_unlock_hp_context();
|
|
|
|
/*
|
|
|
|
* There may be additional notify handlers for device objects
|
|
|
|
* without the .event() callback, so ignore them here.
|
|
|
|
*/
|
2014-02-21 00:10:27 +00:00
|
|
|
if (notify)
|
|
|
|
error = notify(adev, src);
|
2014-02-06 16:31:37 +00:00
|
|
|
else
|
|
|
|
goto out;
|
2013-03-03 22:05:29 +00:00
|
|
|
}
|
2017-07-03 13:26:10 +00:00
|
|
|
switch (error) {
|
|
|
|
case 0:
|
2013-11-22 20:55:07 +00:00
|
|
|
ost_code = ACPI_OST_SC_SUCCESS;
|
2017-07-03 13:26:10 +00:00
|
|
|
break;
|
|
|
|
case -EPERM:
|
|
|
|
ost_code = ACPI_OST_SC_EJECT_NOT_SUPPORTED;
|
|
|
|
break;
|
|
|
|
case -EBUSY:
|
|
|
|
ost_code = ACPI_OST_SC_DEVICE_BUSY;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE;
|
|
|
|
break;
|
|
|
|
}
|
2013-03-03 22:05:29 +00:00
|
|
|
|
2014-02-06 16:31:37 +00:00
|
|
|
err_out:
|
2014-02-21 00:07:17 +00:00
|
|
|
acpi_evaluate_ost(adev->handle, src, ost_code, NULL);
|
2014-02-06 16:31:37 +00:00
|
|
|
|
|
|
|
out:
|
2014-02-03 23:43:05 +00:00
|
|
|
acpi_bus_put_acpi_device(adev);
|
2013-03-03 22:05:29 +00:00
|
|
|
mutex_unlock(&acpi_scan_lock);
|
2013-08-30 12:19:29 +00:00
|
|
|
unlock_device_hotplug();
|
2013-03-03 22:05:29 +00:00
|
|
|
}
|
|
|
|
|
2013-01-17 13:11:06 +00:00
|
|
|
static void acpi_free_power_resources_lists(struct acpi_device *device)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2013-01-17 13:11:06 +00:00
|
|
|
if (device->wakeup.flags.valid)
|
|
|
|
acpi_power_resources_list_free(&device->wakeup.resources);
|
|
|
|
|
ACPI / PM: Fix PM initialization for devices that are not present
If an ACPI device object whose _STA returns 0 (not present and not
functional) has _PR0 or _PS0, its power_manageable flag will be set
and acpi_bus_init_power() will return 0 for it. Consequently, if
such a device object is passed to the ACPI device PM functions, they
will attempt to carry out the requested operation on the device,
although they should not do that for devices that are not present.
To fix that problem make acpi_bus_init_power() return an error code
for devices that are not present which will cause power_manageable to
be cleared for them as appropriate in acpi_bus_get_power_flags().
However, the lists of power resources should not be freed for the
device in that case, so modify acpi_bus_get_power_flags() to keep
those lists even if acpi_bus_init_power() returns an error.
Accordingly, when deciding whether or not the lists of power
resources need to be freed, acpi_free_power_resources_lists()
should check the power.flags.power_resources flag instead of
flags.power_manageable, so make that change too.
Furthermore, if acpi_bus_attach() sees that flags.initialized is
unset for the given device, it should reset the power management
settings of the device and re-initialize them from scratch instead
of relying on the previous settings (the device may have appeared
after being not present previously, for example), so make it use
the 'valid' flag of the D0 power state as the initial value of
flags.power_manageable for it and call acpi_bus_init_power() to
discover its current power state.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
2015-01-01 22:38:28 +00:00
|
|
|
if (!device->power.flags.power_resources)
|
2013-01-17 13:11:06 +00:00
|
|
|
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 19:35:19 +00:00
|
|
|
}
|
|
|
|
|
2006-12-07 12:56:31 +00:00
|
|
|
static void acpi_device_release(struct device *dev)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2006-12-07 12:56:31 +00:00
|
|
|
struct acpi_device *acpi_dev = to_acpi_device(dev);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
ACPI: Add support for device specific properties
Device Tree is used in many embedded systems to describe the system
configuration to the OS. It supports attaching properties or name-value
pairs to the devices it describe. With these properties one can pass
additional information to the drivers that would not be available
otherwise.
ACPI is another configuration mechanism (among other things) typically
seen, but not limited to, x86 machines. ACPI allows passing arbitrary
data from methods but there has not been mechanism equivalent to Device
Tree until the introduction of _DSD in the recent publication of the
ACPI 5.1 specification.
In order to facilitate ACPI usage in systems where Device Tree is
typically used, it would be beneficial to standardize a way to retrieve
Device Tree style properties from ACPI devices, which is what we do in
this patch.
If a given device described in ACPI namespace wants to export properties it
must implement _DSD method (Device Specific Data, introduced with ACPI 5.1)
that returns the properties in a package of packages. For example:
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"name1", <VALUE1>},
Package () {"name2", <VALUE2>},
...
}
})
The UUID reserved for properties is daffd814-6eba-4d8c-8a91-bc9bbf4aa301
and is documented in the ACPI 5.1 companion document called "_DSD
Implementation Guide" [1], [2].
We add several helper functions that can be used to extract these
properties and convert them to different Linux data types.
The ultimate goal is that we only have one device property API that
retrieves the requested properties from Device Tree or from ACPI
transparent to the caller.
[1] http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
[2] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-21 11:33:55 +00:00
|
|
|
acpi_free_properties(acpi_dev);
|
2013-03-04 21:30:42 +00:00
|
|
|
acpi_free_pnp_ids(&acpi_dev->pnp);
|
2013-01-17 13:11:06 +00:00
|
|
|
acpi_free_power_resources_lists(acpi_dev);
|
2006-12-07 12:56:31 +00:00
|
|
|
kfree(acpi_dev);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2013-11-22 20:52:12 +00:00
|
|
|
static void acpi_device_del(struct acpi_device *device)
|
|
|
|
{
|
2015-11-25 20:19:55 +00:00
|
|
|
struct acpi_device_bus_id *acpi_device_bus_id;
|
|
|
|
|
2013-11-22 20:52:12 +00:00
|
|
|
mutex_lock(&acpi_device_lock);
|
|
|
|
if (device->parent)
|
|
|
|
list_del(&device->node);
|
|
|
|
|
2015-11-25 20:19:55 +00:00
|
|
|
list_for_each_entry(acpi_device_bus_id, &acpi_bus_id_list, node)
|
|
|
|
if (!strcmp(acpi_device_bus_id->bus_id,
|
|
|
|
acpi_device_hid(device))) {
|
2021-03-22 16:31:00 +00:00
|
|
|
ida_simple_remove(&acpi_device_bus_id->instance_ida, device->pnp.instance_no);
|
|
|
|
if (ida_is_empty(&acpi_device_bus_id->instance_ida)) {
|
2015-11-25 20:19:55 +00:00
|
|
|
list_del(&acpi_device_bus_id->node);
|
2021-01-08 07:23:48 +00:00
|
|
|
kfree_const(acpi_device_bus_id->bus_id);
|
2015-11-25 20:19:55 +00:00
|
|
|
kfree(acpi_device_bus_id);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2013-11-22 20:52:12 +00:00
|
|
|
list_del(&device->wakeup_list);
|
|
|
|
mutex_unlock(&acpi_device_lock);
|
|
|
|
|
|
|
|
acpi_power_add_remove_device(device, false);
|
|
|
|
acpi_device_remove_files(device);
|
|
|
|
if (device->remove)
|
|
|
|
device->remove(device);
|
|
|
|
|
|
|
|
device_del(&device->dev);
|
|
|
|
}
|
|
|
|
|
2016-07-08 16:13:09 +00:00
|
|
|
static BLOCKING_NOTIFIER_HEAD(acpi_reconfig_chain);
|
|
|
|
|
2013-11-22 20:52:12 +00:00
|
|
|
static LIST_HEAD(acpi_device_del_list);
|
|
|
|
static DEFINE_MUTEX(acpi_device_del_lock);
|
|
|
|
|
|
|
|
static void acpi_device_del_work_fn(struct work_struct *work_not_used)
|
|
|
|
{
|
|
|
|
for (;;) {
|
|
|
|
struct acpi_device *adev;
|
|
|
|
|
|
|
|
mutex_lock(&acpi_device_del_lock);
|
|
|
|
|
|
|
|
if (list_empty(&acpi_device_del_list)) {
|
|
|
|
mutex_unlock(&acpi_device_del_lock);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
adev = list_first_entry(&acpi_device_del_list,
|
|
|
|
struct acpi_device, del_list);
|
|
|
|
list_del(&adev->del_list);
|
|
|
|
|
|
|
|
mutex_unlock(&acpi_device_del_lock);
|
|
|
|
|
2016-07-08 16:13:09 +00:00
|
|
|
blocking_notifier_call_chain(&acpi_reconfig_chain,
|
|
|
|
ACPI_RECONFIG_DEVICE_REMOVE, adev);
|
|
|
|
|
2013-11-22 20:52:12 +00:00
|
|
|
acpi_device_del(adev);
|
|
|
|
/*
|
|
|
|
* Drop references to all power resources that might have been
|
|
|
|
* used by the device.
|
|
|
|
*/
|
|
|
|
acpi_power_transition(adev, ACPI_STATE_D3_COLD);
|
2021-04-12 22:23:58 +00:00
|
|
|
acpi_dev_put(adev);
|
2013-11-22 20:52:12 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_scan_drop_device - Drop an ACPI device object.
|
|
|
|
* @handle: Handle of an ACPI namespace node, not used.
|
|
|
|
* @context: Address of the ACPI device object to drop.
|
|
|
|
*
|
|
|
|
* This is invoked by acpi_ns_delete_node() during the removal of the ACPI
|
|
|
|
* namespace node the device object pointed to by @context is attached to.
|
|
|
|
*
|
|
|
|
* The unregistration is carried out asynchronously to avoid running
|
|
|
|
* acpi_device_del() under the ACPICA's namespace mutex and the list is used to
|
|
|
|
* ensure the correct ordering (the device objects must be unregistered in the
|
|
|
|
* same order in which the corresponding namespace nodes are deleted).
|
|
|
|
*/
|
|
|
|
static void acpi_scan_drop_device(acpi_handle handle, void *context)
|
2013-07-30 12:38:34 +00:00
|
|
|
{
|
2013-11-22 20:52:12 +00:00
|
|
|
static DECLARE_WORK(work, acpi_device_del_work_fn);
|
|
|
|
struct acpi_device *adev = context;
|
|
|
|
|
|
|
|
mutex_lock(&acpi_device_del_lock);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Use the ACPI hotplug workqueue which is ordered, so this work item
|
|
|
|
* won't run after any hotplug work items submitted subsequently. That
|
|
|
|
* prevents attempts to register device objects identical to those being
|
|
|
|
* deleted from happening concurrently (such attempts result from
|
|
|
|
* hotplug events handled via the ACPI hotplug workqueue). It also will
|
2021-03-13 01:55:35 +00:00
|
|
|
* run after all of the work items submitted previously, which helps
|
2013-11-22 20:52:12 +00:00
|
|
|
* those work items to ensure that they are not accessing stale device
|
|
|
|
* objects.
|
|
|
|
*/
|
|
|
|
if (list_empty(&acpi_device_del_list))
|
|
|
|
acpi_queue_hotplug_work(&work);
|
|
|
|
|
|
|
|
list_add_tail(&adev->del_list, &acpi_device_del_list);
|
|
|
|
/* Make acpi_ns_validate_handle() return NULL for this handle. */
|
|
|
|
adev->handle = INVALID_ACPI_HANDLE;
|
|
|
|
|
|
|
|
mutex_unlock(&acpi_device_del_lock);
|
2013-07-30 12:38:34 +00:00
|
|
|
}
|
|
|
|
|
2021-01-18 19:25:37 +00:00
|
|
|
static struct acpi_device *handle_to_device(acpi_handle handle,
|
|
|
|
void (*callback)(void *))
|
2013-07-30 12:38:34 +00:00
|
|
|
{
|
2021-01-18 19:25:37 +00:00
|
|
|
struct acpi_device *adev = NULL;
|
2013-07-30 12:38:34 +00:00
|
|
|
acpi_status status;
|
|
|
|
|
2014-02-03 23:43:05 +00:00
|
|
|
status = acpi_get_data_full(handle, acpi_scan_drop_device,
|
2021-01-18 19:25:37 +00:00
|
|
|
(void **)&adev, callback);
|
|
|
|
if (ACPI_FAILURE(status) || !adev) {
|
|
|
|
acpi_handle_debug(handle, "No context!\n");
|
|
|
|
return NULL;
|
2013-07-30 12:38:34 +00:00
|
|
|
}
|
2021-01-18 19:25:37 +00:00
|
|
|
return adev;
|
2013-07-30 12:38:34 +00:00
|
|
|
}
|
2014-02-03 23:43:05 +00:00
|
|
|
|
|
|
|
int acpi_bus_get_device(acpi_handle handle, struct acpi_device **device)
|
|
|
|
{
|
2021-01-18 19:25:37 +00:00
|
|
|
if (!device)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
*device = handle_to_device(handle, NULL);
|
|
|
|
if (!*device)
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
return 0;
|
2014-02-03 23:43:05 +00:00
|
|
|
}
|
2013-10-01 21:02:43 +00:00
|
|
|
EXPORT_SYMBOL(acpi_bus_get_device);
|
2013-07-30 12:38:34 +00:00
|
|
|
|
2021-12-03 16:36:20 +00:00
|
|
|
/**
|
|
|
|
* acpi_fetch_acpi_dev - Retrieve ACPI device object.
|
|
|
|
* @handle: ACPI handle associated with the requested ACPI device object.
|
|
|
|
*
|
|
|
|
* Return a pointer to the ACPI device object associated with @handle, if
|
|
|
|
* present, or NULL otherwise.
|
|
|
|
*/
|
|
|
|
struct acpi_device *acpi_fetch_acpi_dev(acpi_handle handle)
|
|
|
|
{
|
|
|
|
return handle_to_device(handle, NULL);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_fetch_acpi_dev);
|
|
|
|
|
2014-02-03 23:43:05 +00:00
|
|
|
static void get_acpi_device(void *dev)
|
|
|
|
{
|
2021-04-12 22:23:58 +00:00
|
|
|
acpi_dev_get(dev);
|
2014-02-03 23:43:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
struct acpi_device *acpi_bus_get_acpi_device(acpi_handle handle)
|
|
|
|
{
|
2021-01-18 19:25:37 +00:00
|
|
|
return handle_to_device(handle, get_acpi_device);
|
2014-02-03 23:43:05 +00:00
|
|
|
}
|
2021-10-13 16:04:09 +00:00
|
|
|
EXPORT_SYMBOL_GPL(acpi_bus_get_acpi_device);
|
2014-02-03 23:43:05 +00:00
|
|
|
|
2021-01-14 18:46:47 +00:00
|
|
|
static struct acpi_device_bus_id *acpi_device_bus_id_match(const char *dev_id)
|
|
|
|
{
|
|
|
|
struct acpi_device_bus_id *acpi_device_bus_id;
|
|
|
|
|
|
|
|
/* Find suitable bus_id and instance number in acpi_bus_id_list. */
|
|
|
|
list_for_each_entry(acpi_device_bus_id, &acpi_bus_id_list, node) {
|
|
|
|
if (!strcmp(acpi_device_bus_id->bus_id, dev_id))
|
|
|
|
return acpi_device_bus_id;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2021-03-22 16:31:00 +00:00
|
|
|
static int acpi_device_set_name(struct acpi_device *device,
|
|
|
|
struct acpi_device_bus_id *acpi_device_bus_id)
|
|
|
|
{
|
|
|
|
struct ida *instance_ida = &acpi_device_bus_id->instance_ida;
|
|
|
|
int result;
|
|
|
|
|
|
|
|
result = ida_simple_get(instance_ida, 0, ACPI_MAX_DEVICE_INSTANCES, GFP_KERNEL);
|
|
|
|
if (result < 0)
|
|
|
|
return result;
|
|
|
|
|
|
|
|
device->pnp.instance_no = result;
|
|
|
|
dev_set_name(&device->dev, "%s:%02x", acpi_device_bus_id->bus_id, result);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-06-16 14:24:30 +00:00
|
|
|
static int acpi_tie_acpi_dev(struct acpi_device *adev)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2021-06-16 14:24:30 +00:00
|
|
|
acpi_handle handle = adev->handle;
|
|
|
|
acpi_status status;
|
2009-09-21 19:29:05 +00:00
|
|
|
|
2021-06-16 14:24:30 +00:00
|
|
|
if (!handle)
|
|
|
|
return 0;
|
2013-01-17 13:11:05 +00:00
|
|
|
|
2021-06-16 14:24:30 +00:00
|
|
|
status = acpi_attach_data(handle, acpi_scan_drop_device, adev);
|
|
|
|
if (ACPI_FAILURE(status)) {
|
|
|
|
acpi_handle_err(handle, "Unable to attach device data\n");
|
|
|
|
return -ENODEV;
|
2013-01-17 13:11:05 +00:00
|
|
|
}
|
|
|
|
|
2021-06-16 14:24:30 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-12-23 08:16:17 +00:00
|
|
|
static void acpi_store_pld_crc(struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
struct acpi_pld_info *pld;
|
|
|
|
acpi_status status;
|
|
|
|
|
|
|
|
status = acpi_get_physical_device_location(adev->handle, &pld);
|
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
return;
|
|
|
|
|
|
|
|
adev->pld_crc = crc32(~0, pld, sizeof(*pld));
|
|
|
|
ACPI_FREE(pld);
|
|
|
|
}
|
|
|
|
|
2021-06-17 13:57:07 +00:00
|
|
|
static int __acpi_device_add(struct acpi_device *device,
|
|
|
|
void (*release)(struct device *))
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2021-01-14 18:46:47 +00:00
|
|
|
struct acpi_device_bus_id *acpi_device_bus_id;
|
2005-08-05 04:44:28 +00:00
|
|
|
int result;
|
2009-09-21 19:29:05 +00:00
|
|
|
|
2006-12-07 12:56:16 +00: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 06:44:09 +00:00
|
|
|
INIT_LIST_HEAD(&device->physical_node_list);
|
2013-11-22 20:52:12 +00:00
|
|
|
INIT_LIST_HEAD(&device->del_list);
|
2012-08-17 06:44:09 +00:00
|
|
|
mutex_init(&device->physical_node_lock);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2009-04-07 02:24:29 +00:00
|
|
|
mutex_lock(&acpi_device_lock);
|
2021-01-14 18:46:47 +00:00
|
|
|
|
|
|
|
acpi_device_bus_id = acpi_device_bus_id_match(acpi_device_hid(device));
|
|
|
|
if (acpi_device_bus_id) {
|
2021-03-22 16:31:00 +00:00
|
|
|
result = acpi_device_set_name(device, acpi_device_bus_id);
|
|
|
|
if (result)
|
|
|
|
goto err_unlock;
|
2021-01-14 18:46:47 +00:00
|
|
|
} else {
|
|
|
|
acpi_device_bus_id = kzalloc(sizeof(*acpi_device_bus_id),
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (!acpi_device_bus_id) {
|
|
|
|
result = -ENOMEM;
|
|
|
|
goto err_unlock;
|
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 09:23:43 +00:00
|
|
|
}
|
2021-01-08 07:23:48 +00:00
|
|
|
acpi_device_bus_id->bus_id =
|
|
|
|
kstrdup_const(acpi_device_hid(device), GFP_KERNEL);
|
|
|
|
if (!acpi_device_bus_id->bus_id) {
|
2021-01-14 18:46:47 +00:00
|
|
|
kfree(acpi_device_bus_id);
|
2021-01-08 07:23:48 +00:00
|
|
|
result = -ENOMEM;
|
2021-01-14 18:46:47 +00:00
|
|
|
goto err_unlock;
|
2021-01-08 07:23:48 +00:00
|
|
|
}
|
|
|
|
|
2021-03-22 16:31:00 +00:00
|
|
|
ida_init(&acpi_device_bus_id->instance_ida);
|
|
|
|
|
|
|
|
result = acpi_device_set_name(device, acpi_device_bus_id);
|
|
|
|
if (result) {
|
2021-05-08 07:23:09 +00:00
|
|
|
kfree_const(acpi_device_bus_id->bus_id);
|
2021-03-22 16:31:00 +00:00
|
|
|
kfree(acpi_device_bus_id);
|
|
|
|
goto err_unlock;
|
|
|
|
}
|
|
|
|
|
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 09:23:43 +00:00
|
|
|
list_add_tail(&acpi_device_bus_id->node, &acpi_bus_id_list);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2008-12-16 03:09:26 +00:00
|
|
|
if (device->parent)
|
2006-12-07 12:56:16 +00:00
|
|
|
list_add_tail(&device->node, &device->parent->children);
|
2008-12-16 03:09:26 +00:00
|
|
|
|
2006-12-07 12:56:16 +00:00
|
|
|
if (device->wakeup.flags.valid)
|
|
|
|
list_add_tail(&device->wakeup_list, &acpi_wakeup_device_list);
|
2021-01-14 18:47:37 +00:00
|
|
|
|
2021-12-23 08:16:17 +00:00
|
|
|
acpi_store_pld_crc(device);
|
|
|
|
|
2009-04-07 02:24:29 +00:00
|
|
|
mutex_unlock(&acpi_device_lock);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2006-12-07 12:56:31 +00:00
|
|
|
if (device->parent)
|
2009-09-21 19:29:05 +00:00
|
|
|
device->dev.parent = &device->parent->dev;
|
2021-01-14 18:47:37 +00:00
|
|
|
|
2006-12-07 12:56:31 +00:00
|
|
|
device->dev.bus = &acpi_bus_type;
|
2013-01-17 13:11:05 +00:00
|
|
|
device->dev.release = release;
|
2013-01-24 11:49:49 +00:00
|
|
|
result = device_add(&device->dev);
|
2009-05-14 14:31:37 +00:00
|
|
|
if (result) {
|
2009-05-14 14:31:32 +00:00
|
|
|
dev_err(&device->dev, "Error registering device\n");
|
2013-01-17 13:11:05 +00:00
|
|
|
goto err;
|
2005-04-16 22:20:36 +00: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 09:23:43 +00:00
|
|
|
result = acpi_device_setup_files(device);
|
2009-05-14 14:31:37 +00:00
|
|
|
if (result)
|
2021-06-02 08:54:37 +00:00
|
|
|
pr_err("Error creating sysfs interface for device %s\n",
|
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 00:18:59 +00:00
|
|
|
dev_name(&device->dev));
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
return 0;
|
2013-01-17 13:11:05 +00:00
|
|
|
|
2021-01-14 18:47:37 +00:00
|
|
|
err:
|
2009-04-07 02:24:29 +00:00
|
|
|
mutex_lock(&acpi_device_lock);
|
2021-01-14 18:47:37 +00:00
|
|
|
|
2008-12-16 03:09:26 +00: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 09:23:43 +00:00
|
|
|
list_del(&device->node);
|
2021-01-08 07:23:48 +00: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 09:23:43 +00:00
|
|
|
list_del(&device->wakeup_list);
|
2021-01-08 07:23:48 +00:00
|
|
|
|
2021-01-14 18:47:37 +00:00
|
|
|
err_unlock:
|
2009-04-07 02:24:29 +00:00
|
|
|
mutex_unlock(&acpi_device_lock);
|
2013-01-17 13:11:05 +00:00
|
|
|
|
2013-11-22 20:52:12 +00:00
|
|
|
acpi_detach_data(device->handle, acpi_scan_drop_device);
|
2021-01-14 18:47:37 +00: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 09:23:43 +00:00
|
|
|
return result;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2021-06-17 13:57:07 +00:00
|
|
|
int acpi_device_add(struct acpi_device *adev, void (*release)(struct device *))
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = acpi_tie_acpi_dev(adev);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
return __acpi_device_add(adev, release);
|
|
|
|
}
|
|
|
|
|
2006-12-07 12:56:16 +00:00
|
|
|
/* --------------------------------------------------------------------------
|
|
|
|
Device Enumeration
|
|
|
|
-------------------------------------------------------------------------- */
|
2020-12-05 15:29:41 +00:00
|
|
|
static bool acpi_info_matches_ids(struct acpi_device_info *info,
|
|
|
|
const char * const ids[])
|
2020-11-21 20:30:34 +00:00
|
|
|
{
|
2020-12-05 15:29:41 +00:00
|
|
|
struct acpi_pnp_device_id_list *cid_list = NULL;
|
2021-04-10 14:02:53 +00:00
|
|
|
int i, index;
|
2020-11-21 20:30:34 +00:00
|
|
|
|
|
|
|
if (!(info->valid & ACPI_VALID_HID))
|
|
|
|
return false;
|
|
|
|
|
2021-04-10 14:02:53 +00:00
|
|
|
index = match_string(ids, -1, info->hardware_id.string);
|
|
|
|
if (index >= 0)
|
|
|
|
return true;
|
|
|
|
|
2020-12-05 15:29:41 +00:00
|
|
|
if (info->valid & ACPI_VALID_CID)
|
|
|
|
cid_list = &info->compatible_id_list;
|
|
|
|
|
2021-04-10 14:02:53 +00:00
|
|
|
if (!cid_list)
|
|
|
|
return false;
|
2020-12-05 15:29:41 +00:00
|
|
|
|
2021-04-10 14:02:53 +00:00
|
|
|
for (i = 0; i < cid_list->count; i++) {
|
|
|
|
index = match_string(ids, -1, cid_list->ids[i].string);
|
|
|
|
if (index >= 0)
|
2020-11-21 20:30:34 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* List of HIDs for which we ignore matching ACPI devices, when checking _DEP lists. */
|
2020-12-05 15:29:41 +00:00
|
|
|
static const char * const acpi_ignore_dep_ids[] = {
|
|
|
|
"PNP0D80", /* Windows-compatible System Power Management Controller */
|
2020-12-15 11:26:02 +00:00
|
|
|
"INT33BD", /* Intel Baytrail Mailbox Device */
|
2020-11-21 20:30:34 +00:00
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
ACPI: delay enumeration of devices with a _DEP pointing to an INT3472 device
The clk and regulator frameworks expect clk/regulator consumer-devices
to have info about the consumed clks/regulators described in the device's
fw_node.
To work around cases where this info is not present in the firmware tables,
which is often the case on x86/ACPI devices, both frameworks allow the
provider-driver to attach info about consumers to the clks/regulators
when registering these.
This causes problems with the probe ordering wrt drivers for consumers
of these clks/regulators. Since the lookups are only registered when the
provider-driver binds, trying to get these clks/regulators before then
results in a -ENOENT error for clks and a dummy regulator for regulators.
One case where we hit this issue is camera sensors such as e.g. the OV8865
sensor found on the Microsoft Surface Go. The sensor uses clks, regulators
and GPIOs provided by a TPS68470 PMIC which is described in an INT3472
ACPI device. There is special platform code handling this and setting
platform_data with the necessary consumer info on the MFD cells
instantiated for the PMIC under: drivers/platform/x86/intel/int3472.
For this to work properly the ov8865 driver must not bind to the I2C-client
for the OV8865 sensor until after the TPS68470 PMIC gpio, regulator and
clk MFD cells have all been fully setup.
The OV8865 on the Microsoft Surface Go is just one example, all X86
devices using the Intel IPU3 camera block found on recent Intel SoCs
have similar issues where there is an INT3472 HID ACPI-device, which
describes the clks and regulators, and the driver for this INT3472 device
must be fully initialized before the sensor driver (any sensor driver)
binds for things to work properly.
On these devices the ACPI nodes describing the sensors all have a _DEP
dependency on the matching INT3472 ACPI device (there is one per sensor).
This allows solving the probe-ordering problem by delaying the enumeration
(instantiation of the I2C-client in the ov8865 example) of ACPI-devices
which have a _DEP dependency on an INT3472 device.
The new acpi_dev_ready_for_enumeration() helper used for this is also
exported because for devices, which have the enumeration_by_parent flag
set, the parent-driver will do its own scan of child ACPI devices and
it will try to enumerate those during its probe(). Code doing this such
as e.g. the i2c-core-acpi.c code must call this new helper to ensure
that it too delays the enumeration until all the _DEP dependencies are
met on devices which have the new honor_deps flag set.
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211203102857.44539-2-hdegoede@redhat.com
2021-12-03 10:28:44 +00:00
|
|
|
/* List of HIDs for which we honor deps of matching ACPI devs, when checking _DEP lists. */
|
|
|
|
static const char * const acpi_honor_dep_ids[] = {
|
|
|
|
"INT3472", /* Camera sensor PMIC / clk and regulator info */
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
2009-09-21 19:29:35 +00:00
|
|
|
static struct acpi_device *acpi_bus_get_parent(acpi_handle handle)
|
|
|
|
{
|
2021-12-03 16:36:20 +00:00
|
|
|
struct acpi_device *device;
|
2009-09-21 19:29:35 +00: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 19:57:40 +00:00
|
|
|
if (!handle)
|
2009-09-21 19:29:35 +00:00
|
|
|
return acpi_root;
|
|
|
|
|
|
|
|
do {
|
|
|
|
status = acpi_get_parent(handle, &handle);
|
|
|
|
if (ACPI_FAILURE(status))
|
2013-01-31 19:57:40 +00:00
|
|
|
return status == AE_NULL_ENTRY ? NULL : acpi_root;
|
2021-12-03 16:36:20 +00:00
|
|
|
|
|
|
|
device = acpi_fetch_acpi_dev(handle);
|
|
|
|
} while (!device);
|
2013-01-31 19:57:40 +00:00
|
|
|
return device;
|
2009-09-21 19:29:35 +00:00
|
|
|
}
|
|
|
|
|
2006-12-07 12:56:16 +00: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 12:40:34 +00:00
|
|
|
status = acpi_get_handle(ACPI_ROOT_OBJECT, obj->string.pointer,
|
|
|
|
ejd);
|
2006-12-07 12:56:16 +00:00
|
|
|
kfree(buffer.pointer);
|
|
|
|
}
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_bus_get_ejd);
|
|
|
|
|
2019-03-25 18:34:02 +00:00
|
|
|
static int acpi_bus_extract_wakeup_device_power_package(struct acpi_device *dev)
|
2006-12-07 12:56:16 +00:00
|
|
|
{
|
2019-03-25 18:34:02 +00:00
|
|
|
acpi_handle handle = dev->handle;
|
|
|
|
struct acpi_device_wakeup *wakeup = &dev->wakeup;
|
2010-12-17 21:34:01 +00:00
|
|
|
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
|
|
|
|
union acpi_object *package = NULL;
|
2006-12-07 12:56:16 +00:00
|
|
|
union acpi_object *element = NULL;
|
2010-12-17 21:34:01 +00:00
|
|
|
acpi_status status;
|
2013-01-17 13:11:07 +00:00
|
|
|
int err = -ENODATA;
|
2006-12-07 12:56:16 +00:00
|
|
|
|
2013-01-17 13:11:06 +00:00
|
|
|
INIT_LIST_HEAD(&wakeup->resources);
|
2006-12-07 12:56:16 +00:00
|
|
|
|
2010-12-17 21:34:01 +00:00
|
|
|
/* _PRW */
|
|
|
|
status = acpi_evaluate_object(handle, "_PRW", NULL, &buffer);
|
|
|
|
if (ACPI_FAILURE(status)) {
|
2021-01-20 18:59:51 +00:00
|
|
|
acpi_handle_info(handle, "_PRW evaluation failed: %s\n",
|
|
|
|
acpi_format_exception(status));
|
2013-01-17 13:11:07 +00:00
|
|
|
return err;
|
2010-12-17 21:34:01 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
package = (union acpi_object *)buffer.pointer;
|
|
|
|
|
2013-01-17 13:11:07 +00:00
|
|
|
if (!package || package->package.count < 2)
|
2010-12-17 21:34:01 +00:00
|
|
|
goto out;
|
|
|
|
|
2006-12-07 12:56:16 +00:00
|
|
|
element = &(package->package.elements[0]);
|
2013-01-17 13:11:07 +00:00
|
|
|
if (!element)
|
2010-12-17 21:34:01 +00:00
|
|
|
goto out;
|
2013-01-17 13:11:07 +00:00
|
|
|
|
2006-12-07 12:56:16 +00:00
|
|
|
if (element->type == ACPI_TYPE_PACKAGE) {
|
|
|
|
if ((element->package.count < 2) ||
|
|
|
|
(element->package.elements[0].type !=
|
|
|
|
ACPI_TYPE_LOCAL_REFERENCE)
|
2013-01-17 13:11:07 +00:00
|
|
|
|| (element->package.elements[1].type != ACPI_TYPE_INTEGER))
|
2010-12-17 21:34:01 +00:00
|
|
|
goto out;
|
2013-01-17 13:11:07 +00:00
|
|
|
|
2010-12-17 21:34:01 +00:00
|
|
|
wakeup->gpe_device =
|
2006-12-07 12:56:16 +00:00
|
|
|
element->package.elements[0].reference.handle;
|
2010-12-17 21:34:01 +00:00
|
|
|
wakeup->gpe_number =
|
2006-12-07 12:56:16 +00:00
|
|
|
(u32) element->package.elements[1].integer.value;
|
|
|
|
} else if (element->type == ACPI_TYPE_INTEGER) {
|
2010-12-17 21:34:01 +00:00
|
|
|
wakeup->gpe_device = NULL;
|
|
|
|
wakeup->gpe_number = element->integer.value;
|
|
|
|
} else {
|
|
|
|
goto out;
|
|
|
|
}
|
2006-12-07 12:56:16 +00:00
|
|
|
|
|
|
|
element = &(package->package.elements[1]);
|
2013-01-17 13:11:07 +00:00
|
|
|
if (element->type != ACPI_TYPE_INTEGER)
|
2010-12-17 21:34:01 +00:00
|
|
|
goto out;
|
2013-01-17 13:11:07 +00:00
|
|
|
|
2010-12-17 21:34:01 +00:00
|
|
|
wakeup->sleep_state = element->integer.value;
|
2006-12-07 12:56:16 +00:00
|
|
|
|
2013-01-17 13:11:07 +00:00
|
|
|
err = acpi_extract_power_resources(package, 2, &wakeup->resources);
|
|
|
|
if (err)
|
2010-12-17 21:34:01 +00:00
|
|
|
goto out;
|
2006-12-07 12:56:16 +00:00
|
|
|
|
2013-01-17 13:11:07 +00:00
|
|
|
if (!list_empty(&wakeup->resources)) {
|
|
|
|
int sleep_state;
|
2006-12-07 12:56:16 +00:00
|
|
|
|
ACPI / PM: Take unusual configurations of power resources into account
Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device
wakeup) moved the initial disabling of system wakeup for PCI devices
into a place where it can actually work and that exposed a hidden old
issue with crap^Wunusual system designs where the same power
resources are used for both wakeup power and device power control at
run time.
Namely, say there is one power resource such that the ACPI power
state D0 of a PCI device depends on that power resource (i.e. the
device is in D0 when that power resource is "on") and it is used
as a wakeup power resource for the same device. Then, calling
acpi_pci_sleep_wake(pci_dev, false) for the device in question will
cause the reference counter of that power resource to drop to 0,
which in turn will cause it to be turned off. As a result, the
device will go into D3cold at that point, although it should have
stayed in D0.
As it turns out, that happens to USB controllers on some laptops
and USB becomes unusable on those machines as a result, which is
a major regression from v3.8.
To fix this problem, (1) increment the reference counters of wakup
power resources during their initialization if they are "on"
initially, (2) prevent acpi_disable_wakeup_device_power() from
decrementing the reference counters of wakeup power resources that
were not enabled for wakeup power previously, and (3) prevent
acpi_enable_wakeup_device_power() from incrementing the reference
counters of wakeup power resources that already are enabled for
wakeup power.
In addition to that, if it is impossible to determine the initial
states of wakeup power resources, avoid enabling wakeup for devices
whose wakeup power depends on those power resources.
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Tested-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-02-23 22:15:21 +00: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 13:11:07 +00: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;
|
|
|
|
}
|
|
|
|
}
|
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-07 22:43:36 +00:00
|
|
|
|
2010-12-17 21:34:01 +00:00
|
|
|
out:
|
|
|
|
kfree(buffer.pointer);
|
2013-01-17 13:11:07 +00:00
|
|
|
return err;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2017-06-23 23:53:14 +00:00
|
|
|
static bool acpi_wakeup_gpe_init(struct acpi_device *device)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2015-06-13 12:26:58 +00:00
|
|
|
static const struct acpi_device_id button_device_ids[] = {
|
2019-03-25 18:34:03 +00:00
|
|
|
{"PNP0C0C", 0}, /* Power button */
|
|
|
|
{"PNP0C0D", 0}, /* Lid */
|
|
|
|
{"PNP0C0E", 0}, /* Sleep button */
|
2007-07-23 12:43:51 +00:00
|
|
|
{"", 0},
|
|
|
|
};
|
2014-07-14 20:41:41 +00:00
|
|
|
struct acpi_device_wakeup *wakeup = &device->wakeup;
|
2010-02-17 22:41:49 +00:00
|
|
|
acpi_status status;
|
|
|
|
|
2014-07-14 20:41:41 +00:00
|
|
|
wakeup->flags.notifier_present = 0;
|
2010-02-17 22:41:49 +00:00
|
|
|
|
|
|
|
/* Power button, Lid switch always enable wakeup */
|
|
|
|
if (!acpi_match_device_ids(device, button_device_ids)) {
|
2012-12-04 22:23:16 +00:00
|
|
|
if (!acpi_match_device_ids(device, &button_device_ids[1])) {
|
|
|
|
/* Do not use Lid/sleep button for S5 wakeup */
|
2014-07-14 20:41:41 +00:00
|
|
|
if (wakeup->sleep_state == ACPI_STATE_S5)
|
|
|
|
wakeup->sleep_state = ACPI_STATE_S4;
|
2012-12-04 22:23:16 +00:00
|
|
|
}
|
2014-07-14 20:41:41 +00:00
|
|
|
acpi_mark_gpe_for_wake(wakeup->gpe_device, wakeup->gpe_number);
|
2011-01-06 22:34:22 +00:00
|
|
|
device_set_wakeup_capable(&device->dev, true);
|
2017-06-23 23:53:14 +00:00
|
|
|
return true;
|
2010-02-17 22:41:49 +00:00
|
|
|
}
|
|
|
|
|
2017-06-23 23:53:14 +00:00
|
|
|
status = acpi_setup_gpe_for_wake(device->handle, wakeup->gpe_device,
|
|
|
|
wakeup->gpe_number);
|
|
|
|
return ACPI_SUCCESS(status);
|
2010-02-17 22:41:49 +00:00
|
|
|
}
|
|
|
|
|
2011-01-06 22:41:27 +00:00
|
|
|
static void acpi_bus_get_wakeup_device_flags(struct acpi_device *device)
|
2010-02-17 22:41:49 +00:00
|
|
|
{
|
2013-01-17 13:11:07 +00:00
|
|
|
int err;
|
2007-07-23 12:43:51 +00:00
|
|
|
|
2011-01-06 22:41:27 +00:00
|
|
|
/* Presence of _PRW indicates wake capable */
|
2013-06-28 16:24:38 +00:00
|
|
|
if (!acpi_has_method(device->handle, "_PRW"))
|
2011-01-06 22:41:27 +00:00
|
|
|
return;
|
|
|
|
|
2019-03-25 18:34:02 +00:00
|
|
|
err = acpi_bus_extract_wakeup_device_power_package(device);
|
2013-01-17 13:11:07 +00:00
|
|
|
if (err) {
|
2021-01-20 18:59:51 +00:00
|
|
|
dev_err(&device->dev, "Unable to extract wakeup power resources");
|
2011-01-06 22:41:27 +00:00
|
|
|
return;
|
2006-12-07 12:56:16 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2017-06-23 23:53:14 +00:00
|
|
|
device->wakeup.flags.valid = acpi_wakeup_gpe_init(device);
|
2009-09-08 21:15:31 +00:00
|
|
|
device->wakeup.prepare_count = 0;
|
2017-06-23 23:53:14 +00:00
|
|
|
/*
|
|
|
|
* Call _PSW/_DSW object to disable its ability to wake the sleeping
|
2008-03-19 05:26:54 +00:00
|
|
|
* system for the ACPI device with the _PRW object.
|
2019-03-25 18:34:00 +00:00
|
|
|
* The _PSW object is deprecated in ACPI 3.0 and is replaced by _DSW.
|
2008-03-19 05:26:54 +00:00
|
|
|
* So it is necessary to call _DSW object first. Only when it is not
|
|
|
|
* present will the _PSW object used.
|
|
|
|
*/
|
2013-01-17 13:11:07 +00:00
|
|
|
err = acpi_device_sleep_wake(device, 0, 0, 0);
|
|
|
|
if (err)
|
2020-09-27 01:14:28 +00:00
|
|
|
pr_debug("error in _DSW or _PSW evaluation\n");
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2013-01-17 13:11:06 +00: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 13:11:07 +00:00
|
|
|
char pathname[5] = { '_', 'P', 'R', '0' + state, '\0' };
|
|
|
|
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
|
2013-01-17 13:11:06 +00:00
|
|
|
acpi_status status;
|
2010-11-24 23:10:44 +00:00
|
|
|
|
2013-01-17 13:11:06 +00:00
|
|
|
INIT_LIST_HEAD(&ps->resources);
|
|
|
|
|
2013-01-17 13:11:07 +00: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
|
ACPI: PM: Avoid using power resources if there are none for D0
As recently reported, some platforms provide a list of power
resources for device power state D3hot, through the _PR3 object,
but they do not provide a list of power resources for device power
state D0.
Among other things, this causes acpi_device_get_power() to return
D3hot as the current state of the device in question if all of the
D3hot power resources are "on", because it sees the power_resources
flag set and calls acpi_power_get_inferred_state() which finds that
D3hot is the shallowest power state with all of the associated power
resources turned "on", so that's what it returns. Moreover, that
value takes precedence over the acpi_dev_pm_explicit_get() return
value, because it means a deeper power state. The device may very
well be in D0 physically at that point, however.
Moreover, the presence of _PR3 without _PR0 for a given device
means that only one D3-level power state can be supported by it.
Namely, because there are no power resources to turn "off" when
transitioning the device from D0 into D3cold (which should be
supported since _PR3 is present), the evaluation of _PS3 should
be sufficient to put it straight into D3cold, but this means that
the effect of turning "on" the _PR3 power resources is unclear,
so it is better to avoid doing that altogether. Consequently,
there is no practical way do distinguish D3cold from D3hot for
the device in question and the power states of it can be labeled
so that D3hot is the deepest supported one (and Linux assumes
that putting a device into D3hot via ACPI may cause power to be
removed from it anyway, for legacy reasons).
To work around the problem described above modify the ACPI
enumeration of devices so that power resources are only used
for device power management if the list of D0 power resources
is not empty and make it mart D3cold as supported only if that
is the case and the D3hot list of power resources is not empty
too.
Fixes: ef85bdbec444 ("ACPI / scan: Consolidate extraction of power resources lists")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=205057
Link: https://lore.kernel.org/linux-acpi/20200603194659.185757-1-hdegoede@redhat.com/
Reported-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: youling257@gmail.com
Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2020-06-04 17:22:26 +00:00
|
|
|
&& package->package.count)
|
|
|
|
acpi_extract_power_resources(package, 0, &ps->resources);
|
|
|
|
|
2013-01-17 13:11:07 +00:00
|
|
|
ACPI_FREE(buffer.pointer);
|
2013-01-17 13:11:06 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Evaluate "_PSx" to see if we can do explicit sets */
|
2013-01-17 13:11:07 +00:00
|
|
|
pathname[2] = 'S';
|
2013-06-28 16:24:38 +00:00
|
|
|
if (acpi_has_method(device->handle, pathname))
|
2013-01-17 13:11:06 +00:00
|
|
|
ps->flags.explicit_set = 1;
|
|
|
|
|
2015-05-15 23:55:35 +00:00
|
|
|
/* State is valid if there are means to put the device into it. */
|
|
|
|
if (!list_empty(&ps->resources) || ps->flags.explicit_set)
|
2013-01-17 13:11:06 +00:00
|
|
|
ps->flags.valid = 1;
|
|
|
|
|
|
|
|
ps->power = -1; /* Unknown - driver assigned */
|
|
|
|
ps->latency = -1; /* Unknown - driver assigned */
|
|
|
|
}
|
|
|
|
|
2013-01-17 13:11:05 +00:00
|
|
|
static void acpi_bus_get_power_flags(struct acpi_device *device)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2021-10-18 12:17:24 +00:00
|
|
|
unsigned long long dsc = ACPI_STATE_D0;
|
2013-01-17 13:11:07 +00:00
|
|
|
u32 i;
|
2006-03-28 22:04:00 +00:00
|
|
|
|
2013-01-17 13:11:05 +00:00
|
|
|
/* Presence of _PS0|_PR0 indicates 'power manageable' */
|
2013-06-28 16:24:38 +00:00
|
|
|
if (!acpi_has_method(device->handle, "_PS0") &&
|
|
|
|
!acpi_has_method(device->handle, "_PR0"))
|
|
|
|
return;
|
2006-03-28 22:04:00 +00:00
|
|
|
|
2013-01-17 13:11:05 +00:00
|
|
|
device->flags.power_manageable = 1;
|
2005-08-05 04:44:28 +00:00
|
|
|
|
2006-12-07 12:56:16 +00:00
|
|
|
/*
|
|
|
|
* Power Management Flags
|
|
|
|
*/
|
2013-06-28 16:24:38 +00:00
|
|
|
if (acpi_has_method(device->handle, "_PSC"))
|
2006-12-07 12:56:16 +00:00
|
|
|
device->power.flags.explicit_get = 1;
|
2014-05-16 22:18:13 +00:00
|
|
|
|
2013-06-28 16:24:38 +00:00
|
|
|
if (acpi_has_method(device->handle, "_IRC"))
|
2006-12-07 12:56:16 +00:00
|
|
|
device->power.flags.inrush_current = 1;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2014-05-16 22:18:13 +00:00
|
|
|
if (acpi_has_method(device->handle, "_DSW"))
|
|
|
|
device->power.flags.dsw_present = 1;
|
|
|
|
|
2021-10-18 12:17:24 +00:00
|
|
|
acpi_evaluate_integer(device->handle, "_DSC", NULL, &dsc);
|
|
|
|
device->power.state_for_enumeration = dsc;
|
|
|
|
|
2006-12-07 12:56:16 +00:00
|
|
|
/*
|
|
|
|
* Enumerate supported power management states
|
|
|
|
*/
|
2013-01-17 13:11:06 +00:00
|
|
|
for (i = ACPI_STATE_D0; i <= ACPI_STATE_D3_HOT; i++)
|
|
|
|
acpi_bus_init_power_state(device, i);
|
2010-11-24 23:10:44 +00:00
|
|
|
|
2013-01-17 13:11:06 +00:00
|
|
|
INIT_LIST_HEAD(&device->power.states[ACPI_STATE_D3_COLD].resources);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
ACPI: PM: Avoid using power resources if there are none for D0
As recently reported, some platforms provide a list of power
resources for device power state D3hot, through the _PR3 object,
but they do not provide a list of power resources for device power
state D0.
Among other things, this causes acpi_device_get_power() to return
D3hot as the current state of the device in question if all of the
D3hot power resources are "on", because it sees the power_resources
flag set and calls acpi_power_get_inferred_state() which finds that
D3hot is the shallowest power state with all of the associated power
resources turned "on", so that's what it returns. Moreover, that
value takes precedence over the acpi_dev_pm_explicit_get() return
value, because it means a deeper power state. The device may very
well be in D0 physically at that point, however.
Moreover, the presence of _PR3 without _PR0 for a given device
means that only one D3-level power state can be supported by it.
Namely, because there are no power resources to turn "off" when
transitioning the device from D0 into D3cold (which should be
supported since _PR3 is present), the evaluation of _PS3 should
be sufficient to put it straight into D3cold, but this means that
the effect of turning "on" the _PR3 power resources is unclear,
so it is better to avoid doing that altogether. Consequently,
there is no practical way do distinguish D3cold from D3hot for
the device in question and the power states of it can be labeled
so that D3hot is the deepest supported one (and Linux assumes
that putting a device into D3hot via ACPI may cause power to be
removed from it anyway, for legacy reasons).
To work around the problem described above modify the ACPI
enumeration of devices so that power resources are only used
for device power management if the list of D0 power resources
is not empty and make it mart D3cold as supported only if that
is the case and the D3hot list of power resources is not empty
too.
Fixes: ef85bdbec444 ("ACPI / scan: Consolidate extraction of power resources lists")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=205057
Link: https://lore.kernel.org/linux-acpi/20200603194659.185757-1-hdegoede@redhat.com/
Reported-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: youling257@gmail.com
Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2020-06-04 17:22:26 +00:00
|
|
|
/* Set the defaults for D0 and D3hot (always supported). */
|
2006-12-07 12:56:16 +00:00
|
|
|
device->power.states[ACPI_STATE_D0].flags.valid = 1;
|
|
|
|
device->power.states[ACPI_STATE_D0].power = 100;
|
2015-05-15 23:55:35 +00:00
|
|
|
device->power.states[ACPI_STATE_D3_HOT].flags.valid = 1;
|
2012-11-21 22:33:40 +00:00
|
|
|
|
ACPI: PM: Avoid using power resources if there are none for D0
As recently reported, some platforms provide a list of power
resources for device power state D3hot, through the _PR3 object,
but they do not provide a list of power resources for device power
state D0.
Among other things, this causes acpi_device_get_power() to return
D3hot as the current state of the device in question if all of the
D3hot power resources are "on", because it sees the power_resources
flag set and calls acpi_power_get_inferred_state() which finds that
D3hot is the shallowest power state with all of the associated power
resources turned "on", so that's what it returns. Moreover, that
value takes precedence over the acpi_dev_pm_explicit_get() return
value, because it means a deeper power state. The device may very
well be in D0 physically at that point, however.
Moreover, the presence of _PR3 without _PR0 for a given device
means that only one D3-level power state can be supported by it.
Namely, because there are no power resources to turn "off" when
transitioning the device from D0 into D3cold (which should be
supported since _PR3 is present), the evaluation of _PS3 should
be sufficient to put it straight into D3cold, but this means that
the effect of turning "on" the _PR3 power resources is unclear,
so it is better to avoid doing that altogether. Consequently,
there is no practical way do distinguish D3cold from D3hot for
the device in question and the power states of it can be labeled
so that D3hot is the deepest supported one (and Linux assumes
that putting a device into D3hot via ACPI may cause power to be
removed from it anyway, for legacy reasons).
To work around the problem described above modify the ACPI
enumeration of devices so that power resources are only used
for device power management if the list of D0 power resources
is not empty and make it mart D3cold as supported only if that
is the case and the D3hot list of power resources is not empty
too.
Fixes: ef85bdbec444 ("ACPI / scan: Consolidate extraction of power resources lists")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=205057
Link: https://lore.kernel.org/linux-acpi/20200603194659.185757-1-hdegoede@redhat.com/
Reported-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: youling257@gmail.com
Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2020-06-04 17:22:26 +00:00
|
|
|
/*
|
|
|
|
* Use power resources only if the D0 list of them is populated, because
|
|
|
|
* some platforms may provide _PR3 only to indicate D3cold support and
|
|
|
|
* in those cases the power resources list returned by it may be bogus.
|
|
|
|
*/
|
|
|
|
if (!list_empty(&device->power.states[ACPI_STATE_D0].resources)) {
|
|
|
|
device->power.flags.power_resources = 1;
|
|
|
|
/*
|
|
|
|
* D3cold is supported if the D3hot list of power resources is
|
|
|
|
* not empty.
|
|
|
|
*/
|
|
|
|
if (!list_empty(&device->power.states[ACPI_STATE_D3_HOT].resources))
|
|
|
|
device->power.states[ACPI_STATE_D3_COLD].flags.valid = 1;
|
|
|
|
}
|
|
|
|
|
ACPI / PM: Fix PM initialization for devices that are not present
If an ACPI device object whose _STA returns 0 (not present and not
functional) has _PR0 or _PS0, its power_manageable flag will be set
and acpi_bus_init_power() will return 0 for it. Consequently, if
such a device object is passed to the ACPI device PM functions, they
will attempt to carry out the requested operation on the device,
although they should not do that for devices that are not present.
To fix that problem make acpi_bus_init_power() return an error code
for devices that are not present which will cause power_manageable to
be cleared for them as appropriate in acpi_bus_get_power_flags().
However, the lists of power resources should not be freed for the
device in that case, so modify acpi_bus_get_power_flags() to keep
those lists even if acpi_bus_init_power() returns an error.
Accordingly, when deciding whether or not the lists of power
resources need to be freed, acpi_free_power_resources_lists()
should check the power.flags.power_resources flag instead of
flags.power_manageable, so make that change too.
Furthermore, if acpi_bus_attach() sees that flags.initialized is
unset for the given device, it should reset the power management
settings of the device and re-initialize them from scratch instead
of relying on the previous settings (the device may have appeared
after being not present previously, for example), so make it use
the 'valid' flag of the D0 power state as the initial value of
flags.power_manageable for it and call acpi_bus_init_power() to
discover its current power state.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
2015-01-01 22:38:28 +00:00
|
|
|
if (acpi_bus_init_power(device))
|
2013-02-01 22:43:02 +00:00
|
|
|
device->flags.power_manageable = 0;
|
2006-12-07 12:56:16 +00:00
|
|
|
}
|
2006-07-09 21:22:28 +00:00
|
|
|
|
2013-01-17 13:11:05 +00:00
|
|
|
static void acpi_bus_get_flags(struct acpi_device *device)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
/* Presence of _STA indicates 'dynamic_status' */
|
2013-06-28 16:24:38 +00:00
|
|
|
if (acpi_has_method(device->handle, "_STA"))
|
2005-04-16 22:20:36 +00:00
|
|
|
device->flags.dynamic_status = 1;
|
|
|
|
|
|
|
|
/* Presence of _RMV indicates 'removable' */
|
2013-06-28 16:24:38 +00:00
|
|
|
if (acpi_has_method(device->handle, "_RMV"))
|
2005-04-16 22:20:36 +00:00
|
|
|
device->flags.removable = 1;
|
|
|
|
|
|
|
|
/* Presence of _EJD|_EJ0 indicates 'ejectable' */
|
2013-06-28 16:24:38 +00:00
|
|
|
if (acpi_has_method(device->handle, "_EJD") ||
|
|
|
|
acpi_has_method(device->handle, "_EJ0"))
|
2005-04-16 22:20:36 +00:00
|
|
|
device->flags.ejectable = 1;
|
|
|
|
}
|
|
|
|
|
2009-09-21 19:29:25 +00:00
|
|
|
static void acpi_device_get_busid(struct acpi_device *device)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2005-08-05 04:44:28 +00:00
|
|
|
char bus_id[5] = { '?', 0 };
|
|
|
|
struct acpi_buffer buffer = { sizeof(bus_id), bus_id };
|
|
|
|
int i = 0;
|
2005-04-16 22:20:36 +00: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 19:29:50 +00:00
|
|
|
if (ACPI_IS_ROOT_DEVICE(device)) {
|
2005-04-16 22:20:36 +00:00
|
|
|
strcpy(device->pnp.bus_id, "ACPI");
|
2009-09-21 19:29:50 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (device->device_type) {
|
2005-04-16 22:20:36 +00: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;
|
2017-09-26 08:54:09 +00:00
|
|
|
case ACPI_BUS_TYPE_ECDT_EC:
|
|
|
|
strcpy(device->pnp.bus_id, "ECDT");
|
|
|
|
break;
|
2005-04-16 22:20:36 +00:00
|
|
|
default:
|
2009-09-21 19:29:05 +00:00
|
|
|
acpi_get_name(device->handle, ACPI_SINGLE_NAME, &buffer);
|
2005-04-16 22:20:36 +00: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 16:24:41 +00: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 07:09:09 +00:00
|
|
|
/*
|
2013-03-04 21:30:41 +00:00
|
|
|
* acpi_bay_match - see if an acpi object is an ejectable driver bay
|
2007-01-11 07:09:09 +00: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 16:24:41 +00:00
|
|
|
bool acpi_bay_match(acpi_handle handle)
|
2013-03-04 21:30:41 +00:00
|
|
|
{
|
2007-01-11 07:09:09 +00:00
|
|
|
acpi_handle phandle;
|
|
|
|
|
2013-06-28 16:24:38 +00:00
|
|
|
if (!acpi_has_method(handle, "_EJ0"))
|
2013-06-28 16:24:41 +00:00
|
|
|
return false;
|
|
|
|
if (acpi_ata_match(handle))
|
|
|
|
return true;
|
|
|
|
if (ACPI_FAILURE(acpi_get_parent(handle, &phandle)))
|
|
|
|
return false;
|
2007-01-11 07:09:09 +00:00
|
|
|
|
2013-06-28 16:24:41 +00:00
|
|
|
return acpi_ata_match(phandle);
|
2007-01-11 07:09:09 +00:00
|
|
|
}
|
|
|
|
|
2014-02-15 23:09:34 +00:00
|
|
|
bool acpi_device_is_battery(struct acpi_device *adev)
|
ACPI / dock: Dispatch dock notifications from the global notify handler
The ACPI dock station code carries out an extra namespace scan
before the main one in order to find and register all of the dock
device objects. Then, it registers a notify handler for each of
them for handling dock events.
However, dock device objects need not be scanned for upfront. They
very well can be enumerated and registered during the first phase
of the main namespace scan, before attaching scan handlers and ACPI
drivers to ACPI device objects. Then, the dependent devices can be
added to the in the second phase. That makes it possible to drop
the extra namespace scan, so do it.
Moreover, it is not necessary to register notify handlers for all
of the dock stations' namespace nodes, becuase notifications may
be dispatched from the global notify handler for them. Do that and
drop two functions used for dock notify handling, acpi_dock_deferred_cb()
and dock_notify_handler(), that aren't necessary any more.
Finally, some dock station objects have _HID objects matching the
ACPI container scan handler which causes it to claim those objects
and try to handle their hotplug, but that is not a good idea,
because those objects have their own special hotplug handling anyway.
For this reason, the hotplug_notify flag should not be set for ACPI
device objects representing dock stations and the container scan
handler should be made ignore those objects, so make that happen.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-16 00:51:01 +00:00
|
|
|
{
|
2014-02-15 23:09:34 +00:00
|
|
|
struct acpi_hardware_id *hwid;
|
ACPI / dock: Dispatch dock notifications from the global notify handler
The ACPI dock station code carries out an extra namespace scan
before the main one in order to find and register all of the dock
device objects. Then, it registers a notify handler for each of
them for handling dock events.
However, dock device objects need not be scanned for upfront. They
very well can be enumerated and registered during the first phase
of the main namespace scan, before attaching scan handlers and ACPI
drivers to ACPI device objects. Then, the dependent devices can be
added to the in the second phase. That makes it possible to drop
the extra namespace scan, so do it.
Moreover, it is not necessary to register notify handlers for all
of the dock stations' namespace nodes, becuase notifications may
be dispatched from the global notify handler for them. Do that and
drop two functions used for dock notify handling, acpi_dock_deferred_cb()
and dock_notify_handler(), that aren't necessary any more.
Finally, some dock station objects have _HID objects matching the
ACPI container scan handler which causes it to claim those objects
and try to handle their hotplug, but that is not a good idea,
because those objects have their own special hotplug handling anyway.
For this reason, the hotplug_notify flag should not be set for ACPI
device objects representing dock stations and the container scan
handler should be made ignore those objects, so make that happen.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-16 00:51:01 +00:00
|
|
|
|
2014-02-15 23:09:34 +00:00
|
|
|
list_for_each_entry(hwid, &adev->pnp.ids, list)
|
|
|
|
if (!strcmp("PNP0C0A", hwid->id))
|
|
|
|
return true;
|
ACPI / dock: Dispatch dock notifications from the global notify handler
The ACPI dock station code carries out an extra namespace scan
before the main one in order to find and register all of the dock
device objects. Then, it registers a notify handler for each of
them for handling dock events.
However, dock device objects need not be scanned for upfront. They
very well can be enumerated and registered during the first phase
of the main namespace scan, before attaching scan handlers and ACPI
drivers to ACPI device objects. Then, the dependent devices can be
added to the in the second phase. That makes it possible to drop
the extra namespace scan, so do it.
Moreover, it is not necessary to register notify handlers for all
of the dock stations' namespace nodes, becuase notifications may
be dispatched from the global notify handler for them. Do that and
drop two functions used for dock notify handling, acpi_dock_deferred_cb()
and dock_notify_handler(), that aren't necessary any more.
Finally, some dock station objects have _HID objects matching the
ACPI container scan handler which causes it to claim those objects
and try to handle their hotplug, but that is not a good idea,
because those objects have their own special hotplug handling anyway.
For this reason, the hotplug_notify flag should not be set for ACPI
device objects representing dock stations and the container scan
handler should be made ignore those objects, so make that happen.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-16 00:51:01 +00:00
|
|
|
|
2014-02-15 23:09:34 +00:00
|
|
|
return false;
|
ACPI / dock: Dispatch dock notifications from the global notify handler
The ACPI dock station code carries out an extra namespace scan
before the main one in order to find and register all of the dock
device objects. Then, it registers a notify handler for each of
them for handling dock events.
However, dock device objects need not be scanned for upfront. They
very well can be enumerated and registered during the first phase
of the main namespace scan, before attaching scan handlers and ACPI
drivers to ACPI device objects. Then, the dependent devices can be
added to the in the second phase. That makes it possible to drop
the extra namespace scan, so do it.
Moreover, it is not necessary to register notify handlers for all
of the dock stations' namespace nodes, becuase notifications may
be dispatched from the global notify handler for them. Do that and
drop two functions used for dock notify handling, acpi_dock_deferred_cb()
and dock_notify_handler(), that aren't necessary any more.
Finally, some dock station objects have _HID objects matching the
ACPI container scan handler which causes it to claim those objects
and try to handle their hotplug, but that is not a good idea,
because those objects have their own special hotplug handling anyway.
For this reason, the hotplug_notify flag should not be set for ACPI
device objects representing dock stations and the container scan
handler should be made ignore those objects, so make that happen.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-16 00:51:01 +00:00
|
|
|
}
|
|
|
|
|
2014-02-15 23:09:34 +00:00
|
|
|
static bool is_ejectable_bay(struct acpi_device *adev)
|
ACPI / dock: Dispatch dock notifications from the global notify handler
The ACPI dock station code carries out an extra namespace scan
before the main one in order to find and register all of the dock
device objects. Then, it registers a notify handler for each of
them for handling dock events.
However, dock device objects need not be scanned for upfront. They
very well can be enumerated and registered during the first phase
of the main namespace scan, before attaching scan handlers and ACPI
drivers to ACPI device objects. Then, the dependent devices can be
added to the in the second phase. That makes it possible to drop
the extra namespace scan, so do it.
Moreover, it is not necessary to register notify handlers for all
of the dock stations' namespace nodes, becuase notifications may
be dispatched from the global notify handler for them. Do that and
drop two functions used for dock notify handling, acpi_dock_deferred_cb()
and dock_notify_handler(), that aren't necessary any more.
Finally, some dock station objects have _HID objects matching the
ACPI container scan handler which causes it to claim those objects
and try to handle their hotplug, but that is not a good idea,
because those objects have their own special hotplug handling anyway.
For this reason, the hotplug_notify flag should not be set for ACPI
device objects representing dock stations and the container scan
handler should be made ignore those objects, so make that happen.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-16 00:51:01 +00:00
|
|
|
{
|
2014-02-15 23:09:34 +00:00
|
|
|
acpi_handle handle = adev->handle;
|
|
|
|
|
|
|
|
if (acpi_has_method(handle, "_EJ0") && acpi_device_is_battery(adev))
|
ACPI / dock: Dispatch dock notifications from the global notify handler
The ACPI dock station code carries out an extra namespace scan
before the main one in order to find and register all of the dock
device objects. Then, it registers a notify handler for each of
them for handling dock events.
However, dock device objects need not be scanned for upfront. They
very well can be enumerated and registered during the first phase
of the main namespace scan, before attaching scan handlers and ACPI
drivers to ACPI device objects. Then, the dependent devices can be
added to the in the second phase. That makes it possible to drop
the extra namespace scan, so do it.
Moreover, it is not necessary to register notify handlers for all
of the dock stations' namespace nodes, becuase notifications may
be dispatched from the global notify handler for them. Do that and
drop two functions used for dock notify handling, acpi_dock_deferred_cb()
and dock_notify_handler(), that aren't necessary any more.
Finally, some dock station objects have _HID objects matching the
ACPI container scan handler which causes it to claim those objects
and try to handle their hotplug, but that is not a good idea,
because those objects have their own special hotplug handling anyway.
For this reason, the hotplug_notify flag should not be set for ACPI
device objects representing dock stations and the container scan
handler should be made ignore those objects, so make that happen.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-16 00:51:01 +00:00
|
|
|
return true;
|
|
|
|
|
|
|
|
return acpi_bay_match(handle);
|
|
|
|
}
|
|
|
|
|
2007-12-07 12:20:34 +00:00
|
|
|
/*
|
2013-03-04 21:30:41 +00:00
|
|
|
* acpi_dock_match - see if an acpi object has a _DCK method
|
2007-12-07 12:20:34 +00:00
|
|
|
*/
|
2013-06-28 16:24:41 +00:00
|
|
|
bool acpi_dock_match(acpi_handle handle)
|
2007-12-07 12:20:34 +00:00
|
|
|
{
|
2013-06-28 16:24:41 +00:00
|
|
|
return acpi_has_method(handle, "_DCK");
|
2007-12-07 12:20:34 +00:00
|
|
|
}
|
|
|
|
|
2015-06-16 14:27:45 +00:00
|
|
|
static acpi_status
|
|
|
|
acpi_backlight_cap_match(acpi_handle handle, u32 level, void *context,
|
|
|
|
void **return_value)
|
|
|
|
{
|
|
|
|
long *cap = context;
|
|
|
|
|
|
|
|
if (acpi_has_method(handle, "_BCM") &&
|
|
|
|
acpi_has_method(handle, "_BCL")) {
|
2021-01-20 18:59:51 +00:00
|
|
|
acpi_handle_debug(handle, "Found generic backlight support\n");
|
2015-06-16 14:27:45 +00:00
|
|
|
*cap |= ACPI_VIDEO_BACKLIGHT;
|
|
|
|
/* We have backlight support, no need to scan further */
|
|
|
|
return AE_CTRL_TERMINATE;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Returns true if the ACPI object is a video device which can be
|
|
|
|
* handled by video.ko.
|
|
|
|
* The device will get a Linux specific CID added in scan.c to
|
|
|
|
* identify the device as an ACPI graphics device
|
|
|
|
* Be aware that the graphics device may not be physically present
|
|
|
|
* Use acpi_video_get_capabilities() to detect general ACPI video
|
|
|
|
* capabilities of present cards
|
|
|
|
*/
|
|
|
|
long acpi_is_video_device(acpi_handle handle)
|
|
|
|
{
|
|
|
|
long video_caps = 0;
|
|
|
|
|
|
|
|
/* Is this device able to support video switching ? */
|
|
|
|
if (acpi_has_method(handle, "_DOD") || acpi_has_method(handle, "_DOS"))
|
|
|
|
video_caps |= ACPI_VIDEO_OUTPUT_SWITCHING;
|
|
|
|
|
|
|
|
/* Is this device able to retrieve a video ROM ? */
|
|
|
|
if (acpi_has_method(handle, "_ROM"))
|
|
|
|
video_caps |= ACPI_VIDEO_ROM_AVAILABLE;
|
|
|
|
|
|
|
|
/* Is this device able to configure which video head to be POSTed ? */
|
|
|
|
if (acpi_has_method(handle, "_VPO") &&
|
|
|
|
acpi_has_method(handle, "_GPD") &&
|
|
|
|
acpi_has_method(handle, "_SPD"))
|
|
|
|
video_caps |= ACPI_VIDEO_DEVICE_POSTING;
|
|
|
|
|
|
|
|
/* Only check for backlight functionality if one of the above hit. */
|
|
|
|
if (video_caps)
|
|
|
|
acpi_walk_namespace(ACPI_TYPE_DEVICE, handle,
|
|
|
|
ACPI_UINT32_MAX, acpi_backlight_cap_match, NULL,
|
|
|
|
&video_caps, NULL);
|
|
|
|
|
|
|
|
return video_caps;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(acpi_is_video_device);
|
|
|
|
|
2010-10-01 08:54:00 +00:00
|
|
|
const char *acpi_device_hid(struct acpi_device *device)
|
2009-06-29 05:39:29 +00:00
|
|
|
{
|
2009-09-21 19:35:19 +00:00
|
|
|
struct acpi_hardware_id *hid;
|
2009-06-29 05:39:29 +00:00
|
|
|
|
2010-10-01 08:53:59 +00:00
|
|
|
if (list_empty(&device->pnp.ids))
|
|
|
|
return dummy_hid;
|
|
|
|
|
2009-09-21 19:35:19 +00:00
|
|
|
hid = list_first_entry(&device->pnp.ids, struct acpi_hardware_id, list);
|
|
|
|
return hid->id;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(acpi_device_hid);
|
2009-06-29 05:39:29 +00:00
|
|
|
|
2013-03-04 21:30:41 +00:00
|
|
|
static void acpi_add_id(struct acpi_device_pnp *pnp, const char *dev_id)
|
2009-09-21 19:35:19 +00:00
|
|
|
{
|
|
|
|
struct acpi_hardware_id *id;
|
2009-06-29 05:39:29 +00:00
|
|
|
|
2009-09-21 19:35:19 +00:00
|
|
|
id = kmalloc(sizeof(*id), GFP_KERNEL);
|
|
|
|
if (!id)
|
|
|
|
return;
|
2009-06-29 05:39:29 +00:00
|
|
|
|
2015-09-09 21:59:43 +00:00
|
|
|
id->id = kstrdup_const(dev_id, GFP_KERNEL);
|
2009-09-21 19:35:19 +00:00
|
|
|
if (!id->id) {
|
|
|
|
kfree(id);
|
|
|
|
return;
|
2009-06-29 05:39:29 +00:00
|
|
|
}
|
|
|
|
|
2013-03-04 21:30:41 +00:00
|
|
|
list_add_tail(&id->list, &pnp->ids);
|
|
|
|
pnp->type.hardware_id = 1;
|
2009-06-29 05:39:29 +00:00
|
|
|
}
|
|
|
|
|
2010-03-24 13:38:37 +00: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 16:24:41 +00:00
|
|
|
static bool acpi_ibm_smbus_match(acpi_handle handle)
|
2010-03-24 13:38:37 +00:00
|
|
|
{
|
2013-06-28 16:24:41 +00:00
|
|
|
char node_name[ACPI_PATH_SEGMENT_LENGTH];
|
|
|
|
struct acpi_buffer path = { sizeof(node_name), node_name };
|
2010-03-24 13:38:37 +00:00
|
|
|
|
|
|
|
if (!dmi_name_in_vendors("IBM"))
|
2013-06-28 16:24:41 +00:00
|
|
|
return false;
|
2010-03-24 13:38:37 +00:00
|
|
|
|
|
|
|
/* Look for SMBS object */
|
2013-06-28 16:24:41 +00:00
|
|
|
if (ACPI_FAILURE(acpi_get_name(handle, ACPI_SINGLE_NAME, &path)) ||
|
|
|
|
strcmp("SMBS", path.pointer))
|
|
|
|
return false;
|
2010-03-24 13:38:37 +00:00
|
|
|
|
|
|
|
/* Does it have the necessary (but misnamed) methods? */
|
2013-06-28 16:24:38 +00:00
|
|
|
if (acpi_has_method(handle, "SBI") &&
|
|
|
|
acpi_has_method(handle, "SBR") &&
|
|
|
|
acpi_has_method(handle, "SBW"))
|
2013-06-28 16:24:41 +00:00
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
2010-03-24 13:38:37 +00:00
|
|
|
}
|
|
|
|
|
2014-02-19 06:02:19 +00:00
|
|
|
static bool acpi_object_is_system_bus(acpi_handle handle)
|
|
|
|
{
|
|
|
|
acpi_handle tmp;
|
|
|
|
|
|
|
|
if (ACPI_SUCCESS(acpi_get_handle(NULL, "\\_SB", &tmp)) &&
|
|
|
|
tmp == handle)
|
|
|
|
return true;
|
|
|
|
if (ACPI_SUCCESS(acpi_get_handle(NULL, "\\_TZ", &tmp)) &&
|
|
|
|
tmp == handle)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2013-03-04 21:30:42 +00:00
|
|
|
static void acpi_set_pnp_ids(acpi_handle handle, struct acpi_device_pnp *pnp,
|
2021-04-07 14:33:38 +00:00
|
|
|
int device_type)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2021-04-07 14:33:38 +00:00
|
|
|
struct acpi_device_info *info = NULL;
|
2012-10-31 02:25:24 +00:00
|
|
|
struct acpi_pnp_device_id_list *cid_list;
|
2009-09-21 19:35:19 +00:00
|
|
|
int i;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2013-03-04 21:30:42 +00:00
|
|
|
switch (device_type) {
|
2005-04-16 22:20:36 +00:00
|
|
|
case ACPI_BUS_TYPE_DEVICE:
|
2013-03-04 21:30:42 +00:00
|
|
|
if (handle == ACPI_ROOT_OBJECT) {
|
|
|
|
acpi_add_id(pnp, ACPI_SYSTEM_HID);
|
2009-09-21 19:29:50 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2021-04-07 14:33:38 +00:00
|
|
|
acpi_get_object_info(handle, &info);
|
2020-11-21 20:30:35 +00:00
|
|
|
if (!info) {
|
2021-06-02 08:54:37 +00:00
|
|
|
pr_err("%s: Error reading device info\n", __func__);
|
2005-04-16 22:20:36 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-05-30 02:26:18 +00:00
|
|
|
if (info->valid & ACPI_VALID_HID) {
|
2013-03-04 21:30:42 +00:00
|
|
|
acpi_add_id(pnp, info->hardware_id.string);
|
2014-05-30 02:26:18 +00:00
|
|
|
pnp->type.platform_id = 1;
|
2021-10-26 18:57:31 +00:00
|
|
|
if (info->valid & ACPI_VALID_CID) {
|
|
|
|
cid_list = &info->compatible_id_list;
|
|
|
|
for (i = 0; i < cid_list->count; i++)
|
|
|
|
acpi_add_id(pnp, cid_list->ids[i].string);
|
|
|
|
}
|
2009-09-21 19:35:40 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
if (info->valid & ACPI_VALID_ADR) {
|
2013-03-04 21:30:42 +00:00
|
|
|
pnp->bus_address = info->address;
|
|
|
|
pnp->type.bus_address = 1;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2012-10-30 13:41:07 +00:00
|
|
|
if (info->valid & ACPI_VALID_UID)
|
2013-03-04 21:30:42 +00:00
|
|
|
pnp->unique_id = kstrdup(info->unique_id.string,
|
2012-10-30 13:41:07 +00:00
|
|
|
GFP_KERNEL);
|
ACPI / scan: Add support for ACPI _CLS device matching
Device drivers typically use ACPI _HIDs/_CIDs listed in struct device_driver
acpi_match_table to match devices. However, for generic drivers, we do not
want to list _HID for all supported devices. Also, certain classes of devices
do not have _CID (e.g. SATA, USB). Instead, we can leverage ACPI _CLS,
which specifies PCI-defined class code (i.e. base-class, subclass and
programming interface). This patch adds support for matching ACPI devices using
the _CLS method.
To support loadable module, current design uses _HID or _CID to match device's
modalias. With the new way of matching with _CLS this would requires modification
to the current ACPI modalias key to include _CLS. This patch appends PCI-defined
class-code to the existing ACPI modalias as following.
acpi:<HID>:<CID1>:<CID2>:..:<CIDn>:<bbsspp>:
E.g:
# cat /sys/devices/platform/AMDI0600:00/modalias
acpi:AMDI0600:010601:
where bb is th base-class code, ss is te sub-class code, and pp is the
programming interface code
Since there would not be _HID/_CID in the ACPI matching table of the driver,
this patch adds a field to acpi_device_id to specify the matching _CLS.
static const struct acpi_device_id ahci_acpi_match[] = {
{ ACPI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, 0xffffff) },
{},
};
In this case, the corresponded entry in modules.alias file would be:
alias acpi*:010601:* ahci_platform
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-06 23:55:20 +00:00
|
|
|
if (info->valid & ACPI_VALID_CLS)
|
|
|
|
acpi_add_id(pnp, info->class_code.string);
|
2006-12-07 12:57:10 +00:00
|
|
|
|
2021-04-07 14:33:38 +00:00
|
|
|
kfree(info);
|
|
|
|
|
2009-09-21 19:35:40 +00:00
|
|
|
/*
|
|
|
|
* Some devices don't reliably have _HIDs & _CIDs, so add
|
|
|
|
* synthetic HIDs to make sure drivers can find them.
|
|
|
|
*/
|
2013-03-04 21:30:42 +00:00
|
|
|
if (acpi_is_video_device(handle))
|
|
|
|
acpi_add_id(pnp, ACPI_VIDEO_HID);
|
2013-06-28 16:24:41 +00:00
|
|
|
else if (acpi_bay_match(handle))
|
2013-03-04 21:30:42 +00:00
|
|
|
acpi_add_id(pnp, ACPI_BAY_HID);
|
2013-06-28 16:24:41 +00:00
|
|
|
else if (acpi_dock_match(handle))
|
2013-03-04 21:30:42 +00:00
|
|
|
acpi_add_id(pnp, ACPI_DOCK_HID);
|
2013-06-28 16:24:41 +00:00
|
|
|
else if (acpi_ibm_smbus_match(handle))
|
2013-03-04 21:30:42 +00:00
|
|
|
acpi_add_id(pnp, ACPI_SMBUS_IBM_HID);
|
2014-02-19 06:02:19 +00:00
|
|
|
else if (list_empty(&pnp->ids) &&
|
|
|
|
acpi_object_is_system_bus(handle)) {
|
|
|
|
/* \_SB, \_TZ, LNXSYBUS */
|
|
|
|
acpi_add_id(pnp, ACPI_BUS_HID);
|
2013-03-04 21:30:42 +00:00
|
|
|
strcpy(pnp->device_name, ACPI_BUS_DEVICE_NAME);
|
|
|
|
strcpy(pnp->device_class, ACPI_BUS_CLASS);
|
2010-03-24 16:44:33 +00:00
|
|
|
}
|
2007-01-11 07:09:09 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
break;
|
|
|
|
case ACPI_BUS_TYPE_POWER:
|
2013-03-04 21:30:42 +00:00
|
|
|
acpi_add_id(pnp, ACPI_POWER_HID);
|
2005-04-16 22:20:36 +00:00
|
|
|
break;
|
|
|
|
case ACPI_BUS_TYPE_PROCESSOR:
|
2013-03-04 21:30:42 +00:00
|
|
|
acpi_add_id(pnp, ACPI_PROCESSOR_OBJECT_HID);
|
2005-04-16 22:20:36 +00:00
|
|
|
break;
|
|
|
|
case ACPI_BUS_TYPE_THERMAL:
|
2013-03-04 21:30:42 +00:00
|
|
|
acpi_add_id(pnp, ACPI_THERMAL_HID);
|
2005-04-16 22:20:36 +00:00
|
|
|
break;
|
|
|
|
case ACPI_BUS_TYPE_POWER_BUTTON:
|
2013-03-04 21:30:42 +00:00
|
|
|
acpi_add_id(pnp, ACPI_BUTTON_HID_POWERF);
|
2005-04-16 22:20:36 +00:00
|
|
|
break;
|
|
|
|
case ACPI_BUS_TYPE_SLEEP_BUTTON:
|
2013-03-04 21:30:42 +00:00
|
|
|
acpi_add_id(pnp, ACPI_BUTTON_HID_SLEEPF);
|
2005-04-16 22:20:36 +00:00
|
|
|
break;
|
2017-09-26 08:54:09 +00:00
|
|
|
case ACPI_BUS_TYPE_ECDT_EC:
|
|
|
|
acpi_add_id(pnp, ACPI_ECDT_HID);
|
|
|
|
break;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-03-04 21:30:42 +00: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) {
|
2015-09-09 21:59:43 +00:00
|
|
|
kfree_const(id->id);
|
2013-03-04 21:30:42 +00:00
|
|
|
kfree(id);
|
|
|
|
}
|
|
|
|
kfree(pnp->unique_id);
|
|
|
|
}
|
|
|
|
|
2015-10-28 22:50:48 +00:00
|
|
|
/**
|
|
|
|
* acpi_dma_supported - Check DMA support for the specified device.
|
|
|
|
* @adev: The pointer to acpi device
|
|
|
|
*
|
|
|
|
* Return false if DMA is not supported. Otherwise, return true
|
|
|
|
*/
|
2021-06-04 16:50:46 +00:00
|
|
|
bool acpi_dma_supported(const struct acpi_device *adev)
|
2015-10-28 22:50:48 +00:00
|
|
|
{
|
|
|
|
if (!adev)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (adev->flags.cca_seen)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Per ACPI 6.0 sec 6.2.17, assume devices can do cache-coherent
|
|
|
|
* DMA on "Intel platforms". Presumably that includes all x86 and
|
|
|
|
* ia64, and other arches will set CONFIG_ACPI_CCA_REQUIRED=y.
|
|
|
|
*/
|
|
|
|
if (!IS_ENABLED(CONFIG_ACPI_CCA_REQUIRED))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_get_dma_attr - Check the supported DMA attr for the specified device.
|
|
|
|
* @adev: The pointer to acpi device
|
|
|
|
*
|
|
|
|
* Return enum dev_dma_attr.
|
|
|
|
*/
|
|
|
|
enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
if (!acpi_dma_supported(adev))
|
|
|
|
return DEV_DMA_NOT_SUPPORTED;
|
|
|
|
|
|
|
|
if (adev->flags.coherent_dma)
|
|
|
|
return DEV_DMA_COHERENT;
|
|
|
|
else
|
|
|
|
return DEV_DMA_NON_COHERENT;
|
|
|
|
}
|
|
|
|
|
2017-08-07 10:29:48 +00:00
|
|
|
/**
|
|
|
|
* acpi_dma_get_range() - Get device DMA parameters.
|
|
|
|
*
|
|
|
|
* @dev: device to configure
|
|
|
|
* @dma_addr: pointer device DMA address result
|
|
|
|
* @offset: pointer to the DMA offset result
|
|
|
|
* @size: pointer to DMA range size result
|
|
|
|
*
|
|
|
|
* Evaluate DMA regions and return respectively DMA region start, offset
|
|
|
|
* and size in dma_addr, offset and size on parsing success; it does not
|
|
|
|
* update the passed in values on failure.
|
|
|
|
*
|
|
|
|
* Return 0 on success, < 0 on failure.
|
|
|
|
*/
|
|
|
|
int acpi_dma_get_range(struct device *dev, u64 *dma_addr, u64 *offset,
|
|
|
|
u64 *size)
|
|
|
|
{
|
|
|
|
struct acpi_device *adev;
|
|
|
|
LIST_HEAD(list);
|
|
|
|
struct resource_entry *rentry;
|
|
|
|
int ret;
|
|
|
|
struct device *dma_dev = dev;
|
|
|
|
u64 len, dma_start = U64_MAX, dma_end = 0, dma_offset = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Walk the device tree chasing an ACPI companion with a _DMA
|
|
|
|
* object while we go. Stop if we find a device with an ACPI
|
|
|
|
* companion containing a _DMA method.
|
|
|
|
*/
|
|
|
|
do {
|
|
|
|
adev = ACPI_COMPANION(dma_dev);
|
|
|
|
if (adev && acpi_has_method(adev->handle, METHOD_NAME__DMA))
|
|
|
|
break;
|
|
|
|
|
|
|
|
dma_dev = dma_dev->parent;
|
|
|
|
} while (dma_dev);
|
|
|
|
|
|
|
|
if (!dma_dev)
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
if (!acpi_has_method(adev->handle, METHOD_NAME__CRS)) {
|
|
|
|
acpi_handle_warn(adev->handle, "_DMA is valid only if _CRS is present\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = acpi_dev_get_dma_resources(adev, &list);
|
|
|
|
if (ret > 0) {
|
|
|
|
list_for_each_entry(rentry, &list, node) {
|
|
|
|
if (dma_offset && rentry->offset != dma_offset) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
dev_warn(dma_dev, "Can't handle multiple windows with different offsets\n");
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
dma_offset = rentry->offset;
|
|
|
|
|
|
|
|
/* Take lower and upper limits */
|
|
|
|
if (rentry->res->start < dma_start)
|
|
|
|
dma_start = rentry->res->start;
|
|
|
|
if (rentry->res->end > dma_end)
|
|
|
|
dma_end = rentry->res->end;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (dma_start >= dma_end) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
dev_dbg(dma_dev, "Invalid DMA regions configuration\n");
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
*dma_addr = dma_start - dma_offset;
|
|
|
|
len = dma_end - dma_start;
|
|
|
|
*size = max(len, len + 1);
|
|
|
|
*offset = dma_offset;
|
|
|
|
}
|
|
|
|
out:
|
|
|
|
acpi_dev_free_resource_list(&list);
|
|
|
|
|
|
|
|
return ret >= 0 ? 0 : ret;
|
|
|
|
}
|
|
|
|
|
2021-06-18 15:20:57 +00:00
|
|
|
#ifdef CONFIG_IOMMU_API
|
|
|
|
int acpi_iommu_fwspec_init(struct device *dev, u32 id,
|
|
|
|
struct fwnode_handle *fwnode,
|
|
|
|
const struct iommu_ops *ops)
|
|
|
|
{
|
|
|
|
int ret = iommu_fwspec_init(dev, fwnode, ops);
|
|
|
|
|
|
|
|
if (!ret)
|
|
|
|
ret = iommu_fwspec_add_ids(dev, &id, 1);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline const struct iommu_ops *acpi_iommu_fwspec_ops(struct device *dev)
|
|
|
|
{
|
|
|
|
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
|
|
|
|
|
|
|
|
return fwspec ? fwspec->ops : NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct iommu_ops *acpi_iommu_configure_id(struct device *dev,
|
|
|
|
const u32 *id_in)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
const struct iommu_ops *ops;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we already translated the fwspec there is nothing left to do,
|
|
|
|
* return the iommu_ops.
|
|
|
|
*/
|
|
|
|
ops = acpi_iommu_fwspec_ops(dev);
|
|
|
|
if (ops)
|
|
|
|
return ops;
|
|
|
|
|
|
|
|
err = iort_iommu_configure_id(dev, id_in);
|
ACPI: Add driver for the VIOT table
The ACPI Virtual I/O Translation Table describes topology of
para-virtual platforms, similarly to vendor tables DMAR, IVRS and IORT.
For now it describes the relation between virtio-iommu and the endpoints
it manages.
Three steps are needed to configure DMA of endpoints:
(1) acpi_viot_init(): parse the VIOT table, find or create the fwnode
associated to each vIOMMU device. This needs to happen after
acpi_scan_init(), because it relies on the struct device and their
fwnode to be available.
(2) When probing the vIOMMU device, the driver registers its IOMMU ops
within the IOMMU subsystem. This step doesn't require any
intervention from the VIOT driver.
(3) viot_iommu_configure(): before binding the endpoint to a driver,
find the associated IOMMU ops. Register them, along with the
endpoint ID, into the device's iommu_fwspec.
If step (3) happens before step (2), it is deferred until the IOMMU is
initialized, then retried.
Tested-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Link: https://lore.kernel.org/r/20210618152059.1194210-4-jean-philippe@linaro.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2021-06-18 15:20:58 +00:00
|
|
|
if (err && err != -EPROBE_DEFER)
|
|
|
|
err = viot_iommu_configure(dev);
|
2021-06-18 15:20:57 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If we have reason to believe the IOMMU driver missed the initial
|
|
|
|
* iommu_probe_device() call for dev, replay it to get things in order.
|
|
|
|
*/
|
|
|
|
if (!err && dev->bus && !device_iommu_mapped(dev))
|
|
|
|
err = iommu_probe_device(dev);
|
|
|
|
|
|
|
|
/* Ignore all other errors apart from EPROBE_DEFER */
|
|
|
|
if (err == -EPROBE_DEFER) {
|
|
|
|
return ERR_PTR(err);
|
|
|
|
} else if (err) {
|
|
|
|
dev_dbg(dev, "Adding to IOMMU failed: %d\n", err);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
return acpi_iommu_fwspec_ops(dev);
|
|
|
|
}
|
|
|
|
|
|
|
|
#else /* !CONFIG_IOMMU_API */
|
|
|
|
|
|
|
|
int acpi_iommu_fwspec_init(struct device *dev, u32 id,
|
|
|
|
struct fwnode_handle *fwnode,
|
|
|
|
const struct iommu_ops *ops)
|
|
|
|
{
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct iommu_ops *acpi_iommu_configure_id(struct device *dev,
|
|
|
|
const u32 *id_in)
|
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* !CONFIG_IOMMU_API */
|
|
|
|
|
2016-11-21 10:01:39 +00:00
|
|
|
/**
|
2020-11-02 11:19:31 +00:00
|
|
|
* acpi_dma_configure_id - Set-up DMA configuration for the device.
|
2016-11-21 10:01:39 +00:00
|
|
|
* @dev: The pointer to the device
|
|
|
|
* @attr: device dma attributes
|
2020-06-19 08:20:06 +00:00
|
|
|
* @input_id: input device id const value pointer
|
2016-11-21 10:01:39 +00:00
|
|
|
*/
|
2020-06-19 08:20:06 +00:00
|
|
|
int acpi_dma_configure_id(struct device *dev, enum dev_dma_attr attr,
|
|
|
|
const u32 *input_id)
|
2016-11-21 10:01:39 +00:00
|
|
|
{
|
2016-11-21 10:01:48 +00:00
|
|
|
const struct iommu_ops *iommu;
|
2017-08-07 10:29:49 +00:00
|
|
|
u64 dma_addr = 0, size = 0;
|
2016-11-21 10:01:48 +00:00
|
|
|
|
2018-12-06 21:20:49 +00:00
|
|
|
if (attr == DEV_DMA_NOT_SUPPORTED) {
|
|
|
|
set_dma_ops(dev, &dma_dummy_ops);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-06-18 15:20:56 +00:00
|
|
|
acpi_arch_dma_setup(dev, &dma_addr, &size);
|
2016-11-21 10:01:39 +00:00
|
|
|
|
2021-06-18 15:20:57 +00:00
|
|
|
iommu = acpi_iommu_configure_id(dev, input_id);
|
2020-02-04 01:37:45 +00:00
|
|
|
if (PTR_ERR(iommu) == -EPROBE_DEFER)
|
2017-05-27 13:47:42 +00:00
|
|
|
return -EPROBE_DEFER;
|
2016-11-21 10:01:48 +00:00
|
|
|
|
2017-08-07 10:29:49 +00:00
|
|
|
arch_setup_dma_ops(dev, dma_addr, size,
|
|
|
|
iommu, attr == DEV_DMA_COHERENT);
|
2017-04-10 11:21:03 +00:00
|
|
|
|
|
|
|
return 0;
|
2016-11-21 10:01:39 +00:00
|
|
|
}
|
2020-06-19 08:20:06 +00:00
|
|
|
EXPORT_SYMBOL_GPL(acpi_dma_configure_id);
|
2016-11-21 10:01:39 +00:00
|
|
|
|
2015-06-10 16:08:52 +00:00
|
|
|
static void acpi_init_coherency(struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
unsigned long long cca = 0;
|
|
|
|
acpi_status status;
|
|
|
|
struct acpi_device *parent = adev->parent;
|
|
|
|
|
|
|
|
if (parent && parent->flags.cca_seen) {
|
|
|
|
/*
|
|
|
|
* From ACPI spec, OSPM will ignore _CCA if an ancestor
|
|
|
|
* already saw one.
|
|
|
|
*/
|
|
|
|
adev->flags.cca_seen = 1;
|
|
|
|
cca = parent->flags.coherent_dma;
|
|
|
|
} else {
|
|
|
|
status = acpi_evaluate_integer(adev->handle, "_CCA",
|
|
|
|
NULL, &cca);
|
|
|
|
if (ACPI_SUCCESS(status))
|
|
|
|
adev->flags.cca_seen = 1;
|
|
|
|
else if (!IS_ENABLED(CONFIG_ACPI_CCA_REQUIRED))
|
|
|
|
/*
|
|
|
|
* If architecture does not specify that _CCA is
|
|
|
|
* required for DMA-able devices (e.g. x86),
|
|
|
|
* we default to _CCA=1.
|
|
|
|
*/
|
|
|
|
cca = 1;
|
|
|
|
else
|
|
|
|
acpi_handle_debug(adev->handle,
|
|
|
|
"ACPI device is missing _CCA.\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
adev->flags.coherent_dma = cca;
|
|
|
|
}
|
|
|
|
|
2017-10-11 08:32:14 +00:00
|
|
|
static int acpi_check_serial_bus_slave(struct acpi_resource *ares, void *data)
|
2017-06-19 12:53:01 +00:00
|
|
|
{
|
2017-10-11 08:32:14 +00:00
|
|
|
bool *is_serial_bus_slave_p = data;
|
2017-06-19 12:53:01 +00:00
|
|
|
|
|
|
|
if (ares->type != ACPI_RESOURCE_TYPE_SERIAL_BUS)
|
|
|
|
return 1;
|
|
|
|
|
2017-10-11 08:32:14 +00:00
|
|
|
*is_serial_bus_slave_p = true;
|
2017-06-19 12:53:01 +00:00
|
|
|
|
|
|
|
/* no need to do more checking */
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2018-03-14 18:15:57 +00:00
|
|
|
static bool acpi_is_indirect_io_slave(struct acpi_device *device)
|
|
|
|
{
|
|
|
|
struct acpi_device *parent = device->parent;
|
2018-08-07 13:15:05 +00:00
|
|
|
static const struct acpi_device_id indirect_io_hosts[] = {
|
2018-03-14 18:15:57 +00:00
|
|
|
{"HISI0191", 0},
|
|
|
|
{}
|
|
|
|
};
|
|
|
|
|
|
|
|
return parent && !acpi_match_device_ids(parent, indirect_io_hosts);
|
|
|
|
}
|
|
|
|
|
2018-03-14 18:15:56 +00:00
|
|
|
static bool acpi_device_enumeration_by_parent(struct acpi_device *device)
|
2017-06-19 12:53:01 +00:00
|
|
|
{
|
|
|
|
struct list_head resource_list;
|
2017-10-11 08:32:14 +00:00
|
|
|
bool is_serial_bus_slave = false;
|
2021-12-30 11:57:47 +00:00
|
|
|
static const struct acpi_device_id ignore_serial_bus_ids[] = {
|
2018-08-09 09:15:56 +00:00
|
|
|
/*
|
2022-01-21 17:24:27 +00:00
|
|
|
* These devices have multiple SerialBus resources and a client
|
|
|
|
* device must be instantiated for each of them, each with
|
|
|
|
* its own device id.
|
|
|
|
* Normally we only instantiate one client device for the first
|
|
|
|
* resource, using the ACPI HID as id. These special cases are handled
|
|
|
|
* by the drivers/platform/x86/serial-multi-instantiate.c driver, which
|
|
|
|
* knows which client device id to use for each resource.
|
2018-08-09 09:15:56 +00:00
|
|
|
*/
|
|
|
|
{"BSG1160", },
|
2018-12-20 14:34:51 +00:00
|
|
|
{"BSG2150", },
|
2018-10-17 08:59:28 +00:00
|
|
|
{"INT33FE", },
|
2018-11-28 11:45:34 +00:00
|
|
|
{"INT3515", },
|
2021-12-30 11:57:47 +00:00
|
|
|
/*
|
|
|
|
* HIDs of device with an UartSerialBusV2 resource for which userspace
|
|
|
|
* expects a regular tty cdev to be created (instead of the in kernel
|
|
|
|
* serdev) and which have a kernel driver which expects a platform_dev
|
|
|
|
* such as the rfkill-gpio driver.
|
|
|
|
*/
|
|
|
|
{"BCM4752", },
|
|
|
|
{"LNV4752", },
|
2018-08-09 09:15:56 +00:00
|
|
|
{}
|
|
|
|
};
|
2017-06-19 12:53:01 +00:00
|
|
|
|
2018-03-14 18:15:57 +00:00
|
|
|
if (acpi_is_indirect_io_slave(device))
|
|
|
|
return true;
|
|
|
|
|
2017-08-01 12:10:41 +00:00
|
|
|
/* Macs use device properties in lieu of _CRS resources */
|
|
|
|
if (x86_apple_machine &&
|
|
|
|
(fwnode_property_present(&device->fwnode, "spiSclkPeriod") ||
|
2017-10-11 08:32:14 +00:00
|
|
|
fwnode_property_present(&device->fwnode, "i2cAddress") ||
|
|
|
|
fwnode_property_present(&device->fwnode, "baud")))
|
2017-08-01 12:10:41 +00:00
|
|
|
return true;
|
|
|
|
|
2021-12-30 11:57:47 +00:00
|
|
|
if (!acpi_match_device_ids(device, ignore_serial_bus_ids))
|
2018-08-09 09:15:56 +00:00
|
|
|
return false;
|
|
|
|
|
2017-06-19 12:53:01 +00:00
|
|
|
INIT_LIST_HEAD(&resource_list);
|
2017-10-11 08:32:14 +00:00
|
|
|
acpi_dev_get_resources(device, &resource_list,
|
|
|
|
acpi_check_serial_bus_slave,
|
|
|
|
&is_serial_bus_slave);
|
2017-06-19 12:53:01 +00:00
|
|
|
acpi_dev_free_resource_list(&resource_list);
|
|
|
|
|
2017-10-11 08:32:14 +00:00
|
|
|
return is_serial_bus_slave;
|
2017-06-19 12:53:01 +00:00
|
|
|
}
|
|
|
|
|
2013-01-17 13:11:05 +00:00
|
|
|
void acpi_init_device_object(struct acpi_device *device, acpi_handle handle,
|
2021-04-07 14:33:38 +00:00
|
|
|
int type)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2013-01-17 13:11:05 +00:00
|
|
|
INIT_LIST_HEAD(&device->pnp.ids);
|
|
|
|
device->device_type = type;
|
|
|
|
device->handle = handle;
|
|
|
|
device->parent = acpi_bus_get_parent(handle);
|
2020-11-21 02:02:22 +00:00
|
|
|
fwnode_init(&device->fwnode, &acpi_device_fwnode_ops);
|
2021-04-07 14:32:43 +00:00
|
|
|
acpi_set_device_status(device, ACPI_STA_DEFAULT);
|
2013-01-17 13:11:05 +00:00
|
|
|
acpi_device_get_busid(device);
|
2021-04-07 14:33:38 +00:00
|
|
|
acpi_set_pnp_ids(handle, &device->pnp, type);
|
ACPI: Add support for device specific properties
Device Tree is used in many embedded systems to describe the system
configuration to the OS. It supports attaching properties or name-value
pairs to the devices it describe. With these properties one can pass
additional information to the drivers that would not be available
otherwise.
ACPI is another configuration mechanism (among other things) typically
seen, but not limited to, x86 machines. ACPI allows passing arbitrary
data from methods but there has not been mechanism equivalent to Device
Tree until the introduction of _DSD in the recent publication of the
ACPI 5.1 specification.
In order to facilitate ACPI usage in systems where Device Tree is
typically used, it would be beneficial to standardize a way to retrieve
Device Tree style properties from ACPI devices, which is what we do in
this patch.
If a given device described in ACPI namespace wants to export properties it
must implement _DSD method (Device Specific Data, introduced with ACPI 5.1)
that returns the properties in a package of packages. For example:
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"name1", <VALUE1>},
Package () {"name2", <VALUE2>},
...
}
})
The UUID reserved for properties is daffd814-6eba-4d8c-8a91-bc9bbf4aa301
and is documented in the ACPI 5.1 companion document called "_DSD
Implementation Guide" [1], [2].
We add several helper functions that can be used to extract these
properties and convert them to different Linux data types.
The ultimate goal is that we only have one device property API that
retrieves the requested properties from Device Tree or from ACPI
transparent to the caller.
[1] http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
[2] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-21 11:33:55 +00:00
|
|
|
acpi_init_properties(device);
|
2013-01-17 13:11:05 +00:00
|
|
|
acpi_bus_get_flags(device);
|
2013-01-29 12:57:20 +00:00
|
|
|
device->flags.match_driver = false;
|
ACPI / scan: Add acpi_device objects for all device nodes in the namespace
Modify the ACPI namespace scanning code to register a struct
acpi_device object for every namespace node representing a device,
processor and so on, even if the device represented by that namespace
node is reported to be not present and not functional by _STA.
There are multiple reasons to do that. First of all, it avoids
quite a lot of overhead when struct acpi_device objects are
deleted every time acpi_bus_trim() is run and then added again
by a subsequent acpi_bus_scan() for the same scope, although the
namespace objects they correspond to stay in memory all the time
(which always is the case on a vast majority of systems).
Second, it will allow user space to see that there are namespace
nodes representing devices that are not present at the moment and may
be added to the system. It will also allow user space to evaluate
_SUN for those nodes to check what physical slots the "missing"
devices may be put into and it will make sense to add a sysfs
attribute for _STA evaluation after this change (that will be
useful for thermal management on some systems).
Next, it will help to consolidate the ACPI hotplug handling among
subsystems by making it possible to store hotplug-related information
in struct acpi_device objects in a standard common way.
Finally, it will help to avoid a race condition related to the
deletion of ACPI namespace nodes. Namely, namespace nodes may be
deleted as a result of a table unload triggered by _EJ0 or _DCK.
If a hotplug notification for one of those nodes is triggered
right before the deletion and it executes a hotplug callback
via acpi_hotplug_execute(), the ACPI handle passed to that
callback may be stale when the callback actually runs. One way
to work around that is to always pass struct acpi_device pointers
to hotplug callbacks after doing a get_device() on the objects in
question which eliminates the use-after-free possibility (the ACPI
handles in those objects are invalidated by acpi_scan_drop_device(),
so they will trigger ACPICA errors on attempts to use them).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-22 20:54:37 +00:00
|
|
|
device->flags.initialized = true;
|
2018-03-14 18:15:56 +00:00
|
|
|
device->flags.enumeration_by_parent =
|
|
|
|
acpi_device_enumeration_by_parent(device);
|
2016-07-08 16:13:08 +00:00
|
|
|
acpi_device_clear_enumerated(device);
|
2013-01-24 11:49:49 +00:00
|
|
|
device_initialize(&device->dev);
|
|
|
|
dev_set_uevent_suppress(&device->dev, true);
|
2015-06-10 16:08:52 +00:00
|
|
|
acpi_init_coherency(device);
|
2021-05-10 17:53:18 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void acpi_scan_dep_init(struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
struct acpi_dep_data *dep;
|
|
|
|
|
|
|
|
list_for_each_entry(dep, &acpi_dep_list, node) {
|
ACPI: delay enumeration of devices with a _DEP pointing to an INT3472 device
The clk and regulator frameworks expect clk/regulator consumer-devices
to have info about the consumed clks/regulators described in the device's
fw_node.
To work around cases where this info is not present in the firmware tables,
which is often the case on x86/ACPI devices, both frameworks allow the
provider-driver to attach info about consumers to the clks/regulators
when registering these.
This causes problems with the probe ordering wrt drivers for consumers
of these clks/regulators. Since the lookups are only registered when the
provider-driver binds, trying to get these clks/regulators before then
results in a -ENOENT error for clks and a dummy regulator for regulators.
One case where we hit this issue is camera sensors such as e.g. the OV8865
sensor found on the Microsoft Surface Go. The sensor uses clks, regulators
and GPIOs provided by a TPS68470 PMIC which is described in an INT3472
ACPI device. There is special platform code handling this and setting
platform_data with the necessary consumer info on the MFD cells
instantiated for the PMIC under: drivers/platform/x86/intel/int3472.
For this to work properly the ov8865 driver must not bind to the I2C-client
for the OV8865 sensor until after the TPS68470 PMIC gpio, regulator and
clk MFD cells have all been fully setup.
The OV8865 on the Microsoft Surface Go is just one example, all X86
devices using the Intel IPU3 camera block found on recent Intel SoCs
have similar issues where there is an INT3472 HID ACPI-device, which
describes the clks and regulators, and the driver for this INT3472 device
must be fully initialized before the sensor driver (any sensor driver)
binds for things to work properly.
On these devices the ACPI nodes describing the sensors all have a _DEP
dependency on the matching INT3472 ACPI device (there is one per sensor).
This allows solving the probe-ordering problem by delaying the enumeration
(instantiation of the I2C-client in the ov8865 example) of ACPI-devices
which have a _DEP dependency on an INT3472 device.
The new acpi_dev_ready_for_enumeration() helper used for this is also
exported because for devices, which have the enumeration_by_parent flag
set, the parent-driver will do its own scan of child ACPI devices and
it will try to enumerate those during its probe(). Code doing this such
as e.g. the i2c-core-acpi.c code must call this new helper to ensure
that it too delays the enumeration until all the _DEP dependencies are
met on devices which have the new honor_deps flag set.
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211203102857.44539-2-hdegoede@redhat.com
2021-12-03 10:28:44 +00:00
|
|
|
if (dep->consumer == adev->handle) {
|
|
|
|
if (dep->honor_dep)
|
|
|
|
adev->flags.honor_deps = 1;
|
|
|
|
|
2021-05-10 17:53:18 +00:00
|
|
|
adev->dep_unmet++;
|
ACPI: delay enumeration of devices with a _DEP pointing to an INT3472 device
The clk and regulator frameworks expect clk/regulator consumer-devices
to have info about the consumed clks/regulators described in the device's
fw_node.
To work around cases where this info is not present in the firmware tables,
which is often the case on x86/ACPI devices, both frameworks allow the
provider-driver to attach info about consumers to the clks/regulators
when registering these.
This causes problems with the probe ordering wrt drivers for consumers
of these clks/regulators. Since the lookups are only registered when the
provider-driver binds, trying to get these clks/regulators before then
results in a -ENOENT error for clks and a dummy regulator for regulators.
One case where we hit this issue is camera sensors such as e.g. the OV8865
sensor found on the Microsoft Surface Go. The sensor uses clks, regulators
and GPIOs provided by a TPS68470 PMIC which is described in an INT3472
ACPI device. There is special platform code handling this and setting
platform_data with the necessary consumer info on the MFD cells
instantiated for the PMIC under: drivers/platform/x86/intel/int3472.
For this to work properly the ov8865 driver must not bind to the I2C-client
for the OV8865 sensor until after the TPS68470 PMIC gpio, regulator and
clk MFD cells have all been fully setup.
The OV8865 on the Microsoft Surface Go is just one example, all X86
devices using the Intel IPU3 camera block found on recent Intel SoCs
have similar issues where there is an INT3472 HID ACPI-device, which
describes the clks and regulators, and the driver for this INT3472 device
must be fully initialized before the sensor driver (any sensor driver)
binds for things to work properly.
On these devices the ACPI nodes describing the sensors all have a _DEP
dependency on the matching INT3472 ACPI device (there is one per sensor).
This allows solving the probe-ordering problem by delaying the enumeration
(instantiation of the I2C-client in the ov8865 example) of ACPI-devices
which have a _DEP dependency on an INT3472 device.
The new acpi_dev_ready_for_enumeration() helper used for this is also
exported because for devices, which have the enumeration_by_parent flag
set, the parent-driver will do its own scan of child ACPI devices and
it will try to enumerate those during its probe(). Code doing this such
as e.g. the i2c-core-acpi.c code must call this new helper to ensure
that it too delays the enumeration until all the _DEP dependencies are
met on devices which have the new honor_deps flag set.
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211203102857.44539-2-hdegoede@redhat.com
2021-12-03 10:28:44 +00:00
|
|
|
}
|
2021-05-10 17:53:18 +00:00
|
|
|
}
|
2013-01-24 11:49:49 +00:00
|
|
|
}
|
2009-09-21 19:29:20 +00:00
|
|
|
|
2013-01-24 11:49:49 +00: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-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2021-04-07 14:32:43 +00:00
|
|
|
static void acpi_scan_init_status(struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
if (acpi_bus_get_status(adev))
|
|
|
|
acpi_set_device_status(adev, 0);
|
|
|
|
}
|
|
|
|
|
2009-09-21 19:29:35 +00:00
|
|
|
static int acpi_add_single_object(struct acpi_device **child,
|
2021-05-10 17:53:18 +00:00
|
|
|
acpi_handle handle, int type, bool dep_init)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2021-01-20 18:59:51 +00:00
|
|
|
struct acpi_device *device;
|
2021-06-17 13:57:07 +00:00
|
|
|
bool release_dep_lock = false;
|
2021-01-20 18:59:51 +00:00
|
|
|
int result;
|
2020-11-21 20:30:35 +00:00
|
|
|
|
2006-12-19 20:56:11 +00:00
|
|
|
device = kzalloc(sizeof(struct acpi_device), GFP_KERNEL);
|
2021-04-07 14:33:38 +00:00
|
|
|
if (!device)
|
2006-06-27 04:41:40 +00:00
|
|
|
return -ENOMEM;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2021-04-07 14:33:38 +00:00
|
|
|
acpi_init_device_object(device, handle, type);
|
2018-01-26 15:02:59 +00:00
|
|
|
/*
|
2021-04-07 14:32:43 +00:00
|
|
|
* Getting the status is delayed till here so that we can call
|
|
|
|
* acpi_bus_get_status() and use its quirk handling. Note that
|
|
|
|
* this must be done before the get power-/wakeup_dev-flags calls.
|
2018-01-26 15:02:59 +00:00
|
|
|
*/
|
2021-05-10 17:53:18 +00:00
|
|
|
if (type == ACPI_BUS_TYPE_DEVICE || type == ACPI_BUS_TYPE_PROCESSOR) {
|
2021-06-17 13:57:07 +00:00
|
|
|
if (dep_init) {
|
|
|
|
mutex_lock(&acpi_dep_list_lock);
|
|
|
|
/*
|
|
|
|
* Hold the lock until the acpi_tie_acpi_dev() call
|
|
|
|
* below to prevent concurrent acpi_scan_clear_dep()
|
|
|
|
* from deleting a dependency list entry without
|
|
|
|
* updating dep_unmet for the device.
|
|
|
|
*/
|
|
|
|
release_dep_lock = true;
|
2021-05-10 17:53:18 +00:00
|
|
|
acpi_scan_dep_init(device);
|
2021-06-17 13:57:07 +00:00
|
|
|
}
|
2021-04-07 14:32:43 +00:00
|
|
|
acpi_scan_init_status(device);
|
2021-05-10 17:53:18 +00:00
|
|
|
}
|
2018-01-26 15:02:59 +00:00
|
|
|
|
2013-01-17 13:11:05 +00:00
|
|
|
acpi_bus_get_power_flags(device);
|
2011-01-06 22:41:27 +00:00
|
|
|
acpi_bus_get_wakeup_device_flags(device);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2021-06-17 13:57:07 +00:00
|
|
|
result = acpi_tie_acpi_dev(device);
|
|
|
|
|
|
|
|
if (release_dep_lock)
|
|
|
|
mutex_unlock(&acpi_dep_list_lock);
|
|
|
|
|
|
|
|
if (!result)
|
|
|
|
result = __acpi_device_add(device, acpi_device_release);
|
|
|
|
|
2013-01-17 13:11:05 +00:00
|
|
|
if (result) {
|
2009-08-06 23:18:12 +00:00
|
|
|
acpi_device_release(&device->dev);
|
2013-01-17 13:11:05 +00:00
|
|
|
return result;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2013-01-17 13:11:05 +00:00
|
|
|
acpi_power_add_remove_device(device, true);
|
2013-01-24 11:49:49 +00:00
|
|
|
acpi_device_add_finalize(device);
|
2021-01-20 18:59:51 +00:00
|
|
|
|
|
|
|
acpi_handle_debug(handle, "Added as %s, parent %s\n",
|
|
|
|
dev_name(&device->dev), device->parent ?
|
|
|
|
dev_name(&device->parent->dev) : "(null)");
|
|
|
|
|
2013-01-17 13:11:05 +00:00
|
|
|
*child = device;
|
|
|
|
return 0;
|
2010-11-24 23:10:44 +00:00
|
|
|
}
|
|
|
|
|
2016-04-07 12:03:18 +00:00
|
|
|
static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
|
|
|
|
void *context)
|
|
|
|
{
|
|
|
|
struct resource *res = context;
|
|
|
|
|
|
|
|
if (acpi_dev_resource_memory(ares, res))
|
|
|
|
return AE_CTRL_TERMINATE;
|
|
|
|
|
|
|
|
return AE_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool acpi_device_should_be_hidden(acpi_handle handle)
|
|
|
|
{
|
|
|
|
acpi_status status;
|
|
|
|
struct resource res;
|
|
|
|
|
|
|
|
/* Check if it should ignore the UART device */
|
|
|
|
if (!(spcr_uart_addr && acpi_has_method(handle, METHOD_NAME__CRS)))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The UART device described in SPCR table is assumed to have only one
|
|
|
|
* memory resource present. So we only look for the first one here.
|
|
|
|
*/
|
|
|
|
status = acpi_walk_resources(handle, METHOD_NAME__CRS,
|
|
|
|
acpi_get_resource_memory, &res);
|
|
|
|
if (ACPI_FAILURE(status) || res.start != spcr_uart_addr)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
acpi_handle_info(handle, "The UART device @%pa in SPCR table will be hidden\n",
|
|
|
|
&res.start);
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2017-06-06 09:37:36 +00:00
|
|
|
bool acpi_device_is_present(const struct acpi_device *adev)
|
ACPI / scan: Add acpi_device objects for all device nodes in the namespace
Modify the ACPI namespace scanning code to register a struct
acpi_device object for every namespace node representing a device,
processor and so on, even if the device represented by that namespace
node is reported to be not present and not functional by _STA.
There are multiple reasons to do that. First of all, it avoids
quite a lot of overhead when struct acpi_device objects are
deleted every time acpi_bus_trim() is run and then added again
by a subsequent acpi_bus_scan() for the same scope, although the
namespace objects they correspond to stay in memory all the time
(which always is the case on a vast majority of systems).
Second, it will allow user space to see that there are namespace
nodes representing devices that are not present at the moment and may
be added to the system. It will also allow user space to evaluate
_SUN for those nodes to check what physical slots the "missing"
devices may be put into and it will make sense to add a sysfs
attribute for _STA evaluation after this change (that will be
useful for thermal management on some systems).
Next, it will help to consolidate the ACPI hotplug handling among
subsystems by making it possible to store hotplug-related information
in struct acpi_device objects in a standard common way.
Finally, it will help to avoid a race condition related to the
deletion of ACPI namespace nodes. Namely, namespace nodes may be
deleted as a result of a table unload triggered by _EJ0 or _DCK.
If a hotplug notification for one of those nodes is triggered
right before the deletion and it executes a hotplug callback
via acpi_hotplug_execute(), the ACPI handle passed to that
callback may be stale when the callback actually runs. One way
to work around that is to always pass struct acpi_device pointers
to hotplug callbacks after doing a get_device() on the objects in
question which eliminates the use-after-free possibility (the ACPI
handles in those objects are invalidated by acpi_scan_drop_device(),
so they will trigger ACPICA errors on attempts to use them).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-22 20:54:37 +00:00
|
|
|
{
|
2017-06-06 09:37:36 +00:00
|
|
|
return adev->status.present || adev->status.functional;
|
ACPI / scan: Add acpi_device objects for all device nodes in the namespace
Modify the ACPI namespace scanning code to register a struct
acpi_device object for every namespace node representing a device,
processor and so on, even if the device represented by that namespace
node is reported to be not present and not functional by _STA.
There are multiple reasons to do that. First of all, it avoids
quite a lot of overhead when struct acpi_device objects are
deleted every time acpi_bus_trim() is run and then added again
by a subsequent acpi_bus_scan() for the same scope, although the
namespace objects they correspond to stay in memory all the time
(which always is the case on a vast majority of systems).
Second, it will allow user space to see that there are namespace
nodes representing devices that are not present at the moment and may
be added to the system. It will also allow user space to evaluate
_SUN for those nodes to check what physical slots the "missing"
devices may be put into and it will make sense to add a sysfs
attribute for _STA evaluation after this change (that will be
useful for thermal management on some systems).
Next, it will help to consolidate the ACPI hotplug handling among
subsystems by making it possible to store hotplug-related information
in struct acpi_device objects in a standard common way.
Finally, it will help to avoid a race condition related to the
deletion of ACPI namespace nodes. Namely, namespace nodes may be
deleted as a result of a table unload triggered by _EJ0 or _DCK.
If a hotplug notification for one of those nodes is triggered
right before the deletion and it executes a hotplug callback
via acpi_hotplug_execute(), the ACPI handle passed to that
callback may be stale when the callback actually runs. One way
to work around that is to always pass struct acpi_device pointers
to hotplug callbacks after doing a get_device() on the objects in
question which eliminates the use-after-free possibility (the ACPI
handles in those objects are invalidated by acpi_scan_drop_device(),
so they will trigger ACPICA errors on attempts to use them).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-22 20:54:37 +00:00
|
|
|
}
|
|
|
|
|
2013-03-03 22:06:21 +00:00
|
|
|
static bool acpi_scan_handler_matching(struct acpi_scan_handler *handler,
|
2015-09-09 21:59:42 +00:00
|
|
|
const char *idstr,
|
2013-03-03 22:06:21 +00:00
|
|
|
const struct acpi_device_id **matchid)
|
|
|
|
{
|
|
|
|
const struct acpi_device_id *devid;
|
|
|
|
|
2014-05-30 02:21:52 +00:00
|
|
|
if (handler->match)
|
|
|
|
return handler->match(idstr, matchid);
|
|
|
|
|
2013-03-03 22:06:21 +00:00
|
|
|
for (devid = handler->ids; devid->id[0]; devid++)
|
|
|
|
if (!strcmp((char *)devid->id, idstr)) {
|
|
|
|
if (matchid)
|
|
|
|
*matchid = devid;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2015-09-09 21:59:42 +00:00
|
|
|
static struct acpi_scan_handler *acpi_scan_match_handler(const char *idstr,
|
2013-03-04 21:30:43 +00:00
|
|
|
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-03 22:08:16 +00: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);
|
|
|
|
}
|
|
|
|
|
2014-02-06 16:31:37 +00:00
|
|
|
static void acpi_scan_init_hotplug(struct acpi_device *adev)
|
2013-03-03 22:05:29 +00:00
|
|
|
{
|
2013-03-04 21:30:43 +00:00
|
|
|
struct acpi_hardware_id *hwid;
|
2013-03-03 22:05:29 +00:00
|
|
|
|
2014-02-15 23:09:34 +00:00
|
|
|
if (acpi_dock_match(adev->handle) || is_ejectable_bay(adev)) {
|
ACPI / dock: Dispatch dock notifications from the global notify handler
The ACPI dock station code carries out an extra namespace scan
before the main one in order to find and register all of the dock
device objects. Then, it registers a notify handler for each of
them for handling dock events.
However, dock device objects need not be scanned for upfront. They
very well can be enumerated and registered during the first phase
of the main namespace scan, before attaching scan handlers and ACPI
drivers to ACPI device objects. Then, the dependent devices can be
added to the in the second phase. That makes it possible to drop
the extra namespace scan, so do it.
Moreover, it is not necessary to register notify handlers for all
of the dock stations' namespace nodes, becuase notifications may
be dispatched from the global notify handler for them. Do that and
drop two functions used for dock notify handling, acpi_dock_deferred_cb()
and dock_notify_handler(), that aren't necessary any more.
Finally, some dock station objects have _HID objects matching the
ACPI container scan handler which causes it to claim those objects
and try to handle their hotplug, but that is not a good idea,
because those objects have their own special hotplug handling anyway.
For this reason, the hotplug_notify flag should not be set for ACPI
device objects representing dock stations and the container scan
handler should be made ignore those objects, so make that happen.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-16 00:51:01 +00:00
|
|
|
acpi_dock_add(adev);
|
|
|
|
return;
|
|
|
|
}
|
2014-02-06 16:31:37 +00:00
|
|
|
list_for_each_entry(hwid, &adev->pnp.ids, list) {
|
|
|
|
struct acpi_scan_handler *handler;
|
2013-03-03 22:05:29 +00:00
|
|
|
|
2013-03-04 21:30:43 +00:00
|
|
|
handler = acpi_scan_match_handler(hwid->id, NULL);
|
2014-02-06 12:58:13 +00:00
|
|
|
if (handler) {
|
|
|
|
adev->flags.hotplug_notify = true;
|
|
|
|
break;
|
|
|
|
}
|
2014-02-06 16:31:37 +00:00
|
|
|
}
|
2013-03-03 22:05:29 +00:00
|
|
|
}
|
|
|
|
|
2021-04-07 14:30:56 +00:00
|
|
|
static u32 acpi_scan_check_dep(acpi_handle handle, bool check_dep)
|
2014-11-23 13:22:54 +00:00
|
|
|
{
|
|
|
|
struct acpi_handle_list dep_devices;
|
|
|
|
acpi_status status;
|
2020-12-14 20:25:23 +00:00
|
|
|
u32 count;
|
2014-11-23 13:22:54 +00:00
|
|
|
int i;
|
|
|
|
|
2020-12-14 20:27:27 +00:00
|
|
|
/*
|
|
|
|
* Check for _HID here to avoid deferring the enumeration of:
|
|
|
|
* 1. PCI devices.
|
|
|
|
* 2. ACPI nodes describing USB ports.
|
|
|
|
* Still, checking for _HID catches more then just these cases ...
|
|
|
|
*/
|
2021-04-07 14:30:56 +00:00
|
|
|
if (!check_dep || !acpi_has_method(handle, "_DEP") ||
|
|
|
|
!acpi_has_method(handle, "_HID"))
|
2020-12-14 20:25:23 +00:00
|
|
|
return 0;
|
2014-11-23 13:22:54 +00:00
|
|
|
|
2020-12-14 20:25:23 +00:00
|
|
|
status = acpi_evaluate_reference(handle, "_DEP", NULL, &dep_devices);
|
2014-11-23 13:22:54 +00:00
|
|
|
if (ACPI_FAILURE(status)) {
|
2020-12-14 20:25:23 +00:00
|
|
|
acpi_handle_debug(handle, "Failed to evaluate _DEP.\n");
|
|
|
|
return 0;
|
2014-11-23 13:22:54 +00:00
|
|
|
}
|
|
|
|
|
2020-12-14 20:25:23 +00:00
|
|
|
for (count = 0, i = 0; i < dep_devices.count; i++) {
|
2014-11-23 13:22:54 +00:00
|
|
|
struct acpi_device_info *info;
|
2020-12-14 20:25:23 +00:00
|
|
|
struct acpi_dep_data *dep;
|
ACPI: delay enumeration of devices with a _DEP pointing to an INT3472 device
The clk and regulator frameworks expect clk/regulator consumer-devices
to have info about the consumed clks/regulators described in the device's
fw_node.
To work around cases where this info is not present in the firmware tables,
which is often the case on x86/ACPI devices, both frameworks allow the
provider-driver to attach info about consumers to the clks/regulators
when registering these.
This causes problems with the probe ordering wrt drivers for consumers
of these clks/regulators. Since the lookups are only registered when the
provider-driver binds, trying to get these clks/regulators before then
results in a -ENOENT error for clks and a dummy regulator for regulators.
One case where we hit this issue is camera sensors such as e.g. the OV8865
sensor found on the Microsoft Surface Go. The sensor uses clks, regulators
and GPIOs provided by a TPS68470 PMIC which is described in an INT3472
ACPI device. There is special platform code handling this and setting
platform_data with the necessary consumer info on the MFD cells
instantiated for the PMIC under: drivers/platform/x86/intel/int3472.
For this to work properly the ov8865 driver must not bind to the I2C-client
for the OV8865 sensor until after the TPS68470 PMIC gpio, regulator and
clk MFD cells have all been fully setup.
The OV8865 on the Microsoft Surface Go is just one example, all X86
devices using the Intel IPU3 camera block found on recent Intel SoCs
have similar issues where there is an INT3472 HID ACPI-device, which
describes the clks and regulators, and the driver for this INT3472 device
must be fully initialized before the sensor driver (any sensor driver)
binds for things to work properly.
On these devices the ACPI nodes describing the sensors all have a _DEP
dependency on the matching INT3472 ACPI device (there is one per sensor).
This allows solving the probe-ordering problem by delaying the enumeration
(instantiation of the I2C-client in the ov8865 example) of ACPI-devices
which have a _DEP dependency on an INT3472 device.
The new acpi_dev_ready_for_enumeration() helper used for this is also
exported because for devices, which have the enumeration_by_parent flag
set, the parent-driver will do its own scan of child ACPI devices and
it will try to enumerate those during its probe(). Code doing this such
as e.g. the i2c-core-acpi.c code must call this new helper to ensure
that it too delays the enumeration until all the _DEP dependencies are
met on devices which have the new honor_deps flag set.
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211203102857.44539-2-hdegoede@redhat.com
2021-12-03 10:28:44 +00:00
|
|
|
bool skip, honor_dep;
|
2014-11-23 13:22:54 +00:00
|
|
|
|
|
|
|
status = acpi_get_object_info(dep_devices.handles[i], &info);
|
|
|
|
if (ACPI_FAILURE(status)) {
|
2020-12-14 20:25:23 +00:00
|
|
|
acpi_handle_debug(handle, "Error reading _DEP device info\n");
|
2014-11-23 13:22:54 +00:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2020-12-05 15:29:41 +00:00
|
|
|
skip = acpi_info_matches_ids(info, acpi_ignore_dep_ids);
|
ACPI: delay enumeration of devices with a _DEP pointing to an INT3472 device
The clk and regulator frameworks expect clk/regulator consumer-devices
to have info about the consumed clks/regulators described in the device's
fw_node.
To work around cases where this info is not present in the firmware tables,
which is often the case on x86/ACPI devices, both frameworks allow the
provider-driver to attach info about consumers to the clks/regulators
when registering these.
This causes problems with the probe ordering wrt drivers for consumers
of these clks/regulators. Since the lookups are only registered when the
provider-driver binds, trying to get these clks/regulators before then
results in a -ENOENT error for clks and a dummy regulator for regulators.
One case where we hit this issue is camera sensors such as e.g. the OV8865
sensor found on the Microsoft Surface Go. The sensor uses clks, regulators
and GPIOs provided by a TPS68470 PMIC which is described in an INT3472
ACPI device. There is special platform code handling this and setting
platform_data with the necessary consumer info on the MFD cells
instantiated for the PMIC under: drivers/platform/x86/intel/int3472.
For this to work properly the ov8865 driver must not bind to the I2C-client
for the OV8865 sensor until after the TPS68470 PMIC gpio, regulator and
clk MFD cells have all been fully setup.
The OV8865 on the Microsoft Surface Go is just one example, all X86
devices using the Intel IPU3 camera block found on recent Intel SoCs
have similar issues where there is an INT3472 HID ACPI-device, which
describes the clks and regulators, and the driver for this INT3472 device
must be fully initialized before the sensor driver (any sensor driver)
binds for things to work properly.
On these devices the ACPI nodes describing the sensors all have a _DEP
dependency on the matching INT3472 ACPI device (there is one per sensor).
This allows solving the probe-ordering problem by delaying the enumeration
(instantiation of the I2C-client in the ov8865 example) of ACPI-devices
which have a _DEP dependency on an INT3472 device.
The new acpi_dev_ready_for_enumeration() helper used for this is also
exported because for devices, which have the enumeration_by_parent flag
set, the parent-driver will do its own scan of child ACPI devices and
it will try to enumerate those during its probe(). Code doing this such
as e.g. the i2c-core-acpi.c code must call this new helper to ensure
that it too delays the enumeration until all the _DEP dependencies are
met on devices which have the new honor_deps flag set.
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211203102857.44539-2-hdegoede@redhat.com
2021-12-03 10:28:44 +00:00
|
|
|
honor_dep = acpi_info_matches_ids(info, acpi_honor_dep_ids);
|
2014-11-23 13:22:54 +00:00
|
|
|
kfree(info);
|
|
|
|
|
|
|
|
if (skip)
|
|
|
|
continue;
|
|
|
|
|
2020-12-14 20:25:23 +00:00
|
|
|
dep = kzalloc(sizeof(*dep), GFP_KERNEL);
|
2014-11-23 13:22:54 +00:00
|
|
|
if (!dep)
|
2020-12-14 20:25:23 +00:00
|
|
|
continue;
|
|
|
|
|
|
|
|
count++;
|
2014-11-23 13:22:54 +00:00
|
|
|
|
2020-12-07 17:46:06 +00:00
|
|
|
dep->supplier = dep_devices.handles[i];
|
2020-12-14 20:25:23 +00:00
|
|
|
dep->consumer = handle;
|
ACPI: delay enumeration of devices with a _DEP pointing to an INT3472 device
The clk and regulator frameworks expect clk/regulator consumer-devices
to have info about the consumed clks/regulators described in the device's
fw_node.
To work around cases where this info is not present in the firmware tables,
which is often the case on x86/ACPI devices, both frameworks allow the
provider-driver to attach info about consumers to the clks/regulators
when registering these.
This causes problems with the probe ordering wrt drivers for consumers
of these clks/regulators. Since the lookups are only registered when the
provider-driver binds, trying to get these clks/regulators before then
results in a -ENOENT error for clks and a dummy regulator for regulators.
One case where we hit this issue is camera sensors such as e.g. the OV8865
sensor found on the Microsoft Surface Go. The sensor uses clks, regulators
and GPIOs provided by a TPS68470 PMIC which is described in an INT3472
ACPI device. There is special platform code handling this and setting
platform_data with the necessary consumer info on the MFD cells
instantiated for the PMIC under: drivers/platform/x86/intel/int3472.
For this to work properly the ov8865 driver must not bind to the I2C-client
for the OV8865 sensor until after the TPS68470 PMIC gpio, regulator and
clk MFD cells have all been fully setup.
The OV8865 on the Microsoft Surface Go is just one example, all X86
devices using the Intel IPU3 camera block found on recent Intel SoCs
have similar issues where there is an INT3472 HID ACPI-device, which
describes the clks and regulators, and the driver for this INT3472 device
must be fully initialized before the sensor driver (any sensor driver)
binds for things to work properly.
On these devices the ACPI nodes describing the sensors all have a _DEP
dependency on the matching INT3472 ACPI device (there is one per sensor).
This allows solving the probe-ordering problem by delaying the enumeration
(instantiation of the I2C-client in the ov8865 example) of ACPI-devices
which have a _DEP dependency on an INT3472 device.
The new acpi_dev_ready_for_enumeration() helper used for this is also
exported because for devices, which have the enumeration_by_parent flag
set, the parent-driver will do its own scan of child ACPI devices and
it will try to enumerate those during its probe(). Code doing this such
as e.g. the i2c-core-acpi.c code must call this new helper to ensure
that it too delays the enumeration until all the _DEP dependencies are
met on devices which have the new honor_deps flag set.
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211203102857.44539-2-hdegoede@redhat.com
2021-12-03 10:28:44 +00:00
|
|
|
dep->honor_dep = honor_dep;
|
2014-11-23 13:22:54 +00:00
|
|
|
|
|
|
|
mutex_lock(&acpi_dep_list_lock);
|
|
|
|
list_add_tail(&dep->node , &acpi_dep_list);
|
|
|
|
mutex_unlock(&acpi_dep_list_lock);
|
|
|
|
}
|
2020-12-14 20:25:23 +00:00
|
|
|
|
|
|
|
return count;
|
2014-11-23 13:22:54 +00:00
|
|
|
}
|
|
|
|
|
2020-12-14 20:32:44 +00:00
|
|
|
static bool acpi_bus_scan_second_pass;
|
|
|
|
|
2020-12-14 20:27:27 +00:00
|
|
|
static acpi_status acpi_bus_check_add(acpi_handle handle, bool check_dep,
|
|
|
|
struct acpi_device **adev_p)
|
2009-09-21 19:30:06 +00:00
|
|
|
{
|
2021-12-03 16:36:20 +00:00
|
|
|
struct acpi_device *device = acpi_fetch_acpi_dev(handle);
|
2021-04-07 14:30:01 +00:00
|
|
|
acpi_object_type acpi_type;
|
2020-12-14 20:25:23 +00:00
|
|
|
int type;
|
2009-09-21 19:30:06 +00:00
|
|
|
|
2012-12-20 23:36:44 +00:00
|
|
|
if (device)
|
|
|
|
goto out;
|
|
|
|
|
2021-04-07 14:30:01 +00:00
|
|
|
if (ACPI_FAILURE(acpi_get_type(handle, &acpi_type)))
|
2009-09-21 19:30:06 +00:00
|
|
|
return AE_OK;
|
|
|
|
|
2021-04-07 14:30:01 +00:00
|
|
|
switch (acpi_type) {
|
|
|
|
case ACPI_TYPE_DEVICE:
|
|
|
|
if (acpi_device_should_be_hidden(handle))
|
|
|
|
return AE_OK;
|
2013-01-17 13:11:05 +00:00
|
|
|
|
2021-04-07 14:30:56 +00:00
|
|
|
/* Bail out if there are dependencies. */
|
|
|
|
if (acpi_scan_check_dep(handle, check_dep) > 0) {
|
2020-12-14 20:32:44 +00:00
|
|
|
acpi_bus_scan_second_pass = true;
|
2020-12-14 20:27:27 +00:00
|
|
|
return AE_CTRL_DEPTH;
|
2020-12-14 20:32:44 +00:00
|
|
|
}
|
2021-04-07 14:30:56 +00:00
|
|
|
|
2021-04-07 14:30:01 +00:00
|
|
|
fallthrough;
|
|
|
|
case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
|
|
|
|
type = ACPI_BUS_TYPE_DEVICE;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case ACPI_TYPE_PROCESSOR:
|
|
|
|
type = ACPI_BUS_TYPE_PROCESSOR;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case ACPI_TYPE_THERMAL:
|
|
|
|
type = ACPI_BUS_TYPE_THERMAL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case ACPI_TYPE_POWER:
|
2013-01-17 13:11:05 +00:00
|
|
|
acpi_add_power_resource(handle);
|
2021-04-07 14:30:56 +00:00
|
|
|
fallthrough;
|
|
|
|
default:
|
2013-01-17 13:11:05 +00:00
|
|
|
return AE_OK;
|
2020-12-14 20:27:27 +00:00
|
|
|
}
|
2020-12-14 20:25:23 +00:00
|
|
|
|
2021-03-30 18:49:32 +00:00
|
|
|
/*
|
|
|
|
* If check_dep is true at this point, the device has no dependencies,
|
|
|
|
* or the creation of the device object would have been postponed above.
|
|
|
|
*/
|
2021-05-10 17:53:18 +00:00
|
|
|
acpi_add_single_object(&device, handle, type, !check_dep);
|
|
|
|
if (!device)
|
|
|
|
return AE_CTRL_DEPTH;
|
|
|
|
|
|
|
|
acpi_scan_init_hotplug(device);
|
2014-02-06 16:31:37 +00:00
|
|
|
|
2020-12-14 20:27:27 +00:00
|
|
|
out:
|
|
|
|
if (!*adev_p)
|
|
|
|
*adev_p = 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-20 23:36:39 +00:00
|
|
|
|
2009-09-21 19:29:56 +00:00
|
|
|
return AE_OK;
|
|
|
|
}
|
2005-04-28 07:25:52 +00:00
|
|
|
|
2020-12-14 20:27:27 +00:00
|
|
|
static acpi_status acpi_bus_check_add_1(acpi_handle handle, u32 lvl_not_used,
|
|
|
|
void *not_used, void **ret_p)
|
|
|
|
{
|
|
|
|
return acpi_bus_check_add(handle, true, (struct acpi_device **)ret_p);
|
|
|
|
}
|
|
|
|
|
|
|
|
static acpi_status acpi_bus_check_add_2(acpi_handle handle, u32 lvl_not_used,
|
|
|
|
void *not_used, void **ret_p)
|
|
|
|
{
|
|
|
|
return acpi_bus_check_add(handle, false, (struct acpi_device **)ret_p);
|
|
|
|
}
|
|
|
|
|
2014-05-30 12:35:34 +00:00
|
|
|
static void acpi_default_enumeration(struct acpi_device *device)
|
|
|
|
{
|
|
|
|
/*
|
2018-03-14 18:15:56 +00:00
|
|
|
* Do not enumerate devices with enumeration_by_parent flag set as
|
|
|
|
* they will be enumerated by their respective parents.
|
2014-05-30 12:35:34 +00:00
|
|
|
*/
|
2018-03-14 18:15:56 +00:00
|
|
|
if (!device->flags.enumeration_by_parent) {
|
2016-11-03 14:21:26 +00:00
|
|
|
acpi_create_platform_device(device, NULL);
|
2016-07-08 16:13:08 +00:00
|
|
|
acpi_device_set_enumerated(device);
|
2016-07-08 16:13:09 +00:00
|
|
|
} else {
|
|
|
|
blocking_notifier_call_chain(&acpi_reconfig_chain,
|
|
|
|
ACPI_RECONFIG_DEVICE_ADD, device);
|
2016-07-08 16:13:08 +00:00
|
|
|
}
|
2014-05-30 12:35:34 +00:00
|
|
|
}
|
|
|
|
|
2015-04-24 00:18:01 +00:00
|
|
|
static const struct acpi_device_id generic_device_ids[] = {
|
2015-05-22 02:24:34 +00:00
|
|
|
{ACPI_DT_NAMESPACE_HID, },
|
2015-04-24 00:18:01 +00:00
|
|
|
{"", },
|
|
|
|
};
|
|
|
|
|
|
|
|
static int acpi_generic_device_attach(struct acpi_device *adev,
|
|
|
|
const struct acpi_device_id *not_used)
|
|
|
|
{
|
|
|
|
/*
|
2015-05-22 02:24:34 +00:00
|
|
|
* Since ACPI_DT_NAMESPACE_HID is the only ID handled here, the test
|
|
|
|
* below can be unconditional.
|
2015-04-24 00:18:01 +00:00
|
|
|
*/
|
|
|
|
if (adev->data.of_compatible)
|
|
|
|
acpi_default_enumeration(adev);
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct acpi_scan_handler generic_device_handler = {
|
|
|
|
.ids = generic_device_ids,
|
|
|
|
.attach = acpi_generic_device_attach,
|
|
|
|
};
|
|
|
|
|
2013-03-03 22:05:14 +00:00
|
|
|
static int acpi_scan_attach_handler(struct acpi_device *device)
|
2013-01-30 13:27:29 +00:00
|
|
|
{
|
2013-03-03 22:05:14 +00:00
|
|
|
struct acpi_hardware_id *hwid;
|
|
|
|
int ret = 0;
|
2013-01-30 13:27:29 +00:00
|
|
|
|
2013-03-03 22:05:14 +00:00
|
|
|
list_for_each_entry(hwid, &device->pnp.ids, list) {
|
2013-02-06 12:05:22 +00:00
|
|
|
const struct acpi_device_id *devid;
|
2013-03-03 22:05:14 +00:00
|
|
|
struct acpi_scan_handler *handler;
|
2013-01-30 13:27:29 +00:00
|
|
|
|
2013-03-03 22:05:14 +00:00
|
|
|
handler = acpi_scan_match_handler(hwid->id, &devid);
|
|
|
|
if (handler) {
|
2014-05-30 02:27:31 +00:00
|
|
|
if (!handler->attach) {
|
|
|
|
device->pnp.type.platform_id = 0;
|
|
|
|
continue;
|
|
|
|
}
|
2014-02-10 23:35:46 +00:00
|
|
|
device->handler = handler;
|
2013-02-06 12:05:22 +00:00
|
|
|
ret = handler->attach(device, devid);
|
2014-02-10 23:35:46 +00:00
|
|
|
if (ret > 0)
|
2013-03-03 22:05:14 +00:00
|
|
|
break;
|
2014-02-10 23:35:46 +00:00
|
|
|
|
|
|
|
device->handler = NULL;
|
|
|
|
if (ret < 0)
|
2013-03-03 22:05:14 +00:00
|
|
|
break;
|
2013-01-30 13:27:29 +00:00
|
|
|
}
|
|
|
|
}
|
2014-05-30 12:35:34 +00:00
|
|
|
|
2013-01-30 13:27:29 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2020-12-14 20:27:27 +00:00
|
|
|
static void acpi_bus_attach(struct acpi_device *device, bool first_pass)
|
2009-09-21 19:29:56 +00:00
|
|
|
{
|
2013-11-24 23:52:21 +00:00
|
|
|
struct acpi_device *child;
|
2020-12-14 20:27:27 +00:00
|
|
|
bool skip = !first_pass && device->flags.visited;
|
ACPI / dock: Dispatch dock notifications from the global notify handler
The ACPI dock station code carries out an extra namespace scan
before the main one in order to find and register all of the dock
device objects. Then, it registers a notify handler for each of
them for handling dock events.
However, dock device objects need not be scanned for upfront. They
very well can be enumerated and registered during the first phase
of the main namespace scan, before attaching scan handlers and ACPI
drivers to ACPI device objects. Then, the dependent devices can be
added to the in the second phase. That makes it possible to drop
the extra namespace scan, so do it.
Moreover, it is not necessary to register notify handlers for all
of the dock stations' namespace nodes, becuase notifications may
be dispatched from the global notify handler for them. Do that and
drop two functions used for dock notify handling, acpi_dock_deferred_cb()
and dock_notify_handler(), that aren't necessary any more.
Finally, some dock station objects have _HID objects matching the
ACPI container scan handler which causes it to claim those objects
and try to handle their hotplug, but that is not a good idea,
because those objects have their own special hotplug handling anyway.
For this reason, the hotplug_notify flag should not be set for ACPI
device objects representing dock stations and the container scan
handler should be made ignore those objects, so make that happen.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-16 00:51:01 +00:00
|
|
|
acpi_handle ejd;
|
2013-01-30 13:27:29 +00:00
|
|
|
int ret;
|
2005-04-28 07:25:52 +00:00
|
|
|
|
2020-12-14 20:27:27 +00:00
|
|
|
if (skip)
|
|
|
|
goto ok;
|
|
|
|
|
ACPI / dock: Dispatch dock notifications from the global notify handler
The ACPI dock station code carries out an extra namespace scan
before the main one in order to find and register all of the dock
device objects. Then, it registers a notify handler for each of
them for handling dock events.
However, dock device objects need not be scanned for upfront. They
very well can be enumerated and registered during the first phase
of the main namespace scan, before attaching scan handlers and ACPI
drivers to ACPI device objects. Then, the dependent devices can be
added to the in the second phase. That makes it possible to drop
the extra namespace scan, so do it.
Moreover, it is not necessary to register notify handlers for all
of the dock stations' namespace nodes, becuase notifications may
be dispatched from the global notify handler for them. Do that and
drop two functions used for dock notify handling, acpi_dock_deferred_cb()
and dock_notify_handler(), that aren't necessary any more.
Finally, some dock station objects have _HID objects matching the
ACPI container scan handler which causes it to claim those objects
and try to handle their hotplug, but that is not a good idea,
because those objects have their own special hotplug handling anyway.
For this reason, the hotplug_notify flag should not be set for ACPI
device objects representing dock stations and the container scan
handler should be made ignore those objects, so make that happen.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-16 00:51:01 +00:00
|
|
|
if (ACPI_SUCCESS(acpi_bus_get_ejd(device->handle, &ejd)))
|
|
|
|
register_dock_dependent_device(device, ejd);
|
|
|
|
|
2013-11-24 23:52:21 +00:00
|
|
|
acpi_bus_get_status(device);
|
ACPI: delay enumeration of devices with a _DEP pointing to an INT3472 device
The clk and regulator frameworks expect clk/regulator consumer-devices
to have info about the consumed clks/regulators described in the device's
fw_node.
To work around cases where this info is not present in the firmware tables,
which is often the case on x86/ACPI devices, both frameworks allow the
provider-driver to attach info about consumers to the clks/regulators
when registering these.
This causes problems with the probe ordering wrt drivers for consumers
of these clks/regulators. Since the lookups are only registered when the
provider-driver binds, trying to get these clks/regulators before then
results in a -ENOENT error for clks and a dummy regulator for regulators.
One case where we hit this issue is camera sensors such as e.g. the OV8865
sensor found on the Microsoft Surface Go. The sensor uses clks, regulators
and GPIOs provided by a TPS68470 PMIC which is described in an INT3472
ACPI device. There is special platform code handling this and setting
platform_data with the necessary consumer info on the MFD cells
instantiated for the PMIC under: drivers/platform/x86/intel/int3472.
For this to work properly the ov8865 driver must not bind to the I2C-client
for the OV8865 sensor until after the TPS68470 PMIC gpio, regulator and
clk MFD cells have all been fully setup.
The OV8865 on the Microsoft Surface Go is just one example, all X86
devices using the Intel IPU3 camera block found on recent Intel SoCs
have similar issues where there is an INT3472 HID ACPI-device, which
describes the clks and regulators, and the driver for this INT3472 device
must be fully initialized before the sensor driver (any sensor driver)
binds for things to work properly.
On these devices the ACPI nodes describing the sensors all have a _DEP
dependency on the matching INT3472 ACPI device (there is one per sensor).
This allows solving the probe-ordering problem by delaying the enumeration
(instantiation of the I2C-client in the ov8865 example) of ACPI-devices
which have a _DEP dependency on an INT3472 device.
The new acpi_dev_ready_for_enumeration() helper used for this is also
exported because for devices, which have the enumeration_by_parent flag
set, the parent-driver will do its own scan of child ACPI devices and
it will try to enumerate those during its probe(). Code doing this such
as e.g. the i2c-core-acpi.c code must call this new helper to ensure
that it too delays the enumeration until all the _DEP dependencies are
met on devices which have the new honor_deps flag set.
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211203102857.44539-2-hdegoede@redhat.com
2021-12-03 10:28:44 +00:00
|
|
|
/* Skip devices that are not ready for enumeration (e.g. not present) */
|
|
|
|
if (!acpi_dev_ready_for_enumeration(device)) {
|
2017-06-06 09:37:36 +00:00
|
|
|
device->flags.initialized = false;
|
2016-07-08 16:13:08 +00:00
|
|
|
acpi_device_clear_enumerated(device);
|
ACPI / PM: Fix PM initialization for devices that are not present
If an ACPI device object whose _STA returns 0 (not present and not
functional) has _PR0 or _PS0, its power_manageable flag will be set
and acpi_bus_init_power() will return 0 for it. Consequently, if
such a device object is passed to the ACPI device PM functions, they
will attempt to carry out the requested operation on the device,
although they should not do that for devices that are not present.
To fix that problem make acpi_bus_init_power() return an error code
for devices that are not present which will cause power_manageable to
be cleared for them as appropriate in acpi_bus_get_power_flags().
However, the lists of power resources should not be freed for the
device in that case, so modify acpi_bus_get_power_flags() to keep
those lists even if acpi_bus_init_power() returns an error.
Accordingly, when deciding whether or not the lists of power
resources need to be freed, acpi_free_power_resources_lists()
should check the power.flags.power_resources flag instead of
flags.power_manageable, so make that change too.
Furthermore, if acpi_bus_attach() sees that flags.initialized is
unset for the given device, it should reset the power management
settings of the device and re-initialize them from scratch instead
of relying on the previous settings (the device may have appeared
after being not present previously, for example), so make it use
the 'valid' flag of the D0 power state as the initial value of
flags.power_manageable for it and call acpi_bus_init_power() to
discover its current power state.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
2015-01-01 22:38:28 +00:00
|
|
|
device->flags.power_manageable = 0;
|
2013-11-24 23:52:21 +00:00
|
|
|
return;
|
|
|
|
}
|
2013-07-12 11:45:59 +00:00
|
|
|
if (device->handler)
|
2013-11-24 23:52:21 +00:00
|
|
|
goto ok;
|
2013-07-12 11:45:59 +00:00
|
|
|
|
ACPI / scan: Add acpi_device objects for all device nodes in the namespace
Modify the ACPI namespace scanning code to register a struct
acpi_device object for every namespace node representing a device,
processor and so on, even if the device represented by that namespace
node is reported to be not present and not functional by _STA.
There are multiple reasons to do that. First of all, it avoids
quite a lot of overhead when struct acpi_device objects are
deleted every time acpi_bus_trim() is run and then added again
by a subsequent acpi_bus_scan() for the same scope, although the
namespace objects they correspond to stay in memory all the time
(which always is the case on a vast majority of systems).
Second, it will allow user space to see that there are namespace
nodes representing devices that are not present at the moment and may
be added to the system. It will also allow user space to evaluate
_SUN for those nodes to check what physical slots the "missing"
devices may be put into and it will make sense to add a sysfs
attribute for _STA evaluation after this change (that will be
useful for thermal management on some systems).
Next, it will help to consolidate the ACPI hotplug handling among
subsystems by making it possible to store hotplug-related information
in struct acpi_device objects in a standard common way.
Finally, it will help to avoid a race condition related to the
deletion of ACPI namespace nodes. Namely, namespace nodes may be
deleted as a result of a table unload triggered by _EJ0 or _DCK.
If a hotplug notification for one of those nodes is triggered
right before the deletion and it executes a hotplug callback
via acpi_hotplug_execute(), the ACPI handle passed to that
callback may be stale when the callback actually runs. One way
to work around that is to always pass struct acpi_device pointers
to hotplug callbacks after doing a get_device() on the objects in
question which eliminates the use-after-free possibility (the ACPI
handles in those objects are invalidated by acpi_scan_drop_device(),
so they will trigger ACPICA errors on attempts to use them).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-22 20:54:37 +00:00
|
|
|
if (!device->flags.initialized) {
|
ACPI / PM: Fix PM initialization for devices that are not present
If an ACPI device object whose _STA returns 0 (not present and not
functional) has _PR0 or _PS0, its power_manageable flag will be set
and acpi_bus_init_power() will return 0 for it. Consequently, if
such a device object is passed to the ACPI device PM functions, they
will attempt to carry out the requested operation on the device,
although they should not do that for devices that are not present.
To fix that problem make acpi_bus_init_power() return an error code
for devices that are not present which will cause power_manageable to
be cleared for them as appropriate in acpi_bus_get_power_flags().
However, the lists of power resources should not be freed for the
device in that case, so modify acpi_bus_get_power_flags() to keep
those lists even if acpi_bus_init_power() returns an error.
Accordingly, when deciding whether or not the lists of power
resources need to be freed, acpi_free_power_resources_lists()
should check the power.flags.power_resources flag instead of
flags.power_manageable, so make that change too.
Furthermore, if acpi_bus_attach() sees that flags.initialized is
unset for the given device, it should reset the power management
settings of the device and re-initialize them from scratch instead
of relying on the previous settings (the device may have appeared
after being not present previously, for example), so make it use
the 'valid' flag of the D0 power state as the initial value of
flags.power_manageable for it and call acpi_bus_init_power() to
discover its current power state.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
2015-01-01 22:38:28 +00:00
|
|
|
device->flags.power_manageable =
|
|
|
|
device->power.states[ACPI_STATE_D0].flags.valid;
|
|
|
|
if (acpi_bus_init_power(device))
|
|
|
|
device->flags.power_manageable = 0;
|
|
|
|
|
ACPI / scan: Add acpi_device objects for all device nodes in the namespace
Modify the ACPI namespace scanning code to register a struct
acpi_device object for every namespace node representing a device,
processor and so on, even if the device represented by that namespace
node is reported to be not present and not functional by _STA.
There are multiple reasons to do that. First of all, it avoids
quite a lot of overhead when struct acpi_device objects are
deleted every time acpi_bus_trim() is run and then added again
by a subsequent acpi_bus_scan() for the same scope, although the
namespace objects they correspond to stay in memory all the time
(which always is the case on a vast majority of systems).
Second, it will allow user space to see that there are namespace
nodes representing devices that are not present at the moment and may
be added to the system. It will also allow user space to evaluate
_SUN for those nodes to check what physical slots the "missing"
devices may be put into and it will make sense to add a sysfs
attribute for _STA evaluation after this change (that will be
useful for thermal management on some systems).
Next, it will help to consolidate the ACPI hotplug handling among
subsystems by making it possible to store hotplug-related information
in struct acpi_device objects in a standard common way.
Finally, it will help to avoid a race condition related to the
deletion of ACPI namespace nodes. Namely, namespace nodes may be
deleted as a result of a table unload triggered by _EJ0 or _DCK.
If a hotplug notification for one of those nodes is triggered
right before the deletion and it executes a hotplug callback
via acpi_hotplug_execute(), the ACPI handle passed to that
callback may be stale when the callback actually runs. One way
to work around that is to always pass struct acpi_device pointers
to hotplug callbacks after doing a get_device() on the objects in
question which eliminates the use-after-free possibility (the ACPI
handles in those objects are invalidated by acpi_scan_drop_device(),
so they will trigger ACPICA errors on attempts to use them).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-22 20:54:37 +00:00
|
|
|
device->flags.initialized = true;
|
2017-04-16 23:20:48 +00:00
|
|
|
} else if (device->flags.visited) {
|
|
|
|
goto ok;
|
ACPI / scan: Add acpi_device objects for all device nodes in the namespace
Modify the ACPI namespace scanning code to register a struct
acpi_device object for every namespace node representing a device,
processor and so on, even if the device represented by that namespace
node is reported to be not present and not functional by _STA.
There are multiple reasons to do that. First of all, it avoids
quite a lot of overhead when struct acpi_device objects are
deleted every time acpi_bus_trim() is run and then added again
by a subsequent acpi_bus_scan() for the same scope, although the
namespace objects they correspond to stay in memory all the time
(which always is the case on a vast majority of systems).
Second, it will allow user space to see that there are namespace
nodes representing devices that are not present at the moment and may
be added to the system. It will also allow user space to evaluate
_SUN for those nodes to check what physical slots the "missing"
devices may be put into and it will make sense to add a sysfs
attribute for _STA evaluation after this change (that will be
useful for thermal management on some systems).
Next, it will help to consolidate the ACPI hotplug handling among
subsystems by making it possible to store hotplug-related information
in struct acpi_device objects in a standard common way.
Finally, it will help to avoid a race condition related to the
deletion of ACPI namespace nodes. Namely, namespace nodes may be
deleted as a result of a table unload triggered by _EJ0 or _DCK.
If a hotplug notification for one of those nodes is triggered
right before the deletion and it executes a hotplug callback
via acpi_hotplug_execute(), the ACPI handle passed to that
callback may be stale when the callback actually runs. One way
to work around that is to always pass struct acpi_device pointers
to hotplug callbacks after doing a get_device() on the objects in
question which eliminates the use-after-free possibility (the ACPI
handles in those objects are invalidated by acpi_scan_drop_device(),
so they will trigger ACPICA errors on attempts to use them).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-22 20:54:37 +00:00
|
|
|
}
|
2016-07-08 16:13:08 +00:00
|
|
|
|
2013-01-30 13:27:29 +00:00
|
|
|
ret = acpi_scan_attach_handler(device);
|
2013-11-07 00:41:01 +00:00
|
|
|
if (ret < 0)
|
2013-11-24 23:52:21 +00:00
|
|
|
return;
|
2013-11-07 00:41:01 +00:00
|
|
|
|
|
|
|
device->flags.match_driver = true;
|
2018-03-14 18:15:56 +00:00
|
|
|
if (ret > 0 && !device->flags.enumeration_by_parent) {
|
2017-04-10 22:23:42 +00:00
|
|
|
acpi_device_set_enumerated(device);
|
|
|
|
goto ok;
|
2013-11-24 23:52:21 +00:00
|
|
|
}
|
ACPI / scan: Add acpi_device objects for all device nodes in the namespace
Modify the ACPI namespace scanning code to register a struct
acpi_device object for every namespace node representing a device,
processor and so on, even if the device represented by that namespace
node is reported to be not present and not functional by _STA.
There are multiple reasons to do that. First of all, it avoids
quite a lot of overhead when struct acpi_device objects are
deleted every time acpi_bus_trim() is run and then added again
by a subsequent acpi_bus_scan() for the same scope, although the
namespace objects they correspond to stay in memory all the time
(which always is the case on a vast majority of systems).
Second, it will allow user space to see that there are namespace
nodes representing devices that are not present at the moment and may
be added to the system. It will also allow user space to evaluate
_SUN for those nodes to check what physical slots the "missing"
devices may be put into and it will make sense to add a sysfs
attribute for _STA evaluation after this change (that will be
useful for thermal management on some systems).
Next, it will help to consolidate the ACPI hotplug handling among
subsystems by making it possible to store hotplug-related information
in struct acpi_device objects in a standard common way.
Finally, it will help to avoid a race condition related to the
deletion of ACPI namespace nodes. Namely, namespace nodes may be
deleted as a result of a table unload triggered by _EJ0 or _DCK.
If a hotplug notification for one of those nodes is triggered
right before the deletion and it executes a hotplug callback
via acpi_hotplug_execute(), the ACPI handle passed to that
callback may be stale when the callback actually runs. One way
to work around that is to always pass struct acpi_device pointers
to hotplug callbacks after doing a get_device() on the objects in
question which eliminates the use-after-free possibility (the ACPI
handles in those objects are invalidated by acpi_scan_drop_device(),
so they will trigger ACPICA errors on attempts to use them).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-22 20:54:37 +00:00
|
|
|
|
2017-04-10 22:23:42 +00:00
|
|
|
ret = device_attach(&device->dev);
|
|
|
|
if (ret < 0)
|
|
|
|
return;
|
|
|
|
|
2018-03-14 18:15:56 +00:00
|
|
|
if (device->pnp.type.platform_id || device->flags.enumeration_by_parent)
|
2017-06-19 12:53:01 +00:00
|
|
|
acpi_default_enumeration(device);
|
2018-03-14 18:15:56 +00:00
|
|
|
else
|
|
|
|
acpi_device_set_enumerated(device);
|
2017-04-10 22:23:42 +00:00
|
|
|
|
2013-11-24 23:52:21 +00:00
|
|
|
ok:
|
|
|
|
list_for_each_entry(child, &device->children, node)
|
2020-12-14 20:27:27 +00:00
|
|
|
acpi_bus_attach(child, first_pass);
|
2014-09-21 00:58:18 +00:00
|
|
|
|
2020-12-14 20:27:27 +00:00
|
|
|
if (!skip && device->handler && device->handler->hotplug.notify_online)
|
2014-09-21 00:58:18 +00:00
|
|
|
device->handler->hotplug.notify_online(device);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2021-06-03 22:40:03 +00:00
|
|
|
static int acpi_dev_get_first_consumer_dev_cb(struct acpi_dep_data *dep, void *data)
|
2014-11-23 13:22:54 +00:00
|
|
|
{
|
|
|
|
struct acpi_device *adev;
|
|
|
|
|
2021-06-03 22:40:03 +00:00
|
|
|
adev = acpi_bus_get_acpi_device(dep->consumer);
|
2021-06-16 14:21:51 +00:00
|
|
|
if (adev) {
|
|
|
|
*(struct acpi_device **)data = adev;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
/* Continue parsing if the device object is not present. */
|
|
|
|
return 0;
|
2021-06-03 22:40:03 +00:00
|
|
|
}
|
|
|
|
|
2021-06-16 14:23:44 +00:00
|
|
|
struct acpi_scan_clear_dep_work {
|
|
|
|
struct work_struct work;
|
2014-11-23 13:22:54 +00:00
|
|
|
struct acpi_device *adev;
|
2021-06-16 14:23:44 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static void acpi_scan_clear_dep_fn(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct acpi_scan_clear_dep_work *cdw;
|
|
|
|
|
|
|
|
cdw = container_of(work, struct acpi_scan_clear_dep_work, work);
|
2014-11-23 13:22:54 +00:00
|
|
|
|
2021-06-16 14:23:44 +00:00
|
|
|
acpi_scan_lock_acquire();
|
|
|
|
acpi_bus_attach(cdw->adev, true);
|
|
|
|
acpi_scan_lock_release();
|
|
|
|
|
|
|
|
acpi_dev_put(cdw->adev);
|
|
|
|
kfree(cdw);
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool acpi_scan_clear_dep_queue(struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
struct acpi_scan_clear_dep_work *cdw;
|
|
|
|
|
|
|
|
if (adev->dep_unmet)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
cdw = kmalloc(sizeof(*cdw), GFP_KERNEL);
|
|
|
|
if (!cdw)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
cdw->adev = adev;
|
|
|
|
INIT_WORK(&cdw->work, acpi_scan_clear_dep_fn);
|
|
|
|
/*
|
|
|
|
* Since the work function may block on the lock until the entire
|
|
|
|
* initial enumeration of devices is complete, put it into the unbound
|
|
|
|
* workqueue.
|
|
|
|
*/
|
|
|
|
queue_work(system_unbound_wq, &cdw->work);
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int acpi_scan_clear_dep(struct acpi_dep_data *dep, void *data)
|
|
|
|
{
|
|
|
|
struct acpi_device *adev = acpi_bus_get_acpi_device(dep->consumer);
|
2021-06-03 22:40:02 +00:00
|
|
|
|
|
|
|
if (adev) {
|
|
|
|
adev->dep_unmet--;
|
2021-06-16 14:23:44 +00:00
|
|
|
if (!acpi_scan_clear_dep_queue(adev))
|
|
|
|
acpi_dev_put(adev);
|
2021-06-03 22:40:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
list_del(&dep->node);
|
|
|
|
kfree(dep);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_walk_dep_device_list - Apply a callback to every entry in acpi_dep_list
|
|
|
|
* @handle: The ACPI handle of the supplier device
|
|
|
|
* @callback: Pointer to the callback function to apply
|
|
|
|
* @data: Pointer to some data to pass to the callback
|
|
|
|
*
|
|
|
|
* The return value of the callback determines this function's behaviour. If 0
|
|
|
|
* is returned we continue to iterate over acpi_dep_list. If a positive value
|
|
|
|
* is returned then the loop is broken but this function returns 0. If a
|
|
|
|
* negative value is returned by the callback then the loop is broken and that
|
|
|
|
* value is returned as the final error.
|
|
|
|
*/
|
2021-06-16 14:22:50 +00:00
|
|
|
static int acpi_walk_dep_device_list(acpi_handle handle,
|
|
|
|
int (*callback)(struct acpi_dep_data *, void *),
|
|
|
|
void *data)
|
2021-06-03 22:40:02 +00:00
|
|
|
{
|
|
|
|
struct acpi_dep_data *dep, *tmp;
|
2021-06-09 17:33:12 +00:00
|
|
|
int ret = 0;
|
2021-06-03 22:40:02 +00:00
|
|
|
|
2014-11-23 13:22:54 +00:00
|
|
|
mutex_lock(&acpi_dep_list_lock);
|
|
|
|
list_for_each_entry_safe(dep, tmp, &acpi_dep_list, node) {
|
2020-12-07 17:46:06 +00:00
|
|
|
if (dep->supplier == handle) {
|
2021-06-03 22:40:02 +00:00
|
|
|
ret = callback(dep, data);
|
|
|
|
if (ret)
|
|
|
|
break;
|
2014-11-23 13:22:54 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
mutex_unlock(&acpi_dep_list_lock);
|
2021-06-03 22:40:02 +00:00
|
|
|
|
|
|
|
return ret > 0 ? 0 : ret;
|
2014-11-23 13:22:54 +00:00
|
|
|
}
|
|
|
|
|
2021-06-03 22:40:02 +00:00
|
|
|
/**
|
|
|
|
* acpi_dev_clear_dependencies - Inform consumers that the device is now active
|
|
|
|
* @supplier: Pointer to the supplier &struct acpi_device
|
|
|
|
*
|
|
|
|
* Clear dependencies on the given device.
|
|
|
|
*/
|
|
|
|
void acpi_dev_clear_dependencies(struct acpi_device *supplier)
|
|
|
|
{
|
|
|
|
acpi_walk_dep_device_list(supplier->handle, acpi_scan_clear_dep, NULL);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_dev_clear_dependencies);
|
|
|
|
|
ACPI: delay enumeration of devices with a _DEP pointing to an INT3472 device
The clk and regulator frameworks expect clk/regulator consumer-devices
to have info about the consumed clks/regulators described in the device's
fw_node.
To work around cases where this info is not present in the firmware tables,
which is often the case on x86/ACPI devices, both frameworks allow the
provider-driver to attach info about consumers to the clks/regulators
when registering these.
This causes problems with the probe ordering wrt drivers for consumers
of these clks/regulators. Since the lookups are only registered when the
provider-driver binds, trying to get these clks/regulators before then
results in a -ENOENT error for clks and a dummy regulator for regulators.
One case where we hit this issue is camera sensors such as e.g. the OV8865
sensor found on the Microsoft Surface Go. The sensor uses clks, regulators
and GPIOs provided by a TPS68470 PMIC which is described in an INT3472
ACPI device. There is special platform code handling this and setting
platform_data with the necessary consumer info on the MFD cells
instantiated for the PMIC under: drivers/platform/x86/intel/int3472.
For this to work properly the ov8865 driver must not bind to the I2C-client
for the OV8865 sensor until after the TPS68470 PMIC gpio, regulator and
clk MFD cells have all been fully setup.
The OV8865 on the Microsoft Surface Go is just one example, all X86
devices using the Intel IPU3 camera block found on recent Intel SoCs
have similar issues where there is an INT3472 HID ACPI-device, which
describes the clks and regulators, and the driver for this INT3472 device
must be fully initialized before the sensor driver (any sensor driver)
binds for things to work properly.
On these devices the ACPI nodes describing the sensors all have a _DEP
dependency on the matching INT3472 ACPI device (there is one per sensor).
This allows solving the probe-ordering problem by delaying the enumeration
(instantiation of the I2C-client in the ov8865 example) of ACPI-devices
which have a _DEP dependency on an INT3472 device.
The new acpi_dev_ready_for_enumeration() helper used for this is also
exported because for devices, which have the enumeration_by_parent flag
set, the parent-driver will do its own scan of child ACPI devices and
it will try to enumerate those during its probe(). Code doing this such
as e.g. the i2c-core-acpi.c code must call this new helper to ensure
that it too delays the enumeration until all the _DEP dependencies are
met on devices which have the new honor_deps flag set.
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211203102857.44539-2-hdegoede@redhat.com
2021-12-03 10:28:44 +00:00
|
|
|
/**
|
|
|
|
* acpi_dev_ready_for_enumeration - Check if the ACPI device is ready for enumeration
|
|
|
|
* @device: Pointer to the &struct acpi_device to check
|
|
|
|
*
|
|
|
|
* Check if the device is present and has no unmet dependencies.
|
|
|
|
*
|
|
|
|
* Return true if the device is ready for enumeratino. Otherwise, return false.
|
|
|
|
*/
|
|
|
|
bool acpi_dev_ready_for_enumeration(const struct acpi_device *device)
|
|
|
|
{
|
|
|
|
if (device->flags.honor_deps && device->dep_unmet)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return acpi_device_is_present(device);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_dev_ready_for_enumeration);
|
|
|
|
|
2021-06-03 22:40:03 +00:00
|
|
|
/**
|
|
|
|
* acpi_dev_get_first_consumer_dev - Return ACPI device dependent on @supplier
|
|
|
|
* @supplier: Pointer to the dependee device
|
|
|
|
*
|
|
|
|
* Returns the first &struct acpi_device which declares itself dependent on
|
|
|
|
* @supplier via the _DEP buffer, parsed from the acpi_dep_list.
|
|
|
|
*
|
|
|
|
* The caller is responsible for putting the reference to adev when it is no
|
|
|
|
* longer needed.
|
|
|
|
*/
|
|
|
|
struct acpi_device *acpi_dev_get_first_consumer_dev(struct acpi_device *supplier)
|
|
|
|
{
|
|
|
|
struct acpi_device *adev = NULL;
|
|
|
|
|
|
|
|
acpi_walk_dep_device_list(supplier->handle,
|
|
|
|
acpi_dev_get_first_consumer_dev_cb, &adev);
|
|
|
|
|
|
|
|
return adev;
|
2014-11-23 13:22:54 +00:00
|
|
|
}
|
2021-06-03 22:40:03 +00:00
|
|
|
EXPORT_SYMBOL_GPL(acpi_dev_get_first_consumer_dev);
|
2014-11-23 13:22:54 +00:00
|
|
|
|
2012-12-20 23:36:47 +00:00
|
|
|
/**
|
2013-01-19 00:27:35 +00:00
|
|
|
* acpi_bus_scan - Add ACPI device node objects in a given namespace scope.
|
2012-12-20 23:36:47 +00:00
|
|
|
* @handle: Root of the namespace scope to scan.
|
2010-01-29 16:48:52 +00:00
|
|
|
*
|
2012-12-20 23:36:47 +00:00
|
|
|
* Scan a given ACPI tree (probably recently hot-plugged) and create and add
|
|
|
|
* found devices.
|
2010-01-29 16:48:52 +00:00
|
|
|
*
|
2012-12-20 23:36:47 +00: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 13:36:47 +00:00
|
|
|
*
|
|
|
|
* Must be called under acpi_scan_lock.
|
2010-01-29 16:48:52 +00:00
|
|
|
*/
|
2013-01-19 00:27:35 +00:00
|
|
|
int acpi_bus_scan(acpi_handle handle)
|
2005-04-28 07:25:52 +00:00
|
|
|
{
|
2020-12-14 20:27:27 +00:00
|
|
|
struct acpi_device *device = NULL;
|
|
|
|
|
2020-12-14 20:32:44 +00:00
|
|
|
acpi_bus_scan_second_pass = false;
|
2005-04-28 07:25:52 +00:00
|
|
|
|
2020-12-14 20:27:27 +00:00
|
|
|
/* Pass 1: Avoid enumerating devices with missing dependencies. */
|
2005-04-28 07:25:52 +00:00
|
|
|
|
2020-12-14 20:27:27 +00:00
|
|
|
if (ACPI_SUCCESS(acpi_bus_check_add(handle, true, &device)))
|
2013-01-19 00:27:35 +00:00
|
|
|
acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
|
2020-12-14 20:27:27 +00:00
|
|
|
acpi_bus_check_add_1, NULL, NULL,
|
|
|
|
(void **)&device);
|
2005-04-28 07:25:52 +00:00
|
|
|
|
2020-12-14 20:27:27 +00:00
|
|
|
if (!device)
|
|
|
|
return -ENODEV;
|
2005-04-28 07:25:52 +00:00
|
|
|
|
2020-12-14 20:27:27 +00:00
|
|
|
acpi_bus_attach(device, true);
|
|
|
|
|
2020-12-14 20:32:44 +00:00
|
|
|
if (!acpi_bus_scan_second_pass)
|
2013-11-24 23:52:21 +00:00
|
|
|
return 0;
|
2020-12-14 20:32:44 +00:00
|
|
|
|
2020-12-14 20:27:27 +00:00
|
|
|
/* Pass 2: Enumerate all of the remaining devices. */
|
|
|
|
|
|
|
|
device = NULL;
|
|
|
|
|
|
|
|
if (ACPI_SUCCESS(acpi_bus_check_add(handle, false, &device)))
|
|
|
|
acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
|
|
|
|
acpi_bus_check_add_2, NULL, NULL,
|
|
|
|
(void **)&device);
|
|
|
|
|
|
|
|
acpi_bus_attach(device, false);
|
|
|
|
|
|
|
|
return 0;
|
2005-04-28 07:25:52 +00:00
|
|
|
}
|
2013-11-24 23:52:21 +00:00
|
|
|
EXPORT_SYMBOL(acpi_bus_scan);
|
2005-04-16 22:20:36 +00: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 13:36:47 +00:00
|
|
|
/**
|
2013-11-24 23:52:21 +00:00
|
|
|
* acpi_bus_trim - Detach scan handlers and drivers from ACPI device objects.
|
|
|
|
* @adev: Root of the ACPI namespace scope to walk.
|
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 13:36:47 +00:00
|
|
|
*
|
|
|
|
* Must be called under acpi_scan_lock.
|
|
|
|
*/
|
2013-11-24 23:52:21 +00:00
|
|
|
void acpi_bus_trim(struct acpi_device *adev)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2013-11-24 23:52:21 +00:00
|
|
|
struct acpi_scan_handler *handler = adev->handler;
|
|
|
|
struct acpi_device *child;
|
|
|
|
|
|
|
|
list_for_each_entry_reverse(child, &adev->children, node)
|
|
|
|
acpi_bus_trim(child);
|
|
|
|
|
2014-01-27 22:08:09 +00:00
|
|
|
adev->flags.match_driver = false;
|
2013-11-24 23:52:21 +00:00
|
|
|
if (handler) {
|
|
|
|
if (handler->detach)
|
|
|
|
handler->detach(adev);
|
|
|
|
|
|
|
|
adev->handler = NULL;
|
|
|
|
} else {
|
|
|
|
device_release_driver(&adev->dev);
|
|
|
|
}
|
2013-01-15 12:24:13 +00:00
|
|
|
/*
|
2013-11-24 23:52:21 +00:00
|
|
|
* Most likely, the device is going away, so put it into D3cold before
|
|
|
|
* that.
|
2013-01-15 12:24:13 +00:00
|
|
|
*/
|
2013-11-24 23:52:21 +00:00
|
|
|
acpi_device_set_power(adev, ACPI_STATE_D3_COLD);
|
|
|
|
adev->flags.initialized = false;
|
2016-07-08 16:13:08 +00:00
|
|
|
acpi_device_clear_enumerated(adev);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2006-02-24 01:56:01 +00:00
|
|
|
EXPORT_SYMBOL_GPL(acpi_bus_trim);
|
|
|
|
|
2017-09-26 08:54:09 +00:00
|
|
|
int acpi_bus_register_early_device(int type)
|
|
|
|
{
|
|
|
|
struct acpi_device *device = NULL;
|
|
|
|
int result;
|
|
|
|
|
2021-05-10 17:53:18 +00:00
|
|
|
result = acpi_add_single_object(&device, NULL, type, false);
|
2017-09-26 08:54:09 +00:00
|
|
|
if (result)
|
|
|
|
return result;
|
|
|
|
|
|
|
|
device->flags.match_driver = true;
|
|
|
|
return device_attach(&device->dev);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_bus_register_early_device);
|
|
|
|
|
2022-01-11 16:52:00 +00:00
|
|
|
static void acpi_bus_scan_fixed(void)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2013-01-29 12:57:20 +00:00
|
|
|
if (!(acpi_gbl_FADT.flags & ACPI_FADT_POWER_BUTTON)) {
|
2022-01-11 16:52:00 +00:00
|
|
|
struct acpi_device *adev = NULL;
|
|
|
|
|
|
|
|
acpi_add_single_object(&adev, NULL, ACPI_BUS_TYPE_POWER_BUTTON,
|
|
|
|
false);
|
|
|
|
if (adev) {
|
|
|
|
adev->flags.match_driver = true;
|
|
|
|
if (device_attach(&adev->dev) >= 0)
|
|
|
|
device_init_wakeup(&adev->dev, true);
|
|
|
|
else
|
|
|
|
dev_dbg(&adev->dev, "No driver\n");
|
|
|
|
}
|
2005-04-28 07:25:52 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2013-01-29 12:57:20 +00:00
|
|
|
if (!(acpi_gbl_FADT.flags & ACPI_FADT_SLEEP_BUTTON)) {
|
2022-01-11 16:52:00 +00:00
|
|
|
struct acpi_device *adev = NULL;
|
|
|
|
|
|
|
|
acpi_add_single_object(&adev, NULL, ACPI_BUS_TYPE_SLEEP_BUTTON,
|
|
|
|
false);
|
|
|
|
if (adev) {
|
|
|
|
adev->flags.match_driver = true;
|
|
|
|
if (device_attach(&adev->dev) < 0)
|
|
|
|
dev_dbg(&adev->dev, "No driver\n");
|
|
|
|
}
|
2005-04-28 07:25:52 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2016-04-07 12:03:18 +00:00
|
|
|
static void __init acpi_get_spcr_uart_addr(void)
|
|
|
|
{
|
|
|
|
acpi_status status;
|
|
|
|
struct acpi_table_spcr *spcr_ptr;
|
|
|
|
|
|
|
|
status = acpi_get_table(ACPI_SIG_SPCR, 0,
|
|
|
|
(struct acpi_table_header **)&spcr_ptr);
|
2020-05-07 09:09:20 +00:00
|
|
|
if (ACPI_FAILURE(status)) {
|
2021-06-02 08:54:37 +00:00
|
|
|
pr_warn("STAO table present, but SPCR is missing\n");
|
2020-05-07 09:09:20 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
spcr_uart_addr = spcr_ptr->serial_port.address;
|
|
|
|
acpi_put_table((struct acpi_table_header *)spcr_ptr);
|
2016-04-07 12:03:18 +00:00
|
|
|
}
|
|
|
|
|
2016-07-08 16:13:09 +00:00
|
|
|
static bool acpi_scan_initialized;
|
|
|
|
|
2022-01-11 16:50:22 +00:00
|
|
|
void __init acpi_scan_init(void)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2016-04-07 12:03:18 +00:00
|
|
|
acpi_status status;
|
|
|
|
struct acpi_table_stao *stao_ptr;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2012-12-20 23:36:40 +00:00
|
|
|
acpi_pci_root_init();
|
2013-01-30 13:27:37 +00: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-02 22:26:22 +00:00
|
|
|
acpi_processor_init();
|
2019-08-30 14:34:32 +00:00
|
|
|
acpi_platform_init();
|
2013-03-06 22:46:20 +00:00
|
|
|
acpi_lpss_init();
|
2015-02-06 00:27:51 +00:00
|
|
|
acpi_apd_init();
|
2013-06-05 02:27:50 +00:00
|
|
|
acpi_cmos_rtc_init();
|
2013-02-08 22:52:39 +00:00
|
|
|
acpi_container_init();
|
2013-03-03 22:18:03 +00:00
|
|
|
acpi_memory_hotplug_init();
|
2018-04-19 10:08:37 +00:00
|
|
|
acpi_watchdog_init();
|
ACPI / PNP: use device ID list for PNPACPI device enumeration
ACPI can be used to enumerate PNP devices, but the code does not
handle this in the right way currently. Namely, if an ACPI device
object
1. Has a _CRS method,
2. Has an identification of
"three capital characters followed by four hex digits",
3. Is not in the excluded IDs list,
it will be enumerated to PNP bus (that is, a PNP device object will
be create for it). This means that, actually, the PNP bus type is
used as the default bus type for enumerating _HID devices in ACPI.
However, more and more _HID devices need to be enumerated to the
platform bus instead (that is, platform device objects need to be
created for them). As a result, the device ID list in acpi_platform.c
is used to enforce creating platform device objects rather than PNP
device objects for matching devices. That list has been continuously
growing recently, unfortunately, and it is pretty much guaranteed to
grow even more in the future.
To address that problem it is better to enumerate _HID devices
as platform devices by default. To this end, change the way of
enumerating PNP devices by adding a PNP ACPI scan handler that
will use a device ID list to create PNP devices for the ACPI
device objects whose device IDs are present in that list.
The initial device ID list in the PNP ACPI scan handler contains
all of the pnp_device_id strings from all the existing PNP drivers,
so this change should be transparent to the PNP core and all of the
PNP drivers. Still, in the future it should be possible to reduce
its size by converting PNP drivers that need not be PNP for any
technical reasons into platform drivers.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
[rjw: Rewrote the changelog, modified the PNP ACPI scan handler code]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2014-05-30 02:23:01 +00:00
|
|
|
acpi_pnp_init();
|
2014-03-13 16:34:05 +00:00
|
|
|
acpi_int340x_thermal_init();
|
2016-01-20 14:29:27 +00:00
|
|
|
acpi_amba_init();
|
2017-10-05 23:24:03 +00:00
|
|
|
acpi_init_lpit();
|
2010-11-24 23:10:02 +00:00
|
|
|
|
2015-04-24 00:18:01 +00:00
|
|
|
acpi_scan_add_handler(&generic_device_handler);
|
|
|
|
|
2016-04-07 12:03:18 +00:00
|
|
|
/*
|
|
|
|
* If there is STAO table, check whether it needs to ignore the UART
|
|
|
|
* device in SPCR table.
|
|
|
|
*/
|
|
|
|
status = acpi_get_table(ACPI_SIG_STAO, 0,
|
|
|
|
(struct acpi_table_header **)&stao_ptr);
|
|
|
|
if (ACPI_SUCCESS(status)) {
|
|
|
|
if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
|
2021-06-02 08:54:37 +00:00
|
|
|
pr_info("STAO Name List not yet supported.\n");
|
2016-04-07 12:03:18 +00:00
|
|
|
|
|
|
|
if (stao_ptr->ignore_uart)
|
|
|
|
acpi_get_spcr_uart_addr();
|
2020-05-07 09:09:20 +00:00
|
|
|
|
|
|
|
acpi_put_table((struct acpi_table_header *)stao_ptr);
|
2016-04-07 12:03:18 +00:00
|
|
|
}
|
|
|
|
|
2017-08-09 22:34:23 +00:00
|
|
|
acpi_gpe_apply_masked_gpes();
|
|
|
|
acpi_update_all_gpes();
|
|
|
|
|
2019-08-03 04:49:29 +00:00
|
|
|
/*
|
|
|
|
* Although we call __add_memory() that is documented to require the
|
|
|
|
* device_hotplug_lock, it is not necessary here because this is an
|
|
|
|
* early code when userspace or any other code path cannot trigger
|
|
|
|
* hotplug/hotunplug operations.
|
|
|
|
*/
|
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 13:36:47 +00:00
|
|
|
mutex_lock(&acpi_scan_lock);
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* Enumerate devices in the ACPI namespace.
|
|
|
|
*/
|
2022-01-11 16:50:22 +00:00
|
|
|
if (acpi_bus_scan(ACPI_ROOT_OBJECT))
|
2022-01-11 16:53:29 +00:00
|
|
|
goto unlock;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2021-12-03 16:36:20 +00:00
|
|
|
acpi_root = acpi_fetch_acpi_dev(ACPI_ROOT_OBJECT);
|
|
|
|
if (!acpi_root)
|
2022-01-11 16:53:29 +00:00
|
|
|
goto unlock;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2014-04-28 02:38:04 +00:00
|
|
|
/* Fixed feature devices do not exist on HW-reduced platform */
|
2022-01-11 16:52:00 +00:00
|
|
|
if (!acpi_gbl_reduced_hardware)
|
|
|
|
acpi_bus_scan_fixed();
|
2005-04-16 22:20:36 +00:00
|
|
|
|
ACPI: power: Rework turning off unused power resources
Make turning off unused power resources (after the enumeration of
devices and during system-wide resume from S3) more straightforward
by using the observation that the power resource state stored in
struct acpi_power_resource can be used to determine whether or not
the give power resource has any users.
Namely, when the state of the power resource is unknown, its _STA
method has never been evaluated (or the evaluation of it has failed)
and its _ON and _OFF methods have never been executed (or they have
failed to execute), so for all practical purposes it can be assumed
to have no users (or to be unusable). Therefore, instead of checking
the number of power resource users, it is sufficient to check if its
state is known.
Moreover, if the last known state of a given power resource is "off",
it is not necessary to turn it off, because it has been used to
initialize the power state or the wakeup power resources list of at
least one device and either its _STA method has returned 0 ("off"),
or its _OFF method has been successfully executed already.
Accordingly, modify acpi_turn_off_unused_power_resources() to do the
above checks (which are suitable for both uses of it) instead of
using the number of power resource users or evaluating its _STA
method, drop its argument (which is not useful any more) and update
its callers.
Also drop the users field from struct acpi_power_resource as it is
not useful any more.
Tested-by: Dave Olsthoorn <dave@bewaar.me>
Tested-by: Shujun Wang <wsj20369@163.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-05-24 15:26:16 +00:00
|
|
|
acpi_turn_off_unused_power_resources();
|
2021-05-10 12:02:17 +00:00
|
|
|
|
2016-07-08 16:13:09 +00:00
|
|
|
acpi_scan_initialized = true;
|
|
|
|
|
2022-01-11 16:53:29 +00:00
|
|
|
unlock:
|
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 13:36:47 +00:00
|
|
|
mutex_unlock(&acpi_scan_lock);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2015-09-28 14:49:12 +00:00
|
|
|
|
|
|
|
static struct acpi_probe_entry *ape;
|
|
|
|
static int acpi_probe_count;
|
2016-08-16 15:59:53 +00:00
|
|
|
static DEFINE_MUTEX(acpi_probe_mutex);
|
2015-09-28 14:49:12 +00:00
|
|
|
|
2019-03-11 20:55:57 +00:00
|
|
|
static int __init acpi_match_madt(union acpi_subtable_headers *header,
|
2015-09-28 14:49:12 +00:00
|
|
|
const unsigned long end)
|
|
|
|
{
|
2019-03-11 20:55:57 +00:00
|
|
|
if (!ape->subtable_valid || ape->subtable_valid(&header->common, ape))
|
2015-09-28 14:49:12 +00:00
|
|
|
if (!ape->probe_subtbl(header, end))
|
|
|
|
acpi_probe_count++;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int __init __acpi_probe_device_table(struct acpi_probe_entry *ap_head, int nr)
|
|
|
|
{
|
|
|
|
int count = 0;
|
|
|
|
|
|
|
|
if (acpi_disabled)
|
|
|
|
return 0;
|
|
|
|
|
2016-08-16 15:59:53 +00:00
|
|
|
mutex_lock(&acpi_probe_mutex);
|
2015-09-28 14:49:12 +00:00
|
|
|
for (ape = ap_head; nr; ape++, nr--) {
|
2019-04-08 20:42:24 +00:00
|
|
|
if (ACPI_COMPARE_NAMESEG(ACPI_SIG_MADT, ape->id)) {
|
2015-09-28 14:49:12 +00:00
|
|
|
acpi_probe_count = 0;
|
|
|
|
acpi_table_parse_madt(ape->type, acpi_match_madt, 0);
|
|
|
|
count += acpi_probe_count;
|
|
|
|
} else {
|
|
|
|
int res;
|
|
|
|
res = acpi_table_parse(ape->id, ape->probe_table);
|
|
|
|
if (!res)
|
|
|
|
count++;
|
|
|
|
}
|
|
|
|
}
|
2016-08-16 15:59:53 +00:00
|
|
|
mutex_unlock(&acpi_probe_mutex);
|
2015-09-28 14:49:12 +00:00
|
|
|
|
|
|
|
return count;
|
|
|
|
}
|
2016-07-08 16:13:09 +00:00
|
|
|
|
|
|
|
static void acpi_table_events_fn(struct work_struct *work)
|
|
|
|
{
|
2021-06-16 14:05:50 +00:00
|
|
|
acpi_scan_lock_acquire();
|
|
|
|
acpi_bus_scan(ACPI_ROOT_OBJECT);
|
|
|
|
acpi_scan_lock_release();
|
2016-07-08 16:13:09 +00:00
|
|
|
|
2021-06-16 14:05:50 +00:00
|
|
|
kfree(work);
|
2016-07-08 16:13:09 +00:00
|
|
|
}
|
|
|
|
|
2021-06-16 14:05:50 +00:00
|
|
|
void acpi_scan_table_notify(void)
|
2016-07-08 16:13:09 +00:00
|
|
|
{
|
2021-06-16 14:05:50 +00:00
|
|
|
struct work_struct *work;
|
2016-07-08 16:13:09 +00:00
|
|
|
|
|
|
|
if (!acpi_scan_initialized)
|
|
|
|
return;
|
|
|
|
|
2021-06-16 14:05:50 +00:00
|
|
|
work = kmalloc(sizeof(*work), GFP_KERNEL);
|
|
|
|
if (!work)
|
2016-07-08 16:13:09 +00:00
|
|
|
return;
|
|
|
|
|
2021-06-16 14:05:50 +00:00
|
|
|
INIT_WORK(work, acpi_table_events_fn);
|
|
|
|
schedule_work(work);
|
2016-07-08 16:13:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
int acpi_reconfig_notifier_register(struct notifier_block *nb)
|
|
|
|
{
|
|
|
|
return blocking_notifier_chain_register(&acpi_reconfig_chain, nb);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(acpi_reconfig_notifier_register);
|
|
|
|
|
|
|
|
int acpi_reconfig_notifier_unregister(struct notifier_block *nb)
|
|
|
|
{
|
|
|
|
return blocking_notifier_chain_unregister(&acpi_reconfig_chain, nb);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(acpi_reconfig_notifier_unregister);
|