kernel/linux.git/drivers/acpi/ec.c, branch v7.1-rc5

ACPI: driver: Check ACPI_COMPANION() against NULL during probe

2026-05-11T16:50:06+00:00

Since every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), platform drivers that rely on the existence of a device's ACPI companion object should verify its presence. Accordingly, add requisite ACPI_COMPANION() or ACPI_HANDLE() checks against NULL to 13 platform drivers handling core ACPI devices. Also change the value returned by the ACPI thermal zone driver when the device's ACPI companion is not present to -ENODEV for consistency with the other drivers. Signed-off-by: Rafael J. Wysocki Reviewed-by: Hans de Goede Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/4516068.ejJDZkT8p0@rafael.j.wysocki Cc: 7.0+ # 7.0+

Merge branch 'acpi-driver'

2026-04-09T19:54:15+00:00

Merge ACPI core driver core driver updates and assorted driver updates related to ACPI support for 7.1-rc1: - Clean up the ACPI AC and ACPI PAD (processor aggregator device) drivers (Rafael Wysocki) - Rework checking for duplicate video bus devices and consolidate pnp.bus_id workarounds handling in the ACPI video bus driver (Rafael Wysocki) - Update the ACPI core device drivers to stop setting acpi_device_name() unnecessarily (Rafael Wysocki) - Rearrange code using acpi_device_class() in the ACPI core device drivers and update them to stop setting acpi_device_class() unnecessarily (Rafael Wysocki) - Define ACPI_AC_CLASS in one place (Rafael Wysocki) - Convert the ni903x_wdt watchdog driver and the xen ACPI PAD driver to bind to platform devices instead of ACPI devices (Rafael Wysocki) * acpi-driver: watchdog: ni903x_wdt: Convert to a platform driver ACPI: PAD: xen: Convert to a platform driver ACPI: AC: Define ACPI_AC_CLASS in one place ACPI: driver: Do not set acpi_device_class() unnecessarily ACPI: driver: Avoid using pnp.device_class for netlink handling ACPI: event: Redefine acpi_notifier_call_chain() ACPI: driver: Do not set acpi_device_name() unnecessarily ACPI: video: Consolidate pnp.bus_id workarounds handling ACPI: video: Rework checking for duplicate video bus devices driver core: auxiliary bus: Introduce dev_is_auxiliary() ACPI: PAD: Rearrange notify handler installation and removal ACPI: AC: Get rid of unnecessary declarations

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

2026-03-24T17:47:10+00:00

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

ACPI: driver: Do not set acpi_device_class() unnecessarily

2026-03-13T15:48:26+00:00

Several core ACPI device drivers set acpi_device_class() for the given struct acpi_device to whatever they like, but that value is never used unless the driver itself uses it and, sadly, they neglect to clear it on remove. Since the only one of them still using acpi_device_class() after previous changes is the button driver, update the others to stop setting it in vain. Also drop the related device class sybmols that become redundant. Since the ACPI button driver continues to use acpi_device_class(), make it clear the struct field represented by acpi_device_class() in its remove callback. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/3706295.iIbC2pHGDl@rafael.j.wysocki

ACPI: driver: Do not set acpi_device_name() unnecessarily

2026-03-13T15:48:23+00:00

ACPI drivers usually set acpi_device_name() for the given struct acpi_device to whatever they like, but that value is never used unless the driver itself uses it and, quite unfortunately, drivers neglect to clear it on remove. Some drivers use it for printing messages or initializing the names of subordinate devices, but it is better to use string literals for that, especially if the given one is used just once. To eliminate unnecessary overhead related to acpi_device_name() handling, rework multiple core ACPI device drivers to stop setting acpi_device_name() for struct acpi_device objects manipulated by them and use a string literal instead of it where applicable. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/10840483.nUPlyArG6x@rafael.j.wysocki

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

ACPI: driver: Drop driver_data pointer clearing from two drivers

2026-02-13T21:19:14+00:00

It is not necessary to clear the driver_data pointer in the ACPI companion device object on driver remove in the EC and SMBUS HC ACPI drivers because that pointer is not used there any more after recent changes. Drop the unnecessary statements. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/6242843.lOV4Wx5bFT@rafael.j.wysocki

ACPI: SMBUS HC: Convert the driver to a platform one

2025-12-29T20:04:23+00:00

While binding drivers directly to struct acpi_device objects allows basic functionality to be provided, at least in the majority of cases, there are some problems with it, related to general consistency, sysfs layout, power management operation ordering, and code cleanliness. Overall, it is better to bind drivers to platform devices than to their ACPI companions, so convert the ACPI SMBUS HC driver to a platform one. After this conversion, acpi_ec_probe() does not need to populate the driver_data pointer of the EC platform device's ACPI companion any more, so update it accordingly. While this is not expected to alter functionality, it changes sysfs layout and so it will be visible to user space. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/13909645.uLZWGnKmhe@rafael.j.wysocki

ACPI: EC: Convert the driver to a platform one

2025-12-29T20:04:23+00:00

While binding drivers directly to struct acpi_device objects allows basic functionality to be provided, at least in the majority of cases, there are some problems with it, related to general consistency, sysfs layout, power management operation ordering, and code cleanliness. Overall, it is better to bind drivers to platform devices than to their ACPI companions, so convert the ACPI embedded controller (EC) driver to a platform one. After this conversion, acpi_bus_register_early_device() does not need to attempt to bind an ACPI driver to the struct acpi_device created by it, so update it accordingly. While this is not expected to alter functionality, it changes sysfs layout and so it will be visible to user space. Signed-off-by: Rafael J. Wysocki [ rjw: Removed excess semicolon ] Link: https://patch.msgid.link/1946304.tdWV9SEqCh@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki