user/sven/linux.git/drivers/power, branch v5.10.245

power: supply: bq27xxx: restrict no-battery detection to bq27000

2025-10-02T11:35:41Z

commit 1e451977e1703b6db072719b37cd1b8e250b9cc9 upstream. There are fuel gauges in the bq27xxx series (e.g. bq27z561) which may in some cases report 0xff as the value of BQ27XXX_REG_FLAGS that should not be interpreted as "no battery" like for a disconnected battery with some built in bq27000 chip. So restrict the no-battery detection originally introduced by commit 3dd843e1c26a ("bq27000: report missing device better.") to the bq27000. There is no need to backport further because this was hidden before commit f16d9fb6cf03 ("power: supply: bq27xxx: Retrieve again when busy") Fixes: f16d9fb6cf03 ("power: supply: bq27xxx: Retrieve again when busy") Suggested-by: Jerry Lv Cc: stable@vger.kernel.org Signed-off-by: H. Nikolaus Schaller Link: https://lore.kernel.org/r/dd979fa6855fd051ee5117016c58daaa05966e24.1755945297.git.hns@goldelico.com Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman

power: supply: bq27xxx: fix error return in case of no bq27000 hdq battery

2025-10-02T11:35:41Z

commit 2c334d038466ac509468fbe06905a32d202117db upstream. Since commit commit f16d9fb6cf03 ("power: supply: bq27xxx: Retrieve again when busy") the console log of some devices with hdq enabled but no bq27000 battery (like e.g. the Pandaboard) is flooded with messages like: [ 34.247833] power_supply bq27000-battery: driver failed to report 'status' property: -1 as soon as user-space is finding a /sys entry and trying to read the "status" property. It turns out that the offending commit changes the logic to now return the value of cache.flags if it is <0. This is likely under the assumption that it is an error number. In normal errors from bq27xxx_read() this is indeed the case. But there is special code to detect if no bq27000 is installed or accessible through hdq/1wire and wants to report this. In that case, the cache.flags are set historically by commit 3dd843e1c26a ("bq27000: report missing device better.") to constant -1 which did make reading properties return -ENODEV. So everything appeared to be fine before the return value was passed upwards. Now the -1 is returned as -EPERM instead of -ENODEV, triggering the error condition in power_supply_format_property() which then floods the console log. So we change the detection of missing bq27000 battery to simply set cache.flags = -ENODEV instead of -1. Fixes: f16d9fb6cf03 ("power: supply: bq27xxx: Retrieve again when busy") Cc: Jerry Lv Cc: stable@vger.kernel.org Signed-off-by: H. Nikolaus Schaller Link: https://lore.kernel.org/r/692f79eb6fd541adb397038ea6e750d4de2deddf.1755945297.git.hns@goldelico.com Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman

power: supply: max14577: Handle NULL pdata when CONFIG_OF is not set

2025-08-28T14:22:34Z

[ Upstream commit 2937f5d2e24eefef8cb126244caec7fe3307f724 ] When the kernel is not configured CONFIG_OF, the max14577_charger_dt_init function returns NULL. Fix the max14577_charger_probe functionby returning -ENODATA instead of potentially passing a NULL pointer to PTR_ERR. This fixes the below smatch warning: max14577_charger_probe() warn: passing zero to 'PTR_ERR' Fixes: e30110e9c96f ("charger: max14577: Configure battery-dependent settings from DTS and sysfs") Signed-off-by: Charles Han Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20250519061601.8755-1-hanchunchao@inspur.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin

power: supply: bq27xxx: Retrieve again when busy

2025-06-27T10:04:15Z

[ Upstream commit f16d9fb6cf03fdbdefa41a8b32ba1e57afb7ae3d ] Multiple applications may access the battery gauge at the same time, so the gauge may be busy and EBUSY will be returned. The driver will set a flag to record the EBUSY state, and this flag will be kept until the next periodic update. When this flag is set, bq27xxx_battery_get_property() will just return ENODEV until the flag is updated. Even if the gauge was busy during the last accessing attempt, returning ENODEV is not ideal, and can cause confusion in the applications layer. Instead, retry accessing the I2C to update the flag is as expected, for the gauge typically recovers from busy state within a few milliseconds. If still failed to access the gauge, the real error code would be returned instead of ENODEV (as suggested by Pali Rohár). Reviewed-by: Pali Rohár Signed-off-by: Jerry Lv Link: https://lore.kernel.org/r/20250415-foo-fix-v2-1-5b45a395e4cc@axis.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin

power: reset: at91-reset: Optimize at91_reset()

2025-06-27T10:04:01Z

