[RFC PATCH] ACPI / EC: Fix an issue caused by the serialized _Qxx evaluations.

[Lv Zheng]

It is proven that Windows evaluates _Qxx handlers in a parallel way. This
patch follows this fact, changes _Qxx evaluations to be queued up on the
NOTIFY queue as its behavior is proven to be quite different from the
_Lxx/_Exx handlers, and convert the NOTIFY queue into the parallel style.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=94411
Reported-and-tested-by: Gabriele Mazzotta <gabriele.mzt@xxxxxxxxx>
Signed-off-by: Lv Zheng <lv.zheng@xxxxxxxxx>
---
 drivers/acpi/ec.c  |    5 ++---
 drivers/acpi/osl.c |   20 ++++++++++----------
 2 files changed, 12 insertions(+), 13 deletions(-)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 9d4761d..30f582f 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -1023,9 +1023,8 @@ static int acpi_ec_query(struct acpi_ec *ec, u8 *data)
 			handler = acpi_ec_get_query_handler(handler);
 			ec_dbg_evt("Query(0x%02x) scheduled",
 				   handler->query_bit);
-			status = acpi_os_execute((handler->func) ?
-				OSL_NOTIFY_HANDLER : OSL_GPE_HANDLER,
-				acpi_ec_run, handler);
+			status = acpi_os_execute(OSL_NOTIFY_HANDLER,
+						 acpi_ec_run, handler);
 			if (ACPI_FAILURE(status))
 				result = -EBUSY;
 			break;
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index db14a66..c354754 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -1159,20 +1159,20 @@ acpi_status acpi_os_execute(acpi_execute_type type,
 	if (type == OSL_NOTIFY_HANDLER) {
 		queue = kacpi_notify_wq;
 		INIT_WORK(&dpc->work, acpi_os_execute_deferred);
+		ret = queue_work(queue, &dpc->work);
 	} else {
 		queue = kacpid_wq;
 		INIT_WORK(&dpc->work, acpi_os_execute_deferred);
+		/*
+		 * On some machines, a software-initiated SMI causes
+		 * corruption unless the SMI runs on CPU 0.  An SMI can be
+		 * initiated by any AML, but typically it's done in
+		 * GPE-related methods that are run via workqueues, so we
+		 * can avoid the known corruption cases by always queueing
+		 * on CPU 0.
+		 */
+		ret = queue_work_on(0, queue, &dpc->work);
 	}
-
-	/*
-	 * On some machines, a software-initiated SMI causes corruption unless
-	 * the SMI runs on CPU 0.  An SMI can be initiated by any AML, but
-	 * typically it's done in GPE-related methods that are run via
-	 * workqueues, so we can avoid the known corruption cases by always
-	 * queueing on CPU 0.
-	 */
-	ret = queue_work_on(0, queue, &dpc->work);
-
 	if (!ret) {
 		printk(KERN_ERR PREFIX
 			  "Call to queue_work() failed.\n");
-- 
1.7.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/