kernel.git/drivers/acpi/ec.c, branch linux-5.19.y

ACPI: EC: Drop the EC_FLAGS_IGNORE_DSDT_GPE quirk

2022-08-17T13:14:04Z

[ Upstream commit f7090e0ef360d674f08a22fab90e4e209fb1f658 ] It seems that these quirks are no longer necessary since commit 69b957c26b32 ("ACPI: EC: Fix possible issues related to EC initialization order"), which has fixed this in a generic manner. There are 3 commits adding DMI entries with this quirk (adding multiple DMI entries per commit). 2/3 commits are from before the generic fix. Which leaves commit 6306f0431914 ("ACPI: EC: Make more Asus laptops use ECDT _GPE"), which was committed way after the generic fix. But this was just due to slow upstreaming of it. This commit stems from Endless from 15 Aug 2017 (committed upstream 20 May 2021): https://github.com/endlessm/linux/pull/288 The current code should work fine without this: 1. The EC_FLAGS_IGNORE_DSDT_GPE flag is only checked in ec_parse_device(), like this: if (boot_ec && boot_ec_is_ecdt && EC_FLAGS_IGNORE_DSDT_GPE) { ec->gpe = boot_ec->gpe; } else { /* parse GPE */ } 2. ec_parse_device() is only called from acpi_ec_add() and acpi_ec_dsdt_probe() 3. acpi_ec_dsdt_probe() starts with: if (boot_ec) return; so it only calls ec_parse_device() when boot_ec == NULL, meaning that the quirk never triggers for this call. So only the call in acpi_ec_add() matters. 4. acpi_ec_add() does the following after the ec_parse_device() call: if (boot_ec && ec->command_addr == boot_ec->command_addr && ec->data_addr == boot_ec->data_addr && !EC_FLAGS_TRUST_DSDT_GPE) { /* * Trust PNP0C09 namespace location rather than * ECDT ID. But trust ECDT GPE rather than _GPE * because of ASUS quirks, so do not change * boot_ec->gpe to ec->gpe. */ boot_ec->handle = ec->handle; acpi_handle_debug(ec->handle, "duplicated.\n"); acpi_ec_free(ec); ec = boot_ec; } The quirk only matters if boot_ec != NULL and EC_FLAGS_TRUST_DSDT_GPE is never set at the same time as EC_FLAGS_IGNORE_DSDT_GPE. That means that if the addresses match we always enter this if block and then only the ec->handle part of the data stored in ec by ec_parse_device() is used and the rest is thrown away, after which ec is made to point to boot_ec, at which point ec->gpe == boot_ec->gpe, so the same result as with the quirk set, independent of the value of the quirk. Also note the comment in this block which indicates that the gpe result from ec_parse_device() is deliberately not taken to deal with buggy Asus laptops and all DMI quirks setting EC_FLAGS_IGNORE_DSDT_GPE are for Asus laptops. Based on the above I believe that unless on some quirked laptops the ECDT and DSDT EC addresses do not match we can drop the quirk. I've checked dmesg output to ensure the ECDT and DSDT EC addresses match for quirked models using https://linux-hardware.org hw-probe reports. I've been able to confirm that the addresses match for the following models this way: GL702VMK, X505BA, X505BP, X550VXK, X580VD. Whereas for the following models I could find any dmesg output: FX502VD, FX502VE, X542BA, X542BP. Note the models without dmesg all were submitted in patches with a batch of models and other models from the same batch checkout ok. This, combined with that all the code adding the quirks was written before the generic fix makes me believe that it is safe to remove this quirk now. Signed-off-by: Hans de Goede Reviewed-by: Daniel Drake Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: EC: Remove duplicate ThinkPad X1 Carbon 6th entry from DMI quirks

2022-08-17T13:14:04Z

[ Upstream commit 0dd6db359e5f206cbf1dd1fd40dd211588cd2725 ] Somehow the "ThinkPad X1 Carbon 6th" entry ended up twice in the struct dmi_system_id acpi_ec_no_wakeup[] array. Remove one of the entries. Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: EC: Rearrange code in acpi_ec_submit_event()

2022-02-14T19:14:40Z

Rearange acpi_ec_event_handler() so as to avoid releasing ec->lock and acquiring it again right away in the case when ec_event_clearing is not ACPI_EC_EVT_TIMING_EVENT. This also reduces the number of checks done by acpi_ec_event_handler() in that case. Signed-off-by: Rafael J. Wysocki

ACPI: EC: Reduce indentation level in acpi_ec_submit_event()

2022-02-14T19:14:40Z

The indentation level in acpi_ec_submit_event() can be reduced, so do that and while at it fix a typo in the comment affected by that change. No intentional functional impact. Signed-off-by: Rafael J. Wysocki

ACPI: EC: Do not return result from advance_transaction()

2022-02-14T19:14:40Z

