]>
Commit | Line | Data |
---|---|---|
bf9ffb20 GKH |
1 | From 3afcf2ece453e1a8c2c6de19cdf06da3772a1b08 Mon Sep 17 00:00:00 2001 |
2 | From: Lv Zheng <lv.zheng@intel.com> | |
3 | Date: Thu, 21 Aug 2014 14:41:13 +0800 | |
4 | Subject: ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set | |
5 | ||
6 | From: Lv Zheng <lv.zheng@intel.com> | |
7 | ||
8 | commit 3afcf2ece453e1a8c2c6de19cdf06da3772a1b08 upstream. | |
9 | ||
10 | There is a platform refusing to respond QR_EC when SCI_EVT isn't set | |
11 | (Acer Aspire V5-573G). | |
12 | ||
13 | Currently, we rely on the behaviour that the EC firmware can respond | |
14 | something (for example, 0x00 to indicate "no outstanding events") to | |
15 | QR_EC even when SCI_EVT is not set, but the reporter has complained | |
16 | about AC/battery pluging/unpluging and video brightness change delay | |
17 | on that platform. | |
18 | ||
19 | This is because the work item that has issued QR_EC has to wait until | |
20 | timeout in this case, and the _Qxx method evaluation work item queued | |
21 | after QR_EC one is delayed. | |
22 | ||
23 | It sounds reasonable to fix this issue by: | |
24 | 1. Implementing SCI_EVT sanity check before issuing QR_EC in the EC | |
25 | driver's main state machine. | |
26 | 2. Moving QR_EC issuing out of the work queue used by _Qxx evaluation | |
27 | to a seperate IRQ handling thread. | |
28 | ||
29 | This patch fixes this issue using solution 1. | |
30 | ||
31 | By disallowing QR_EC to be issued when SCI_EVT isn't set, we are able to | |
32 | handle such platform in the EC driver's main state machine. This patch | |
33 | enhances the state machine in this way to survive with such malfunctioning | |
34 | EC firmware. | |
35 | ||
36 | Note that this patch can also fix CLEAR_ON_RESUME quirk which also relies | |
37 | on the assumption that the platforms are able to respond even when SCI_EVT | |
38 | isn't set. | |
39 | ||
40 | Fixes: c0d653412fc8 ACPI / EC: Fix race condition in ec_transaction_completed() | |
41 | Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611 | |
42 | Reported-and-tested-by: Alexander Mezin <mezin.alexander@gmail.com> | |
43 | Signed-off-by: Lv Zheng <lv.zheng@intel.com> | |
44 | Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> | |
45 | Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | |
46 | ||
47 | --- | |
48 | drivers/acpi/ec.c | 17 ++++++++++++++++- | |
49 | 1 file changed, 16 insertions(+), 1 deletion(-) | |
50 | ||
51 | --- a/drivers/acpi/ec.c | |
52 | +++ b/drivers/acpi/ec.c | |
53 | @@ -197,6 +197,8 @@ static bool advance_transaction(struct a | |
54 | t->rdata[t->ri++] = acpi_ec_read_data(ec); | |
55 | if (t->rlen == t->ri) { | |
56 | t->flags |= ACPI_EC_COMMAND_COMPLETE; | |
57 | + if (t->command == ACPI_EC_COMMAND_QUERY) | |
58 | + pr_debug("hardware QR_EC completion\n"); | |
59 | wakeup = true; | |
60 | } | |
61 | } else | |
62 | @@ -208,7 +210,20 @@ static bool advance_transaction(struct a | |
63 | } | |
64 | return wakeup; | |
65 | } else { | |
66 | - if ((status & ACPI_EC_FLAG_IBF) == 0) { | |
67 | + /* | |
68 | + * There is firmware refusing to respond QR_EC when SCI_EVT | |
69 | + * is not set, for which case, we complete the QR_EC | |
70 | + * without issuing it to the firmware. | |
71 | + * https://bugzilla.kernel.org/show_bug.cgi?id=86211 | |
72 | + */ | |
73 | + if (!(status & ACPI_EC_FLAG_SCI) && | |
74 | + (t->command == ACPI_EC_COMMAND_QUERY)) { | |
75 | + t->flags |= ACPI_EC_COMMAND_POLL; | |
76 | + t->rdata[t->ri++] = 0x00; | |
77 | + t->flags |= ACPI_EC_COMMAND_COMPLETE; | |
78 | + pr_debug("software QR_EC completion\n"); | |
79 | + wakeup = true; | |
80 | + } else if ((status & ACPI_EC_FLAG_IBF) == 0) { | |
81 | acpi_ec_write_cmd(ec, t->command); | |
82 | t->flags |= ACPI_EC_COMMAND_POLL; | |
83 | } else |