summaryrefslogtreecommitdiff
path: root/drivers/power
AgeCommit message (Collapse)Author
2025-03-08power: supply: core: Remove unused power_supply_set_battery_chargedDr. David Alan Gilbert
power_supply_set_battery_charged() has been unused since 2019's commit 0f884f8a090e ("ARM: pxa: remove raumfeld board files and defconfig") Remove it. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Link: https://lore.kernel.org/r/20250307230225.128775-2-linux@treblig.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-02-25power: supply: sc27xx: use devm_kmemdup_array()Raag Jadav
Convert to use devm_kmemdup_array() which is more robust. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Link: https://lore.kernel.org/r/20250221165333.2780888-9-raag.jadav@intel.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-02-21power: supply: axp20x_battery: Update temp sensor for AXP717 from device treeChris Morgan
Allow a boolean property of "x-powers,no-thermistor" to specify devices where the ts pin is not connected to anything. This works around an issue found with some devices where the efuse is not programmed correctly from the factory or when the register gets set erroneously. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Tested-by: Philippe Simons <simons.philippe@gmail.com> Link: https://lore.kernel.org/r/20250204155835.161973-4-macroalpha82@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-02-20power: supply: max77705: Add charger driver for Maxim 77705Dzmitry Sankouski
Add driver for Maxim 77705 switch-mode charger. It providing power supply class information to userspace. The driver is configured through DTS (battery and system related settings). Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20250123-starqltechn_integration_upstream-v17-3-8b06685b6612@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-02-20power: supply: bq27xxx_battery: do not update cached flags prematurelySicelo A. Mhlongo
Commit 243f8ffc883a1 ("power: supply: bq27xxx_battery: Notify also about status changes") intended to notify userspace when the status changes, based on the flags register. However, the cached state is updated too early, before the flags are tested for any changes. Remove the premature update. Fixes: 243f8ffc883a1 ("power: supply: bq27xxx_battery: Notify also about status changes") Signed-off-by: Sicelo A. Mhlongo <absicsz@gmail.com> Link: https://lore.kernel.org/r/20241125152945.47937-1-absicsz@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-02-20power: supply: bq27xxx: do not report bogus zero valuesSicelo A. Mhlongo
On the bq27x00 and bq27x10 variants, a number of conditions may reset the value stored in the NAC register. This will cause capacity, energy, and charge to report the value 0, even when the battery is full. On the other hand, the chip also provides a flag, EDVF, which accurately detects the true battery empty condition, when capacity, charge, and energy are really 0. Therefore, discard readings for these properties if their value is 0 while EDVF is unset. Tested on the Nokia N900 with bq27200. Signed-off-by: Sicelo A. Mhlongo <absicsz@gmail.com> Link: https://lore.kernel.org/r/20250207220605.106768-1-absicsz@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-02-20power: supply: bq27xxx: Add voltage_max_design property for bq270x0 and bq27x10Sicelo A. Mhlongo
Report VOLTAGE_MAX_DESIGN for the bq27x00 and bq27x10 fuel gauges. Per the datasheet, this value is stored in the Charge Termination Voltage Settings (QV0 and QV1) of the Pack Configuration register. Tested on the Nokia N900 with bq27200. Signed-off-by: Sicelo A. Mhlongo <absicsz@gmail.com> Link: https://lore.kernel.org/r/20250207211521.103357-1-absicsz@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-02-20power: supply: max1720x: add health propertyDimitri Fedrau
Add health property, which checks that temperature, voltage and current are within limits for the battery. Limits can be programmed in non-volatile memory. Signed-off-by: Dimitri Fedrau <dimitri.fedrau@liebherr.com> Link: https://lore.kernel.org/r/20250204-max1720x_health-v1-1-97ebbe4a0bc5@liebherr.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-02-18power: reset: ltc2952-poweroff: Switch to use hrtimer_setup()Nam Cao
hrtimer_setup() takes the callback function pointer as argument and initializes the timer completely. Replace hrtimer_init() and the open coded initialization of hrtimer::function with the new setup mechanism. Patch was created by using Coccinelle. Signed-off-by: Nam Cao <namcao@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Zack Rusin <zack.rusin@broadcom.com> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/all/75ef5206f52f194b9c51653628cd2d0b083a482f.1738746904.git.namcao@linutronix.de
2025-02-18power: supply: ab8500_chargalg: Switch to use hrtimer_setup()Nam Cao
hrtimer_setup() takes the callback function pointer as argument and initializes the timer completely. Replace hrtimer_init() and the open coded initialization of hrtimer::function with the new setup mechanism. Patch was created by using Coccinelle. Signed-off-by: Nam Cao <namcao@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Zack Rusin <zack.rusin@broadcom.com> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/all/fa0bf7376ce8f124c8285a52d9f55d0ab4c42988.1738746904.git.namcao@linutronix.de
2025-02-15power: supply: axp20x_usb_power: Fix typo in dev_warn messageAndrew Kreimer
There is a typo in a dev_warn message: - reqested -> requested Fix it via codespell. Signed-off-by: Andrew Kreimer <algonell@gmail.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Link: https://lore.kernel.org/r/20250206083405.10286-1-algonell@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-02-15power: supply: max1720x: fix a comment typoAndré Draszik
mesaurment -> measurement Signed-off-by: André Draszik <andre.draszik@linaro.org> Link: https://lore.kernel.org/r/20250213-max1720x-typo-v1-1-9c88611cac34@linaro.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-02-13power: ip5xxx_power: Make use of i2c_get_match_data()Andy Shevchenko
Get matching data in one step by switching to use i2c_get_match_data(). Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2025-02-03power: supply: axp20x_battery: Fix fault handling for AXP717Chris Morgan
Correct the fault handling for the AXP717 by changing the i2c write from regmap_update_bits() to regmap_write_bits(). The update bits function does not work properly on a RW1C register where we must write a 1 back to an existing register to clear it. Additionally, as part of this testing I confirmed the behavior of errors reappearing, so remove comment about assumptions. Fixes: 6625767049c2 ("power: supply: axp20x_battery: add support for AXP717") Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Link: https://lore.kernel.org/r/20250131231455.153447-2-macroalpha82@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-02-03power: supply: core: Fix extension related lockdep warningHans de Goede
Since commit 6037802bbae8 ("power: supply: core: implement extension API") there is the following ABBA deadlock (simplified) between the LED trigger code and the power-supply code: 1) When registering a power-supply class device, power_supply_register() calls led_trigger_register() from power_supply_create_triggers() in a scoped_guard(rwsem_read, &psy->extensions_sem) context. led_trigger_register() then in turn takes a LED subsystem lock. So here we have the following locking order: * Read-lock extensions_sem * Lock LED subsystem lock(s) 2) When registering a LED class device, with its default trigger set to a power-supply LED trigger (which has already been registered) The LED class code calls power_supply_led_trigger_activate() when setting up the default trigger. power_supply_led_trigger_activate() calls power_supply_get_property() to determine the initial value of to assign to the LED and that read-locks extensions_sem. So now we have the following locking order: * Lock LED subsystem lock(s) * Read-lock extensions_sem Fixing this is easy, there is no need to hold the extensions_sem when calling power_supply_create_triggers() since all triggers are always created rather then checking for the presence of certain attributes as power_supply_add_hwmon_sysfs() does. Move power_supply_create_triggers() out of the guard block to fix this. Here is the lockdep report fixed by this change: [ 31.249343] ====================================================== [ 31.249378] WARNING: possible circular locking dependency detected [ 31.249413] 6.13.0-rc6+ #251 Tainted: G C E [ 31.249440] ------------------------------------------------------ [ 31.249471] (udev-worker)/553 is trying to acquire lock: [ 31.249501] ffff892adbcaf660 (&psy->extensions_sem){.+.+}-{4:4}, at: power_supply_get_property.part.0+0x22/0x150 [ 31.249574] but task is already holding lock: [ 31.249603] ffff892adbc0bad0 (&led_cdev->trigger_lock){+.+.}-{4:4}, at: led_trigger_set_default+0x34/0xe0 [ 31.249657] which lock already depends on the new lock. [ 31.249696] the existing dependency chain (in reverse order) is: [ 31.249735] -> #2 (&led_cdev->trigger_lock){+.+.}-{4:4}: [ 31.249778] down_write+0x3b/0xd0 [ 31.249803] led_trigger_set_default+0x34/0xe0 [ 31.249833] led_classdev_register_ext+0x311/0x3a0 [ 31.249863] input_leds_connect+0x1dc/0x2a0 [ 31.249889] input_attach_handler.isra.0+0x75/0x90 [ 31.249921] input_register_device.cold+0xa1/0x150 [ 31.249955] hidinput_connect+0x8a2/0xb80 [ 31.249982] hid_connect+0x582/0x5c0 [ 31.250007] hid_hw_start+0x3f/0x60 [ 31.250030] hid_device_probe+0x122/0x1f0 [ 31.250053] really_probe+0xde/0x340 [ 31.250080] __driver_probe_device+0x78/0x110 [ 31.250105] driver_probe_device+0x1f/0xa0 [ 31.250132] __device_attach_driver+0x85/0x110 [ 31.250160] bus_for_each_drv+0x78/0xc0 [ 31.250184] __device_attach+0xb0/0x1b0 [ 31.250207] bus_probe_device+0x94/0xb0 [ 31.250230] device_add+0x64a/0x860 [ 31.250252] hid_add_device+0xe5/0x240 [ 31.250279] usbhid_probe+0x4dc/0x620 [ 31.250303] usb_probe_interface+0xe4/0x2a0 [ 31.250329] really_probe+0xde/0x340 [ 31.250353] __driver_probe_device+0x78/0x110 [ 31.250377] driver_probe_device+0x1f/0xa0 [ 31.250404] __device_attach_driver+0x85/0x110 [ 31.250431] bus_for_each_drv+0x78/0xc0 [ 31.250455] __device_attach+0xb0/0x1b0 [ 31.250478] bus_probe_device+0x94/0xb0 [ 31.250501] device_add+0x64a/0x860 [ 31.250523] usb_set_configuration+0x606/0x8a0 [ 31.250552] usb_generic_driver_probe+0x3e/0x60 [ 31.250579] usb_probe_device+0x3d/0x120 [ 31.250605] really_probe+0xde/0x340 [ 31.250629] __driver_probe_device+0x78/0x110 [ 31.250653] driver_probe_device+0x1f/0xa0 [ 31.250680] __device_attach_driver+0x85/0x110 [ 31.250707] bus_for_each_drv+0x78/0xc0 [ 31.250731] __device_attach+0xb0/0x1b0 [ 31.250753] bus_probe_device+0x94/0xb0 [ 31.250776] device_add+0x64a/0x860 [ 31.250798] usb_new_device.cold+0x141/0x38f [ 31.250828] hub_event+0x1166/0x1980 [ 31.250854] process_one_work+0x20f/0x580 [ 31.250879] worker_thread+0x1d1/0x3b0 [ 31.250904] kthread+0xee/0x120 [ 31.250926] ret_from_fork+0x30/0x50 [ 31.250954] ret_from_fork_asm+0x1a/0x30 [ 31.250982] -> #1 (triggers_list_lock){++++}-{4:4}: [ 31.251022] down_write+0x3b/0xd0 [ 31.251045] led_trigger_register+0x40/0x1b0 [ 31.251074] power_supply_register_led_trigger+0x88/0x150 [ 31.251107] power_supply_create_triggers+0x55/0xe0 [ 31.251135] __power_supply_register.part.0+0x34e/0x4a0 [ 31.251164] devm_power_supply_register+0x70/0xc0 [ 31.251190] bq27xxx_battery_setup+0x1a1/0x6d0 [bq27xxx_battery] [ 31.251235] bq27xxx_battery_i2c_probe+0xe5/0x17f [bq27xxx_battery_i2c] [ 31.251272] i2c_device_probe+0x125/0x2b0 [ 31.251299] really_probe+0xde/0x340 [ 31.251324] __driver_probe_device+0x78/0x110 [ 31.251348] driver_probe_device+0x1f/0xa0 [ 31.251375] __driver_attach+0xba/0x1c0 [ 31.251398] bus_for_each_dev+0x6b/0xb0 [ 31.251421] bus_add_driver+0x111/0x1f0 [ 31.251445] driver_register+0x6e/0xc0 [ 31.251470] i2c_register_driver+0x41/0xb0 [ 31.251498] do_one_initcall+0x5e/0x3a0 [ 31.251522] do_init_module+0x60/0x220 [ 31.251550] __do_sys_init_module+0x15f/0x190 [ 31.251575] do_syscall_64+0x93/0x180 [ 31.251598] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 31.251629] -> #0 (&psy->extensions_sem){.+.+}-{4:4}: [ 31.251668] __lock_acquire+0x13ce/0x21c0 [ 31.251694] lock_acquire+0xcf/0x2e0 [ 31.251719] down_read+0x3e/0x170 [ 31.251741] power_supply_get_property.part.0+0x22/0x150 [ 31.251774] power_supply_update_leds+0x8d/0x230 [ 31.251804] power_supply_led_trigger_activate+0x18/0x20 [ 31.251837] led_trigger_set+0x1fc/0x300 [ 31.251863] led_trigger_set_default+0x90/0xe0 [ 31.251892] led_classdev_register_ext+0x311/0x3a0 [ 31.251921] devm_led_classdev_multicolor_register_ext+0x6e/0xb80 [led_class_multicolor] [ 31.251969] ktd202x_probe+0x464/0x5c0 [leds_ktd202x] [ 31.252002] i2c_device_probe+0x125/0x2b0 [ 31.252027] really_probe+0xde/0x340 [ 31.252052] __driver_probe_device+0x78/0x110 [ 31.252076] driver_probe_device+0x1f/0xa0 [ 31.252103] __driver_attach+0xba/0x1c0 [ 31.252125] bus_for_each_dev+0x6b/0xb0 [ 31.252148] bus_add_driver+0x111/0x1f0 [ 31.252172] driver_register+0x6e/0xc0 [ 31.252197] i2c_register_driver+0x41/0xb0 [ 31.252225] do_one_initcall+0x5e/0x3a0 [ 31.252248] do_init_module+0x60/0x220 [ 31.252274] __do_sys_init_module+0x15f/0x190 [ 31.253986] do_syscall_64+0x93/0x180 [ 31.255826] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 31.257614] other info that might help us debug this: [ 31.257619] Chain exists of: &psy->extensions_sem --> triggers_list_lock --> &led_cdev->trigger_lock [ 31.257630] Possible unsafe locking scenario: [ 31.257632] CPU0 CPU1 [ 31.257633] ---- ---- [ 31.257634] lock(&led_cdev->trigger_lock); [ 31.257637] lock(triggers_list_lock); [ 31.257640] lock(&led_cdev->trigger_lock); [ 31.257643] rlock(&psy->extensions_sem); [ 31.257646] *** DEADLOCK *** [ 31.289433] 4 locks held by (udev-worker)/553: [ 31.289443] #0: ffff892ad9658108 (&dev->mutex){....}-{4:4}, at: __driver_attach+0xaf/0x1c0 [ 31.289463] #1: ffff892adbc0bbc8 (&led_cdev->led_access){+.+.}-{4:4}, at: led_classdev_register_ext+0x1c7/0x3a0 [ 31.289476] #2: ffffffffad0e30b0 (triggers_list_lock){++++}-{4:4}, at: led_trigger_set_default+0x2c/0xe0 [ 31.289487] #3: ffff892adbc0bad0 (&led_cdev->trigger_lock){+.+.}-{4:4}, at: led_trigger_set_default+0x34/0xe0 Fixes: 6037802bbae8 ("power: supply: core: implement extension API") Cc: Thomas Weißschuh <linux@weissschuh.net> Cc: Armin Wolf <W_Armin@gmx.de> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20250130140035.20636-1-hdegoede@redhat.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-02-03power: supply: da9150-fg: fix potential overflowAndrey Vatoropin
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 <a.vatoropin@crpt.ru> Link: https://lore.kernel.org/r/20250130090030.53422-1-a.vatoropin@crpt.ru Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-01-27Merge tag 'for-v6.14' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply Pull power supply and reset updates from Sebastian Reichel: "Power-supply core: - introduce power supply extensions, which allows adding properties to a power supply device from a separate driver. This will be used initially to extend the generic ACPI charger/battery driver with vendor extensions for charge thresholds. - convert all drivers from power_supply_for_each_device to new power_supply_for_each_psy(), which avoids lots of casting being done in the drivers. - avoid LED trigger like values in uevent for POWER_SUPPLY_PROP_CHARGE_BEHAVIOUR - introduce POWER_SUPPLY_PROP_CHARGE_TYPES, which is similar to the POWER_SUPPLY_PROP_CHARGE_TYPE property, but also lists the available options on the specific platform Power-supply drivers - dell-laptop: use new power_supply_charge_types_show/_parse helpers - stc3117: new driver for equally named fuel gauge chip - bq24190: add support for new POWER_SUPPLY_PROP_CHARGE_TYPES - bq24190: add BQ24297 support - bq27xxx: add voltage min design for bq27000/bq27200 - cros_charge-control: convert to new power supply extension API - multiple drivers: constify 'struct bin_attribute' - ds2782: convert to device managed resources - max1720x: add charge full property - max1720x: support extra thermistor temperatures - max17042: add max77705 support - ip5xxx-power: add support for IP5306 - ltc4162-l-charger: add ltc4162-f/s and ltc4015 support - gpio-charger: support for default charge current limit - misc small cleanups and fixes Reset drivers: - at91-poweroff: add sam9x7 support" * tag 'for-v6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: (77 commits) power: supply: max1720x: add support for reading internal and thermistor temperatures power: supply: ltc4162l: Use GENMASK macro in bitmask operation power: supply: max17042: add max77705 fuel gauge support dt-bindings: power: supply: max17042: add max77705 support power: supply: add undervoltage health status property power: supply: max17042: add platform driver variant power: supply: max17042: make interrupt shared power: reset: keystone: Use syscon_regmap_lookup_by_phandle_args power: supply: Use str_enable_disable-like helpers platform/x86: dell-laptop: Use power_supply_charge_types_show/_parse() helpers power: supply: bq2415x_charger: Immediately reschedule delayed work on notifier events power: supply: Add STC3117 fuel gauge unit driver dt-bindings: power: supply: Add STC3117 Fuel Gauge power: supply: ug3105_battery: Let the core handle POWER_SUPPLY_PROP_TECHNOLOGY power: supply: gpio-charger: add support for default charge current limit dt-bindings: power: supply: gpio-charger: add support for default charge current limit power: supply: Use power_supply_external_power_changed() in __power_supply_changed_work() power: supply: core: fix build of extension sysfs group if CONFIG_SYSFS=n power: supply: bq2415x_charger: report charging state changes to userspace bq27xxx: add voltage min design for bq27000 and bq27200 ...
2025-01-22Merge tag 'pwrseq-updates-for-v6.14-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull power sequencing updates from Bartosz Golaszewski: "We added support for another Qualcomm WCN model and a FIXME comment that explains why we still need to keep a GPIO workaround for now despite having merged a set of changes to the PCI code that seemingly fixed the underlying problem: - support a new model in the qcom-wcn pwrseq driver - explain the need to keep the WLAN_EN GPIO workaround for now with a FIXME comment" * tag 'pwrseq-updates-for-v6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: power: sequencing: qcom-wcn: explain why we need the WLAN_EN GPIO hack power: sequencing: qcom-wcn: add support for the WCN6750 PMU
2025-01-17power: supply: max1720x: add support for reading internal and thermistor ↵Dimitri Fedrau
temperatures If enabled in the nPackCfg register, the Temp1, Temp2 and IntTemp registers contain the temperature readings from the AIN1 thermistor, AIN2 thermistor and internal die temperature respectively. Registers are shared between SBS and normal IC functions and are always readable regardless of IC settings. Signed-off-by: Dimitri Fedrau <dimitri.fedrau@liebherr.com> Link: https://lore.kernel.org/r/20250116-max1720x-temperature-v2-1-9638969d091a@liebherr.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-01-17power: supply: ltc4162l: Use GENMASK macro in bitmask operationKim Seer Paller
Replace the bitmask operation BIT(6) - 1 with GENMASK(5, 0) to make the code clearer and readable. Reviewed-by: Nuno Sa <nuno.sa@analog.com> Signed-off-by: Kim Seer Paller <kimseer.paller@analog.com> Link: https://lore.kernel.org/r/20250117024307.4119-1-kimseer.paller@analog.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-01-15power: supply: max17042: add max77705 fuel gauge supportDzmitry Sankouski
Add max77705 fuel gauge support. Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com> Link: https://lore.kernel.org/r/20250108-starqltechn_integration_upstream-v14-5-f6e84ec20d96@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-01-15power: supply: add undervoltage health status propertyDzmitry Sankouski
Add POWER_SUPPLY_HEALTH_UNDERVOLTAGE status for power supply to report under voltage lockout failures. Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com> Link: https://lore.kernel.org/r/20250108-starqltechn_integration_upstream-v14-1-f6e84ec20d96@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-01-15power: supply: max17042: add platform driver variantDzmitry Sankouski
Maxim PMICs may include fuel gauge with additional features, which is out of single Linux power supply driver scope. For example, in max77705 PMIC fuelgauge has additional registers, like IIN_REG, VSYS_REG, ISYS_REG. Those needed to measure PMIC input current, system voltage and current respectively. Those measurements cannot be bound to any of fuelgauge properties. The solution here add and option to use max17042 driver as a MFD sub device, thus allowing any additional functionality be implemented as another sub device. This will help to reduce code duplication in MFD fuel gauge drivers. Acked-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com> Link: https://lore.kernel.org/r/20250107-b4-max17042-v6-2-3d0104ad5bc7@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-01-15power: supply: max17042: make interrupt sharedDzmitry Sankouski
Fuelgauge blocks often are incorporated in bigger chip, which may use only 1 line for interrupts. Make interrupt shared. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com> Link: https://lore.kernel.org/r/20250107-b4-max17042-v6-1-3d0104ad5bc7@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-01-15power: reset: keystone: Use syscon_regmap_lookup_by_phandle_argsKrzysztof Kozlowski
Use syscon_regmap_lookup_by_phandle_args() which is a wrapper over syscon_regmap_lookup_by_phandle() combined with getting the syscon argument. Except simpler code this annotates within one line that given phandle has arguments, so grepping for code would be easier. There is also no real benefit in printing errors on missing syscon argument, because this is done just too late: runtime check on static/build-time data. Dtschema and Devicetree bindings offer the static/build-time check for this already. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250111185358.183725-1-krzysztof.kozlowski@linaro.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-01-15power: supply: Use str_enable_disable-like helpersKrzysztof Kozlowski
Replace ternary (condition ? "enable" : "disable") syntax with helpers from string_choices.h because: 1. Simple function call with one argument is easier to read. Ternary operator has three arguments and with wrapping might lead to quite long code. 2. Is slightly shorter thus also easier to read. 3. It brings uniformity in the text - same string. 4. Allows deduping by the linker, which results in a smaller binary file. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250114203611.1013324-1-krzysztof.kozlowski@linaro.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-01-13power: sequencing: qcom-wcn: explain why we need the WLAN_EN GPIO hackBartosz Golaszewski
With the recent rework of the PCI power control code, the workaround for the wlan-enable GPIO - where we don't set a default (low) state in the power sequencing driver, but instead request the pin as-is - should no longer be needed but some platforms still fail to probe the WLAN controller. This is caused by the Qcom PCIe controller and needs a workaround in the controller driver so add a FIXME to eventually remove the hack from this driver once this is done. Link: https://lore.kernel.org/r/20250102121530.26993-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-12-23power: supply: bq2415x_charger: Immediately reschedule delayed work on ↵Sicelo A. Mhlongo
notifier events When the notifier is called we want to schedule the worker as soon as possible. Thus it makes sense to reschedule any waiting work and only queue a new one if there is none. Suggested-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> Signed-off-by: Sicelo A. Mhlongo <absicsz@gmail.com> Link: https://lore.kernel.org/r/20241221161124.114989-1-absicsz@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-21power: supply: Add STC3117 fuel gauge unit driverBhavin Sharma
Adds initial support for the STC3117 fuel gauge. The driver provides functionality to monitor key parameters including: Voltage, Current, State of Charge (SOC), Temperature, Status Co-developed-by: Hardevsinh Palaniya <hardevsinh.palaniya@siliconsignals.io> Signed-off-by: Hardevsinh Palaniya <hardevsinh.palaniya@siliconsignals.io> Signed-off-by: Bhavin Sharma <bhavin.sharma@siliconsignals.io> Link: https://lore.kernel.org/r/20241220084958.32367-3-bhavin.sharma@siliconsignals.io Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-20power: supply: ug3105_battery: Let the core handle POWER_SUPPLY_PROP_TECHNOLOGYHans de Goede
The power-supply core already takes care of handling POWER_SUPPLY_PROP_TECHNOLOGY based on the battery_info. Drop the unnecessary handling from the driver. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20241215172133.178460-4-hdegoede@redhat.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-20power: supply: gpio-charger: add support for default charge current limitDimitri Fedrau
With DT properties charge-current-limit-gpios and charge-current-limit-mapping one can define charge current limits in uA using up to 32 GPIOs. At the moment the driver defaults to smallest charge current limitation for safety reasons. When disabling charging is supported, which should be common, the driver defaults to non charging on probe. By having a default, charging can be enabled on probe for such devices. Signed-off-by: Dimitri Fedrau <dimitri.fedrau@liebherr.com> Link: https://lore.kernel.org/r/20241218-default-charge-current-limit-v3-2-b26118cf06b5@liebherr.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-20power: supply: Use power_supply_external_power_changed() in ↵Hans de Goede
__power_supply_changed_work() The power-supply core is designed so that power-supply driver callbacks such as get_property() and external_power_changed() will not be called until the power-supply's parent driver's probe() function has completed. There is a race where power_supply_changed() can be called for a supplier of a power-supply which is being probed after the device_add() in __power_supply_register() but before the parent driver's probe() function has completed. Hitting this race breaks the power-supply core's design to not call power-supply driver callbacks before probe() completion. This problem is caused by __power_supply_changed_work() calling the external_power_changed() directly rather then going through the power_supply_external_power_changed() helper which correcly checks psy->use_cnt . Switch to using power_supply_external_power_changed() to fix this race. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20241215172133.178460-2-hdegoede@redhat.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-19power: supply: core: fix build of extension sysfs group if CONFIG_SYSFS=nThomas Weißschuh
Add and use wrapper functions for the sysfs interaction. Restore the compatibility of CONFIG_POWER_SUPPLY=y and CONFIG_SYSFS=n. Reported-by: Nathan Chancellor <nathan@kernel.org> Closes: https://lore.kernel.org/lkml/20241218195229.GA2796534@ax162/ Fixes: 288a2cabcf6b ("power: supply: core: add UAPI to discover currently used extensions") Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241219-psy-extensions-sysfs-v1-1-868fc6cb46d6@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-19power: supply: bq2415x_charger: report charging state changes to userspaceSicelo A. Mhlongo
Continuously track the charging status register in order to send uevents whenever the state changes. Generate an uevent also when the chip's OTG line is toggled, in bq2415x_notifier_call(). Signed-off-by: Sicelo A. Mhlongo <absicsz@gmail.com> Link: https://lore.kernel.org/r/20241128085759.11840-2-absicsz@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-19bq27xxx: add voltage min design for bq27000 and bq27200Sicelo A. Mhlongo
The bq27x00 gauges have an EEPROM register which contains the value of the voltage that should be considered to be zero battery capacity. Expose this to userspace using the VOLTAGE_MIN_DESIGN property. Tested on Nokia N900 with bq27200. Signed-off-by: Sicelo A. Mhlongo <absicsz@gmail.com> Acked-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20241125151321.45440-1-absicsz@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-19power: reset: as3722-poweroff: Remove unnecessary return in ↵Nobuhiro Iwamatsu
as3722_poweroff_probe The return is executed on the devm_register_sys_off_handler() line in as3722_poweroff_probe, so the last return line is unnecessary. Remove it. Fixes: 348fde771ce7 ("power: reset: as3722-poweroff: Use devm_register_sys_off_handler(POWER_OFF)") Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org> Acked-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20241117053443.1148902-1-iwamatsu@nigauri.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-19power: supply: bq24190: Fix BQ24296 Vbus regulator supportHans de Goede
There are 2 issues with bq24296_set_otg_vbus(): 1. When writing the OTG_CONFIG bit it uses POC_CHG_CONFIG_SHIFT which should be POC_OTG_CONFIG_SHIFT. 2. When turning the regulator off it never turns charging back on. Note this must be done through bq24190_charger_set_charge_type(), to ensure that the charge_type property value of none/trickle/fast is honored. Resolve both issues to fix BQ24296 Vbus regulator support not working. Fixes: b150a703b56f ("power: supply: bq24190_charger: Add support for BQ24296") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20241116203648.169100-2-hdegoede@redhat.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-19power: supply: bq24190: Add BQ24297 supportHans de Goede
The BQ24297 is identical to the BQ24296 except that it uses USB D+ / D- data-lines for charger-type (max. input-current) detection instead of a PSEL input pin. This is the same difference as between the already supported BQ24190 (D+ / D-) and the BQ24192 (PSEL). Note just like with the BQ24190 vs BQ24192 there is no difference how the charger-IC works at the register-level. The only difference is in the external hardware interface. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20241116203648.169100-3-hdegoede@redhat.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-14power: supply: core: add UAPI to discover currently used extensionsThomas Weißschuh
Userspace wants to now about the used power supply extensions, for example to handle a device extended by a certain extension differently or to discover information about the extending device. Add a sysfs directory to the power supply device. This directory contains links which are named after the used extension and point to the device implementing that extension. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20241211-power-supply-extensions-v6-4-9d9dc3f3d387@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-14power: supply: cros_charge-control: implement a power supply extensionThomas Weißschuh
Power supply extensions provide an easier mechanism to implement additional properties for existing power supplies. Use that instead of reimplementing the sysfs attributes manually. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241211-power-supply-extensions-v6-3-9d9dc3f3d387@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-14power: supply: Merge fixes branch into for-nextSebastian Reichel
Merge the fixes branch into the development branch, since the it contains multiple changes to the cros_charge-control driver needed to convert it to the new power-supply extension framework. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-14power: supply: test-power: implement a power supply extensionThomas Weißschuh
Allow easy testing of the new power supply extension functionality. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241211-power-supply-extensions-v6-2-9d9dc3f3d387@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-14power: supply: core: implement extension APIThomas Weißschuh
Various drivers, mostly in platform/x86 extend the ACPI battery driver with additional sysfs attributes to implement more UAPIs than are exposed through ACPI by using various side-channels, like WMI, nonstandard ACPI or EC communication. While the created sysfs attributes look similar to the attributes provided by the powersupply core, there are various deficiencies: * They don't show up in uevent payload. * They can't be queried with the standard in-kernel APIs. * They don't work with triggers. * The extending driver has to reimplement all of the parsing, formatting and sysfs display logic. * Writing a extension driver is completely different from writing a normal power supply driver. This extension API avoids all of these issues. An extension is just a "struct power_supply_ext" with the same kind of callbacks as in a normal "struct power_supply_desc". The API is meant to be used via battery_hook_register(), the same way as the current extensions. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20241211-power-supply-extensions-v6-1-9d9dc3f3d387@weissschuh.net Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-13power: supply: ltc4162-l-charger: Add support for ltc4162-f/s and ltc4015Kim Seer Paller
LTC4162-L 35V/3.2A Multi-Cell Lithium-Ion Step-Down Battery Charger LTC4162-F 35V/3.2A Multi-Cell LiFePO4 Step-Down Battery Charger LTC4162-S 35V/3.2A Lead-Acid Step-Down Battery Charger LTC4015 35V/3.2A Multichemistry Buck Battery Charger Controller The LTC4162-L/F/S variants and LTC4015 share a common set of registers. The difference lies in the resolution value of the scaling factor for battery voltage and battery current measurement, input voltage, and input current for different battery chemistries. The difference also includes the calculation of setting and getting the actual voltage setting applied to the charge voltage, as well as getting the die temperature. Adding chip info structure to encapsulates these differences by defining function pointers and parameters specific to each device. This structure includes: - function pointers for getting and setting various parameters such as battery voltage, charge voltage, and die temperature - resolution parameters for battery current and input voltage - telemetry mask to specify which bits in the register are used for telemetry features Signed-off-by: Kim Seer Paller <kimseer.paller@analog.com> Link: https://lore.kernel.org/r/20241213023746.34168-3-kimseer.paller@analog.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-13power: supply: bq24190_charger: Add support for "charge_types" propertyHans de Goede
The bq24190 power_supply class device has a writeable "charge_type" property, add support for the new "charge_types" property. Reading this returns a list of supported charge-types with the currently active type surrounded by square brackets, allowing userspace to find out which enum power_supply_charge_type values are supported. This has been tested on a GPD win gaming-handheld. Reviewed-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20241211174451.355421-4-hdegoede@redhat.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-13power: supply: core: Add new "charge_types" propertyHans de Goede
Add a new "charge_types" property, this is identical to "charge_type" but reading returns a list of supported charge-types with the currently active type surrounded by square brackets, e.g.: Fast [Standard] "Long_Life" This has the advantage over the existing "charge_type" property that this allows userspace to find out which charge-types are supported for writable charge_type properties. Drivers which already support "charge_type" can easily add support for this by setting power_supply_desc.charge_types to a bitmask representing valid charge_type values. The existing "charge_type" get_property() and set_property() code paths can be re-used for "charge_types". Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241211174451.355421-3-hdegoede@redhat.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-13power: reset: at91-reset: add sdhwc support for sam9x7 SoCVarshini Rajendran
Add shutdown controller support for SAM9X7 SoC. Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com> Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Link: https://lore.kernel.org/r/20241010120414.92993-1-varshini.rajendran@microchip.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-13power: reset: at91-reset: add reset support for sam9x7 SoCVarshini Rajendran
Add power reset support for SAM9X7 SoC. Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com> Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Link: https://lore.kernel.org/r/20241010120410.92942-1-varshini.rajendran@microchip.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-13power: reset: at91-poweroff: lookup for proper pmc dt node for sam9x7Varshini Rajendran
Use sam9x7 pmc's compatible to lookup for in the SHDWC driver. Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com> Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Link: https://lore.kernel.org/r/20241010120404.92893-1-varshini.rajendran@microchip.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-12power: reset: gpio-poweroff: Clarify the warning messageFabio Estevam
When gpio-poweroff fails, a WARN_ON() is triggered without an explanation to the user about the failure. Add some comments explaining that the attempt to poweroff the system via gpio-poweroff failed and convert it to a WARN() message with a bit of context to provide some hint to the user. Signed-off-by: Fabio Estevam <festevam@gmail.com> Link: https://lore.kernel.org/r/20241212130456.580197-1-festevam@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
generated by cgit (git 2.34.1) at 2025-07-15 14:09:04 +0000