Notice that the if the event state is EC_EVENT_READY, the event handling work cannot be pending, so it is not necessary to check the return value of queue_work() in acpi_ec_submit_event(). Moreover, whether or not there is any EC work pending at the moment can always be checked by looking at the events_in_progress and queries_in_progress counters, so acpi_ec_submit_event() and consequently advance_transaction() need not return results. Accordingly, make acpi_ec_dispatch_gpe() always use the counters mentioned above (for first_ec) to check if there is any pending EC work to flush and turn both acpi_ec_submit_event() and advance_transaction() into void functions (again, because they were void functions in the past). While at it, add a clarifying comment about the acpi_ec_mask_events() call in advance_transaction(). Signed-off-by: Rafael J. Wysocki

ACPI: EC / PM: Print additional debug message in acpi_ec_dispatch_gpe()

2022-02-14T18:41:11Z

Make acpi_ec_dispatch_gpe() print an additional debug message after seeing the EC GPE status bit set to help diagnose wakeup-related issues. Signed-off-by: Rafael J. Wysocki

ACPI: PM: s2idle: Cancel wakeup before dispatching EC GPE

2022-02-07T20:02:31Z

Commit 4a9af6cac050 ("ACPI: EC: Rework flushing of EC work while suspended to idle") made acpi_ec_dispatch_gpe() check pm_wakeup_pending(), but that is before canceling the SCI wakeup, so pm_wakeup_pending() is always true. This causes the loop in acpi_ec_dispatch_gpe() to always terminate after one iteration which may not be correct. Address this issue by canceling the SCI wakeup earlier, from acpi_ec_dispatch_gpe() itself. Fixes: 4a9af6cac050 ("ACPI: EC: Rework flushing of EC work while suspended to idle") Signed-off-by: Rafael J. Wysocki

ACPI: EC: Relocate acpi_ec_create_query() and drop acpi_ec_delete_query()

2021-12-01T19:17:32Z

Move acpi_ec_create_query() after acpi_ec_event_processor(), drop the no longer needed forward declaration of the latter, and eliminate acpi_ec_delete_query() which isn't really necessary. No intentional functional impact. Signed-off-by: Rafael J. Wysocki

ACPI: EC: Make the event work state machine visible

2021-12-01T19:17:32Z

The EC driver uses a relatively simple state machine for the event work handling, but it is not really straightforward to figure out. The states are as follows: "Ready": The event handling work can be submitted. In this state, the EC_FLAGS_QUERY_PENDING flag is clear. "In progress": The event handling work is pending or is being processed. It cannot be submitted again. In ths state, the EC_FLAGS_QUERY_PENDING flag is set and both the events_to_process count is nonzero and the EC_FLAGS_QUERY_GUARDING flag is clear. "Complete": The event handling work has been completed, but it still cannot be submitted again. In ths state, the EC_FLAGS_QUERY_PENDING flag is set and the events_to_process count is zero or the EC_FLAGS_QUERY_GUARDING flag is set. The state changes from "Ready" to "In progress" when new event is detected by advance_transaction() and acpi_ec_submit_event() is called by it. Next, the state can change from "In progress" directly to "Ready" in the following situations: * ec_event_clearing is ACPI_EC_EVT_TIMING_STATUS and the state of an ACPI_EC_COMMAND_QUERY transaction becomes ACPI_EC_COMMAND_POLL. * ec_event_clearing is ACPI_EC_EVT_TIMING_QUERY and the state of an ACPI_EC_COMMAND_QUERY transaction becomes ACPI_EC_COMMAND_COMPLETE. * ec_event_clearing is either ACPI_EC_EVT_TIMING_STATUS or ACPI_EC_EVT_TIMING_QUERY and there are no more events to process (ie. ec->events_to_process becomes 0). If ec_event_clearing is ACPI_EC_EVT_TIMING_EVENT, however, the state must change from "In progress" to "Complete" before it can change to "Ready". The changes from "In progress" to "Complete" in that case occur in the following situations: * The state of an ACPI_EC_COMMAND_QUERY transaction becomes ACPI_EC_COMMAND_COMPLETE. * There are no more events to process (ie. ec->events_to_process becomes 0). Finally, the state changes from "Complete" to "Ready" when advance_transaction() is invoked when the state is "Complete" and the state of the current transaction is not ACPI_EC_COMMAND_POLL. To make this state machine visible in the code, add a new event_state field to struct acpi_ec and modify the code to use it istead the EC_FLAGS_QUERY_PENDING and EC_FLAGS_QUERY_GUARDING flags. Signed-off-by: Rafael J. Wysocki

ACPI: EC: Avoid queuing unnecessary work in acpi_ec_submit_event()

2021-12-01T19:17:32Z

Notice that it is not necessary to queue up the event work again if the while () loop in acpi_ec_event_handler() is still running which is the case if nr_pending_queries is greater than 0 at the beginning of acpi_ec_submit_event() and modify the code to avoid doing that. While at it, rename nr_pending_queries in struct acpi_ec to events_to_process which actually matches the role of that field and change its data type to unsigned int which is sufficient. No expected functional impact. Signed-off-by: Rafael J. Wysocki