kernel/drivers/acpi/battery.c, branch 0x221E-v0.0.1-v6.19

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

2026-03-04T12:19:40Z

[ Upstream commit bb1256e0ddc7e9e406164319769b9f8d8389f056 ] 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 Signed-off-by: Sasha Levin

ACPI: battery: Drop redundant locking

2025-10-27T19:19:52Z

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:02Z

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:11Z

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:34Z

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

ACPI: battery: Round capacity percengate to closest integer

2025-04-09T13:56:19Z

If the difference between capacity_now and full_capacity is within 0.5%, 100% is arguably a better number to expose than 99% and exposing the latter may confuse the user to think that there's something wrong with the battery. Round the capacity percentage to the closest integer value to avoid the confusion. Signed-off-by: shitao Link: https://patch.msgid.link/20250407085419.494234-1-shitao@kylinos.cn [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki

ACPI: battery: Rename extensions to hook in messages

2024-12-10T18:50:30Z

This functionality is called "hook" everywhere in the code. For consistency call it the same in the log messages. The power supply subsystem is about to get its own extension functionality. While the two are closely related and will be used together, the current wording leaves room for misinterpretation. Signed-off-by: Thomas Weißschuh Reviewed-by: Sebastian Reichel Link: https://patch.msgid.link/20241205-power-supply-extensions-v5-1-f0f996db4347@weissschuh.net Signed-off-by: Rafael J. Wysocki

Merge tag 'for-v6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply

2024-11-28T17:28:09Z

Pull power supply and reset updates from Sebastian Reichel: "Power-supply core: - replace power_supply_register_no_ws() with power_supply_register() and a new "no_wakeup_source" field in struct power_supply_config - constify battery info tables in the core and all drivers - switch back to remove callback for all platform drivers - allow power_supply_put() to be called from atomic context - mark attribute arrays read-only after init Power-supply drivers: - new driver for TWL6030 and TWL6032 - rk817: improve battery capacity calibration - misc small cleanups and fixes" * tag 'for-v6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: (42 commits) power: reset: ep93xx: add AUXILIARY_BUS dependency dt-bindings: power: reset: Convert mode-.* properties to array power: supply: sc27xx: Fix battery detect GPIO probe dt-bindings: power: supply: sc27xx-fg: document deprecated bat-detect-gpio reset: keystone-reset: remove unused macros power: supply: axp20x_battery: Use scaled iio_read_channel power: supply: axp20x_usb_power: Use scaled iio_read_channel power: supply: generic-adc-battery: change my gmail power: supply: pmu_battery: Set power supply type to BATTERY power: Switch back to struct platform_driver::remove() power: supply: hwmon: move interface to private header power: supply: rk817: Update battery capacity calibration power: supply: rk817: stop updating info in suspend power: supply: rt9471: Use IC status regfield to report real charger status power: supply: rt9471: Fix wrong WDT function regfield declaration dt-bindings: power/supply: qcom,pmi8998-charger: Drop incorrect "#interrupt-cells" from example power: supply: core: mark attribute arrays as ro_after_init power: supply: core: unexport power_supply_property_is_writeable() power: supply: core: use device mutex wrappers power: supply: bq27xxx: Fix registers of bq27426 ...

ACPI: battery: Check for error code from devm_mutex_init() call

2024-11-04T16:49:47Z

Even if it's not critical, the avoidance of checking the error code from devm_mutex_init() call today diminishes the point of using devm variant of it. Tomorrow it may even leak something. Add the missed check. Fixes: 0710c1ce5045 ("ACPI: battery: initialize mutexes through devm_ APIs") Signed-off-by: Andy Shevchenko Reviewed-by: Thomas Weißschuh Link: https://patch.msgid.link/20241030162754.2110946-1-andriy.shevchenko@linux.intel.com [ rjw: Added 2 empty code lines ] Signed-off-by: Rafael J. Wysocki

ACPI: battery: Register power supply with power_supply_register()

2024-10-15T20:22:20Z

power_supply_register_no_ws() is going to be removed. Switch to the general registration API. Signed-off-by: Thomas Weißschuh Reviewed-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20241005-power-supply-no-wakeup-source-v1-2-1d62bf9bcb1d@weissschuh.net Signed-off-by: Sebastian Reichel