diff options
author | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2013-11-07 01:45:40 +0100 |
---|---|---|
committer | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2013-11-07 19:28:48 +0100 |
commit | 7b98118aaa5d75644c48f41fc5d0cc181e478383 (patch) | |
tree | 9ab1e04ce0ee5ce816d744e50db1a3e2ba607575 /drivers/acpi/pci_root.c | |
parent | 176a88d79d6b5aebabaff16734e8b3107efcaaad (diff) | |
download | blackbird-op-linux-7b98118aaa5d75644c48f41fc5d0cc181e478383.tar.gz blackbird-op-linux-7b98118aaa5d75644c48f41fc5d0cc181e478383.zip |
ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routines
There are two different interfaces for queuing up work items on the
ACPI hotplug workqueue, alloc_acpi_hp_work() used by PCI and PCI host
bridge hotplug code and acpi_os_hotplug_execute() used by the common
ACPI hotplug code and docking stations. They both are somewhat
cumbersome to use and work slightly differently.
The users of alloc_acpi_hp_work() have to submit a work function that
will extract the necessary data items from a struct acpi_hp_work
object allocated by alloc_acpi_hp_work() and then will free that
object, while it would be more straightforward to simply use a work
function with one more argument and let the interface take care of
the execution details.
The users of acpi_os_hotplug_execute() also have to deal with the
fact that it takes only one argument in addition to the work function
pointer, although acpi_os_execute_deferred() actually takes care of
the allocation and freeing of memory, so it would have been able to
pass more arguments to the work function if it hadn't been
constrained by the connection with acpi_os_execute().
Moreover, while alloc_acpi_hp_work() makes GFP_KERNEL memory
allocations, which is correct, because hotplug work items are
always queued up from process context, acpi_os_hotplug_execute()
uses GFP_ATOMIC, as that is needed by acpi_os_execute(). Also,
acpi_os_execute_deferred() queued up by it waits for the ACPI event
workqueues to flush before executing the work function, whereas
alloc_acpi_hp_work() can't do anything similar. That leads to
somewhat arbitrary differences in behavior between various ACPI
hotplug code paths and has to be straightened up.
For this reason, replace both alloc_acpi_hp_work() and
acpi_os_hotplug_execute() with a single interface,
acpi_hotplug_execute(), combining their behavior and being more
friendly to its users than any of the two.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Diffstat (limited to 'drivers/acpi/pci_root.c')
-rw-r--r-- | drivers/acpi/pci_root.c | 14 |
1 files changed, 3 insertions, 11 deletions
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c index d77f0bf7eda0..417876bce854 100644 --- a/drivers/acpi/pci_root.c +++ b/drivers/acpi/pci_root.c @@ -592,17 +592,10 @@ static void handle_root_bridge_insertion(acpi_handle handle) acpi_handle_err(handle, "cannot add bridge to acpi list\n"); } -static void _handle_hotplug_event_root(struct work_struct *work) +static void hotplug_event_root(void *data, u32 type) { + acpi_handle handle = data; struct acpi_pci_root *root; - struct acpi_hp_work *hp_work; - acpi_handle handle; - u32 type; - - hp_work = container_of(work, struct acpi_hp_work, work); - handle = hp_work->handle; - type = hp_work->type; - kfree(hp_work); /* allocated in handle_hotplug_event_bridge */ acpi_scan_lock_acquire(); @@ -654,8 +647,7 @@ static void _handle_hotplug_event_root(struct work_struct *work) static void handle_hotplug_event_root(acpi_handle handle, u32 type, void *context) { - alloc_acpi_hp_work(handle, type, context, - _handle_hotplug_event_root); + acpi_hotplug_execute(hotplug_event_root, handle, type); } static acpi_status __init |