kernel/linux.git/drivers/acpi/ec.c, branch v6.1.168

ACPI: EC: Evaluate orphan _REG under EC device

2026-04-11T12:16:39+00:00

commit 0e6b6dedf16800df0ff73ffe2bb5066514db29c2 upstream. After starting to install the EC address space handler at the ACPI namespace root, if there is an "orphan" _REG method in the EC device's scope, it will not be evaluated any more. This breaks EC operation regions on some systems, like Asus gu605. To address this, use a wrapper around an existing ACPICA function to look for an "orphan" _REG method in the EC device scope and evaluate it if present. Fixes: 60fa6ae6e6d0 ("ACPI: EC: Install address space handler at the namespace root") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218945 Reported-by: VitaliiT Tested-by: VitaliiT Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI: EC: clean up handlers on probe failure in acpi_ec_setup()

2026-04-11T12:16:12+00:00

[ Upstream commit f6484cadbcaf26b5844b51bd7307a663dda48ef6 ] When ec_install_handlers() returns -EPROBE_DEFER on reduced-hardware platforms, it has already started the EC and installed the address space handler with the struct acpi_ec pointer as handler context. However, acpi_ec_setup() propagates the error without any cleanup. The caller acpi_ec_add() then frees the struct acpi_ec for non-boot instances, leaving a dangling handler context in ACPICA. Any subsequent AML evaluation that accesses an EC OpRegion field dispatches into acpi_ec_space_handler() with the freed pointer, causing a use-after-free: BUG: KASAN: slab-use-after-free in mutex_lock (kernel/locking/mutex.c:289) Write of size 8 at addr ffff88800721de38 by task init/1 Call Trace: mutex_lock (kernel/locking/mutex.c:289) acpi_ec_space_handler (drivers/acpi/ec.c:1362) acpi_ev_address_space_dispatch (drivers/acpi/acpica/evregion.c:293) acpi_ex_access_region (drivers/acpi/acpica/exfldio.c:246) acpi_ex_field_datum_io (drivers/acpi/acpica/exfldio.c:509) acpi_ex_extract_from_field (drivers/acpi/acpica/exfldio.c:700) acpi_ex_read_data_from_field (drivers/acpi/acpica/exfield.c:327) acpi_ex_resolve_node_to_value (drivers/acpi/acpica/exresolv.c:392) Allocated by task 1: acpi_ec_alloc (drivers/acpi/ec.c:1424) acpi_ec_add (drivers/acpi/ec.c:1692) Freed by task 1: kfree (mm/slub.c:6876) acpi_ec_add (drivers/acpi/ec.c:1751) The bug triggers on reduced-hardware EC platforms (ec->gpe < 0) when the GPIO IRQ provider defers probing. Once the stale handler exists, any unprivileged sysfs read that causes AML to touch an EC OpRegion (battery, thermal, backlight) exercises the dangling pointer. Fix this by calling ec_remove_handlers() in the error path of acpi_ec_setup() before clearing first_ec. ec_remove_handlers() checks each EC_FLAGS_* bit before acting, so it is safe to call regardless of how far ec_install_handlers() progressed: -ENODEV (handler not installed): only calls acpi_ec_stop() -EPROBE_DEFER (handler installed): removes handler, stops EC Fixes: 03e9a0e05739 ("ACPI: EC: Consolidate event handler installation code") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Link: https://patch.msgid.link/20260324165458.1337233-2-bestswngs@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: EC: Install address space handler at the namespace root

2026-04-11T12:16:12+00:00

[ Upstream commit 60fa6ae6e6d09e377fce6f8d9b6f6a4d88769f63 ] It is reported that _DSM evaluation fails in ucsi_acpi_dsm() on Lenovo IdeaPad Pro 5 due to a missing address space handler for the EC address space: ACPI Error: No handler for Region [ECSI] (000000007b8176ee) [EmbeddedControl] (20230628/evregion-130) This happens because if there is no ECDT, the EC driver only registers the EC address space handler for operation regions defined in the EC device scope of the ACPI namespace while the operation region being accessed by the _DSM in question is located beyond that scope. To address this, modify the ACPI EC driver to install the EC address space handler at the root of the ACPI namespace for the first EC that can be found regardless of whether or not an ECDT is present. Note that this change is consistent with some examples in the ACPI specification in which EC operation regions located outside the EC device scope are used (for example, see Section 9.17.15 in ACPI 6.5), so the current behavior of the EC driver is arguably questionable. Reported-by: webcaptcha Link: https://bugzilla.kernel.org/show_bug.cgi?id=218789 Link: https://uefi.org/specs/ACPI/6.5/09_ACPI_Defined_Devices_and_Device_Specific_Objects.html#example-asl-code Link: https://lore.kernel.org/linux-acpi/Zi+0whTvDbAdveHq@kuha.fi.intel.com Suggested-by: Heikki Krogerus Signed-off-by: Rafael J. Wysocki Reviewed-by: Hans de Goede Reviewed-by: Mario Limonciello Reviewed-by: Andy Shevchenko Stable-dep-of: f6484cadbcaf ("ACPI: EC: clean up handlers on probe failure in acpi_ec_setup()") Signed-off-by: Sasha Levin

