|
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6, v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1, v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4, v6.13-rc3, v6.13-rc2, v6.13-rc1, v6.12, v6.12-rc7, v6.12-rc6, v6.12-rc5, v6.12-rc4, v6.12-rc3, v6.12-rc2, v6.12-rc1, v6.11, v6.11-rc7, v6.11-rc6, v6.11-rc5, v6.11-rc4, v6.11-rc3, v6.11-rc2, v6.11-rc1, v6.10, v6.10-rc7, v6.10-rc6, v6.10-rc5, v6.10-rc4, v6.10-rc3, v6.10-rc2, v6.10-rc1, v6.9, v6.9-rc7, v6.9-rc6, v6.9-rc5, v6.9-rc4, v6.9-rc3, v6.9-rc2, v6.9-rc1, v6.8, v6.8-rc7, v6.8-rc6, v6.8-rc5, v6.8-rc4, v6.8-rc3, v6.8-rc2, v6.8-rc1, v6.7, v6.7-rc8, v6.7-rc7, v6.7-rc6, v6.7-rc5, v6.7-rc4, v6.7-rc3, v6.7-rc2, v6.7-rc1, v6.6, v6.6-rc7, v6.6-rc6, v6.6-rc5, v6.6-rc4, v6.6-rc3, v6.6-rc2, v6.6-rc1, v6.5, v6.5-rc7, v6.5-rc6, v6.5-rc5, v6.5-rc4, v6.5-rc3, v6.5-rc2, v6.5-rc1, v6.4, v6.4-rc7, v6.4-rc6, v6.4-rc5, v6.4-rc4, v6.4-rc3, v6.4-rc2, v6.4-rc1, v6.3, v6.3-rc7, v6.3-rc6, v6.3-rc5, v6.3-rc4, v6.3-rc3, v6.3-rc2, v6.3-rc1, v6.2, v6.2-rc8, v6.2-rc7, v6.2-rc6, v6.2-rc5, v6.2-rc4, v6.2-rc3, v6.2-rc2, v6.2-rc1, v6.1, v6.1-rc8, v6.1-rc7, v6.1-rc6, v6.1-rc5, v6.1-rc4, v6.1-rc3, v6.1-rc2, v6.1-rc1, v6.0, v6.0-rc7, v6.0-rc6, v6.0-rc5, v6.0-rc4, v6.0-rc3, v6.0-rc2, v6.0-rc1, v5.19, v5.19-rc8, v5.19-rc7, v5.19-rc6, v5.19-rc5, v5.19-rc4, v5.19-rc3 |
|
| #
abda0af4 |
| 13-Jun-2022 |
Rafael J. Wysocki <[email protected]> |
ACPI: container: Use acpi_dev_for_each_child()
Instead of walking the list of children of an ACPI device directly, use acpi_dev_for_each_child() to carry out an action for all of the given ACPI devi
ACPI: container: Use acpi_dev_for_each_child()
Instead of walking the list of children of an ACPI device directly, use acpi_dev_for_each_child() to carry out an action for all of the given ACPI device's children.
This will help to eliminate the children list head from struct acpi_device as it is redundant and it is used in questionable ways in some places (in particular, locking is needed for walking the list pointed to it safely, but it is often missing).
Signed-off-by: Rafael J. Wysocki <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]>
show more ...
|
|
Revision tags: v5.19-rc2, v5.19-rc1, v5.18, v5.18-rc7, v5.18-rc6, v5.18-rc5, v5.18-rc4, v5.18-rc3, v5.18-rc2, v5.18-rc1, v5.17, v5.17-rc8, v5.17-rc7, v5.17-rc6, v5.17-rc5, v5.17-rc4, v5.17-rc3, v5.17-rc2, v5.17-rc1, v5.16, v5.16-rc8, v5.16-rc7, v5.16-rc6, v5.16-rc5, v5.16-rc4, v5.16-rc3, v5.16-rc2, v5.16-rc1, v5.15, v5.15-rc7, v5.15-rc6, v5.15-rc5, v5.15-rc4, v5.15-rc3, v5.15-rc2, v5.15-rc1, v5.14, v5.14-rc7, v5.14-rc6, v5.14-rc5, v5.14-rc4, v5.14-rc3, v5.14-rc2, v5.14-rc1, v5.13, v5.13-rc7, v5.13-rc6, v5.13-rc5, v5.13-rc4, v5.13-rc3, v5.13-rc2, v5.13-rc1, v5.12, v5.12-rc8, v5.12-rc7, v5.12-rc6, v5.12-rc5, v5.12-rc4, v5.12-rc3, v5.12-rc2, v5.12-rc1, v5.12-rc1-dontuse, v5.11, v5.11-rc7, v5.11-rc6, v5.11-rc5, v5.11-rc4, v5.11-rc3, v5.11-rc2, v5.11-rc1, v5.10, v5.10-rc7, v5.10-rc6, v5.10-rc5, v5.10-rc4, v5.10-rc3, v5.10-rc2, v5.10-rc1, v5.9, v5.9-rc8, v5.9-rc7 |
|
| #
d2c18c0d |
| 24-Sep-2020 |
Hanjun Guo <[email protected]> |
ACPI: container: Remove leftover ACPICA debug functionality
After commit 737f1a9f8082 ("ACPI / scan: Make container driver use struct acpi_scan_handler"), ACPICA debug print function calls were remo
ACPI: container: Remove leftover ACPICA debug functionality
After commit 737f1a9f8082 ("ACPI / scan: Make container driver use struct acpi_scan_handler"), ACPICA debug print function calls were removed, so the leftover ACPICA debug functionality is useless, remove it.
Signed-off-by: Hanjun Guo <[email protected]> [ rjw: Subject edit ] Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
|
Revision tags: v5.9-rc6, v5.9-rc5, v5.9-rc4, v5.9-rc3, v5.9-rc2, v5.9-rc1, v5.8, v5.8-rc7, v5.8-rc6, v5.8-rc5, v5.8-rc4, v5.8-rc3, v5.8-rc2, v5.8-rc1, v5.7, v5.7-rc7, v5.7-rc6, v5.7-rc5, v5.7-rc4, v5.7-rc3, v5.7-rc2, v5.7-rc1, v5.6, v5.6-rc7, v5.6-rc6, v5.6-rc5, v5.6-rc4, v5.6-rc3, v5.6-rc2, v5.6-rc1, v5.5, v5.5-rc7, v5.5-rc6, v5.5-rc5, v5.5-rc4, v5.5-rc3, v5.5-rc2, v5.5-rc1, v5.4, v5.4-rc8, v5.4-rc7, v5.4-rc6, v5.4-rc5, v5.4-rc4, v5.4-rc3, v5.4-rc2, v5.4-rc1, v5.3, v5.3-rc8, v5.3-rc7, v5.3-rc6, v5.3-rc5, v5.3-rc4, v5.3-rc3, v5.3-rc2, v5.3-rc1, v5.2, v5.2-rc7, v5.2-rc6, v5.2-rc5, v5.2-rc4, v5.2-rc3 |
|
| #
c942fddf |
| 27-May-2019 |
Thomas Gleixner <[email protected]> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 157
Based on 3 normalized pattern(s):
this program is free software you can redistribute it and or modify it under the terms of th
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 157
Based on 3 normalized pattern(s):
this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details
this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version [author] [kishon] [vijay] [abraham] [i] [kishon]@[ti] [com] this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details
this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version [author] [graeme] [gregory] [gg]@[slimlogic] [co] [uk] [author] [kishon] [vijay] [abraham] [i] [kishon]@[ti] [com] [based] [on] [twl6030]_[usb] [c] [author] [hema] [hk] [hemahk]@[ti] [com] this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 1105 file(s).
Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Allison Randal <[email protected]> Reviewed-by: Richard Fontana <[email protected]> Reviewed-by: Kate Stewart <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
|
Revision tags: v5.2-rc2, v5.2-rc1, v5.1, v5.1-rc7, v5.1-rc6, v5.1-rc5, v5.1-rc4, v5.1-rc3, v5.1-rc2, v5.1-rc1, v5.0, v5.0-rc8, v5.0-rc7, v5.0-rc6, v5.0-rc5, v5.0-rc4, v5.0-rc3, v5.0-rc2, v5.0-rc1, v4.20, v4.20-rc7, v4.20-rc6, v4.20-rc5, v4.20-rc4, v4.20-rc3, v4.20-rc2, v4.20-rc1, v4.19, v4.19-rc8, v4.19-rc7, v4.19-rc6, v4.19-rc5, v4.19-rc4, v4.19-rc3, v4.19-rc2, v4.19-rc1, v4.18, v4.18-rc8, v4.18-rc7, v4.18-rc6, v4.18-rc5, v4.18-rc4, v4.18-rc3, v4.18-rc2, v4.18-rc1, v4.17, v4.17-rc7, v4.17-rc6, v4.17-rc5, v4.17-rc4, v4.17-rc3, v4.17-rc2, v4.17-rc1, v4.16, v4.16-rc7, v4.16-rc6, v4.16-rc5, v4.16-rc4, v4.16-rc3, v4.16-rc2, v4.16-rc1, v4.15, v4.15-rc9, v4.15-rc8, v4.15-rc7, v4.15-rc6, v4.15-rc5, v4.15-rc4, v4.15-rc3, v4.15-rc2, v4.15-rc1, v4.14, v4.14-rc8, v4.14-rc7, v4.14-rc6, v4.14-rc5, v4.14-rc4, v4.14-rc3, v4.14-rc2, v4.14-rc1, v4.13, v4.13-rc7, v4.13-rc6, v4.13-rc5, v4.13-rc4, v4.13-rc3, v4.13-rc2, v4.13-rc1, v4.12, v4.12-rc7, v4.12-rc6, v4.12-rc5, v4.12-rc4, v4.12-rc3, v4.12-rc2, v4.12-rc1, v4.11, v4.11-rc8, v4.11-rc7, v4.11-rc6, v4.11-rc5, v4.11-rc4, v4.11-rc3, v4.11-rc2, v4.11-rc1, v4.10, v4.10-rc8, v4.10-rc7, v4.10-rc6, v4.10-rc5, v4.10-rc4, v4.10-rc3, v4.10-rc2, v4.10-rc1, v4.9, v4.9-rc8, v4.9-rc7, v4.9-rc6, v4.9-rc5, v4.9-rc4, v4.9-rc3, v4.9-rc2, v4.9-rc1, v4.8, v4.8-rc8, v4.8-rc7, v4.8-rc6, v4.8-rc5, v4.8-rc4, v4.8-rc3, v4.8-rc2, v4.8-rc1, v4.7, v4.7-rc7, v4.7-rc6, v4.7-rc5, v4.7-rc4, v4.7-rc3, v4.7-rc2, v4.7-rc1, v4.6, v4.6-rc7, v4.6-rc6, v4.6-rc5, v4.6-rc4, v4.6-rc3, v4.6-rc2, v4.6-rc1, v4.5, v4.5-rc7, v4.5-rc6, v4.5-rc5, v4.5-rc4, v4.5-rc3, v4.5-rc2, v4.5-rc1, v4.4, v4.4-rc8, v4.4-rc7, v4.4-rc6, v4.4-rc5, v4.4-rc4, v4.4-rc3, v4.4-rc2, v4.4-rc1, v4.3, v4.3-rc7, v4.3-rc6, v4.3-rc5, v4.3-rc4, v4.3-rc3, v4.3-rc2, v4.3-rc1, v4.2, v4.2-rc8, v4.2-rc7, v4.2-rc6, v4.2-rc5, v4.2-rc4, v4.2-rc3, v4.2-rc2, v4.2-rc1 |
|
| #
4c62dbbc |
| 26-Jun-2015 |
Jarkko Nikula <[email protected]> |
ACPI: Remove FSF mailing addresses
There is no need to carry potentially outdated Free Software Foundation mailing address in file headers since the COPYING file includes it.
Signed-off-by: Jarkko
ACPI: Remove FSF mailing addresses
There is no need to carry potentially outdated Free Software Foundation mailing address in file headers since the COPYING file includes it.
Signed-off-by: Jarkko Nikula <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
|
Revision tags: v4.1, v4.1-rc8, v4.1-rc7, v4.1-rc6, v4.1-rc5, v4.1-rc4, v4.1-rc3, v4.1-rc2, v4.1-rc1, v4.0, v4.0-rc7, v4.0-rc6, v4.0-rc5, v4.0-rc4, v4.0-rc3, v4.0-rc2, v4.0-rc1, v3.19, v3.19-rc7, v3.19-rc6, v3.19-rc5, v3.19-rc4, v3.19-rc3, v3.19-rc2, v3.19-rc1, v3.18, v3.18-rc7, v3.18-rc6, v3.18-rc5, v3.18-rc4, v3.18-rc3, v3.18-rc2, v3.18-rc1, v3.17, v3.17-rc7, v3.17-rc6 |
|
| #
8ab17fc9 |
| 21-Sep-2014 |
Rafael J. Wysocki <[email protected]> |
ACPI / hotplug: Generate online uevents for ACPI containers
Commit 46394fd01 (ACPI / hotplug: Move container-specific code out of the core) removed the generation of "online" uevents for containers,
ACPI / hotplug: Generate online uevents for ACPI containers
Commit 46394fd01 (ACPI / hotplug: Move container-specific code out of the core) removed the generation of "online" uevents for containers, because "add" uevents are now generated for them automatically when container system devices are registered. However, there are user space tools that need to be notified when the container and all of its children have been enumerated, which doesn't happen any more.
For this reason, add a mechanism allowing "online" uevents to be generated for ACPI containers after enumerating the container along with all of its children.
Fixes: 46394fd01 (ACPI / hotplug: Move container-specific code out of the core) Reported-and-tested-by: Yasuaki Ishimatsu <[email protected]> Cc: 3.14+ <[email protected]> # 3.14+ Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
|
Revision tags: v3.17-rc5, v3.17-rc4, v3.17-rc3, v3.17-rc2, v3.17-rc1, v3.16, v3.16-rc7, v3.16-rc6, v3.16-rc5, v3.16-rc4, v3.16-rc3, v3.16-rc2, v3.16-rc1, v3.15, v3.15-rc8 |
|
| #
a1ec6572 |
| 30-May-2014 |
Rafael J. Wysocki <[email protected]> |
ACPI / scan: always register container scan handler
Prevent platform devices from being created for ACPI containers if CONFIG_ACPI_CONTAINER is unset by compiling out the container scan handler's ca
ACPI / scan: always register container scan handler
Prevent platform devices from being created for ACPI containers if CONFIG_ACPI_CONTAINER is unset by compiling out the container scan handler's callbacks only in that case and still compiling its device ID list in and registering the scan handler in either case.
This change is based on a prototype from Zhang Rui.
Signed-off-by: Rafael J. Wysocki <[email protected]> Reviewed-by: Mika Westerberg <[email protected]>
show more ...
|
|
Revision tags: v3.15-rc7, v3.15-rc6, v3.15-rc5, v3.15-rc4, v3.15-rc3, v3.15-rc2, v3.15-rc1, v3.14, v3.14-rc8, v3.14-rc7 |
|
| #
07070e12 |
| 13-Mar-2014 |
Hanjun Guo <[email protected]> |
ACPI: Remove duplicate definitions of PREFIX
We already have a macro for PREFIX of "ACPI: " in drivers/acpi/internal.h, so remove the duplicate ones in ACPI drivers when internal.h is included.
Sig
ACPI: Remove duplicate definitions of PREFIX
We already have a macro for PREFIX of "ACPI: " in drivers/acpi/internal.h, so remove the duplicate ones in ACPI drivers when internal.h is included.
Signed-off-by: Hanjun Guo <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
|
Revision tags: v3.14-rc6, v3.14-rc5, v3.14-rc4, v3.14-rc3 |
|
| #
1e2380cd |
| 16-Feb-2014 |
Rafael J. Wysocki <[email protected]> |
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 do
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 <[email protected]>
show more ...
|
| #
0f6aa09e |
| 11-Feb-2014 |
Rafael J. Wysocki <[email protected]> |
ACPI / container: Fix error code path in container_device_attach()
To avoid leaking memory on errors from device_register(), do a put_device() on the device object in question in the error code path
ACPI / container: Fix error code path in container_device_attach()
To avoid leaking memory on errors from device_register(), do a put_device() on the device object in question in the error code path of container_device_attach().
Fixes: caa73ea158de (ACPI / hotplug / driver core: Handle containers in a special way) Signed-off-by: Rafael J. Wysocki <[email protected]> Reviewed-by: Yasuaki Ishimatsu <[email protected]>
show more ...
|
|
Revision tags: v3.14-rc2, v3.14-rc1, v3.13, v3.13-rc8, v3.13-rc7, v3.13-rc6 |
|
| #
caa73ea1 |
| 29-Dec-2013 |
Rafael J. Wysocki <[email protected]> |
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 syst
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 <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
|
Revision tags: v3.13-rc5, v3.13-rc4, v3.13-rc3, v3.13-rc2 |
|
| #
46394fd0 |
| 22-Nov-2013 |
Rafael J. Wysocki <[email protected]> |
ACPI / hotplug: Move container-specific code out of the core
Move container-specific uevents from the core hotplug code to the container scan handler's .attach() and .detach() callbacks.
This way t
ACPI / hotplug: Move container-specific code out of the core
Move container-specific uevents from the core hotplug code to the container scan handler's .attach() and .detach() callbacks.
This way the core will not have to special-case containers and the uevents will be guaranteed to happen every time a container is either scanned or trimmed as appropriate.
Signed-off-by: Rafael J. Wysocki <[email protected]> Tested-by: Mika Westerberg <[email protected]>
show more ...
|
|
Revision tags: v3.13-rc1, v3.12, v3.12-rc7, v3.12-rc6, v3.12-rc5, v3.12-rc4, v3.12-rc3, v3.12-rc2, v3.12-rc1, v3.11, v3.11-rc7, v3.11-rc6, v3.11-rc5, v3.11-rc4, v3.11-rc3, v3.11-rc2, v3.11-rc1, v3.10, v3.10-rc7, v3.10-rc6, v3.10-rc5, v3.10-rc4, v3.10-rc3, v3.10-rc2, v3.10-rc1, v3.9, v3.9-rc8, v3.9-rc7, v3.9-rc6, v3.9-rc5, v3.9-rc4, v3.9-rc3 |
|
| #
2f9b06fc |
| 11-Mar-2013 |
Andy Shevchenko <[email protected]> |
ACPI: suppress compiler warning in container.c
This patch fixes following compiler warning when build via make W=1:
drivers/acpi/container.c:183:116: warning: no previous prototype for ‘acpi_contai
ACPI: suppress compiler warning in container.c
This patch fixes following compiler warning when build via make W=1:
drivers/acpi/container.c:183:116: warning: no previous prototype for ‘acpi_container_init’ [-Wmissing-prototypes]
Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
|
Revision tags: v3.9-rc2, v3.9-rc1 |
|
| #
79917f34 |
| 03-Mar-2013 |
Rafael J. Wysocki <[email protected]> |
ACPI / container: Use hotplug profile user space interface
Make the ACPI container driver register its ACPI scan handler object using acpi_scan_add_handler_with_hotplug() to allow user space to mani
ACPI / container: Use hotplug profile user space interface
Make the ACPI container driver register its ACPI scan handler object using acpi_scan_add_handler_with_hotplug() to allow user space to manipulate its hotplug profile attributes.
Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Toshi Kani <[email protected]> Tested-by: Toshi Kani <[email protected]>
show more ...
|
| #
68a67f6c |
| 03-Mar-2013 |
Rafael J. Wysocki <[email protected]> |
ACPI / container: Use common hotplug code
Switch the ACPI container driver to using common device hotplug code introduced previously. This reduces the driver down to a trivial definition and regist
ACPI / container: Use common hotplug code
Switch the ACPI container driver to using common device hotplug code introduced previously. This reduces the driver down to a trivial definition and registration of a struct acpi_scan_handler object.
Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Toshi Kani <[email protected]> Tested-by: Toshi Kani <[email protected]>
show more ...
|
|
Revision tags: v3.8 |
|
| #
3757b948 |
| 13-Feb-2013 |
Rafael J. Wysocki <[email protected]> |
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 handler
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 <[email protected]> Acked-by: Yinghai Lu <[email protected]>
show more ...
|
| #
87d4a4da |
| 09-Feb-2013 |
Rafael J. Wysocki <[email protected]> |
ACPI: Drop the container.h header file
The include/acpi/container.h only contains a definition of a structure that is not used any more, so drop it entirely.
Similar change was proposed earlier by
ACPI: Drop the container.h header file
The include/acpi/container.h only contains a definition of a structure that is not used any more, so drop it entirely.
Similar change was proposed earlier by Toshi Kani.
Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Toshi Kani <[email protected]>
show more ...
|
| #
737f1a9f |
| 08-Feb-2013 |
Rafael J. Wysocki <[email protected]> |
ACPI / scan: Make container driver use struct acpi_scan_handler
Make the ACPI container driver use struct acpi_scan_handler for representing the object used to initialize ACPI containers and remove
ACPI / scan: Make container driver use struct acpi_scan_handler
Make the ACPI container driver use struct acpi_scan_handler for representing the object used to initialize ACPI containers and remove the ACPI driver structure used previously and the data structures created by it, since in fact they were not used for any purpose.
This simplifies the code and reduces the kernel's memory footprint by avoiding the registration of a struct device_driver object with the driver core and creation of its sysfs directory which is unnecessary.
In addition to that, make the namespace walk callback used for installing the notify handlers for ACPI containers more straightforward.
This change includes fixes from Toshi Kani.
Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Yinghai Lu <[email protected]> Acked-by: Yasuaki Ishimatsu <[email protected]> Tested-by: Yasuaki Ishimatsu <[email protected]> Reviewed-by: Toshi Kani <[email protected]> Tested-by: Toshi Kani <[email protected]>
show more ...
|
|
Revision tags: v3.8-rc7, v3.8-rc6, v3.8-rc5 |
|
| #
51fac838 |
| 23-Jan-2013 |
Rafael J. Wysocki <[email protected]> |
ACPI: Remove useless type argument of driver .remove() operation
The second argument of ACPI driver .remove() operation is only used by the ACPI processor driver and the value passed to that driver
ACPI: Remove useless type argument of driver .remove() operation
The second argument of ACPI driver .remove() operation is only used by the ACPI processor driver and the value passed to that driver through it is always available from the given struct acpi_device object's removal_type field. For this reason, the second ACPI driver .remove() argument is in fact useless, so drop it.
Signed-off-by: Rafael J. Wysocki <[email protected]> Reviewed-by: Jiang Liu <[email protected]> Acked-by: Toshi Kani <[email protected]> Acked-by: Yinghai Lu <[email protected]>
show more ...
|
| #
b8bd759a |
| 19-Jan-2013 |
Rafael J. Wysocki <[email protected]> |
ACPI / scan: Drop acpi_bus_add() and use acpi_bus_scan() instead
The only difference between acpi_bus_scan() and acpi_bus_add() is the invocation of acpi_update_all_gpes() in the latter which in fac
ACPI / scan: Drop acpi_bus_add() and use acpi_bus_scan() instead
The only difference between acpi_bus_scan() and acpi_bus_add() is the invocation of acpi_update_all_gpes() in the latter which in fact is unnecessary, because acpi_update_all_gpes() has already been called by acpi_scan_init() and the way it is implemented guarantees the next invocations of it to do nothing.
For this reason, drop acpi_bus_add() and make all its callers use acpi_bus_scan() directly instead of it. Additionally, rearrange the code in acpi_scan_init() slightly to improve the visibility of the acpi_update_all_gpes() call in there.
Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Yinghai Lu <[email protected]>
show more ...
|
|
Revision tags: v3.8-rc4, v3.8-rc3, v3.8-rc2, v3.8-rc1 |
|
| #
0cd6ac52 |
| 20-Dec-2012 |
Rafael J. Wysocki <[email protected]> |
ACPI: Make acpi_bus_scan() and acpi_bus_add() take only one argument
The callers of acpi_bus_add() usually assume that if it has succeeded, then a struct acpi_device object has been attached to the
ACPI: Make acpi_bus_scan() and acpi_bus_add() take only one argument
The callers of acpi_bus_add() usually assume that if it has succeeded, then a struct acpi_device object has been attached to the handle passed as the first argument. Unfortunately, however, this assumption is wrong, because acpi_bus_scan(), and acpi_bus_add() too as a result, may return a pointer to a different struct acpi_device object on success (it may be an object corresponding to one of the descendant ACPI nodes in the namespace scope below that handle).
For this reason, the callers of acpi_bus_add() who care about whether or not a struct acpi_device object has been created for its first argument need to check that using acpi_bus_get_device() anyway, so the second argument of acpi_bus_add() is not really useful for them. The same observation applies to acpi_bus_scan() executed directly from acpi_scan_init().
Therefore modify the relevant callers of acpi_bus_add() to check the existence of the struct acpi_device in question with the help of acpi_bus_get_device() and drop the no longer necessary second argument of acpi_bus_add(). Accordingly, modify acpi_scan_init() to use acpi_bus_get_device() to get acpi_root and drop the no longer needed second argument of acpi_bus_scan().
Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Yinghai Lu <[email protected]> Acked-by: Toshi Kani <[email protected]>
show more ...
|
| #
636458de |
| 20-Dec-2012 |
Rafael J. Wysocki <[email protected]> |
ACPI: Remove the arguments of acpi_bus_add() that are not used
Notice that acpi_bus_add() uses only 2 of its 4 arguments and redefine its header to match the body. Update all of its callers as nece
ACPI: Remove the arguments of acpi_bus_add() that are not used
Notice that acpi_bus_add() uses only 2 of its 4 arguments and redefine its header to match the body. Update all of its callers as necessary and observe that this leads to quite a number of removed lines of code (Linus will like that).
Add a kerneldoc comment documenting acpi_bus_add() and wonder how its callers make wrong assumptions about the second argument (make note to self to take care of that later).
Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Yinghai Lu <[email protected]> Acked-by: Toshi Kani <[email protected]>
show more ...
|
| #
02f57c67 |
| 20-Dec-2012 |
Rafael J. Wysocki <[email protected]> |
ACPI: Remove acpi_start_single_object() and acpi_bus_start()
The ACPI PCI root bridge driver was the only ACPI driver implementing the .start() callback, which isn't used by any ACPI drivers any mor
ACPI: Remove acpi_start_single_object() and acpi_bus_start()
The ACPI PCI root bridge driver was the only ACPI driver implementing the .start() callback, which isn't used by any ACPI drivers any more now.
For this reason, acpi_start_single_object() has no purpose any more, so remove it and all references to it. Also remove acpi_bus_start_device(), whose only purpose was to call acpi_start_single_object().
Moreover, since after the removal of acpi_bus_start_device() the only purpose of acpi_bus_start() remains to call acpi_update_all_gpes(), move that into acpi_bus_add() and drop acpi_bus_start() too, remove its header from acpi_bus.h and update all of its former users accordingly.
This change was previously proposed in a different from by Yinghai Lu.
Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Yinghai Lu <[email protected]> Acked-by: Toshi Kani <[email protected]>
show more ...
|
|
Revision tags: v3.7, v3.7-rc8, v3.7-rc7 |
|
| #
3d78bd9e |
| 20-Nov-2012 |
Toshi Kani <[email protected]> |
ACPI: Update Container hotplug error messages
Updated Container hotplug error messages with acpi_handle_<level>() and pr_<level>(). Removed an unnecessary check to the device arg in acpi_container_
ACPI: Update Container hotplug error messages
Updated Container hotplug error messages with acpi_handle_<level>() and pr_<level>(). Removed an unnecessary check to the device arg in acpi_container_add().
Signed-off-by: Toshi Kani <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
|
Revision tags: v3.7-rc6, v3.7-rc5, v3.7-rc4, v3.7-rc3 |
|
| #
594df89a |
| 26-Oct-2012 |
Tang Chen <[email protected]> |
ACPI: Fix a hard coding style when determining if a device is a container, v3
"ACPI0004","PNP0A05" and "PNP0A06" are all defined in array container_device_ids[], so use it, but not the hard coding s
ACPI: Fix a hard coding style when determining if a device is a container, v3
"ACPI0004","PNP0A05" and "PNP0A06" are all defined in array container_device_ids[], so use it, but not the hard coding style.
Also, introduce a new API is_container_device() to determine if a device is a container device.
Signed-off-by: Tang Chen <[email protected]> Signed-off-by: Yasuaki Ishimatsu <[email protected]> Reviewed-by: Bjorn Helgaas <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
|
Revision tags: v3.7-rc2, v3.7-rc1, v3.6, v3.6-rc7, v3.6-rc6, v3.6-rc5, v3.6-rc4, v3.6-rc3, v3.6-rc2, v3.6-rc1, v3.5, v3.5-rc7, v3.5-rc6, v3.5-rc5, v3.5-rc4, v3.5-rc3, v3.5-rc2, v3.5-rc1 |
|
| #
0c67dc24 |
| 24-May-2012 |
Toshi Kani <[email protected]> |
ACPI: Add _OST support for ACPI container hotplug
Changed container_notify_cb() to call ACPI _OST method when ACPI container hotplug operation has completed. Slightly restructured the code with the
ACPI: Add _OST support for ACPI container hotplug
Changed container_notify_cb() to call ACPI _OST method when ACPI container hotplug operation has completed. Slightly restructured the code with the same logic. The function sets eject_pending bit for an eject request since it does not initiate hot-remove operation. This bit is checked by the sysfs eject handler to determine if the request is originated from an ACPI eject notification.
Signed-off-by: Toshi Kani <[email protected]> Signed-off-by: Len Brown <[email protected]>
show more ...
|