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

ACPI: EC: Do not release locks during operation region accesses

2024-11-08T15:19:11+00:00

[ Upstream commit dc171114926ec390ab90f46534545420ec03e458 ] It is not particularly useful to release locks (the EC mutex and the ACPI global lock, if present) and re-acquire them immediately thereafter during EC address space accesses in acpi_ec_space_handler(). First, releasing them for a while before grabbing them again does not really help anyone because there may not be enough time for another thread to acquire them. Second, if another thread successfully acquires them and carries out a new EC write or read in the middle if an operation region access in progress, it may confuse the EC firmware, especially after the burst mode has been enabled. Finally, manipulating the locks after writing or reading every single byte of data is overhead that it is better to avoid. Accordingly, modify the code to carry out EC address space accesses entirely without releasing the locks. Signed-off-by: Rafael J. Wysocki Reviewed-by: Hans de Goede Link: https://patch.msgid.link/12473338.O9o76ZdvQC@rjwysocki.net Signed-off-by: Sasha Levin

ACPI: EC: Avoid returning AE_OK on errors in address space handler

2024-07-27T08:33:41+00:00

[ Upstream commit c4bd7f1d78340e63de4d073fd3dbe5391e2996e5 ] If an error code other than EINVAL, ENODEV or ETIME is returned by acpi_ec_read() / acpi_ec_write(), then AE_OK is incorrectly returned by acpi_ec_space_handler(). Fix this by only returning AE_OK on success, and return AE_ERROR otherwise. Signed-off-by: Armin Wolf [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: EC: Abort address space access upon error

2024-07-27T08:33:41+00:00

[ Upstream commit f6f172dc6a6d7775b2df6adfd1350700e9a847ec ] When a multi-byte address space access is requested, acpi_ec_read()/ acpi_ec_write() is being called multiple times. Abort such operations if a single call to acpi_ec_read() / acpi_ec_write() fails, as the data read from / written to the EC might be incomplete. Signed-off-by: Armin Wolf Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: EC: Fix oops when removing custom query handlers

2023-05-30T11:42:08+00:00

[ Upstream commit e5b492c6bb900fcf9722e05f4a10924410e170c1 ] When removing custom query handlers, the handler might still be used inside the EC query workqueue, causing a kernel oops if the module holding the callback function was already unloaded. Fix this by flushing the EC query workqueue when removing custom query handlers. Tested on a Acer Travelmate 4002WLMi Signed-off-by: Armin Wolf 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-25T09:14:59+00:00

[ 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: Make more Asus laptops use ECDT _GPE

2021-07-20T14:15:45+00:00

[ Upstream commit 6306f0431914beaf220634ad36c08234006571d5 ] More ASUS laptops have the _GPE define in the DSDT table with a different value than the _GPE number in the ECDT. This is causing media keys not working on ASUS X505BA/BP, X542BA/BP Add model info to the quirks list. Signed-off-by: Chris Chiu Signed-off-by: Jian-Hong Pan Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: EC: Reference count query handlers under lock

2020-10-01T11:14:30+00:00

[ Upstream commit 3df663a147fe077a6ee8444ec626738946e65547 ] There is a race condition in acpi_ec_get_query_handler() theoretically allowing query handlers to go away before refernce counting them. In order to avoid it, call kref_get() on query handlers under ec->mutex. Also simplify the code a bit while at it. Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

Revert "ACPI / EC: Remove old CLEAR_ON_RESUME quirk"

2019-04-20T07:16:04+00:00

[ Upstream commit b6a3e1475b0220378ad32bdf4d8692f058b1fc03 ] On some Samsung hardware, it is necessary to clear events accumulated by the EC during sleep. These ECs stop reporting GPEs until they are manually polled, if too many events are accumulated. Thus the CLEAR_ON_RESUME quirk is introduced to send EC query commands unconditionally after resume to clear all the EC query events on those platforms. Later, commit 4c237371f290 ("ACPI / EC: Remove old CLEAR_ON_RESUME quirk") removes the CLEAR_ON_RESUME quirk because we thought the new EC IRQ polling logic should handle this case. Now it has been proved that the EC IRQ Polling logic does not fix the issue actually because we got regression report on these Samsung platforms after removing the quirk. Thus revert commit 4c237371f290 ("ACPI / EC: Remove old CLEAR_ON_RESUME quirk") to introduce back the Samsung quirk in this patch. Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161 Tested-by: Ortwin Glück Tested-by: Francisco Cribari Tested-by: Balazs Varga Signed-off-by: Zhang Rui Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: EC / PM: Disable non-wakeup GPEs for suspend-to-idle

2019-04-20T07:16:03+00:00

[ Upstream commit f941d3e41da7f86bdb9dcc1977c2bcc6b89bfe47 ] There are systems in which non-wakeup GPEs fire during the "noirq" suspend stage of suspending devices and that effectively prevents the system that tries to suspend to idle from entering any low-power state at all. If the offending GPE fires regularly and often enough, the system appears to be suspended, but in fact it is in a tight loop over "noirq" suspend and "noirq" resume of devices all the time. To prevent that from happening, disable all non-wakeup GPEs except for the EC GPE for suspend-to-idle (the EC GPE is special, because on some systems it has to be enabled for power button wakeup events to be generated as expected). Fixes: 147a7d9d25ca (ACPI / PM: Do not reconfigure GPEs for suspend-to-idle) Link: https://bugzilla.kernel.org/show_bug.cgi?id=201987 Reported-by: Zhang Rui Tested-by: Mika Westerberg Tested-by: Zhang Rui Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI / EC: Add another entry for Thinkpad X1 Carbon 6th

2018-08-09T09:01:59+00:00

Commit 2c4d6baf1bc4 (ACPI / EC: Use ec_no_wakeup on more Thinkpad X1 Carbon 6th systems) changed the DMI table to match all systems where DMI product family is "Thinkpad X1 Carbon 6th". However, the system I have here has this string written differently (ThinkPad vs. Thinkpad) which makes the match fail. In addition to that, after BIOS upgrade Robin now has the same string than my system has (perhaps newer BIOS has changed the string). In any case add another DMI entry to acpi_ec_no_wakeup[] table hopefully covering all the X1 Carbon 6th systems out there. Fixes: 2c4d6baf1bc4 (ACPI / EC: Use ec_no_wakeup on more Thinkpad X1 Carbon 6th systems) Signed-off-by: Mika Westerberg [ rjw: Rebase and change the ident string to match the product familiy ] Signed-off-by: Rafael J. Wysocki