ACPI: EC: Fix ECDT probe ordering issues

2026-04-11T12:16:11+00:00

[ Upstream commit ab4620f58d38206687b9f99d9d2cc1d5a2640985 ] ACPI-2.0 says that the EC OpRegion handler must be available immediately (like the standard default OpRegion handlers): Quoting from the ACPI spec version 6.3: "6.5.4 _REG (Region) ... 2. OSPM must make Embedded Controller operation regions, accessed via the Embedded Controllers described in ECDT, available before executing any control method. These operation regions may become inaccessible after OSPM runs _REG(EmbeddedControl, 0)." So acpi_bus_init() calls acpi_ec_ecdt_probe(), which calls acpi_install_address_space_handler() to install the EC's OpRegion handler, early on. This not only installs the OpRegion handler, but also calls the EC's _REG method. The _REG method call is a problem because it may rely on initialization done by the _INI methods of one of the PCI / _SB root devs, see for example: https://bugzilla.kernel.org/show_bug.cgi?id=214899 . Generally speaking _REG methods are executed when the ACPI-device they are part of has a driver bound to it. Where as _INI methods must be executed at table load time (according to the spec). The problem here is that the early acpi_install_address_space_handler() call causes the _REG handler to run too early. To allow fixing this the ACPICA code now allows to split the OpRegion handler installation and the executing of _REG into 2 separate steps. This commit uses this ACPICA functionality to fix the EC probe ordering by delaying the executing of _REG for ECDT described ECs till the matching EC device in the DSDT gets parsed and acpi_ec_add() for it gets called. This moves the calling of _REG for the EC on devices with an ECDT to the same point in time where it is called on devices without an ECDT table. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214899 Reported-and-tested-by: Johannes Penßel Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Stable-dep-of: f6484cadbcaf ("ACPI: EC: clean up handlers on probe failure in acpi_ec_setup()") Signed-off-by: Sasha Levin

ACPI: EC: Fix EC address space handler unregistration

2026-04-11T12:16:11+00:00

[ Upstream commit a5072078dbfaa9d70130805766dfa34bbb7bf2a7 ] When an ECDT table is present the EC address space handler gets registered on the root node. So to unregister it properly the unregister call also must be done on the root node. Store the ACPI handle used for the acpi_install_address_space_handler() call and use te same handle for the acpi_remove_address_space_handler() call. Reported-by: Rafael J. Wysocki Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Stable-dep-of: f6484cadbcaf ("ACPI: EC: clean up handlers on probe failure in acpi_ec_setup()") Signed-off-by: Sasha Levin

ACPI: EC: Add device to acpi_ec_no_wakeup[] qurik list

2025-09-04T13:26:25+00:00

commit 9cd51eefae3c871440b93c03716c5398f41bdf78 upstream. Add the TUXEDO InfinityBook Pro AMD Gen9 to the acpi_ec_no_wakeup[] quirk list to prevent spurious wakeups. Signed-off-by: Werner Sembach Link: https://patch.msgid.link/20250508111625.12149-1-wse@tuxedocomputers.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI: EC: Set ec_no_wakeup for Lenovo Go S

2025-05-02T05:47:05+00:00

[ Upstream commit b988685388effd648150aab272533f833a2a70f0 ] When AC adapter is unplugged or plugged in EC wakes from HW sleep but APU doesn't enter back into HW sleep. The reason this happens is that, when the APU exits HW sleep, the power rails controlled by the EC will power up the TCON. The TCON has a GPIO that will be toggled at this time. The GPIO is not marked as a wakeup source, but the GPIO controller still has an unserviced interrupt. Unserviced interrupts will block entering HW sleep again. Clearing the GPIO doesn't help as the TCON continues to assert it until it's been initialized by i2c-hid. Fixing this would require TCON F/W changes and it's already broken in the wild on production hardware. To avoid triggering this issue add a quirk to avoid letting EC wake up system at all. The power button still works properly on this system. Reported-by: Antheas Kapenekakis Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3929 Link: https://github.com/bazzite-org/patchwork/commit/95b93b2852718ee1e808c72e6b1836da4a95fc63 Co-developed-by: Antheas Kapenekakis Signed-off-by: Antheas Kapenekakis Signed-off-by: Mario Limonciello Link: https://patch.msgid.link/20250401133858.1892077-1-superm1@kernel.org [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

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

2024-10-17T13:21:37+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-25T07:49:08+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-25T07:49:08+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