2019-05-19 13:08:55 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-02 16:54:37 +08:00
|
|
|
|
|
|
|
|
|
ACPI: scan: Use async schedule function in acpi_scan_clear_dep_fn()
The device object rescan in acpi_scan_clear_dep_fn() is scheduled on a
system workqueue which is not guaranteed to be finished before entering
userspace. This may cause some key devices to be missing when userspace
init task tries to find them. Two issues observed on RISCV platforms:
- Kernel panic due to userspace init cannot have an opened
console.
The console device scanning is queued by acpi_scan_clear_dep_queue()
and not finished by the time userspace init process running, thus by
the time userspace init runs, no console is present.
- Entering rescue shell due to the lack of root devices (PCIe nvme in
our case).
Same reason as above, the PCIe host bridge scanning is queued on
a system workqueue and finished after init process runs.
The reason is because both devices (console, PCIe host bridge) depend on
riscv-aplic irqchip to serve their interrupts (console's wired interrupt
and PCI's INTx interrupts). In order to keep the dependency, these
devices are scanned and created after initializing riscv-aplic. The
riscv-aplic is initialized in device_initcall() and a device scan work
is queued via acpi_scan_clear_dep_queue(), which is close to the time
userspace init process is run. Since system_dfl_wq is used in
acpi_scan_clear_dep_queue() with no synchronization, the issues will
happen if userspace init runs before these devices are ready.
The solution is to wait for the queued work to complete before entering
userspace init. One possible way would be to use a dedicated workqueue
instead of system_dfl_wq, and explicitly flush it somewhere in the
initcall stage before entering userspace. Another way is to use
async_schedule_dev_nocall() for scanning these devices. It's designed
for asynchronous initialization and will work in the same way as before
because it's using a dedicated unbound workqueue as well, but the kernel
init code calls async_synchronize_full() right before entering userspace
init which will wait for the work to complete.
Compared to a dedicated workqueue, the second approach is simpler
because the async schedule framework takes care of all of the details.
The ACPI code only needs to focus on its job. A dedicated workqueue for
this could also be redundant because some platforms don't need
acpi_scan_clear_dep_queue() for their device scanning.
Signed-off-by: Yicong Yang <yang.yicong@picoheart.com>
[ rjw: Subject adjustment, changelog edits ]
Link: https://patch.msgid.link/20260128132848.93638-1-yang.yicong@picoheart.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-28 21:28:47 +08:00
|
|
|
|
2026-03-09 21:54:17 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
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 17:04:11 +09:00
|
|
|
|
2006-07-12 02:08:00 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-11-21 10:01:48 +00:00
|
|
|
|
2025-08-18 10:28:06 +05:30
|
|
|
|
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 17:20:58 +02:00
|
|
|
|
2021-06-18 17:20:57 +02:00
|
|
|
|
2008-06-13 12:54:24 -04:00
|
|
|
|
|
|
|
|
|
2010-03-24 14:38:37 +01:00
|
|
|
|
2020-09-22 15:31:03 +02:00
|
|
|
|
2017-08-01 14:10:41 +02:00
|
|
|
|
2020-06-08 21:32:38 -07:00
|
|
|
|
2021-12-23 11:16:17 +03:00
|
|
|
|
2022-09-11 17:06:34 +08:00
|
|
|
|
2013-11-22 21:52:12 +01:00
|
|
|
|
2009-03-13 12:08:26 -06:00
|
|
|
|
2023-07-03 13:48:31 +01:00
|
|
|
|
2009-03-13 12:08:26 -06:00
|
|
|
|
2007-07-23 14:43:51 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2022-10-18 23:57:53 +02:00
|
|
|
|
2013-11-22 21:52:12 +01:00
|
|
|
|
2010-10-01 10:54:00 +02:00
|
|
|
|
2010-10-01 10:53:59 +02:00
|
|
|
|
2014-11-23 21:22:54 +08:00
|
|
|
|
|
|
|
|
|
2015-11-25 21:19:55 +01:00
|
|
|
|
2013-01-27 21:17:29 +01:00
|
|
|
|
2013-01-30 14:27:29 +01:00
|
|
|
|
2009-04-07 10:24:29 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-02-04 00:43:17 +01:00
|
|
|
|
ACPI: PNP: Drop PNP0C01 and PNP0C02 from acpi_pnp_device_ids[]
There is a long-standing problem with ACPI device enumeration that
if the given device has a compatible ID which is one of the generic
system resource device IDs (PNP0C01 and PNP0C02), it will be claimed
by the PNP scan handler and it will not be represented as a platform
device, so it cannot be handled by a platform driver.
Drivers have been working around this issue by "manually" creating
platform devices that they can bind to (see the Intel HID driver for
one example) or adding their device IDs to acpi_nonpnp_device_ids[].
None of the above is particularly clean though and the only reason why
the PNP0C01 and PNP0C02 device IDs are present in acpi_pnp_device_ids[]
is to allow the legacy PNP system driver to bind to those devices and
reserve their resources so they are not used going forward.
Obviously, to address this problem PNP0C01 and PNP0C02 need to be
dropped from acpi_pnp_device_ids[], but doing so without making any
other changes would be problematic because the ACPI core would then
create platform devices for the generic system resource device objects
and that would not work on all systems for two reasons. First, the
PNP system driver explicitly avoids reserving I/O resources below the
"standard PC hardware" boundary, 0x100, to avoid conflicts in that range
(one possible case when this may happen is when the CMOS RTC driver is
involved), but the platform device creation code does not do that.
Second, there may be resource conflicts between the "system" devices and
the other devices in the system, possibly including conflicts with PCI
BARs. Registering the PNP system driver via fs_initcall() helps to
manage those conflicts, even though it does not make them go away.
Resource conflicts during the registration of "motherboard resources"
that occur after PCI has claimed BARs are harmless as a rule and do
not need to be addressed in any specific way.
To overcome the issues mentioned above, use the observation that it
is not actually necessary to create any device objects in addition
to struct acpi_device ones in order to reserve the "system" device
resources because that can be done directly in the ACPI device
enumeration code.
Namely, modify acpi_default_enumeration() to add the given ACPI device
object to a special "system devices" list if its _HID is either PNP0C01
or PNP0C02 without creating a platform device for it. Next, add a new
special acpi_scan_claim_resources() function that will be run via
fs_initcall() and will walk that list and reserve resources for each
device in it along the lines of what the PNP system driver does.
Having made the above changes, drop PNP0C01 and PNP0C02 from
acpi_pnp_device_ids[] which will allow platform devices to be created
for ACPI device objects whose _CID lists contain PNP0C01 or PNP0C02,
but the _HID is not in acpi_pnp_device_ids[].
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
[ rjw: Drop a leftover comment and add a new one elsewhere ]
Link: https://patch.msgid.link/9550709.CDJkKcVGEf@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-12-15 14:34:06 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-04-07 20:03:18 +08: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 14:36:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-04 00:43:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-22 00:48:31 +01:00
|
|
|
|
|
|
|
|
|
2024-03-25 14:33:03 +02:00
|
|
|
|
2014-02-22 00:48:31 +01:00
|
|
|
|
|
|
|
|
|
2014-07-15 22:03:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-22 00:48:31 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-30 14:27:29 +01:00
|
|
|
|
|
|
|
|
|
2014-05-30 04:27:31 +02:00
|
|
|
|
2013-01-30 14:27:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-03 23:08:16 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 15:25:48 +01:00
|
|
|
|
2013-12-29 15:25:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-03-20 13:51:26 +08:00
|
|
|
|
2013-12-29 15:25:35 +01:00
|
|
|
|
2015-04-18 01:25:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-29 15:25:35 +01:00
|
|
|
|
|
|
|
|
|
2026-04-06 16:23:02 -07:00
|
|
|
|
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 15:25:48 +01:00
|
|
|
|
2018-03-20 13:51:26 +08:00
|
|
|
|
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 15:25:48 +01:00
|
|
|
|
2013-12-29 15:25:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-07 01:41:14 +01:00
|
|
|
|
|
|
|
|
|
2013-05-03 00:26:16 +02:00
|
|
|
|
2021-12-03 17:36:20 +01:00
|
|
|
|
2013-05-03 00:26:16 +02:00
|
|
|
|
2013-05-23 10:43:13 +02:00
|
|
|
|
2013-05-03 00:26:16 +02:00
|
|
|
|
|
|
|
|
|
2021-12-03 17:36:20 +01:00
|
|
|
|
2013-05-03 00:26:16 +02:00
|
|
|
|
|
|
|
|
|
2013-11-07 01:41:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-03 00:26:16 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-23 10:43:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-03 00:26:16 +02:00
|
|
|
|
2013-05-23 10:43:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-03 00:26:16 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-07 01:41:14 +01:00
|
|
|
|
|
|
|
|
|
2013-05-03 00:26:16 +02:00
|
|
|
|
2021-12-03 17:36:20 +01:00
|
|
|
|
2013-05-03 00:26:16 +02:00
|
|
|
|
|
|
|
|
|
2021-12-03 17:36:20 +01:00
|
|
|
|
2013-05-03 00:26:16 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-29 15:25:35 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-01-11 22:40:41 +00:00
|
|
|
|
2013-12-29 15:25:35 +01:00
|
|
|
|
2013-03-03 23:05:29 +01:00
|
|
|
|
2013-02-09 15:29:11 +01:00
|
|
|
|
2013-05-23 10:43:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-07 01:41:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-23 10:43:13 +02:00
|
|
|
|
|
|
|
|
|
2013-05-03 00:26:16 +02:00
|
|
|
|
2013-11-07 01:41:14 +01:00
|
|
|
|
|
|
|
|
|
2017-04-03 09:40:23 +02:00
|
|
|
|
2013-11-07 01:41:14 +01:00
|
|
|
|
|
|
|
|
|
2013-05-03 00:26:16 +02:00
|
|
|
|
2017-04-03 09:40:23 +02:00
|
|
|
|
2013-05-23 10:43:13 +02:00
|
|
|
|
2013-11-07 01:41:14 +01:00
|
|
|
|
2013-05-23 10:43:13 +02:00
|
|
|
|
2013-11-07 01:41:14 +01:00
|
|
|
|
|
|
|
|
|
2013-05-23 10:43:13 +02:00
|
|
|
|
|
|
|
|
|
2013-05-03 00:26:16 +02:00
|
|
|
|
2013-12-29 15:25:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-05-29 14:34:36 +01:00
|
|
|
|
2024-05-29 14:34:37 +01:00
|
|
|
|
2024-05-29 14:34:36 +01:00
|
|
|
|
|
|
|
|
|
2024-02-26 17:36:22 +01:00
|
|
|
|
|
|
|
|
|
2024-05-29 14:34:36 +01:00
|
|
|
|
2024-02-26 17:36:22 +01:00
|
|
|
|
2024-05-29 14:34:36 +01:00
|
|
|
|
2024-02-26 17:45:11 +01:00
|
|
|
|
2024-05-29 14:34:36 +01:00
|
|
|
|
2024-02-26 17:45:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-26 17:36:22 +01:00
|
|
|
|
2026-07-01 21:16:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-26 17:36:22 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-05-29 14:34:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-26 17:36:22 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-26 17:45:11 +01:00
|
|
|
|
|
|
|
|
|
2024-05-29 14:34:36 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-26 17:45:11 +01:00
|
|
|
|
|
|
|
|
|
2013-12-29 15:25:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-05-29 14:34:37 +01:00
|
|
|
|
2013-12-29 15:25:35 +01:00
|
|
|
|
2017-04-03 09:40:23 +02:00
|
|
|
|
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 15:25:48 +01:00
|
|
|
|
2013-12-29 15:25:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-03 00:26:16 +02:00
|
|
|
|
2021-01-20 19:59:51 +01:00
|
|
|
|
2008-04-29 02:35:48 -04:00
|
|
|
|
2024-05-29 14:34:37 +01:00
|
|
|
|
2013-05-03 00:26:16 +02:00
|
|
|
|
2013-06-29 00:24:40 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-29 00:24:40 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-02-09 15:29:11 +01:00
|
|
|
|
2013-03-13 19:29:26 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-05-29 14:34:37 +01:00
|
|
|
|
|
|
|
|
|
2013-03-13 19:29:26 +00:00
|
|
|
|
|
|
|
|
|
2013-03-03 23:05:29 +01:00
|
|
|
|
|
|
|
|
|
2013-02-09 15:29:11 +01:00
|
|
|
|
2024-02-26 17:46:41 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-22 21:55:07 +01:00
|
|
|
|
2013-03-03 23:05:29 +01:00
|
|
|
|
2024-02-26 17:46:41 +01:00
|
|
|
|
2013-03-03 23:05:29 +01:00
|
|
|
|
2024-02-26 17:45:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-22 21:55:43 +01:00
|
|
|
|
2024-02-26 17:45:11 +01:00
|
|
|
|
2024-02-26 17:46:41 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-22 21:55:43 +01:00
|
|
|
|
|
|
|
|
|
2024-02-26 17:46:41 +01:00
|
|
|
|
2013-11-22 21:55:43 +01:00
|
|
|
|
2024-02-26 17:45:11 +01:00
|
|
|
|
|
|
|
|
|
2024-02-26 17:46:41 +01:00
|
|
|
|
2013-03-03 23:05:29 +01:00
|
|
|
|
|
|
|
|
|
2014-02-06 17:31:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-26 17:46:41 +01:00
|
|
|
|
2014-02-06 17:31:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-04 00:44:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-21 01:07:17 +01:00
|
|
|
|
|
|
|
|
|
2014-02-06 17:31:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-03 00:40:38 +01:00
|
|
|
|
2013-03-03 23:05:29 +01:00
|
|
|
|
|
|
|
|
|
2014-02-06 17:31:37 +01:00
|
|
|
|
2013-03-03 23:05:29 +01:00
|
|
|
|
2013-05-03 00:26:16 +02:00
|
|
|
|
2013-08-30 14:19:29 +02:00
|
|
|
|
2013-03-03 23:05:29 +01:00
|
|
|
|
2013-11-22 21:55:07 +01:00
|
|
|
|
|
|
|
|
|
2014-02-06 17:31:37 +01:00
|
|
|
|
2013-11-22 21:55:07 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-06 17:31:37 +01:00
|
|
|
|
2013-11-22 21:55:07 +01: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 01:51:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-06 17:31:37 +01:00
|
|
|
|
|
|
|
|
|
2024-03-25 14:33:03 +02:00
|
|
|
|
2014-02-06 17:31:37 +01:00
|
|
|
|
|
|
|
|
|
2014-02-21 01:10:27 +01:00
|
|
|
|
2014-02-06 17:31:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-21 01:10:27 +01:00
|
|
|
|
|
|
|
|
|
2014-02-06 17:31:37 +01:00
|
|
|
|
|
|
|
|
|
2013-03-03 23:05:29 +01:00
|
|
|
|
2017-07-03 21:26:10 +08:00
|
|
|
|
|
|
|
|
|
2013-11-22 21:55:07 +01:00
|
|
|
|
2017-07-03 21:26:10 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-03 23:05:29 +01:00
|
|
|
|
2014-02-06 17:31:37 +01:00
|
|
|
|
2014-02-21 01:07:17 +01:00
|
|
|
|
2014-02-06 17:31:37 +01:00
|
|
|
|
|
|
|
|
|
2022-08-10 18:14:22 +02:00
|
|
|
|
2013-03-03 23:05:29 +01:00
|
|
|
|
2013-08-30 14:19:29 +02:00
|
|
|
|
2013-03-03 23:05:29 +01:00
|
|
|
|
|
|
|
|
|
2013-01-17 14:11:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-17 14:11:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 23:38:28 +01:00
|
|
|
|
2013-01-17 14:11:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-21 13:35:19 -06:00
|
|
|
|
|
|
|
|
|
2006-12-07 20:56:31 +08: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 13:33:55 +02:00
|
|
|
|
2013-03-04 21:30:42 +00:00
|
|
|
|
2013-01-17 14:11:06 +01:00
|
|
|
|
2006-12-07 20:56:31 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-08 16:59:42 +08:00
|
|
|
|
2013-07-30 14:38:34 +02:00
|
|
|
|
2015-11-25 21:19:55 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-10 21:05:33 +01:00
|
|
|
|
|
|
|
|
|
2021-03-22 18:31:00 +02:00
|
|
|
|
2015-11-25 21:19:55 +01:00
|
|
|
|
2021-01-07 23:23:48 -08:00
|
|
|
|
2015-11-25 21:19:55 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-22 21:52:12 +01:00
|
|
|
|
2026-08-08 16:59:42 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-13 20:38:00 +02:00
|
|
|
|
2013-11-22 21:52:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-08 19:13:09 +03:00
|
|
|
|
|
|
|
|
|
2013-11-22 21:52:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-08 19:13:09 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-22 21:52:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-13 01:23:58 +03:00
|
|
|
|
2013-11-22 21:52:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-12 18:55:35 -07:00
|
|
|
|
2013-11-22 21:52:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-30 14:38:34 +02:00
|
|
|
|
|
|
|
|
|
2021-01-18 20:25:37 +01:00
|
|
|
|
|
|
|
|
|
2013-07-30 14:38:34 +02:00
|
|
|
|
2021-01-18 20:25:37 +01:00
|
|
|
|
2013-07-30 14:38:34 +02:00
|
|
|
|
|
|
|
|
|
2014-02-04 00:43:05 +01:00
|
|
|
|
2021-01-18 20:25:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-30 14:38:34 +02:00
|
|
|
|
2021-01-18 20:25:37 +01:00
|
|
|
|
2013-07-30 14:38:34 +02:00
|
|
|
|
2014-02-04 00:43:05 +01:00
|
|
|
|
2021-12-03 17:36:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-04 00:43:05 +01:00
|
|
|
|
|
|
|
|
|
2021-04-13 01:23:58 +03:00
|
|
|
|
2014-02-04 00:43:05 +01:00
|
|
|
|
|
|
|
|
|
2022-08-10 18:14:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-04 00:43:05 +01:00
|
|
|
|
2021-01-18 20:25:37 +01:00
|
|
|
|
2014-02-04 00:43:05 +01:00
|
|
|
|
2022-08-10 18:14:22 +02:00
|
|
|
|
2014-02-04 00:43:05 +01:00
|
|
|
|
2021-01-14 19:46:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-22 18:31:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-10 21:05:33 +01:00
|
|
|
|
2021-03-22 18:31:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-08-10 18:17:23 +02:00
|
|
|
|
2021-06-16 16:24:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-12-23 11:16:17 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-12-16 21:17:15 +00:00
|
|
|
|
2021-12-23 11:16:17 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-08-10 18:17:23 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-01-14 19:46:47 +01: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 17:23:43 +08:00
|
|
|
|
2009-09-21 19:29:05 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-17 14:44:09 +08:00
|
|
|
|
2013-11-22 21:52:12 +01:00
|
|
|
|
2012-08-17 14:44:09 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-04-07 10:24:29 +08:00
|
|
|
|
2021-01-14 19:46:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-22 18:31:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-14 19:46:47 +01:00
|
|
|
|
2026-02-21 20:03:00 -08:00
|
|
|
|
2021-01-14 19:46:47 +01: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 17:23:43 +08:00
|
|
|
|
2021-01-07 23:23:48 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-14 19:46:47 +01:00
|
|
|
|
2021-01-07 23:23:48 -08:00
|
|
|
|
2021-01-14 19:46:47 +01:00
|
|
|
|
2021-01-07 23:23:48 -08:00
|
|
|
|
|
|
|
|
|
2021-03-22 18:31:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-08 09:23:09 +02:00
|
|
|
|
2021-03-22 18:31:00 +02: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 17:23:43 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2021-01-14 19:47:37 +01:00
|
|
|
|
2021-12-23 11:16:17 +03:00
|
|
|
|
|
|
|
|
|
2009-04-07 10:24:29 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-01-24 12:49:49 +01:00
|
|
|
|
2009-05-14 08:31:37 -06:00
|
|
|
|
2009-05-14 08:31:32 -06:00
|
|
|
|
2013-01-17 14:11:05 +01: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 17:23:43 +08:00
|
|
|
|
|
|
|
|
|
2024-07-09 22:37:28 +02:00
|
|
|
|
2006-12-07 20:56:38 +08: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 17:23:43 +08:00
|
|
|
|
2013-01-17 14:11:05 +01:00
|
|
|
|
2021-01-14 19:47:37 +01:00
|
|
|
|
2009-04-07 10:24:29 +08:00
|
|
|
|
2021-01-14 19:47:37 +01:00
|
|
|
|
2026-08-08 16:59:42 +08:00
|
|
|
|
2021-01-07 23:23:48 -08:00
|
|
|
|
2021-01-14 19:47:37 +01:00
|
|
|
|
2009-04-07 10:24:29 +08:00
|
|
|
|
2013-01-17 14:11:05 +01:00
|
|
|
|
2013-11-22 21:52:12 +01:00
|
|
|
|
2021-01-14 19:47:37 +01: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 17:23:43 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-05 16:29:41 +01:00
|
|
|
|
|
|
|
|
|
2020-11-21 21:30:34 +01:00
|
|
|
|
2020-12-05 16:29:41 +01:00
|
|
|
|
2021-04-10 17:02:53 +03:00
|
|
|
|
2020-11-21 21:30:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-10 17:02:53 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-05 16:29:41 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-10 17:02:53 +03:00
|
|
|
|
|
|
|
|
|
2020-12-05 16:29:41 +01:00
|
|
|
|
2021-04-10 17:02:53 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-21 21:30:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-05 16:29:41 +01:00
|
|
|
|
|
|
|
|
|
2020-12-15 12:26:02 +01:00
|
|
|
|
2022-10-25 14:12:23 +02:00
|
|
|
|
2020-11-21 21:30:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 11:28:44 +01:00
|
|
|
|
|
|
|
|
|
2026-07-09 10:40:16 +02:00
|
|
|
|
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 11:28:44 +01:00
|
|
|
|
2023-07-29 19:52:55 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-07 08:59:08 +08:00
|
|
|
|
2026-06-01 12:40:40 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-07-04 22:48:52 +05:30
|
|
|
|
2024-08-12 06:29:17 +05:30
|
|
|
|
|
|
|
|
|
2025-08-18 09:39:12 +05:30
|
|
|
|
|
|
|
|
|
2024-08-12 06:29:20 +05:30
|
|
|
|
2026-05-26 10:51:18 +08:00
|
|
|
|
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 11:28:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-08-10 18:15:24 +02:00
|
|
|
|
2009-09-21 19:29:35 +00:00
|
|
|
|
2022-08-10 18:15:24 +02:00
|
|
|
|
2009-09-21 19:29:35 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-31 20:57:40 +01:00
|
|
|
|
2009-09-21 19:29:35 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-08-10 18:15:24 +02:00
|
|
|
|
2021-12-03 17:36:20 +01:00
|
|
|
|
2022-08-10 18:15:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-21 19:29:35 +00:00
|
|
|
|
|
|
|
|
|
2006-07-09 17:22:28 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-14 13:40:34 +01:00
|
|
|
|
|
|
|
|
|
2006-07-09 17:22:28 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-25 13:34:02 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2019-03-25 13:34:02 -05:00
|
|
|
|
|
|
|
|
|
2010-12-17 22:34:01 +01:00
|
|
|
|
|
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2010-12-17 22:34:01 +01:00
|
|
|
|
2013-01-17 14:11:07 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-01-17 14:11:06 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-12-17 22:34:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-20 19:59:51 +01:00
|
|
|
|
|
|
|
|
|
2013-01-17 14:11:07 +01:00
|
|
|
|
2010-12-17 22:34:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-17 14:11:07 +01:00
|
|
|
|
2010-12-17 22:34:01 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-01-17 14:11:07 +01:00
|
|
|
|
2010-12-17 22:34:01 +01:00
|
|
|
|
2013-01-17 14:11:07 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
|
|
|
|
|
2013-01-17 14:11:07 +01:00
|
|
|
|
2010-12-17 22:34:01 +01:00
|
|
|
|
2013-01-17 14:11:07 +01:00
|
|
|
|
2010-12-17 22:34:01 +01:00
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2010-12-17 22:34:01 +01:00
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
|
|
|
|
|
2010-12-17 22:34:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-01-17 14:11:07 +01:00
|
|
|
|
2010-12-17 22:34:01 +01:00
|
|
|
|
2013-01-17 14:11:07 +01:00
|
|
|
|
2010-12-17 22:34:01 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-01-17 14:11:07 +01:00
|
|
|
|
|
|
|
|
|
2010-12-17 22:34:01 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-01-17 14:11:07 +01: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 23:15:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-17 14:11:07 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-17 22:34:01 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
ACPI / ACPICA: Do not execute _PRW methods during initialization
Currently, during initialization ACPICA walks the entire ACPI
namespace in search of any device objects with assciated _PRW
methods. All of the _PRW methods found are executed in the process
to extract the GPE information returned by them, so that the GPEs in
question can be marked as "able to wakeup" (more precisely, the
ACPI_GPE_CAN_WAKE flag is set for them). The only purpose of this
exercise is to avoid enabling the CAN_WAKE GPEs automatically, even
if there are _Lxx/_Exx methods associated with them. However, it is
both costly and unnecessary, because the host OS has to execute the
_PRW methods anyway to check which devices can wake up the system
from sleep states. Moreover, it then uses full information
returned by _PRW, including the GPE information, so it can take care
of disabling the GPEs if necessary.
Remove the code that walks the namespace and executes _PRW from
ACPICA and modify comments to reflect that change. Make
acpi_bus_set_run_wake_flags() disable GPEs for wakeup devices
so that they don't cause spurious wakeup events to be signaled.
This not only reduces the complexity of the ACPICA initialization
code, but in some cases it should reduce the kernel boot time as
well.
Unfortunately, for this purpose we need a new ACPICA function,
acpi_gpe_can_wake(), to be called by the host OS in order to disable
the GPEs that can wake up the system and were previously enabled by
acpi_ev_initialize_gpe_block() or acpi_ev_update_gpes() (such a GPE
should be disabled only once, because the initialization code enables
it only once, but it may be pointed to by _PRW for multiple devices
and that's why the additional function is necessary).
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-07-08 00:43:36 +02:00
|
|
|
|
2010-12-17 22:34:01 +01:00
|
|
|
|
|
|
|
|
|
2013-01-17 14:11:07 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2017-06-24 01:53:14 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-06-13 14:26:58 +02:00
|
|
|
|
2026-01-10 12:58:38 +01:00
|
|
|
|
|
|
|
|
|
2007-07-23 14:43:51 +02:00
|
|
|
|
|
|
|
|
|
2014-07-14 22:41:41 +02:00
|
|
|
|
2023-07-03 15:14:10 +03:00
|
|
|
|
2010-02-17 23:41:49 +01:00
|
|
|
|
|
|
|
|
|
2014-07-14 22:41:41 +02:00
|
|
|
|
2010-02-17 23:41:49 +01:00
|
|
|
|
2023-07-03 15:14:10 +03:00
|
|
|
|
2026-01-10 12:58:38 +01:00
|
|
|
|
|
|
|
|
|
2010-02-17 23:41:49 +01:00
|
|
|
|
2017-06-24 01:53:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-17 23:41:49 +01:00
|
|
|
|
|
|
|
|
|
2011-01-06 23:41:27 +01:00
|
|
|
|
2010-02-17 23:41:49 +01:00
|
|
|
|
2013-01-17 14:11:07 +01:00
|
|
|
|
2007-07-23 14:43:51 +02:00
|
|
|
|
2011-01-06 23:41:27 +01:00
|
|
|
|
2013-06-29 00:24:38 +08:00
|
|
|
|
2011-01-06 23:41:27 +01:00
|
|
|
|
|
|
|
|
|
2019-03-25 13:34:02 -05:00
|
|
|
|
2013-01-17 14:11:07 +01:00
|
|
|
|
2021-01-20 19:59:51 +01:00
|
|
|
|
2011-01-06 23:41:27 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2017-06-24 01:53:14 +02:00
|
|
|
|
2009-09-08 23:15:31 +02:00
|
|
|
|
2017-06-24 01:53:14 +02:00
|
|
|
|
|
|
|
|
|
2008-03-19 13:26:54 +08:00
|
|
|
|
2019-03-25 13:34:00 -05:00
|
|
|
|
2008-03-19 13:26:54 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-17 14:11:07 +01:00
|
|
|
|
|
|
|
|
|
2020-09-27 09:14:28 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-01-17 14:11:06 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-01-17 14:11:06 +01:00
|
|
|
|
2013-01-17 14:11:07 +01:00
|
|
|
|
|
|
|
|
|
2013-01-17 14:11:06 +01:00
|
|
|
|
2006-12-07 20:56:16 +08:00
|
|
|
|
2013-01-17 14:11:06 +01:00
|
|
|
|
|
|
|
|
|
2013-01-17 14:11:07 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-17 14:11:06 +01:00
|
|
|
|
2013-01-17 14:11:07 +01: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 19:22:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-17 14:11:07 +01:00
|
|
|
|
2013-01-17 14:11:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-17 14:11:07 +01:00
|
|
|
|
2013-06-29 00:24:38 +08:00
|
|
|
|
2013-01-17 14:11:06 +01:00
|
|
|
|
|
|
|
|
|
2015-05-16 01:55:35 +02:00
|
|
|
|
|
|
|
|
|
2013-01-17 14:11:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-17 14:11:05 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-10-18 15:17:24 +03:00
|
|
|
|
2013-01-17 14:11:07 +01:00
|
|
|
|
2006-12-07 20:56:16 +08:00
|
|
|
|
2013-01-17 14:11:05 +01:00
|
|
|
|
2013-06-29 00:24:38 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-17 14:11:05 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-12-07 20:56:16 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-06-29 00:24:38 +08:00
|
|
|
|
2006-12-07 20:56:16 +08:00
|
|
|
|
2014-05-17 00:18:13 +02:00
|
|
|
|
2013-06-29 00:24:38 +08:00
|
|
|
|
2006-12-07 20:56:16 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-05-17 00:18:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-18 15:17:24 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-12-07 20:56:16 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-01-17 14:11:06 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-01-17 14:11:06 +01:00
|
|
|
|
2005-04-16 15:20:36 -07: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 19:22:26 +02:00
|
|
|
|
2006-12-07 20:56:16 +08:00
|
|
|
|
|
|
|
|
|
2015-05-16 01:55:35 +02:00
|
|
|
|
2012-11-21 23:33:40 +01: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 19:22:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-27 15:59:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-01-17 14:11:05 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-06-29 00:24:38 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-29 00:24:38 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-29 00:24:38 +08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-21 19:29:25 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-08-24 18:59:48 +02:00
|
|
|
|
2024-09-15 23:38:21 +05:00
|
|
|
|
2009-09-21 19:29:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2024-09-15 23:38:21 +05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2024-09-15 23:38:21 +05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-09-26 16:54:09 +08:00
|
|
|
|
2024-09-15 23:38:21 +05:00
|
|
|
|
2017-09-26 16:54:09 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-09-21 19:29:05 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-09-15 23:38:21 +05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-29 00:24:41 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-01-11 02:09:09 -05:00
|
|
|
|
2013-03-04 21:30:41 +00:00
|
|
|
|
2007-01-11 02:09:09 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-29 00:24:41 +08:00
|
|
|
|
2013-03-04 21:30:41 +00:00
|
|
|
|
2007-01-11 02:09:09 -05:00
|
|
|
|
|
|
|
|
|
2013-06-29 00:24:38 +08:00
|
|
|
|
2013-06-29 00:24:41 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-01-11 02:09:09 -05:00
|
|
|
|
2013-06-29 00:24:41 +08:00
|
|
|
|
2007-01-11 02:09:09 -05:00
|
|
|
|
|
|
|
|
|
2014-02-16 00:09:34 +01: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 01:51:01 +01:00
|
|
|
|
2014-02-16 00:09:34 +01: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 01:51:01 +01:00
|
|
|
|
2014-02-16 00:09:34 +01: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 01:51:01 +01:00
|
|
|
|
2014-02-16 00:09:34 +01: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 01:51:01 +01:00
|
|
|
|
|
|
|
|
|
2014-02-16 00:09:34 +01: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 01:51:01 +01:00
|
|
|
|
2014-02-16 00:09:34 +01: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 01:51:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-12-07 13:20:34 +01:00
|
|
|
|
2013-03-04 21:30:41 +00:00
|
|
|
|
2007-12-07 13:20:34 +01:00
|
|
|
|
2013-06-29 00:24:41 +08:00
|
|
|
|
2007-12-07 13:20:34 +01:00
|
|
|
|
2013-06-29 00:24:41 +08:00
|
|
|
|
2007-12-07 13:20:34 +01:00
|
|
|
|
|
|
|
|
|
2015-06-16 16:27:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-20 19:59:51 +01:00
|
|
|
|
2015-06-16 16:27:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-10-01 10:54:00 +02:00
|
|
|
|
2009-06-29 13:39:29 +08:00
|
|
|
|
2009-09-21 13:35:19 -06:00
|
|
|
|
2009-06-29 13:39:29 +08:00
|
|
|
|
2024-03-25 14:33:00 +02:00
|
|
|
|
|
|
|
|
|
2010-10-01 10:53:59 +02:00
|
|
|
|
|
|
|
|
|
2009-09-21 13:35:19 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-29 13:39:29 +08:00
|
|
|
|
2013-03-04 21:30:41 +00:00
|
|
|
|
2009-09-21 13:35:19 -06:00
|
|
|
|
|
|
|
|
|
2009-06-29 13:39:29 +08:00
|
|
|
|
2026-02-21 16:37:42 -08:00
|
|
|
|
2009-09-21 13:35:19 -06:00
|
|
|
|
|
|
|
|
|
2009-06-29 13:39:29 +08:00
|
|
|
|
2015-09-09 23:59:43 +02:00
|
|
|
|
2009-09-21 13:35:19 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-29 13:39:29 +08:00
|
|
|
|
|
|
|
|
|
2013-03-04 21:30:41 +00:00
|
|
|
|
|
|
|
|
|
2009-06-29 13:39:29 +08:00
|
|
|
|
|
|
|
|
|
2010-03-24 14:38:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-29 00:24:41 +08:00
|
|
|
|
2010-03-24 14:38:37 +01:00
|
|
|
|
2013-06-29 00:24:41 +08:00
|
|
|
|
|
|
|
|
|
2010-03-24 14:38:37 +01:00
|
|
|
|
|
|
|
|
|
2013-06-29 00:24:41 +08:00
|
|
|
|
2010-03-24 14:38:37 +01:00
|
|
|
|
|
|
|
|
|
2013-06-29 00:24:41 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-24 14:38:37 +01:00
|
|
|
|
|
|
|
|
|
2013-06-29 00:24:38 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-29 00:24:41 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-24 14:38:37 +01:00
|
|
|
|
|
|
|
|
|
2014-02-19 14:02:19 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-04 21:30:42 +00:00
|
|
|
|
2021-04-07 16:33:38 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-04-07 16:33:38 +02:00
|
|
|
|
2012-10-31 02:25:24 +00:00
|
|
|
|
2009-09-21 13:35:19 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-03-04 21:30:42 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-03-04 21:30:42 +00:00
|
|
|
|
|
|
|
|
|
2009-09-21 19:29:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-07 16:33:38 +02:00
|
|
|
|
2020-11-21 21:30:35 +01:00
|
|
|
|
2021-06-02 16:54:37 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-30 04:26:18 +02:00
|
|
|
|
2013-03-04 21:30:42 +00:00
|
|
|
|
2014-05-30 04:26:18 +02:00
|
|
|
|
2022-03-16 11:23:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-21 13:35:40 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-03-04 21:30:42 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-10-30 14:41:07 +01:00
|
|
|
|
2013-03-04 21:30:42 +00:00
|
|
|
|
2012-10-30 14:41:07 +01:00
|
|
|
|
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-07 01:55:20 +02:00
|
|
|
|
|
|
|
|
|
2006-12-07 20:57:10 +08:00
|
|
|
|
2021-04-07 16:33:38 +02:00
|
|
|
|
|
|
|
|
|
2009-09-21 13:35:40 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ACPI: Fix selecting wrong ACPI fwnode for the iGPU on some Dell laptops
The Dell Latitude E6430 both with and without the optional NVidia dGPU
has a bug in its ACPI tables which is causing Linux to assign the wrong
ACPI fwnode / companion to the pci_device for the i915 iGPU.
Specifically under the PCI root bridge there are these 2 ACPI Device()s :
Scope (_SB.PCI0)
{
Device (GFX0)
{
Name (_ADR, 0x00020000) // _ADR: Address
}
...
Device (VID)
{
Name (_ADR, 0x00020000) // _ADR: Address
...
Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching
{
VDP8 = Arg0
VDP1 (One, VDP8)
}
Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices
{
...
}
...
}
}
The non-functional GFX0 ACPI device is a problem, because this gets
returned as ACPI companion-device by acpi_find_child_device() for the iGPU.
This is a long standing problem and the i915 driver does use the ACPI
companion for some things, but works fine without it.
However since commit 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()")
acpi_get_pci_dev() relies on the physical-node pointer in the acpi_device
and that is set on the wrong acpi_device because of the wrong
acpi_find_child_device() return. This breaks the ACPI video code,
leading to non working backlight control in some cases.
Add a type.backlight flag, mark ACPI video bus devices with this and make
find_child_checks() return a higher score for children with this flag set,
so that it picks the right companion-device.
Fixes: 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()")
Co-developed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Cc: 6.1+ <stable@vger.kernel.org> # 6.1+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-01-10 16:30:28 +01:00
|
|
|
|
2013-03-04 21:30:42 +00:00
|
|
|
|
ACPI: Fix selecting wrong ACPI fwnode for the iGPU on some Dell laptops
The Dell Latitude E6430 both with and without the optional NVidia dGPU
has a bug in its ACPI tables which is causing Linux to assign the wrong
ACPI fwnode / companion to the pci_device for the i915 iGPU.
Specifically under the PCI root bridge there are these 2 ACPI Device()s :
Scope (_SB.PCI0)
{
Device (GFX0)
{
Name (_ADR, 0x00020000) // _ADR: Address
}
...
Device (VID)
{
Name (_ADR, 0x00020000) // _ADR: Address
...
Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching
{
VDP8 = Arg0
VDP1 (One, VDP8)
}
Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices
{
...
}
...
}
}
The non-functional GFX0 ACPI device is a problem, because this gets
returned as ACPI companion-device by acpi_find_child_device() for the iGPU.
This is a long standing problem and the i915 driver does use the ACPI
companion for some things, but works fine without it.
However since commit 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()")
acpi_get_pci_dev() relies on the physical-node pointer in the acpi_device
and that is set on the wrong acpi_device because of the wrong
acpi_find_child_device() return. This breaks the ACPI video code,
leading to non working backlight control in some cases.
Add a type.backlight flag, mark ACPI video bus devices with this and make
find_child_checks() return a higher score for children with this flag set,
so that it picks the right companion-device.
Fixes: 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()")
Co-developed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Cc: 6.1+ <stable@vger.kernel.org> # 6.1+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-01-10 16:30:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-04 21:30:42 +00:00
|
|
|
|
2013-06-29 00:24:41 +08:00
|
|
|
|
2013-03-04 21:30:42 +00:00
|
|
|
|
2013-06-29 00:24:41 +08:00
|
|
|
|
2013-03-04 21:30:42 +00:00
|
|
|
|
2014-02-19 14:02:19 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-24 10:44:33 -06:00
|
|
|
|
2007-01-11 02:09:09 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-03-04 21:30:42 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-03-04 21:30:42 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-03-04 21:30:42 +00:00
|
|
|
|
2025-12-10 15:42:21 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-03-04 21:30:42 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-03-04 21:30:42 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-09-26 16:54:09 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-04 21:30:42 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-09 23:59:43 +02:00
|
|
|
|
2013-03-04 21:30:42 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-28 15:50:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-04 19:50:46 +03:00
|
|
|
|
2015-10-28 15:50:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-07 11:29:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-11 17:06:34 +08:00
|
|
|
|
2017-08-07 11:29:48 +01:00
|
|
|
|
2022-09-11 17:06:34 +08:00
|
|
|
|
|
|
|
|
|
2017-08-07 11:29:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-11 17:06:34 +08:00
|
|
|
|
2017-08-07 11:29:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-11 17:06:34 +08:00
|
|
|
|
2017-08-07 11:29:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-21 16:37:42 -08:00
|
|
|
|
2022-09-11 17:06:34 +08:00
|
|
|
|
|
|
|
|
|
2017-08-07 11:29:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-18 14:14:04 +01:00
|
|
|
|
|
|
|
|
|
2022-09-11 17:06:34 +08:00
|
|
|
|
|
|
|
|
|
2022-10-18 14:14:04 +01:00
|
|
|
|
|
|
|
|
|
2022-09-11 17:06:34 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-07 11:29:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-18 17:20:57 +02:00
|
|
|
|
|
|
|
|
|
2024-07-02 12:40:48 +01:00
|
|
|
|
2021-06-18 17:20:57 +02:00
|
|
|
|
2024-03-25 14:33:02 +02:00
|
|
|
|
2021-06-18 17:20:57 +02:00
|
|
|
|
2024-07-02 12:40:48 +01:00
|
|
|
|
2024-03-25 14:33:02 +02:00
|
|
|
|
|
|
|
|
|
2021-06-18 17:20:57 +02:00
|
|
|
|
2024-03-25 14:33:02 +02:00
|
|
|
|
2021-06-18 17:20:57 +02:00
|
|
|
|
|
|
|
|
|
2023-12-07 14:03:13 -04:00
|
|
|
|
2021-06-18 17:20:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-11-15 18:25:44 +00:00
|
|
|
|
|
|
|
|
|
2024-07-02 12:40:49 +01:00
|
|
|
|
|
|
|
|
|
2023-11-15 18:25:44 +00:00
|
|
|
|
2023-12-07 14:03:13 -04:00
|
|
|
|
2023-11-15 18:25:44 +00:00
|
|
|
|
2021-06-18 17:20:57 +02:00
|
|
|
|
|
|
|
|
|
2025-08-18 10:28:06 +05:30
|
|
|
|
|
|
|
|
|
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 17:20:58 +02:00
|
|
|
|
|
|
|
|
|
2025-08-18 10:28:06 +05:30
|
|
|
|
2023-11-15 18:25:44 +00:00
|
|
|
|
2021-06-18 17:20:57 +02:00
|
|
|
|
2024-07-02 12:40:49 +01:00
|
|
|
|
2021-06-18 17:20:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-02 12:40:48 +01:00
|
|
|
|
2021-06-18 17:20:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-07 14:03:13 -04:00
|
|
|
|
2021-06-18 17:20:57 +02:00
|
|
|
|
2023-12-07 14:03:13 -04:00
|
|
|
|
2021-06-18 17:20:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-21 10:01:39 +00:00
|
|
|
|
2020-11-02 19:19:31 +08:00
|
|
|
|
2016-11-21 10:01:39 +00:00
|
|
|
|
|
|
|
|
|
2020-06-19 09:20:06 +01:00
|
|
|
|
2016-11-21 10:01:39 +00:00
|
|
|
|
2020-06-19 09:20:06 +01:00
|
|
|
|
|
|
|
|
|
2016-11-21 10:01:39 +00:00
|
|
|
|
2023-12-07 14:03:13 -04:00
|
|
|
|
2016-11-21 10:01:48 +00:00
|
|
|
|
2018-12-06 13:20:49 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-11 17:06:34 +08:00
|
|
|
|
2016-11-21 10:01:39 +00:00
|
|
|
|
2024-03-25 14:33:01 +02:00
|
|
|
|
2023-12-07 14:03:13 -04:00
|
|
|
|
|
|
|
|
|
2017-05-27 19:17:42 +05:30
|
|
|
|
2024-07-02 12:40:49 +01:00
|
|
|
|
|
|
|
|
|
2016-11-21 10:01:48 +00:00
|
|
|
|
2024-04-19 17:54:46 +01:00
|
|
|
|
2017-04-10 16:51:03 +05:30
|
|
|
|
|
|
|
|
|
2016-11-21 10:01:39 +00:00
|
|
|
|
2020-06-19 09:20:06 +01:00
|
|
|
|
2016-11-21 10:01:39 +00:00
|
|
|
|
2015-06-10 11:08:52 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-08-24 18:59:48 +02:00
|
|
|
|
2015-06-10 11:08:52 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-10-11 10:32:14 +02:00
|
|
|
|
2017-06-19 15:53:01 +03:00
|
|
|
|
2017-10-11 10:32:14 +02:00
|
|
|
|
2017-06-19 15:53:01 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-10-11 10:32:14 +02:00
|
|
|
|
2017-06-19 15:53:01 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-03-15 02:15:57 +08:00
|
|
|
|
|
|
|
|
|
2022-08-24 18:59:48 +02:00
|
|
|
|
2018-08-07 21:15:05 +08:00
|
|
|
|
2018-03-15 02:15:57 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-03-15 02:15:56 +08:00
|
|
|
|
2017-06-19 15:53:01 +03:00
|
|
|
|
|
|
|
|
|
2017-10-11 10:32:14 +02:00
|
|
|
|
2021-12-30 12:57:47 +01:00
|
|
|
|
2018-08-09 11:15:56 +02:00
|
|
|
|
2022-01-21 17:24:27 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-09 11:15:56 +02:00
|
|
|
|
2026-07-29 11:33:13 +02:00
|
|
|
|
2018-08-09 11:15:56 +02:00
|
|
|
|
2018-12-20 15:34:51 +01:00
|
|
|
|
2022-01-21 17:24:31 +00:00
|
|
|
|
2024-03-08 13:59:00 +00:00
|
|
|
|
2023-07-28 12:13:45 +01:00
|
|
|
|
2024-03-08 13:59:00 +00:00
|
|
|
|
2018-10-17 10:59:28 +02:00
|
|
|
|
2018-11-28 13:45:34 +02:00
|
|
|
|
ALSA: hda/tas2781: Add tas2781 hda SPI driver
This patch was used to add TAS2781 devices on SPI support in sound/pci/hda.
It use ACPI node descript about parameters of TAS2781 on SPI, it like:
Scope (_SB.PC00.SPI0)
{
Device (GSPK)
{
Name (_HID, "TXNW2781") // _HID: Hardware ID
Method (_CRS, 0, NotSerialized)
{
Name (RBUF, ResourceTemplate ()
{
SpiSerialBusV2 (...)
SpiSerialBusV2 (...)
}
}
}
}
And in platform/x86/serial-multi-instantiate.c, those spi devices will be
added into system as a single SPI device, so TAS2781 SPI driver will
probe twice for every single SPI device. And driver will also parser
mono DSP firmware binary and RCA binary for itself.
The code support Realtek as the primary codec.
In patch version-10, add multi devices firmware binary support,
to compatble with windows driver, they can share same firmware binary.
Signed-off-by: Baojun Xu <baojun.xu@ti.com>
Link: https://patch.msgid.link/20241216122008.15425-1-baojun.xu@ti.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-12-16 20:20:08 +08:00
|
|
|
|
2022-01-21 17:24:31 +00:00
|
|
|
|
|
|
|
|
|
2022-07-27 10:59:23 +01:00
|
|
|
|
2022-02-24 12:02:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-12-30 12:57:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-09 11:15:56 +02:00
|
|
|
|
|
|
|
|
|
2017-06-19 15:53:01 +03:00
|
|
|
|
2018-03-15 02:15:57 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-01 14:10:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-10-11 10:32:14 +02:00
|
|
|
|
|
|
|
|
|
2017-08-01 14:10:41 +02:00
|
|
|
|
|
|
|
|
|
2026-07-14 20:53:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-12-30 12:57:47 +01:00
|
|
|
|
2018-08-09 11:15:56 +02:00
|
|
|
|
|
|
|
|
|
2017-06-19 15:53:01 +03:00
|
|
|
|
2017-10-11 10:32:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-19 15:53:01 +03:00
|
|
|
|
|
|
|
|
|
2017-10-11 10:32:14 +02:00
|
|
|
|
2017-06-19 15:53:01 +03:00
|
|
|
|
|
|
|
|
|
2013-01-17 14:11:05 +01:00
|
|
|
|
2022-08-10 18:16:33 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2022-08-10 18:16:33 +02:00
|
|
|
|
|
|
|
|
|
2013-01-17 14:11:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-08-24 18:59:48 +02:00
|
|
|
|
2022-08-10 18:16:33 +02:00
|
|
|
|
|
|
|
|
|
2024-07-09 22:37:27 +02:00
|
|
|
|
2026-07-01 21:17:28 +02:00
|
|
|
|
2020-11-20 18:02:22 -08:00
|
|
|
|
2021-04-07 16:32:43 +02:00
|
|
|
|
2013-01-17 14:11:05 +01:00
|
|
|
|
2021-04-07 16:33:38 +02: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 13:33:55 +02:00
|
|
|
|
2013-01-17 14:11:05 +01:00
|
|
|
|
2026-08-27 15:59:32 +02:00
|
|
|
|
2018-03-15 02:15:56 +08:00
|
|
|
|
|
|
|
|
|
2016-07-08 19:13:08 +03:00
|
|
|
|
2013-01-24 12:49:49 +01:00
|
|
|
|
|
|
|
|
|
2015-06-10 11:08:52 -05:00
|
|
|
|
2021-05-10 19:53:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 11:28:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-04-06 13:40:52 +02:00
|
|
|
|
|
|
|
|
|
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 11:28:44 +01:00
|
|
|
|
2021-05-10 19:53:18 +02:00
|
|
|
|
2013-01-24 12:49:49 +01:00
|
|
|
|
2009-09-21 19:29:20 +00:00
|
|
|
|
2013-01-24 12:49:49 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2021-04-07 16:32:43 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-21 19:29:35 +00:00
|
|
|
|
2021-05-10 19:53:18 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-01-20 19:59:51 +01:00
|
|
|
|
2021-06-17 15:57:07 +02:00
|
|
|
|
2021-01-20 19:59:51 +01:00
|
|
|
|
2020-11-21 21:30:35 +01:00
|
|
|
|
2026-02-21 16:37:42 -08:00
|
|
|
|
2021-04-07 16:33:38 +02:00
|
|
|
|
2006-06-27 00:41:40 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2022-08-10 18:16:33 +02:00
|
|
|
|
2018-01-26 16:02:59 +01:00
|
|
|
|
2021-04-07 16:32:43 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-01-26 16:02:59 +01:00
|
|
|
|
2021-05-10 19:53:18 +02:00
|
|
|
|
2021-06-17 15:57:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-10 19:53:18 +02:00
|
|
|
|
2021-06-17 15:57:07 +02:00
|
|
|
|
2021-04-07 16:32:43 +02:00
|
|
|
|
2021-05-10 19:53:18 +02:00
|
|
|
|
2018-01-26 16:02:59 +01:00
|
|
|
|
2013-01-17 14:11:05 +01:00
|
|
|
|
2011-01-06 23:41:27 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-06-17 15:57:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-08-10 18:17:23 +02:00
|
|
|
|
2021-06-17 15:57:07 +02:00
|
|
|
|
2013-01-17 14:11:05 +01:00
|
|
|
|
2026-04-13 21:53:43 +08:00
|
|
|
|
2013-01-17 14:11:05 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-01-17 14:11:05 +01:00
|
|
|
|
2013-01-24 12:49:49 +01:00
|
|
|
|
2021-01-20 19:59:51 +01:00
|
|
|
|
|
|
|
|
|
2022-08-24 18:59:48 +02:00
|
|
|
|
|
|
|
|
|
2021-01-20 19:59:51 +01:00
|
|
|
|
2013-01-17 14:11:05 +01:00
|
|
|
|
|
|
|
|
|
2010-11-25 00:10:44 +01:00
|
|
|
|
|
|
|
|
|
2016-04-07 20:03:18 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-06 12:37:36 +03: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 21:54:37 +01:00
|
|
|
|
2017-06-06 12:37:36 +03: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 21:54:37 +01:00
|
|
|
|
|
|
|
|
|
2024-02-26 17:40:52 +01:00
|
|
|
|
|
|
|
|
|
2024-04-30 18:02:20 +02:00
|
|
|
|
2024-02-26 17:40:52 +01:00
|
|
|
|
|
|
|
|
|
2013-03-03 23:06:21 +01:00
|
|
|
|
2015-09-09 23:59:42 +02:00
|
|
|
|
2013-03-03 23:06:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-30 04:21:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-03 23:06:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-09 23:59:42 +02:00
|
|
|
|
2013-03-04 21:30:43 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-03 23:08:16 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-08-12 06:29:16 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-21 16:37:42 -08:00
|
|
|
|
2024-08-12 06:29:16 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-06 17:31:37 +01:00
|
|
|
|
2013-03-03 23:05:14 +01:00
|
|
|
|
2013-03-04 21:30:43 +00:00
|
|
|
|
2013-03-03 23:05:14 +01:00
|
|
|
|
2014-02-16 00:09:34 +01: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 01:51:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-06 17:31:37 +01:00
|
|
|
|
|
|
|
|
|
2013-03-03 23:05:14 +01:00
|
|
|
|
2013-03-04 21:30:43 +00:00
|
|
|
|
2014-02-06 13:58:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-06 17:31:37 +01:00
|
|
|
|
2013-03-03 23:05:29 +01:00
|
|
|
|
|
|
|
|
|
2024-08-12 06:29:18 +05:30
|
|
|
|
|
|
|
|
|
2023-11-06 17:09:01 +01:00
|
|
|
|
2014-11-23 21:22:54 +08:00
|
|
|
|
|
|
|
|
|
2024-08-12 06:29:16 +05:30
|
|
|
|
2014-11-23 21:22:54 +08:00
|
|
|
|
2024-08-12 06:29:18 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-14 21:27:27 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-11-06 17:09:01 +01:00
|
|
|
|
2024-08-12 06:29:16 +05:30
|
|
|
|
2018-01-26 16:02:59 +01:00
|
|
|
|
2023-12-08 21:06:04 +01:00
|
|
|
|
2020-12-14 21:25:23 +01:00
|
|
|
|
2024-08-12 06:29:16 +05:30
|
|
|
|
2014-11-23 21:22:54 +08:00
|
|
|
|
|
|
|
|
|
2024-08-12 06:29:16 +05:30
|
|
|
|
2020-12-14 21:25:23 +01:00
|
|
|
|
2014-11-23 21:22:54 +08:00
|
|
|
|
|
|
|
|
|
2023-11-06 17:09:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-14 21:27:27 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-12-03 17:36:20 +01:00
|
|
|
|
2021-04-07 16:30:01 +02:00
|
|
|
|
2020-12-14 21:25:23 +01:00
|
|
|
|
2009-09-21 19:29:56 +00:00
|
|
|
|
2012-12-21 00:36:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-07 16:30:01 +02:00
|
|
|
|
2009-09-21 19:29:56 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-04-07 16:30:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-17 14:11:05 +01:00
|
|
|
|
2023-11-06 17:09:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-07 16:30:56 +02:00
|
|
|
|
2021-04-07 16:30:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-07 16:30:56 +02:00
|
|
|
|
|
|
|
|
|
2021-04-07 16:30:01 +02:00
|
|
|
|
|
|
|
|
|
2020-12-14 21:27:27 +01:00
|
|
|
|
2020-12-14 21:25:23 +01:00
|
|
|
|
2021-03-30 20:49:32 +02:00
|
|
|
|
2023-11-06 17:09:01 +01:00
|
|
|
|
2021-03-30 20:49:32 +02:00
|
|
|
|
|
|
|
|
|
2023-11-06 17:09:01 +01:00
|
|
|
|
2021-05-10 19:53:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-06 17:31:37 +01:00
|
|
|
|
2020-12-14 21:27:27 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ACPI: Separate adding ACPI device objects from probing ACPI drivers
Split the ACPI namespace scanning for devices into two passes, such
that struct acpi_device objects are registerd in the first pass
without probing ACPI drivers and the drivers are probed against them
directly in the second pass.
There are two main reasons for doing that.
First, the ACPI PCI root bridge driver's .add() routine,
acpi_pci_root_add(), causes struct pci_dev objects to be created for
all PCI devices under the given root bridge. Usually, there are
corresponding ACPI device nodes in the ACPI namespace for some of
those devices and therefore there should be "companion" struct
acpi_device objects to attach those struct pci_dev objects to. These
struct acpi_device objects should exist when the corresponding
struct pci_dev objects are created, but that is only guaranteed
during boot and not during hotplug. This leads to a number of
functional differences between the boot and the hotplug cases which
are not strictly necessary and make the code more complicated.
For example, this forces the ACPI PCI root bridge driver to defer the
registration of the just created struct pci_dev objects and to use a
special .start() callback routine, acpi_pci_root_start(), to make
sure that all of the "companion" struct acpi_device objects will be
present at PCI devices registration time during hotplug.
If those differences can be eliminated, we will be able to
consolidate the boot and hotplug code paths for the enumeration and
registration of PCI devices and to reduce the complexity of that
code quite a bit.
The second reason is that, in general, it should be possible to
resolve conflicts of resources assigned by the BIOS to different
devices represented by ACPI namespace nodes before any drivers bind
to them and before they are attached to "companion" objects
representing physical devices (such as struct pci_dev). However, for
this purpose we first need to enumerate all ACPI device nodes in the
given namespace scope.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Toshi Kani <toshi.kani@hp.com>
2012-12-21 00:36:39 +01:00
|
|
|
|
2009-09-21 19:29:56 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-14 21:27:27 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-03-09 21:54:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-10 13:40:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-03-09 21:54:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-10 13:40:18 +02:00
|
|
|
|
2026-03-09 21:54:17 +01:00
|
|
|
|
|
|
|
|
|
2026-08-10 13:40:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-03-09 21:54:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ACPI: PNP: Drop PNP0C01 and PNP0C02 from acpi_pnp_device_ids[]
There is a long-standing problem with ACPI device enumeration that
if the given device has a compatible ID which is one of the generic
system resource device IDs (PNP0C01 and PNP0C02), it will be claimed
by the PNP scan handler and it will not be represented as a platform
device, so it cannot be handled by a platform driver.
Drivers have been working around this issue by "manually" creating
platform devices that they can bind to (see the Intel HID driver for
one example) or adding their device IDs to acpi_nonpnp_device_ids[].
None of the above is particularly clean though and the only reason why
the PNP0C01 and PNP0C02 device IDs are present in acpi_pnp_device_ids[]
is to allow the legacy PNP system driver to bind to those devices and
reserve their resources so they are not used going forward.
Obviously, to address this problem PNP0C01 and PNP0C02 need to be
dropped from acpi_pnp_device_ids[], but doing so without making any
other changes would be problematic because the ACPI core would then
create platform devices for the generic system resource device objects
and that would not work on all systems for two reasons. First, the
PNP system driver explicitly avoids reserving I/O resources below the
"standard PC hardware" boundary, 0x100, to avoid conflicts in that range
(one possible case when this may happen is when the CMOS RTC driver is
involved), but the platform device creation code does not do that.
Second, there may be resource conflicts between the "system" devices and
the other devices in the system, possibly including conflicts with PCI
BARs. Registering the PNP system driver via fs_initcall() helps to
manage those conflicts, even though it does not make them go away.
Resource conflicts during the registration of "motherboard resources"
that occur after PCI has claimed BARs are harmless as a rule and do
not need to be addressed in any specific way.
To overcome the issues mentioned above, use the observation that it
is not actually necessary to create any device objects in addition
to struct acpi_device ones in order to reserve the "system" device
resources because that can be done directly in the ACPI device
enumeration code.
Namely, modify acpi_default_enumeration() to add the given ACPI device
object to a special "system devices" list if its _HID is either PNP0C01
or PNP0C02 without creating a platform device for it. Next, add a new
special acpi_scan_claim_resources() function that will be run via
fs_initcall() and will walk that list and reserve resources for each
device in it along the lines of what the PNP system driver does.
Having made the above changes, drop PNP0C01 and PNP0C02 from
acpi_pnp_device_ids[] which will allow platform devices to be created
for ACPI device objects whose _CID lists contain PNP0C01 or PNP0C02,
but the _HID is not in acpi_pnp_device_ids[].
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
[ rjw: Drop a leftover comment and add a new one elsewhere ]
Link: https://patch.msgid.link/9550709.CDJkKcVGEf@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-12-15 14:34:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-30 14:35:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-03-15 02:15:56 +08:00
|
|
|
|
|
|
|
|
|
2014-05-30 14:35:34 +02:00
|
|
|
|
ACPI: PNP: Drop PNP0C01 and PNP0C02 from acpi_pnp_device_ids[]
There is a long-standing problem with ACPI device enumeration that
if the given device has a compatible ID which is one of the generic
system resource device IDs (PNP0C01 and PNP0C02), it will be claimed
by the PNP scan handler and it will not be represented as a platform
device, so it cannot be handled by a platform driver.
Drivers have been working around this issue by "manually" creating
platform devices that they can bind to (see the Intel HID driver for
one example) or adding their device IDs to acpi_nonpnp_device_ids[].
None of the above is particularly clean though and the only reason why
the PNP0C01 and PNP0C02 device IDs are present in acpi_pnp_device_ids[]
is to allow the legacy PNP system driver to bind to those devices and
reserve their resources so they are not used going forward.
Obviously, to address this problem PNP0C01 and PNP0C02 need to be
dropped from acpi_pnp_device_ids[], but doing so without making any
other changes would be problematic because the ACPI core would then
create platform devices for the generic system resource device objects
and that would not work on all systems for two reasons. First, the
PNP system driver explicitly avoids reserving I/O resources below the
"standard PC hardware" boundary, 0x100, to avoid conflicts in that range
(one possible case when this may happen is when the CMOS RTC driver is
involved), but the platform device creation code does not do that.
Second, there may be resource conflicts between the "system" devices and
the other devices in the system, possibly including conflicts with PCI
BARs. Registering the PNP system driver via fs_initcall() helps to
manage those conflicts, even though it does not make them go away.
Resource conflicts during the registration of "motherboard resources"
that occur after PCI has claimed BARs are harmless as a rule and do
not need to be addressed in any specific way.
To overcome the issues mentioned above, use the observation that it
is not actually necessary to create any device objects in addition
to struct acpi_device ones in order to reserve the "system" device
resources because that can be done directly in the ACPI device
enumeration code.
Namely, modify acpi_default_enumeration() to add the given ACPI device
object to a special "system devices" list if its _HID is either PNP0C01
or PNP0C02 without creating a platform device for it. Next, add a new
special acpi_scan_claim_resources() function that will be run via
fs_initcall() and will walk that list and reserve resources for each
device in it along the lines of what the PNP system driver does.
Having made the above changes, drop PNP0C01 and PNP0C02 from
acpi_pnp_device_ids[] which will allow platform devices to be created
for ACPI device objects whose _CID lists contain PNP0C01 or PNP0C02,
but the _HID is not in acpi_pnp_device_ids[].
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
[ rjw: Drop a leftover comment and add a new one elsewhere ]
Link: https://patch.msgid.link/9550709.CDJkKcVGEf@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-12-15 14:34:06 +01:00
|
|
|
|
2016-07-08 19:13:09 +03:00
|
|
|
|
|
|
|
|
|
ACPI: PNP: Drop PNP0C01 and PNP0C02 from acpi_pnp_device_ids[]
There is a long-standing problem with ACPI device enumeration that
if the given device has a compatible ID which is one of the generic
system resource device IDs (PNP0C01 and PNP0C02), it will be claimed
by the PNP scan handler and it will not be represented as a platform
device, so it cannot be handled by a platform driver.
Drivers have been working around this issue by "manually" creating
platform devices that they can bind to (see the Intel HID driver for
one example) or adding their device IDs to acpi_nonpnp_device_ids[].
None of the above is particularly clean though and the only reason why
the PNP0C01 and PNP0C02 device IDs are present in acpi_pnp_device_ids[]
is to allow the legacy PNP system driver to bind to those devices and
reserve their resources so they are not used going forward.
Obviously, to address this problem PNP0C01 and PNP0C02 need to be
dropped from acpi_pnp_device_ids[], but doing so without making any
other changes would be problematic because the ACPI core would then
create platform devices for the generic system resource device objects
and that would not work on all systems for two reasons. First, the
PNP system driver explicitly avoids reserving I/O resources below the
"standard PC hardware" boundary, 0x100, to avoid conflicts in that range
(one possible case when this may happen is when the CMOS RTC driver is
involved), but the platform device creation code does not do that.
Second, there may be resource conflicts between the "system" devices and
the other devices in the system, possibly including conflicts with PCI
BARs. Registering the PNP system driver via fs_initcall() helps to
manage those conflicts, even though it does not make them go away.
Resource conflicts during the registration of "motherboard resources"
that occur after PCI has claimed BARs are harmless as a rule and do
not need to be addressed in any specific way.
To overcome the issues mentioned above, use the observation that it
is not actually necessary to create any device objects in addition
to struct acpi_device ones in order to reserve the "system" device
resources because that can be done directly in the ACPI device
enumeration code.
Namely, modify acpi_default_enumeration() to add the given ACPI device
object to a special "system devices" list if its _HID is either PNP0C01
or PNP0C02 without creating a platform device for it. Next, add a new
special acpi_scan_claim_resources() function that will be run via
fs_initcall() and will walk that list and reserve resources for each
device in it along the lines of what the PNP system driver does.
Having made the above changes, drop PNP0C01 and PNP0C02 from
acpi_pnp_device_ids[] which will allow platform devices to be created
for ACPI device objects whose _CID lists contain PNP0C01 or PNP0C02,
but the _HID is not in acpi_pnp_device_ids[].
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
[ rjw: Drop a leftover comment and add a new one elsewhere ]
Link: https://patch.msgid.link/9550709.CDJkKcVGEf@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-12-15 14:34:06 +01:00
|
|
|
|
2016-07-08 19:13:08 +03:00
|
|
|
|
ACPI: PNP: Drop PNP0C01 and PNP0C02 from acpi_pnp_device_ids[]
There is a long-standing problem with ACPI device enumeration that
if the given device has a compatible ID which is one of the generic
system resource device IDs (PNP0C01 and PNP0C02), it will be claimed
by the PNP scan handler and it will not be represented as a platform
device, so it cannot be handled by a platform driver.
Drivers have been working around this issue by "manually" creating
platform devices that they can bind to (see the Intel HID driver for
one example) or adding their device IDs to acpi_nonpnp_device_ids[].
None of the above is particularly clean though and the only reason why
the PNP0C01 and PNP0C02 device IDs are present in acpi_pnp_device_ids[]
is to allow the legacy PNP system driver to bind to those devices and
reserve their resources so they are not used going forward.
Obviously, to address this problem PNP0C01 and PNP0C02 need to be
dropped from acpi_pnp_device_ids[], but doing so without making any
other changes would be problematic because the ACPI core would then
create platform devices for the generic system resource device objects
and that would not work on all systems for two reasons. First, the
PNP system driver explicitly avoids reserving I/O resources below the
"standard PC hardware" boundary, 0x100, to avoid conflicts in that range
(one possible case when this may happen is when the CMOS RTC driver is
involved), but the platform device creation code does not do that.
Second, there may be resource conflicts between the "system" devices and
the other devices in the system, possibly including conflicts with PCI
BARs. Registering the PNP system driver via fs_initcall() helps to
manage those conflicts, even though it does not make them go away.
Resource conflicts during the registration of "motherboard resources"
that occur after PCI has claimed BARs are harmless as a rule and do
not need to be addressed in any specific way.
To overcome the issues mentioned above, use the observation that it
is not actually necessary to create any device objects in addition
to struct acpi_device ones in order to reserve the "system" device
resources because that can be done directly in the ACPI device
enumeration code.
Namely, modify acpi_default_enumeration() to add the given ACPI device
object to a special "system devices" list if its _HID is either PNP0C01
or PNP0C02 without creating a platform device for it. Next, add a new
special acpi_scan_claim_resources() function that will be run via
fs_initcall() and will walk that list and reserve resources for each
device in it along the lines of what the PNP system driver does.
Having made the above changes, drop PNP0C01 and PNP0C02 from
acpi_pnp_device_ids[] which will allow platform devices to be created
for ACPI device objects whose _CID lists contain PNP0C01 or PNP0C02,
but the _HID is not in acpi_pnp_device_ids[].
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
[ rjw: Drop a leftover comment and add a new one elsewhere ]
Link: https://patch.msgid.link/9550709.CDJkKcVGEf@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-12-15 14:34:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-21 16:37:42 -08:00
|
|
|
|
ACPI: PNP: Drop PNP0C01 and PNP0C02 from acpi_pnp_device_ids[]
There is a long-standing problem with ACPI device enumeration that
if the given device has a compatible ID which is one of the generic
system resource device IDs (PNP0C01 and PNP0C02), it will be claimed
by the PNP scan handler and it will not be represented as a platform
device, so it cannot be handled by a platform driver.
Drivers have been working around this issue by "manually" creating
platform devices that they can bind to (see the Intel HID driver for
one example) or adding their device IDs to acpi_nonpnp_device_ids[].
None of the above is particularly clean though and the only reason why
the PNP0C01 and PNP0C02 device IDs are present in acpi_pnp_device_ids[]
is to allow the legacy PNP system driver to bind to those devices and
reserve their resources so they are not used going forward.
Obviously, to address this problem PNP0C01 and PNP0C02 need to be
dropped from acpi_pnp_device_ids[], but doing so without making any
other changes would be problematic because the ACPI core would then
create platform devices for the generic system resource device objects
and that would not work on all systems for two reasons. First, the
PNP system driver explicitly avoids reserving I/O resources below the
"standard PC hardware" boundary, 0x100, to avoid conflicts in that range
(one possible case when this may happen is when the CMOS RTC driver is
involved), but the platform device creation code does not do that.
Second, there may be resource conflicts between the "system" devices and
the other devices in the system, possibly including conflicts with PCI
BARs. Registering the PNP system driver via fs_initcall() helps to
manage those conflicts, even though it does not make them go away.
Resource conflicts during the registration of "motherboard resources"
that occur after PCI has claimed BARs are harmless as a rule and do
not need to be addressed in any specific way.
To overcome the issues mentioned above, use the observation that it
is not actually necessary to create any device objects in addition
to struct acpi_device ones in order to reserve the "system" device
resources because that can be done directly in the ACPI device
enumeration code.
Namely, modify acpi_default_enumeration() to add the given ACPI device
object to a special "system devices" list if its _HID is either PNP0C01
or PNP0C02 without creating a platform device for it. Next, add a new
special acpi_scan_claim_resources() function that will be run via
fs_initcall() and will walk that list and reserve resources for each
device in it along the lines of what the PNP system driver does.
Having made the above changes, drop PNP0C01 and PNP0C02 from
acpi_pnp_device_ids[] which will allow platform devices to be created
for ACPI device objects whose _CID lists contain PNP0C01 or PNP0C02,
but the _HID is not in acpi_pnp_device_ids[].
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
[ rjw: Drop a leftover comment and add a new one elsewhere ]
Link: https://patch.msgid.link/9550709.CDJkKcVGEf@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-12-15 14:34:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-03-09 21:54:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ACPI: PNP: Drop PNP0C01 and PNP0C02 from acpi_pnp_device_ids[]
There is a long-standing problem with ACPI device enumeration that
if the given device has a compatible ID which is one of the generic
system resource device IDs (PNP0C01 and PNP0C02), it will be claimed
by the PNP scan handler and it will not be represented as a platform
device, so it cannot be handled by a platform driver.
Drivers have been working around this issue by "manually" creating
platform devices that they can bind to (see the Intel HID driver for
one example) or adding their device IDs to acpi_nonpnp_device_ids[].
None of the above is particularly clean though and the only reason why
the PNP0C01 and PNP0C02 device IDs are present in acpi_pnp_device_ids[]
is to allow the legacy PNP system driver to bind to those devices and
reserve their resources so they are not used going forward.
Obviously, to address this problem PNP0C01 and PNP0C02 need to be
dropped from acpi_pnp_device_ids[], but doing so without making any
other changes would be problematic because the ACPI core would then
create platform devices for the generic system resource device objects
and that would not work on all systems for two reasons. First, the
PNP system driver explicitly avoids reserving I/O resources below the
"standard PC hardware" boundary, 0x100, to avoid conflicts in that range
(one possible case when this may happen is when the CMOS RTC driver is
involved), but the platform device creation code does not do that.
Second, there may be resource conflicts between the "system" devices and
the other devices in the system, possibly including conflicts with PCI
BARs. Registering the PNP system driver via fs_initcall() helps to
manage those conflicts, even though it does not make them go away.
Resource conflicts during the registration of "motherboard resources"
that occur after PCI has claimed BARs are harmless as a rule and do
not need to be addressed in any specific way.
To overcome the issues mentioned above, use the observation that it
is not actually necessary to create any device objects in addition
to struct acpi_device ones in order to reserve the "system" device
resources because that can be done directly in the ACPI device
enumeration code.
Namely, modify acpi_default_enumeration() to add the given ACPI device
object to a special "system devices" list if its _HID is either PNP0C01
or PNP0C02 without creating a platform device for it. Next, add a new
special acpi_scan_claim_resources() function that will be run via
fs_initcall() and will walk that list and reserve resources for each
device in it along the lines of what the PNP system driver does.
Having made the above changes, drop PNP0C01 and PNP0C02 from
acpi_pnp_device_ids[] which will allow platform devices to be created
for ACPI device objects whose _CID lists contain PNP0C01 or PNP0C02,
but the _HID is not in acpi_pnp_device_ids[].
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
[ rjw: Drop a leftover comment and add a new one elsewhere ]
Link: https://patch.msgid.link/9550709.CDJkKcVGEf@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-12-15 14:34:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-30 14:35:34 +02:00
|
|
|
|
|
|
|
|
|
2015-04-24 02:18:01 +02:00
|
|
|
|
2015-05-22 04:24:34 +02:00
|
|
|
|
2015-04-24 02:18:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-22 04:24:34 +02:00
|
|
|
|
|
|
|
|
|
2015-04-24 02:18:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-02-06 13:05:22 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-03 23:05:14 +01:00
|
|
|
|
|
|
|
|
|
2013-02-06 13:05:22 +01:00
|
|
|
|
2013-03-03 23:05:14 +01:00
|
|
|
|
|
|
|
|
|
2014-05-30 04:27:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-11 00:35:46 +01:00
|
|
|
|
2013-03-03 23:05:14 +01:00
|
|
|
|
2014-02-11 00:35:46 +01:00
|
|
|
|
2013-03-03 23:05:14 +01:00
|
|
|
|
2014-02-11 00:35:46 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-03 23:05:14 +01:00
|
|
|
|
|
|
|
|
|
2013-02-06 13:05:22 +01:00
|
|
|
|
2014-05-30 14:35:34 +02:00
|
|
|
|
2013-01-30 14:27:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-21 14:34:28 +02:00
|
|
|
|
2009-09-21 19:29:56 +00:00
|
|
|
|
2020-12-14 21:27:27 +01: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 01:51:01 +01:00
|
|
|
|
2013-01-30 14:27:29 +01:00
|
|
|
|
2009-09-21 19:29:56 +00:00
|
|
|
|
2020-12-14 21:27:27 +01: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 01:51:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-25 00:52:21 +01:00
|
|
|
|
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 11:28:44 +01:00
|
|
|
|
|
|
|
|
|
2017-06-06 12:37:36 +03:00
|
|
|
|
2016-07-08 19:13:08 +03:00
|
|
|
|
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 23:38:28 +01:00
|
|
|
|
2022-06-21 14:34:28 +02:00
|
|
|
|
2013-11-25 00:52:21 +01:00
|
|
|
|
2013-07-12 13:45:59 +02:00
|
|
|
|
2013-11-25 00:52:21 +01:00
|
|
|
|
2013-07-12 13:45:59 +02:00
|
|
|
|
2024-08-12 15:16:21 +02: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 21:54:37 +01:00
|
|
|
|
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 23:38:28 +01: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 21:54:37 +01:00
|
|
|
|
2017-04-17 01:20:48 +02: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 21:54:37 +01:00
|
|
|
|
2016-07-08 19:13:08 +03:00
|
|
|
|
2013-01-30 14:27:29 +01:00
|
|
|
|
2013-11-07 01:41:01 +01:00
|
|
|
|
2022-06-21 14:34:28 +02:00
|
|
|
|
2013-11-07 01:41:01 +01:00
|
|
|
|
2018-03-15 02:15:56 +08:00
|
|
|
|
2017-04-11 00:23:42 +02:00
|
|
|
|
|
|
|
|
|
2013-11-25 00:52:21 +01: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 21:54:37 +01:00
|
|
|
|
2026-01-02 12:50:57 +01:00
|
|
|
|
|
|
|
|
|
2017-06-19 15:53:01 +03:00
|
|
|
|
2018-03-15 02:15:56 +08:00
|
|
|
|
|
|
|
|
|
2017-04-11 00:23:42 +02:00
|
|
|
|
2022-06-21 14:34:28 +02:00
|
|
|
|
|
|
|
|
|
2014-09-21 02:58:18 +02:00
|
|
|
|
2020-12-14 21:27:27 +01:00
|
|
|
|
2014-09-21 02:58:18 +02:00
|
|
|
|
2022-06-21 14:34:28 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2022-09-22 00:04:35 +01:00
|
|
|
|
2021-06-03 23:40:03 +01:00
|
|
|
|
2022-09-22 00:04:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-03 23:40:03 +01:00
|
|
|
|
2022-08-10 18:14:22 +02:00
|
|
|
|
2021-06-16 16:21:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-03 23:40:03 +01:00
|
|
|
|
|
|
|
|
|
ACPI: scan: Use async schedule function in acpi_scan_clear_dep_fn()
The device object rescan in acpi_scan_clear_dep_fn() is scheduled on a
system workqueue which is not guaranteed to be finished before entering
userspace. This may cause some key devices to be missing when userspace
init task tries to find them. Two issues observed on RISCV platforms:
- Kernel panic due to userspace init cannot have an opened
console.
The console device scanning is queued by acpi_scan_clear_dep_queue()
and not finished by the time userspace init process running, thus by
the time userspace init runs, no console is present.
- Entering rescue shell due to the lack of root devices (PCIe nvme in
our case).
Same reason as above, the PCIe host bridge scanning is queued on
a system workqueue and finished after init process runs.
The reason is because both devices (console, PCIe host bridge) depend on
riscv-aplic irqchip to serve their interrupts (console's wired interrupt
and PCI's INTx interrupts). In order to keep the dependency, these
devices are scanned and created after initializing riscv-aplic. The
riscv-aplic is initialized in device_initcall() and a device scan work
is queued via acpi_scan_clear_dep_queue(), which is close to the time
userspace init process is run. Since system_dfl_wq is used in
acpi_scan_clear_dep_queue() with no synchronization, the issues will
happen if userspace init runs before these devices are ready.
The solution is to wait for the queued work to complete before entering
userspace init. One possible way would be to use a dedicated workqueue
instead of system_dfl_wq, and explicitly flush it somewhere in the
initcall stage before entering userspace. Another way is to use
async_schedule_dev_nocall() for scanning these devices. It's designed
for asynchronous initialization and will work in the same way as before
because it's using a dedicated unbound workqueue as well, but the kernel
init code calls async_synchronize_full() right before entering userspace
init which will wait for the work to complete.
Compared to a dedicated workqueue, the second approach is simpler
because the async schedule framework takes care of all of the details.
The ACPI code only needs to focus on its job. A dedicated workqueue for
this could also be redundant because some platforms don't need
acpi_scan_clear_dep_queue() for their device scanning.
Signed-off-by: Yicong Yang <yang.yicong@picoheart.com>
[ rjw: Subject adjustment, changelog edits ]
Link: https://patch.msgid.link/20260128132848.93638-1-yang.yicong@picoheart.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-28 21:28:47 +08:00
|
|
|
|
2021-06-16 16:23:44 +02:00
|
|
|
|
ACPI: scan: Use async schedule function in acpi_scan_clear_dep_fn()
The device object rescan in acpi_scan_clear_dep_fn() is scheduled on a
system workqueue which is not guaranteed to be finished before entering
userspace. This may cause some key devices to be missing when userspace
init task tries to find them. Two issues observed on RISCV platforms:
- Kernel panic due to userspace init cannot have an opened
console.
The console device scanning is queued by acpi_scan_clear_dep_queue()
and not finished by the time userspace init process running, thus by
the time userspace init runs, no console is present.
- Entering rescue shell due to the lack of root devices (PCIe nvme in
our case).
Same reason as above, the PCIe host bridge scanning is queued on
a system workqueue and finished after init process runs.
The reason is because both devices (console, PCIe host bridge) depend on
riscv-aplic irqchip to serve their interrupts (console's wired interrupt
and PCI's INTx interrupts). In order to keep the dependency, these
devices are scanned and created after initializing riscv-aplic. The
riscv-aplic is initialized in device_initcall() and a device scan work
is queued via acpi_scan_clear_dep_queue(), which is close to the time
userspace init process is run. Since system_dfl_wq is used in
acpi_scan_clear_dep_queue() with no synchronization, the issues will
happen if userspace init runs before these devices are ready.
The solution is to wait for the queued work to complete before entering
userspace init. One possible way would be to use a dedicated workqueue
instead of system_dfl_wq, and explicitly flush it somewhere in the
initcall stage before entering userspace. Another way is to use
async_schedule_dev_nocall() for scanning these devices. It's designed
for asynchronous initialization and will work in the same way as before
because it's using a dedicated unbound workqueue as well, but the kernel
init code calls async_synchronize_full() right before entering userspace
init which will wait for the work to complete.
Compared to a dedicated workqueue, the second approach is simpler
because the async schedule framework takes care of all of the details.
The ACPI code only needs to focus on its job. A dedicated workqueue for
this could also be redundant because some platforms don't need
acpi_scan_clear_dep_queue() for their device scanning.
Signed-off-by: Yicong Yang <yang.yicong@picoheart.com>
[ rjw: Subject adjustment, changelog edits ]
Link: https://patch.msgid.link/20260128132848.93638-1-yang.yicong@picoheart.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-28 21:28:47 +08:00
|
|
|
|
2021-06-16 16:23:44 +02:00
|
|
|
|
|
|
|
|
|
ACPI: scan: Use async schedule function in acpi_scan_clear_dep_fn()
The device object rescan in acpi_scan_clear_dep_fn() is scheduled on a
system workqueue which is not guaranteed to be finished before entering
userspace. This may cause some key devices to be missing when userspace
init task tries to find them. Two issues observed on RISCV platforms:
- Kernel panic due to userspace init cannot have an opened
console.
The console device scanning is queued by acpi_scan_clear_dep_queue()
and not finished by the time userspace init process running, thus by
the time userspace init runs, no console is present.
- Entering rescue shell due to the lack of root devices (PCIe nvme in
our case).
Same reason as above, the PCIe host bridge scanning is queued on
a system workqueue and finished after init process runs.
The reason is because both devices (console, PCIe host bridge) depend on
riscv-aplic irqchip to serve their interrupts (console's wired interrupt
and PCI's INTx interrupts). In order to keep the dependency, these
devices are scanned and created after initializing riscv-aplic. The
riscv-aplic is initialized in device_initcall() and a device scan work
is queued via acpi_scan_clear_dep_queue(), which is close to the time
userspace init process is run. Since system_dfl_wq is used in
acpi_scan_clear_dep_queue() with no synchronization, the issues will
happen if userspace init runs before these devices are ready.
The solution is to wait for the queued work to complete before entering
userspace init. One possible way would be to use a dedicated workqueue
instead of system_dfl_wq, and explicitly flush it somewhere in the
initcall stage before entering userspace. Another way is to use
async_schedule_dev_nocall() for scanning these devices. It's designed
for asynchronous initialization and will work in the same way as before
because it's using a dedicated unbound workqueue as well, but the kernel
init code calls async_synchronize_full() right before entering userspace
init which will wait for the work to complete.
Compared to a dedicated workqueue, the second approach is simpler
because the async schedule framework takes care of all of the details.
The ACPI code only needs to focus on its job. A dedicated workqueue for
this could also be redundant because some platforms don't need
acpi_scan_clear_dep_queue() for their device scanning.
Signed-off-by: Yicong Yang <yang.yicong@picoheart.com>
[ rjw: Subject adjustment, changelog edits ]
Link: https://patch.msgid.link/20260128132848.93638-1-yang.yicong@picoheart.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-28 21:28:47 +08:00
|
|
|
|
2021-06-16 16:23:44 +02:00
|
|
|
|
|
|
|
|
|
ACPI: scan: Use async schedule function in acpi_scan_clear_dep_fn()
The device object rescan in acpi_scan_clear_dep_fn() is scheduled on a
system workqueue which is not guaranteed to be finished before entering
userspace. This may cause some key devices to be missing when userspace
init task tries to find them. Two issues observed on RISCV platforms:
- Kernel panic due to userspace init cannot have an opened
console.
The console device scanning is queued by acpi_scan_clear_dep_queue()
and not finished by the time userspace init process running, thus by
the time userspace init runs, no console is present.
- Entering rescue shell due to the lack of root devices (PCIe nvme in
our case).
Same reason as above, the PCIe host bridge scanning is queued on
a system workqueue and finished after init process runs.
The reason is because both devices (console, PCIe host bridge) depend on
riscv-aplic irqchip to serve their interrupts (console's wired interrupt
and PCI's INTx interrupts). In order to keep the dependency, these
devices are scanned and created after initializing riscv-aplic. The
riscv-aplic is initialized in device_initcall() and a device scan work
is queued via acpi_scan_clear_dep_queue(), which is close to the time
userspace init process is run. Since system_dfl_wq is used in
acpi_scan_clear_dep_queue() with no synchronization, the issues will
happen if userspace init runs before these devices are ready.
The solution is to wait for the queued work to complete before entering
userspace init. One possible way would be to use a dedicated workqueue
instead of system_dfl_wq, and explicitly flush it somewhere in the
initcall stage before entering userspace. Another way is to use
async_schedule_dev_nocall() for scanning these devices. It's designed
for asynchronous initialization and will work in the same way as before
because it's using a dedicated unbound workqueue as well, but the kernel
init code calls async_synchronize_full() right before entering userspace
init which will wait for the work to complete.
Compared to a dedicated workqueue, the second approach is simpler
because the async schedule framework takes care of all of the details.
The ACPI code only needs to focus on its job. A dedicated workqueue for
this could also be redundant because some platforms don't need
acpi_scan_clear_dep_queue() for their device scanning.
Signed-off-by: Yicong Yang <yang.yicong@picoheart.com>
[ rjw: Subject adjustment, changelog edits ]
Link: https://patch.msgid.link/20260128132848.93638-1-yang.yicong@picoheart.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-28 21:28:47 +08:00
|
|
|
|
2021-06-16 16:23:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ACPI: scan: Use async schedule function in acpi_scan_clear_dep_fn()
The device object rescan in acpi_scan_clear_dep_fn() is scheduled on a
system workqueue which is not guaranteed to be finished before entering
userspace. This may cause some key devices to be missing when userspace
init task tries to find them. Two issues observed on RISCV platforms:
- Kernel panic due to userspace init cannot have an opened
console.
The console device scanning is queued by acpi_scan_clear_dep_queue()
and not finished by the time userspace init process running, thus by
the time userspace init runs, no console is present.
- Entering rescue shell due to the lack of root devices (PCIe nvme in
our case).
Same reason as above, the PCIe host bridge scanning is queued on
a system workqueue and finished after init process runs.
The reason is because both devices (console, PCIe host bridge) depend on
riscv-aplic irqchip to serve their interrupts (console's wired interrupt
and PCI's INTx interrupts). In order to keep the dependency, these
devices are scanned and created after initializing riscv-aplic. The
riscv-aplic is initialized in device_initcall() and a device scan work
is queued via acpi_scan_clear_dep_queue(), which is close to the time
userspace init process is run. Since system_dfl_wq is used in
acpi_scan_clear_dep_queue() with no synchronization, the issues will
happen if userspace init runs before these devices are ready.
The solution is to wait for the queued work to complete before entering
userspace init. One possible way would be to use a dedicated workqueue
instead of system_dfl_wq, and explicitly flush it somewhere in the
initcall stage before entering userspace. Another way is to use
async_schedule_dev_nocall() for scanning these devices. It's designed
for asynchronous initialization and will work in the same way as before
because it's using a dedicated unbound workqueue as well, but the kernel
init code calls async_synchronize_full() right before entering userspace
init which will wait for the work to complete.
Compared to a dedicated workqueue, the second approach is simpler
because the async schedule framework takes care of all of the details.
The ACPI code only needs to focus on its job. A dedicated workqueue for
this could also be redundant because some platforms don't need
acpi_scan_clear_dep_queue() for their device scanning.
Signed-off-by: Yicong Yang <yang.yicong@picoheart.com>
[ rjw: Subject adjustment, changelog edits ]
Link: https://patch.msgid.link/20260128132848.93638-1-yang.yicong@picoheart.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-28 21:28:47 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-16 16:23:44 +02:00
|
|
|
|
ACPI: scan: Use async schedule function in acpi_scan_clear_dep_fn()
The device object rescan in acpi_scan_clear_dep_fn() is scheduled on a
system workqueue which is not guaranteed to be finished before entering
userspace. This may cause some key devices to be missing when userspace
init task tries to find them. Two issues observed on RISCV platforms:
- Kernel panic due to userspace init cannot have an opened
console.
The console device scanning is queued by acpi_scan_clear_dep_queue()
and not finished by the time userspace init process running, thus by
the time userspace init runs, no console is present.
- Entering rescue shell due to the lack of root devices (PCIe nvme in
our case).
Same reason as above, the PCIe host bridge scanning is queued on
a system workqueue and finished after init process runs.
The reason is because both devices (console, PCIe host bridge) depend on
riscv-aplic irqchip to serve their interrupts (console's wired interrupt
and PCI's INTx interrupts). In order to keep the dependency, these
devices are scanned and created after initializing riscv-aplic. The
riscv-aplic is initialized in device_initcall() and a device scan work
is queued via acpi_scan_clear_dep_queue(), which is close to the time
userspace init process is run. Since system_dfl_wq is used in
acpi_scan_clear_dep_queue() with no synchronization, the issues will
happen if userspace init runs before these devices are ready.
The solution is to wait for the queued work to complete before entering
userspace init. One possible way would be to use a dedicated workqueue
instead of system_dfl_wq, and explicitly flush it somewhere in the
initcall stage before entering userspace. Another way is to use
async_schedule_dev_nocall() for scanning these devices. It's designed
for asynchronous initialization and will work in the same way as before
because it's using a dedicated unbound workqueue as well, but the kernel
init code calls async_synchronize_full() right before entering userspace
init which will wait for the work to complete.
Compared to a dedicated workqueue, the second approach is simpler
because the async schedule framework takes care of all of the details.
The ACPI code only needs to focus on its job. A dedicated workqueue for
this could also be redundant because some platforms don't need
acpi_scan_clear_dep_queue() for their device scanning.
Signed-off-by: Yicong Yang <yang.yicong@picoheart.com>
[ rjw: Subject adjustment, changelog edits ]
Link: https://patch.msgid.link/20260128132848.93638-1-yang.yicong@picoheart.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-28 21:28:47 +08:00
|
|
|
|
2021-06-16 16:23:44 +02:00
|
|
|
|
|
|
|
|
|
2023-05-16 12:25:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-03 23:40:02 +01:00
|
|
|
|
|
|
|
|
|
2022-08-10 18:14:22 +02:00
|
|
|
|
2021-06-03 23:40:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-16 16:23:44 +02:00
|
|
|
|
|
|
|
|
|
2021-06-03 23:40:02 +01:00
|
|
|
|
|
|
|
|
|
2023-05-16 12:25:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-03 23:40:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-16 16:22:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-23 21:22:54 +08:00
|
|
|
|
|
|
|
|
|
2021-06-09 18:33:12 +01:00
|
|
|
|
2014-11-23 21:22:54 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-07 18:46:06 +01:00
|
|
|
|
2021-06-03 23:40:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-23 21:22:54 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-03 23:40:02 +01:00
|
|
|
|
|
|
|
|
|
2014-11-23 21:22:54 +08:00
|
|
|
|
|
|
|
|
|
2021-06-03 23:40:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 11:28:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-03 23:40:03 +01:00
|
|
|
|
2022-09-22 00:04:35 +01:00
|
|
|
|
2021-06-03 23:40:03 +01:00
|
|
|
|
2022-09-22 00:04:35 +01:00
|
|
|
|
2021-06-03 23:40:03 +01:00
|
|
|
|
2022-09-22 00:04:35 +01:00
|
|
|
|
2021-06-03 23:40:03 +01:00
|
|
|
|
|
|
|
|
|
2022-09-22 00:04:35 +01:00
|
|
|
|
|
|
|
|
|
2021-06-03 23:40:03 +01:00
|
|
|
|
2022-09-22 00:04:35 +01:00
|
|
|
|
|
|
|
|
|
2021-06-03 23:40:03 +01:00
|
|
|
|
2022-09-22 00:04:35 +01:00
|
|
|
|
2021-06-03 23:40:03 +01:00
|
|
|
|
|
|
|
|
|
2022-09-22 00:04:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-03 23:40:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-22 00:04:35 +01:00
|
|
|
|
2014-11-23 21:22:54 +08:00
|
|
|
|
2023-05-16 12:25:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-11-07 20:19:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-05-16 12:25:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ACPI: PNP: Drop PNP0C01 and PNP0C02 from acpi_pnp_device_ids[]
There is a long-standing problem with ACPI device enumeration that
if the given device has a compatible ID which is one of the generic
system resource device IDs (PNP0C01 and PNP0C02), it will be claimed
by the PNP scan handler and it will not be represented as a platform
device, so it cannot be handled by a platform driver.
Drivers have been working around this issue by "manually" creating
platform devices that they can bind to (see the Intel HID driver for
one example) or adding their device IDs to acpi_nonpnp_device_ids[].
None of the above is particularly clean though and the only reason why
the PNP0C01 and PNP0C02 device IDs are present in acpi_pnp_device_ids[]
is to allow the legacy PNP system driver to bind to those devices and
reserve their resources so they are not used going forward.
Obviously, to address this problem PNP0C01 and PNP0C02 need to be
dropped from acpi_pnp_device_ids[], but doing so without making any
other changes would be problematic because the ACPI core would then
create platform devices for the generic system resource device objects
and that would not work on all systems for two reasons. First, the
PNP system driver explicitly avoids reserving I/O resources below the
"standard PC hardware" boundary, 0x100, to avoid conflicts in that range
(one possible case when this may happen is when the CMOS RTC driver is
involved), but the platform device creation code does not do that.
Second, there may be resource conflicts between the "system" devices and
the other devices in the system, possibly including conflicts with PCI
BARs. Registering the PNP system driver via fs_initcall() helps to
manage those conflicts, even though it does not make them go away.
Resource conflicts during the registration of "motherboard resources"
that occur after PCI has claimed BARs are harmless as a rule and do
not need to be addressed in any specific way.
To overcome the issues mentioned above, use the observation that it
is not actually necessary to create any device objects in addition
to struct acpi_device ones in order to reserve the "system" device
resources because that can be done directly in the ACPI device
enumeration code.
Namely, modify acpi_default_enumeration() to add the given ACPI device
object to a special "system devices" list if its _HID is either PNP0C01
or PNP0C02 without creating a platform device for it. Next, add a new
special acpi_scan_claim_resources() function that will be run via
fs_initcall() and will walk that list and reserve resources for each
device in it along the lines of what the PNP system driver does.
Having made the above changes, drop PNP0C01 and PNP0C02 from
acpi_pnp_device_ids[] which will allow platform devices to be created
for ACPI device objects whose _CID lists contain PNP0C01 or PNP0C02,
but the _HID is not in acpi_pnp_device_ids[].
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
[ rjw: Drop a leftover comment and add a new one elsewhere ]
Link: https://patch.msgid.link/9550709.CDJkKcVGEf@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-12-15 14:34:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-10 12:50:54 +01:00
|
|
|
|
ACPI: PNP: Drop PNP0C01 and PNP0C02 from acpi_pnp_device_ids[]
There is a long-standing problem with ACPI device enumeration that
if the given device has a compatible ID which is one of the generic
system resource device IDs (PNP0C01 and PNP0C02), it will be claimed
by the PNP scan handler and it will not be represented as a platform
device, so it cannot be handled by a platform driver.
Drivers have been working around this issue by "manually" creating
platform devices that they can bind to (see the Intel HID driver for
one example) or adding their device IDs to acpi_nonpnp_device_ids[].
None of the above is particularly clean though and the only reason why
the PNP0C01 and PNP0C02 device IDs are present in acpi_pnp_device_ids[]
is to allow the legacy PNP system driver to bind to those devices and
reserve their resources so they are not used going forward.
Obviously, to address this problem PNP0C01 and PNP0C02 need to be
dropped from acpi_pnp_device_ids[], but doing so without making any
other changes would be problematic because the ACPI core would then
create platform devices for the generic system resource device objects
and that would not work on all systems for two reasons. First, the
PNP system driver explicitly avoids reserving I/O resources below the
"standard PC hardware" boundary, 0x100, to avoid conflicts in that range
(one possible case when this may happen is when the CMOS RTC driver is
involved), but the platform device creation code does not do that.
Second, there may be resource conflicts between the "system" devices and
the other devices in the system, possibly including conflicts with PCI
BARs. Registering the PNP system driver via fs_initcall() helps to
manage those conflicts, even though it does not make them go away.
Resource conflicts during the registration of "motherboard resources"
that occur after PCI has claimed BARs are harmless as a rule and do
not need to be addressed in any specific way.
To overcome the issues mentioned above, use the observation that it
is not actually necessary to create any device objects in addition
to struct acpi_device ones in order to reserve the "system" device
resources because that can be done directly in the ACPI device
enumeration code.
Namely, modify acpi_default_enumeration() to add the given ACPI device
object to a special "system devices" list if its _HID is either PNP0C01
or PNP0C02 without creating a platform device for it. Next, add a new
special acpi_scan_claim_resources() function that will be run via
fs_initcall() and will walk that list and reserve resources for each
device in it along the lines of what the PNP system driver does.
Having made the above changes, drop PNP0C01 and PNP0C02 from
acpi_pnp_device_ids[] which will allow platform devices to be created
for ACPI device objects whose _CID lists contain PNP0C01 or PNP0C02,
but the _HID is not in acpi_pnp_device_ids[].
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
[ rjw: Drop a leftover comment and add a new one elsewhere ]
Link: https://patch.msgid.link/9550709.CDJkKcVGEf@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-12-15 14:34:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-12-30 10:57:34 +01:00
|
|
|
|
ACPI: PNP: Drop PNP0C01 and PNP0C02 from acpi_pnp_device_ids[]
There is a long-standing problem with ACPI device enumeration that
if the given device has a compatible ID which is one of the generic
system resource device IDs (PNP0C01 and PNP0C02), it will be claimed
by the PNP scan handler and it will not be represented as a platform
device, so it cannot be handled by a platform driver.
Drivers have been working around this issue by "manually" creating
platform devices that they can bind to (see the Intel HID driver for
one example) or adding their device IDs to acpi_nonpnp_device_ids[].
None of the above is particularly clean though and the only reason why
the PNP0C01 and PNP0C02 device IDs are present in acpi_pnp_device_ids[]
is to allow the legacy PNP system driver to bind to those devices and
reserve their resources so they are not used going forward.
Obviously, to address this problem PNP0C01 and PNP0C02 need to be
dropped from acpi_pnp_device_ids[], but doing so without making any
other changes would be problematic because the ACPI core would then
create platform devices for the generic system resource device objects
and that would not work on all systems for two reasons. First, the
PNP system driver explicitly avoids reserving I/O resources below the
"standard PC hardware" boundary, 0x100, to avoid conflicts in that range
(one possible case when this may happen is when the CMOS RTC driver is
involved), but the platform device creation code does not do that.
Second, there may be resource conflicts between the "system" devices and
the other devices in the system, possibly including conflicts with PCI
BARs. Registering the PNP system driver via fs_initcall() helps to
manage those conflicts, even though it does not make them go away.
Resource conflicts during the registration of "motherboard resources"
that occur after PCI has claimed BARs are harmless as a rule and do
not need to be addressed in any specific way.
To overcome the issues mentioned above, use the observation that it
is not actually necessary to create any device objects in addition
to struct acpi_device ones in order to reserve the "system" device
resources because that can be done directly in the ACPI device
enumeration code.
Namely, modify acpi_default_enumeration() to add the given ACPI device
object to a special "system devices" list if its _HID is either PNP0C01
or PNP0C02 without creating a platform device for it. Next, add a new
special acpi_scan_claim_resources() function that will be run via
fs_initcall() and will walk that list and reserve resources for each
device in it along the lines of what the PNP system driver does.
Having made the above changes, drop PNP0C01 and PNP0C02 from
acpi_pnp_device_ids[] which will allow platform devices to be created
for ACPI device objects whose _CID lists contain PNP0C01 or PNP0C02,
but the _HID is not in acpi_pnp_device_ids[].
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
[ rjw: Drop a leftover comment and add a new one elsewhere ]
Link: https://patch.msgid.link/9550709.CDJkKcVGEf@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-12-15 14:34:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-12-30 10:57:34 +01:00
|
|
|
|
ACPI: PNP: Drop PNP0C01 and PNP0C02 from acpi_pnp_device_ids[]
There is a long-standing problem with ACPI device enumeration that
if the given device has a compatible ID which is one of the generic
system resource device IDs (PNP0C01 and PNP0C02), it will be claimed
by the PNP scan handler and it will not be represented as a platform
device, so it cannot be handled by a platform driver.
Drivers have been working around this issue by "manually" creating
platform devices that they can bind to (see the Intel HID driver for
one example) or adding their device IDs to acpi_nonpnp_device_ids[].
None of the above is particularly clean though and the only reason why
the PNP0C01 and PNP0C02 device IDs are present in acpi_pnp_device_ids[]
is to allow the legacy PNP system driver to bind to those devices and
reserve their resources so they are not used going forward.
Obviously, to address this problem PNP0C01 and PNP0C02 need to be
dropped from acpi_pnp_device_ids[], but doing so without making any
other changes would be problematic because the ACPI core would then
create platform devices for the generic system resource device objects
and that would not work on all systems for two reasons. First, the
PNP system driver explicitly avoids reserving I/O resources below the
"standard PC hardware" boundary, 0x100, to avoid conflicts in that range
(one possible case when this may happen is when the CMOS RTC driver is
involved), but the platform device creation code does not do that.
Second, there may be resource conflicts between the "system" devices and
the other devices in the system, possibly including conflicts with PCI
BARs. Registering the PNP system driver via fs_initcall() helps to
manage those conflicts, even though it does not make them go away.
Resource conflicts during the registration of "motherboard resources"
that occur after PCI has claimed BARs are harmless as a rule and do
not need to be addressed in any specific way.
To overcome the issues mentioned above, use the observation that it
is not actually necessary to create any device objects in addition
to struct acpi_device ones in order to reserve the "system" device
resources because that can be done directly in the ACPI device
enumeration code.
Namely, modify acpi_default_enumeration() to add the given ACPI device
object to a special "system devices" list if its _HID is either PNP0C01
or PNP0C02 without creating a platform device for it. Next, add a new
special acpi_scan_claim_resources() function that will be run via
fs_initcall() and will walk that list and reserve resources for each
device in it along the lines of what the PNP system driver does.
Having made the above changes, drop PNP0C01 and PNP0C02 from
acpi_pnp_device_ids[] which will allow platform devices to be created
for ACPI device objects whose _CID lists contain PNP0C01 or PNP0C02,
but the _HID is not in acpi_pnp_device_ids[].
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
[ rjw: Drop a leftover comment and add a new one elsewhere ]
Link: https://patch.msgid.link/9550709.CDJkKcVGEf@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-12-15 14:34:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-19 01:27:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-29 17:48:52 +01:00
|
|
|
|
2013-01-19 01:27:35 +01:00
|
|
|
|
|
|
|
|
|
2010-01-29 17:48:52 +01:00
|
|
|
|
2013-01-19 01:27:35 +01: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 14:36:47 +01:00
|
|
|
|
|
|
|
|
|
2010-01-29 17:48:52 +01:00
|
|
|
|
2013-01-19 01:27:35 +01:00
|
|
|
|
2005-04-28 00:25:52 -07:00
|
|
|
|
2020-12-14 21:27:27 +01:00
|
|
|
|
2005-04-28 00:25:52 -07:00
|
|
|
|
2020-12-14 21:27:27 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-21 19:29:56 +00:00
|
|
|
|
2020-12-14 21:27:27 +01:00
|
|
|
|
|
|
|
|
|
2005-04-28 00:25:52 -07:00
|
|
|
|
2020-12-14 21:27:27 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-11-06 17:09:01 +01:00
|
|
|
|
2023-11-07 20:19:42 +01:00
|
|
|
|
2023-11-06 17:09:01 +01:00
|
|
|
|
2023-11-07 20:19:42 +01:00
|
|
|
|
2023-11-06 17:09:01 +01:00
|
|
|
|
|
|
|
|
|
2023-11-07 20:19:42 +01:00
|
|
|
|
2023-11-06 17:09:01 +01:00
|
|
|
|
2022-06-21 14:34:28 +02:00
|
|
|
|
2020-12-14 21:27:27 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-05-16 12:25:22 +02:00
|
|
|
|
2020-12-14 21:27:27 +01:00
|
|
|
|
2023-11-06 17:09:01 +01:00
|
|
|
|
|
|
|
|
|
2020-12-14 21:27:27 +01:00
|
|
|
|
2005-04-28 00:25:52 -07:00
|
|
|
|
2013-01-19 01:27:35 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2022-06-21 14:34:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-05-29 14:34:36 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-02-23 17:56:01 -08:00
|
|
|
|
|
|
|
|
|
2017-09-26 16:54:09 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-10 19:53:18 +02:00
|
|
|
|
2017-09-26 16:54:09 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-12-11 15:16:37 +01:00
|
|
|
|
ACPI: EC: Convert the driver to a platform one
While binding drivers directly to struct acpi_device objects allows
basic functionality to be provided, at least in the majority of cases,
there are some problems with it, related to general consistency, sysfs
layout, power management operation ordering, and code cleanliness.
Overall, it is better to bind drivers to platform devices than to their
ACPI companions, so convert the ACPI embedded controller (EC) driver
to a platform one.
After this conversion, acpi_bus_register_early_device() does not need
to attempt to bind an ACPI driver to the struct acpi_device created by
it, so update it accordingly.
While this is not expected to alter functionality, it changes sysfs
layout and so it will be visible to user space.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
[ rjw: Removed excess semicolon ]
Link: https://patch.msgid.link/1946304.tdWV9SEqCh@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-12-11 15:17:23 +01:00
|
|
|
|
2017-09-26 16:54:09 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-12-15 14:54:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-12-15 15:00:01 +01:00
|
|
|
|
2025-12-15 14:54:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-11 17:52:00 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2025-12-15 14:54:17 +01:00
|
|
|
|
|
|
|
|
|
2013-01-29 13:57:20 +01:00
|
|
|
|
2025-12-15 14:54:17 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-04-07 20:03:18 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-07 17:09:20 +08:00
|
|
|
|
2021-06-02 16:54:37 +08:00
|
|
|
|
2020-05-07 17:09:20 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-07 20:03:18 +08:00
|
|
|
|
|
|
|
|
|
2016-07-08 19:13:09 +03:00
|
|
|
|
|
|
|
|
|
2022-01-11 17:50:22 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-04-07 20:03:18 +08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-12-21 00:36:40 +01:00
|
|
|
|
2013-01-30 14:27:37 +01:00
|
|
|
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-03 00:26:22 +02:00
|
|
|
|
2019-08-30 17:34:32 +03:00
|
|
|
|
2013-03-06 23:46:20 +01:00
|
|
|
|
2015-02-06 08:27:51 +08:00
|
|
|
|
2013-06-05 02:27:50 +00:00
|
|
|
|
2013-02-08 23:52:39 +01:00
|
|
|
|
2013-03-03 23:18:03 +01:00
|
|
|
|
2018-04-19 13:08:37 +03:00
|
|
|
|
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 04:23:01 +02:00
|
|
|
|
2025-08-03 21:18:11 +02:00
|
|
|
|
2017-10-05 16:24:03 -07:00
|
|
|
|
2010-11-25 00:10:02 +01:00
|
|
|
|
2015-04-24 02:18:01 +02:00
|
|
|
|
|
|
|
|
|
2016-04-07 20:03:18 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-02 16:54:37 +08:00
|
|
|
|
2016-04-07 20:03:18 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-07 17:09:20 +08:00
|
|
|
|
|
|
|
|
|
2016-04-07 20:03:18 +08:00
|
|
|
|
|
|
|
|
|
2017-08-10 00:34:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-08-02 21:49:29 -07: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 14:36:47 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-11 17:50:22 +01:00
|
|
|
|
2022-01-11 17:53:29 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-12-03 17:36:20 +01:00
|
|
|
|
|
|
|
|
|
2022-01-11 17:53:29 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-04-28 10:38:04 +08:00
|
|
|
|
2022-01-11 17:52:00 +01:00
|
|
|
|
|
|
|
|
|
2013-01-19 01:27:35 +01: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 17:26:16 +02:00
|
|
|
|
2021-05-10 14:02:17 +02:00
|
|
|
|
2016-07-08 19:13:09 +03:00
|
|
|
|
|
|
|
|
|
2022-01-11 17:53:29 +01: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 14:36:47 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-09-28 15:49:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-16 16:59:53 +01:00
|
|
|
|
2015-09-28 15:49:12 +01:00
|
|
|
|
2019-03-11 14:55:57 -06:00
|
|
|
|
2015-09-28 15:49:12 +01:00
|
|
|
|
|
|
|
|
|
2019-03-11 14:55:57 -06:00
|
|
|
|
2015-09-28 15:49:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-08-12 06:29:14 +05:30
|
|
|
|
|
|
|
|
|
2015-09-28 15:49:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-16 16:59:53 +01:00
|
|
|
|
2024-08-12 06:29:14 +05:30
|
|
|
|
2015-09-28 15:49:12 +01:00
|
|
|
|
2019-04-08 13:42:24 -07:00
|
|
|
|
2015-09-28 15:49:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-16 16:59:53 +01:00
|
|
|
|
2015-09-28 15:49:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-08 19:13:09 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-16 16:05:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-08 19:13:09 +03:00
|
|
|
|
2021-06-16 16:05:50 +02:00
|
|
|
|
2016-07-08 19:13:09 +03:00
|
|
|
|
|
|
|
|
|
2021-06-16 16:05:50 +02:00
|
|
|
|
2016-07-08 19:13:09 +03:00
|
|
|
|
2021-06-16 16:05:50 +02:00
|
|
|
|
2016-07-08 19:13:09 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-21 16:37:42 -08:00
|
|
|
|
2021-06-16 16:05:50 +02:00
|
|
|
|
2016-07-08 19:13:09 +03:00
|
|
|
|
|
|
|
|
|
2021-06-16 16:05:50 +02:00
|
|
|
|
|
|
|
|
|
2016-07-08 19:13:09 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
