kernel/linux.git/include/linux/power, branch v5.10.185

power: supply: bq27xxx: Ensure power_supply_changed() is called on current sign changes

2023-06-05T07:07:02+00:00

[ Upstream commit 939a116142012926e25de0ea6b7e2f8d86a5f1b6 ] On gauges where the current register is signed, there is no charging flag in the flags register. So only checking flags will not result in power_supply_changed() getting called when e.g. a charger is plugged in and the current sign changes from negative (discharging) to positive (charging). This causes userspace's notion of the status to lag until userspace does a poll. And when a power_supply_leds.c LED trigger is used to indicate charging status with a LED, this LED will lag until the capacity percentage changes, which may take many minutes (because the LED trigger only is updated on power_supply_changed() calls). Fix this by calling bq27xxx_battery_current_and_status() on gauges with a signed current register and checking if the status has changed. Fixes: 297a533b3e62 ("bq27x00: Cache battery registers") Signed-off-by: Hans de Goede Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin

power: supply: bq27xxx: Fix poll_interval handling and races on remove

2023-05-30T11:57:58+00:00

commit c00bc80462afc7963f449d7f21d896d2f629cacc upstream. Before this patch bq27xxx_battery_teardown() was setting poll_interval = 0 to avoid bq27xxx_battery_update() requeuing the delayed_work item. There are 2 problems with this: 1. If the driver is unbound through sysfs, rather then the module being rmmod-ed, this changes poll_interval unexpectedly 2. This is racy, after it being set poll_interval could be changed before bq27xxx_battery_update() checks it through /sys/module/bq27xxx_battery/parameters/poll_interval Fix this by added a removed attribute to struct bq27xxx_device_info and using that instead of setting poll_interval to 0. There also is another poll_interval related race on remove(), writing /sys/module/bq27xxx_battery/parameters/poll_interval will requeue the delayed_work item for all devices on the bq27xxx_battery_devices list and the device being removed was only removed from that list after cancelling the delayed_work item. Fix this by moving the removal from the bq27xxx_battery_devices list to before cancelling the delayed_work item. Fixes: 8cfaaa811894 ("bq27x00_battery: Fix OOPS caused by unregistring bq27x00 driver") Signed-off-by: Hans de Goede Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman

power: supply: max17042_battery: fix typo in MAx17042_TOFF

2021-09-15T07:50:26+00:00

[ Upstream commit ed0d0a0506025f06061325cedae1bbebd081620a ] Signed-off-by: Sebastian Krzyszkowiak Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin

power: supply: bq27xxx: fix power_avg for newer ICs

2021-05-11T12:47:24+00:00

[ Upstream commit c4d57c22ac65bd503716062a06fad55a01569cac ] On all newer bq27xxx ICs, the AveragePower register contains a signed value; in addition to handling the raw value as unsigned, the driver code also didn't convert it to µW as expected. At least for the BQ28Z610, the reference manual incorrectly states that the value is in units of 1mW and not 10mW. I have no way of knowing whether the manuals of other supported ICs contain the same error, or if there are models that actually use 1mW. At least, the new code shouldn't be *less* correct than the old version for any device. power_avg is removed from the cache structure, se we don't have to extend it to store both a signed value and an error code. Always getting an up-to-date value may be desirable anyways, as it avoids inconsistent current and power readings when switching between charging and discharging. Signed-off-by: Matthias Schiffer Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin

power: supply: bq27xxx: add support for TI bq34z100

2020-10-01T22:01:42+00:00

Add support for new device: the TI bq34z100-G1, a Wide Range Fuel Gauge for Li-Ion, PbA, NiMH, and NiCd batteries. The device shares a lot with other models, although it has its own differences requiring new quirks. This patch was tested on a system equipped with NiMH batteries. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sebastian Reichel

power: supply: charger-manager: Update extcon functions

2020-08-28T17:27:45+00:00

In commit 830ae442202e ("extcon: Remove the deprecated extcon functions") the function extcon_register_interest became a no-op returning an error, leading to non-functional behaviour in charger-manager. Additionally, a translation table is needed between the text representation of the extcon cable names and their IDs is needed. In order to retain DT compatibility, TA and CHARGE-DOWNSTREAM are added as they were present up until commit 11eecf910bd8 ("extcon: Modify the id and name of external connector") Signed-off-by: Jonathan Bakker Signed-off-by: Sebastian Reichel

power: supply: charger-manager: Make decisions focussed on battery status

2020-08-28T17:27:45+00:00

cm_monitor(), where charging management starts, checks various charging condition sequentially to decide next charging operation. However, as it follows sequential process, cascaded if statements, it does some jobs which have already done in the previous stage. This results in a delay in decision making. Moreover, starting point of charging is spread all around which makes maintain code and debugging difficult. Both of the problems mentioned above become clean if it manages battery charging focusing on battery status not following sequential condition checking. Now, cm_monitor() moves battery state diagram and does the optimal operation for current state. As a result, it reduces whole monitoring time almost in half. Signed-off-by: Jonghwa Lee Signed-off-by: Krzysztof Kozlowski Signed-off-by: Jonathan Bakker Signed-off-by: Sebastian Reichel

power: supply: charger-manager: Remove cm_notify_event function

2020-08-28T17:03:24+00:00

cm_notify_event() was introduced to get an event associated with the battery status externally (ie in board files), but no one ever used it. Moreover it makes charger manager driver more complicated. Drop the function and all data related to it to simplify the driver. Signed-off-by: Jonghwa Lee Signed-off-by: Krzysztof Kozlowski Signed-off-by: Jonathan Bakker Signed-off-by: Sebastian Reichel

power: supply: smb347-charger: Drop pdata support

2020-08-28T13:33:10+00:00

There are no platforms using the pdata support, so let's drop it to simplify the driver. Reviewed-by: Dmitry Osipenko Tested-by: Dmitry Osipenko Signed-off-by: Sebastian Reichel

power: supply: gpio-charger: Convert to GPIO descriptors

2020-08-27T14:47:14+00:00

This converts the GPIO charger to use exclusively GPIO descriptors, moving the two remaining platforms passing global GPIO numbers over to using a GPIO descriptor table. Signed-off-by: Linus Walleij Cc: Robert Jarzmik Cc: Dmitry Eremin-Solenikov Signed-off-by: Sebastian Reichel