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

Revert "ACPI: battery: negate current when discharging"

2025-07-17T16:25:03Z

commit de1675de39aa945bad5937d1fde4df3682670639 upstream. 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 Signed-off-by: Greg Kroah-Hartman

ACPI: battery: negate current when discharging

2025-06-27T10:02:53Z

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

ACPI: battery: Fix possible crash when unregistering a battery hook

2024-11-08T15:20:43Z

[ Upstream commit 76959aff14a0012ad6b984ec7686d163deccdc16 ] When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash. Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by battery_hook_unregister(). Fixes: fa93854f7a7e ("battery: Add the battery hooking API") Signed-off-by: Armin Wolf Link: https://patch.msgid.link/20241001212835.341788-3-W_Armin@gmx.de Cc: All applicable Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: battery: Simplify battery hook locking

2024-11-08T15:20:43Z

[ Upstream commit 86309cbed26139e1caae7629dcca1027d9a28e75 ] Move the conditional locking from __battery_hook_unregister() into battery_hook_unregister() and rename the low-level function to simplify the locking during battery hook removal. Reviewed-by: Ilpo Järvinen Reviewed-by: Pali Rohár Signed-off-by: Armin Wolf Link: https://patch.msgid.link/20241001212835.341788-2-W_Armin@gmx.de Signed-off-by: Rafael J. Wysocki Stable-dep-of: 76959aff14a0 ("ACPI: battery: Fix possible crash when unregistering a battery hook") Signed-off-by: Sasha Levin

ACPI: battery: create alarm sysfs attribute atomically

2024-08-19T03:33:47Z

[ Upstream commit a231eed10ed5a290129fda36ad7bcc263c53ff7d ] Let the power supply core register the attribute. This ensures that the attribute is created before the device is announced to userspace, avoid a race condition. Signed-off-by: Thomas Weißschuh Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: battery: Fix missing NUL-termination with large strings

2023-03-11T15:43:39Z

[ Upstream commit f2ac14b5f197e4a2dec51e5ceaa56682ff1592bc ] When encountering a string bigger than the destination buffer (32 bytes), the string is not properly NUL-terminated, causing buffer overreads later. This for example happens on the Inspiron 3505, where the battery model name is larger than 32 bytes, which leads to sysfs showing the model name together with the serial number string (which is NUL-terminated and thus prevents worse). Fix this by using strscpy() which ensures that the result is always NUL-terminated. Fixes: 106449e870b3 ("ACPI: Battery: Allow extract string from integer") Signed-off-by: Armin Wolf Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: battery: Add device HID and quirk for Microsoft Surface Go 3

2022-03-28T06:46:47Z

commit 7dacee0b9efc8bd061f097b1a8d4daa6591af0c6 upstream. For some reason, the Microsoft Surface Go 3 uses the standard ACPI interface for battery information, but does not use the standard PNP0C0A HID. Instead it uses MSHW0146 as identifier. Add that ID to the driver as this seems to work well. Additionally, the power state is not updated immediately after the AC has been (un-)plugged, so add the respective quirk for that. Signed-off-by: Maximilian Luz Cc: All applicable Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI: battery: Add the ThinkPad "Not Charging" quirk

2022-01-27T08:19:45Z

[ Upstream commit e96c1197aca628f7d2480a1cc3214912b40b3414 ] The EC/ACPI firmware on Lenovo ThinkPads used to report a status of "Unknown" when the battery is between the charge start and charge stop thresholds. On Windows, it reports "Not Charging" so the quirk has been added to also report correctly. Now the "status" attribute returns "Not Charging" when the battery on ThinkPads is not physicaly charging. Signed-off-by: Thomas Weißschuh Reviewed-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: battery: Accept charges over the design capacity as full

2021-11-17T08:48:30Z

[ Upstream commit 2835f327bd1240508db2c89fe94a056faa53c49a ] Some buggy firmware and/or brand new batteries can support a charge that's slightly over the reported design capacity. In such cases, the kernel will report to userspace that the charging state of the battery is "Unknown", when in reality the battery charge is "Full", at least from the design capacity point of view. Make the fallback condition accepts capacities over the designed capacity so userspace knows that is full. Signed-off-by: André Almeida Reviewed-by: Hans de Goede Reviewed-by: Sebastian Reichel Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI / battery: Deal better with neither design nor full capacity not being reported

2020-02-11T12:35:20Z

commit ff3154d1d89a2343fd5f82e65bc0cf1d4e6659b3 upstream. Commit b41901a2cf06 ("ACPI / battery: Do not export energy_full[_design] on devices without full_charge_capacity") added support for some (broken) devices which always report 0 for both design_capacity and full_charge_capacity. Since the device that commit was written as a fix for is not reporting any form of "full" capacity we cannot calculate the value for the POWER_SUPPLY_PROP_CAPACITY, this is worked around by using an alternative array of available properties which does not contain this property. This is necessary because userspace (upower) treats us returning -ENODEV as 0 and then typically will trigger an emergency shutdown because of that. Userspace does not do this if the capacity sysfs attribute is not present at all. There are two potential problems with that commit: 1) It assumes that both full_charge- and design-capacity are broken at the same time and only checks if full_charge- is broken. 2) It assumes that this only ever happens for devices which report energy units rather then charge units. This commit fixes both issues by only using the alternative array of available properties if both full_charge- and design-capacity are broken and by also adding an alternative array of available properties for devices using mA units. Fixes: b41901a2cf06 ("ACPI / battery: Do not export energy_full[_design] on devices without full_charge_capacity") Cc: 4.19+ # 4.19+ Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman