kernel/linux.git/drivers/acpi/battery.c, branch linux-7.1.y

ACPI: battery: Fix system wakeup on critical battery status

2026-05-19T21:06:09+00:00

Commit 0a869409a981 ("ACPI: battery: Convert the driver to a platform one") changed the parent of the battery wakeup source to the platform device used for driver binding, but it forgot to update the acpi_pm_wakeup_event() call in acpi_battery_update() accordingly. Do it now to unbreak waking up the system on critical battery status during suspend-to-idle and during transitions to ACPI S3/S4. Fixes: 0a869409a981 ("ACPI: battery: Convert the driver to a platform one") Signed-off-by: Rafael J. Wysocki Cc: 7.0+ # 7.0+ Link: https://patch.msgid.link/12898712.O9o76ZdvQC@rafael.j.wysocki

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+

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: Avoid using pnp.device_class for netlink handling

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

Update several core ACPI device drivers that use acpi_bus_generate_netlink_event() for generating netlink messages to pass a string literal as its first argument instead of a pointer to pnp.device_class in a given struct acpi_device, which will allow them to avoid initializing the pnp.device_class field in the future. The ACPI button driver that uses different acpi_device_class() values for different button types will still pass it to acpi_bus_generate_netlink_event(), but update it to use the acpi_device_class() macro instead of open coding the pointer access path. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/7944022.EvYhyI6sBW@rafael.j.wysocki

ACPI: event: Redefine acpi_notifier_call_chain()

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

Notice that acpi_notifier_call_chain() only uses its device argument to retrieve the pnp.device_class and pnp.bus_id values from there, so it can be redefined to take pointers to those two strings as parameters istead of a struct acpi_device pointer. That allows all of its callers to pass a string literal as its first argument, so they won't need to initialize pnp.device_class in struct acpi_device objects operated by them any more, and its signature becomes more similar to acpi_bus_generate_netlink_event() then. Update the code as per the above. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2056097.PYKUYFuaPT@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

ACPI: battery: Drop redundant checks from acpi_battery_remove()

2026-02-13T13:22:19+00:00

In acpi_battery_remove(), "battery" cannot be NULL because it is the driver data of the platform device passed to that function and it has been set by acpi_battery_probe(), so drop the redundant check of it against NULL. Moreover, getting the ACPI device pointer from battery->device is slightly less overhead than using the ACPI_COMPANION() macro on the platform device to retrieve it, so do that and drop the check of that pointer against NULL which is also redundant. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/12836976.O9o76ZdvQC@rafael.j.wysocki

ACPI: battery: Drop redundant check from acpi_battery_notify()

2026-02-11T20:21:58+00:00

The battery pointer check against NULL in acpi_battery_notify() is redundant because the value of that pointer is the one passed to acpi_dev_install_notify_handler() in acpi_battery_probe() as the last argument which is not NULL. Drop the redundant check. No intentional functional impact. Closes: https://lore.kernel.org/linux-acpi/aYXvS1h3Bxf_5sCj@stanley.mountain/ Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/5981321.DvuYhMxLoT@rafael.j.wysocki

ACPI: battery: fix incorrect charging status when current is zero

2026-02-01T12:48:23+00:00

On some laptops, such as the Huawei Matebook series, the embedded controller continues to report "Charging" status even when the charge threshold is reached and no current is being drawn. This incorrect reporting prevents the system from switching to battery power profiles, leading to significantly higher power (e.g., 18W instead of 7W during browsing) and missed remaining battery time estimation. Validate the "Charging" state by checking if rate_now is zero. If the hardware reports charging but the current is zero, report "Not Charging" to user space. Signed-off-by: Ata İlhan Köktürk [ rjw: Whitespace fix, braces added to an inner if (), new comment rewrite ] [ rjw: Changelog edits ] Link: https://patch.msgid.link/20260129144856.43058-1-atailhan2006@gmail.com Signed-off-by: Rafael J. Wysocki

ACPI: battery: Convert the driver to a platform one

2025-12-26T14:11:38+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 battery driver to a platform one. 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/3187448.CbtlEUcBR6@rafael.j.wysocki