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

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

ACPI: battery: Reduce code duplication related to cleanup

2025-12-26T14:11:38+00:00

Notice that sysfs_battery_cleanup() calls sysfs_remove_battery() under battery->update_lock which is also done in acpi_battery_remove(), so adjust the latter to use it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/1866517.TLkxdtWsSY@rafael.j.wysocki

ACPI: battery: Adjust event notification routine

2025-12-26T14:11:38+00:00

Adjust acpi_battery_notify() to cast its "data" argument to a struct acpi_battery pointer istead of a struct acpi_device one, which allows the use of acpi_driver_data() to be limited and will facilitate subsequent changes. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/4344406.1IzOArtZ34@rafael.j.wysocki

ACPI: battery: Drop redundant locking

2025-10-27T19:19:52+00:00

All of the evaluations of objects in the ACPI namespace are carried out under the namespace lock and interpreter lock in ACPICA, so it is not necessary to put any additional locks around them for synchronization. However, the ACPI battery driver does just that, so remove the redundant locking around ACPI object evaluation from it. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2344462.iZASKD2KPV@rafael.j.wysocki

ACPI: battery: Add synchronization between interface updates

2025-09-28T10:25:02+00:00

There is no synchronization between different code paths in the ACPI battery driver that update its sysfs interface or its power supply class device interface. In some cases this results to functional failures due to race conditions. One example of this is when two ACPI notifications: - ACPI_BATTERY_NOTIFY_STATUS (0x80) - ACPI_BATTERY_NOTIFY_INFO (0x81) are triggered (by the platform firmware) in a row with a little delay in between after removing and reinserting a laptop battery. Both notifications cause acpi_battery_update() to be called and if the delay between them is sufficiently small, sysfs_add_battery() can be re-entered before battery->bat is set which leads to a duplicate sysfs entry error: sysfs: cannot create duplicate filename '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT1' CPU: 1 UID: 0 PID: 185 Comm: kworker/1:4 Kdump: loaded Not tainted 6.12.38+deb13-amd64 #1 Debian 6.12.38-1 Hardware name: Gateway NV44 /SJV40-MV , BIOS V1.3121 04/08/2009 Workqueue: kacpi_notify acpi_os_execute_deferred Call Trace: dump_stack_lvl+0x5d/0x80 sysfs_warn_dup.cold+0x17/0x23 sysfs_create_dir_ns+0xce/0xe0 kobject_add_internal+0xba/0x250 kobject_add+0x96/0xc0 ? get_device_parent+0xde/0x1e0 device_add+0xe2/0x870 __power_supply_register.part.0+0x20f/0x3f0 ? wake_up_q+0x4e/0x90 sysfs_add_battery+0xa4/0x1d0 [battery] acpi_battery_update+0x19e/0x290 [battery] acpi_battery_notify+0x50/0x120 [battery] acpi_ev_notify_dispatch+0x49/0x70 acpi_os_execute_deferred+0x1a/0x30 process_one_work+0x177/0x330 worker_thread+0x251/0x390 ? __pfx_worker_thread+0x10/0x10 kthread+0xd2/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 kobject: kobject_add_internal failed for BAT1 with -EEXIST, don't try to register things with the same name in the same directory. There are also other scenarios in which analogous issues may occur. Address this by using a common lock in all of the code paths leading to updates of driver interfaces: ACPI Notify () handler, system resume callback and post-resume notification, device addition and removal. This new lock replaces sysfs_lock that has been used only in sysfs_remove_battery() which now is going to be always called under the new lock, so it doesn't need any internal locking any more. Fixes: 10666251554c ("ACPI: battery: Install Notify() handler directly") Closes: https://lore.kernel.org/linux-acpi/20250910142653.313360-1-luogf2025@163.com/ Reported-by: GuangFei Luo Tested-by: GuangFei Luo Cc: 6.6+ # 6.6+ Signed-off-by: Rafael J. Wysocki

Revert "ACPI: battery: negate current when discharging"

2025-07-03T11:00:11+00:00

Revert commit 234f71555019 ("ACPI: battery: negate current when discharging") breaks not one but several userspace implementations of battery monitoring: Steam and MangoHud. Perhaps it breaks more, but those are the two that have been tested. Reported-by: Matthew Schwartz Closes: https://lore.kernel.org/linux-acpi/87C1B2AF-D430-4568-B620-14B941A8ABA4@linux.dev/ Signed-off-by: Rafael J. Wysocki

ACPI: battery: negate current when discharging

2025-05-09T19:14:34+00:00

The ACPI specification requires that battery rate is always positive, but the kernel ABI for POWER_SUPPLY_PROP_CURRENT_NOW (Documentation/ABI/testing/sysfs-class-power) specifies that it should be negative when a battery is discharging. When reporting CURRENT_NOW, massage the value to match the documented ABI. This only changes the sign of `current_now` and not `power_now` because documentation doesn't describe any particular meaning for `power_now` so leaving `power_now` unchanged is less likely to confuse userspace unnecessarily, whereas becoming consistent with the documented ABI is worth potentially confusing clients that read `current_now`. Signed-off-by: Peter Marheine Link: https://patch.msgid.link/20250508024146.1436129-1-pmarheine@chromium.org Signed-off-by: Rafael J. Wysocki