From 7b98118aaa5d75644c48f41fc5d0cc181e478383 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Thu, 7 Nov 2013 01:45:40 +0100 Subject: 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 Tested-by: Mika Westerberg --- drivers/pci/hotplug/acpiphp_glue.c | 18 +++++++----------- 1 file changed, 7 insertions(+), 11 deletions(-) (limited to 'drivers/pci/hotplug/acpiphp_glue.c') diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplug/acpiphp_glue.c index 0b7d23b4ad9..5246ba29747 100644 --- a/drivers/pci/hotplug/acpiphp_glue.c +++ b/drivers/pci/hotplug/acpiphp_glue.c @@ -875,21 +875,17 @@ static void hotplug_event(acpi_handle handle, u32 type, void *data) put_bridge(bridge); } -static void hotplug_event_work(struct work_struct *work) +static void hotplug_event_work(void *data, u32 type) { - struct acpiphp_context *context; - struct acpi_hp_work *hp_work; + struct acpiphp_context *context = data; + acpi_handle handle = context->handle; - hp_work = container_of(work, struct acpi_hp_work, work); - context = hp_work->context; acpi_scan_lock_acquire(); - hotplug_event(hp_work->handle, hp_work->type, context); + hotplug_event(handle, type, context); acpi_scan_lock_release(); - acpi_evaluate_hotplug_ost(hp_work->handle, hp_work->type, - ACPI_OST_SC_SUCCESS, NULL); - kfree(hp_work); /* allocated in handle_hotplug_event() */ + acpi_evaluate_hotplug_ost(handle, type, ACPI_OST_SC_SUCCESS, NULL); put_bridge(context->func.parent); } @@ -940,10 +936,10 @@ static void handle_hotplug_event(acpi_handle handle, u32 type, void *data) mutex_lock(&acpiphp_context_lock); context = acpiphp_get_context(handle); - if (context) { + if (context && !WARN_ON(context->handle != handle)) { get_bridge(context->func.parent); acpiphp_put_context(context); - alloc_acpi_hp_work(handle, type, context, hotplug_event_work); + acpi_hotplug_execute(hotplug_event_work, context, type); mutex_unlock(&acpiphp_context_lock); return; } -- cgit v1.2.3-70-g09d2