[ Upstream commit 62d48983f215bf1dd48665913318101fa3414dcf ] This patch adds a small optimization to the low-level at91_reset() function, which includes: - Removes the extra branch, since the following store operations already have proper condition checks. - Removes the definition of the clobber register r4, since it is no longer used in the code. Fixes: fcd0532fac2a ("power: reset: at91-reset: make at91sam9g45_restart() generic") Signed-off-by: Alexander Shiyan Reviewed-by: Alexandre Belloni Link: https://lore.kernel.org/r/20250307053809.20245-1-eagle.alexander923@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin

power: supply: max77693: Fix wrong conversion of charge input threshold value

2025-04-10T12:30:58Z

[ Upstream commit 30cc7b0d0e9341d419eb7da15fb5c22406dbe499 ] The charge input threshold voltage register on the MAX77693 PMIC accepts four values: 0x0 for 4.3v, 0x1 for 4.7v, 0x2 for 4.8v and 0x3 for 4.9v. Due to an oversight, the driver calculated the values for 4.7v and above starting from 0x0, rather than from 0x1 ([(4700000 - 4700000) / 100000] gives 0). Add 1 to the calculation to ensure that 4.7v is converted to a register value of 0x1 and that the other two voltages are converted correctly as well. Fixes: 87c2d9067893 ("power: max77693: Add charger driver for Maxim 77693") Signed-off-by: Artur Weber Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20250316-max77693-charger-input-threshold-fix-v1-1-2b037d0ac722@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin

power: supply: da9150-fg: fix potential overflow

2025-03-13T11:47:29Z

[ Upstream commit 3fb3cb4350befc4f901c54e0cb4a2a47b1302e08 ] Size of variable sd_gain equals four bytes - DA9150_QIF_SD_GAIN_SIZE. Size of variable shunt_val equals two bytes - DA9150_QIF_SHUNT_VAL_SIZE. The expression sd_gain * shunt_val is currently being evaluated using 32-bit arithmetic. So during the multiplication an overflow may occur. As the value of type 'u64' is used as storage for the eventual result, put ULL variable at the first position of each expression in order to give the compiler complete information about the proper arithmetic to use. According to C99 the guaranteed width for a variable of type 'unsigned long long' >= 64 bits. Remove the explicit cast to u64 as it is meaningless. Just for the sake of consistency, perform the similar trick with another expression concerning 'iavg'. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: a419b4fd9138 ("power: Add support for DA9150 Fuel-Gauge") Signed-off-by: Andrey Vatoropin Link: https://lore.kernel.org/r/20250130090030.53422-1-a.vatoropin@crpt.ru Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin

power: supply: gpio-charger: Fix set charge current limits

2025-01-09T12:25:00Z

commit afc6e39e824ad0e44b2af50a97885caec8d213d1 upstream. Fix set charge current limits for devices which allow to set the lowest charge current limit to be greater zero. If requested charge current limit is below lowest limit, the index equals current_limit_map_size which leads to accessing memory beyond allocated memory. Fixes: be2919d8355e ("power: supply: gpio-charger: add charge-current-limit feature") Cc: stable@vger.kernel.org Signed-off-by: Dimitri Fedrau Link: https://lore.kernel.org/r/20241209-fix-charge-current-limit-v1-1-760d9b8f2af3@liebherr.com Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman

power: supply: bq27xxx: Fix registers of bq27426

2024-12-14T18:48:04Z

[ Upstream commit 34f99d3b706a519e556841f405c224ca708b1f54 ] Correct bq27426 registers, according to technical reference manual it does not have Design Capacity register so it is not register compatible with bq27421. Fixes: 5ef6a16033b47 ("power: supply: bq27xxx: Add support for BQ27426") Signed-off-by: Barnabás Czémán Link: https://lore.kernel.org/r/20241016-fix_bq27426-v2-1-aa6c0f51a9f6@mainlining.org Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin

power: supply: bq27xxx: Support CHARGE_NOW for bq27z561/bq28z610/bq34z100

2024-12-14T18:48:04Z

[ Upstream commit 3ed510f06e12f8876c20474766cc2f101a41174f ] Currently REG_NAC (nominal available capacity) is mapped to power-supply's CHARGE_NOW property. Some chips do not have REG_NAC and do not expose CHARGE_NOW at the moment. Some bq27xxx chips also have another register REG_RM (remaining capacity). The difference between REG_NAC and REG_RM is load compensation. This patch adds register information for REG_RM for all supported fuel gauges. On systems having REG_NAC it is ignored, so behaviour does not change. On systems without REG_NAC, REG_RM will be used to provide CHARGE_NOW functionality. As a result there are three more chips exposing CHARGE_NOW: bq27z561, bq28z610 and bq34z100 Signed-off-by: Hermes Zhang Signed-off-by: Sebastian Reichel Stable-dep-of: 34f99d3b706a ("power: supply: bq27xxx: Fix registers of bq27426") Signed-off-by: Sasha Levin