3316 Commits

Author SHA1 Message Date
Chris Morgan
98380110bd power: supply: axp20x_battery: Fix fault handling for AXP717
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: 6625767049 ("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-03 12:41:18 +01:00
Hans de Goede
64dd6edfc4 power: supply: core: Fix extension related lockdep warning
Since commit 6037802bba ("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: 6037802bba ("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-03 12:25:37 +01:00
Andrey Vatoropin
3fb3cb4350 power: supply: da9150-fg: fix potential overflow
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: a419b4fd91 ("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-02-03 12:23:49 +01:00
Linus Torvalds
f28f489045 Merge tag 'for-v6.14' of 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-27 15:37:16 -08:00
Linus Torvalds
0c9343150c Merge tag 'pwrseq-updates-for-v6.14-rc1' of 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-22 08:52:26 -08:00
Dimitri Fedrau
b4a95b8fd3 power: supply: max1720x: add support for reading internal and thermistor 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-17 22:33:04 +01:00
Kim Seer Paller
92c71aa1a8 power: supply: ltc4162l: Use GENMASK macro in bitmask operation
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-17 22:31:16 +01:00
Dzmitry Sankouski
260d7c5e53 power: supply: max17042: add max77705 fuel gauge support
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-15 22:39:18 +01:00
Dzmitry Sankouski
df998c2232 power: supply: add undervoltage health status property
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-15 22:39:18 +01:00
Dzmitry Sankouski
0cd4f1f77a power: supply: max17042: add platform driver variant
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-15 22:00:32 +01:00
Dzmitry Sankouski
bed41f08e2 power: supply: max17042: make interrupt shared
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-15 22:00:32 +01:00
Krzysztof Kozlowski
81312ea9b8 power: reset: keystone: Use syscon_regmap_lookup_by_phandle_args
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-15 21:51:39 +01:00
Krzysztof Kozlowski
2d678e3e1e power: supply: Use str_enable_disable-like helpers
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-15 21:41:22 +01:00
Bartosz Golaszewski
29da3e8748 power: sequencing: qcom-wcn: explain why we need the WLAN_EN GPIO hack
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>
2025-01-13 09:07:20 +01:00
Sicelo A. Mhlongo
f6945d52ee power: supply: bq2415x_charger: Immediately reschedule delayed work on 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-23 03:27:30 +01:00
Bhavin Sharma
74e3f62085 power: supply: Add STC3117 fuel gauge unit driver
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-21 16:39:34 +01:00
Hans de Goede
db9d8eca3d power: supply: ug3105_battery: Let the core handle POWER_SUPPLY_PROP_TECHNOLOGY
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-20 01:08:51 +01:00
Dimitri Fedrau
de68987480 power: supply: gpio-charger: add support for default charge current limit
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-20 00:52:31 +01:00
Hans de Goede
04d9741493 power: supply: Use power_supply_external_power_changed() in __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-20 00:36:05 +01:00
Thomas Weißschuh
21096800c5 power: supply: core: fix build of extension sysfs group if CONFIG_SYSFS=n
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: 288a2cabcf ("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-19 21:45:58 +01:00
Sicelo A. Mhlongo
5972da73f7 power: supply: bq2415x_charger: report charging state changes to userspace
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-19 01:09:54 +01:00
Sicelo A. Mhlongo
525f6a2c63 bq27xxx: add voltage min design for bq27000 and bq27200
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-19 00:42:21 +01:00
Nobuhiro Iwamatsu
156fb706f9 power: reset: as3722-poweroff: Remove unnecessary return in 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: 348fde771c ("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-19 00:38:11 +01:00
Hans de Goede
b3ded6072c power: supply: bq24190: Fix BQ24296 Vbus regulator support
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: b150a703b5 ("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-19 00:35:30 +01:00
Hans de Goede
3c7c176b10 power: supply: bq24190: Add BQ24297 support
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-19 00:32:40 +01:00