linux-stable.git/include/linux/power, branch v5.15.208

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

2023-06-05T07:21:12+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-30T12:55:32+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

Merge tag 'drivers-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc

2021-09-01T22:25:28+00:00

Pull ARM SoC driver updates from Arnd Bergmann:
 "These are updates for drivers that are tied to a particular SoC,
  including the correspondig device tree bindings:

   - A couple of reset controller changes for unisoc, uniphier, renesas
     and zte platforms

   - memory controller driver fixes for omap and tegra

   - Rockchip io domain driver updates

   - Lots of updates for qualcomm platforms, mostly touching their
     firmware and power management drivers

   - Tegra FUSE and firmware driver updateѕ

   - Support for virtio transports in the SCMI firmware framework

   - cleanup of ixp4xx drivers, towards enabling multiplatform support
     and bringing it up to date with modern platforms

   - Minor updates for keystone, mediatek, omap, renesas"

* tag 'drivers-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (96 commits)
  reset: simple: remove ZTE details in Kconfig help
  soc: rockchip: io-domain: Remove unneeded semicolon
  soc: rockchip: io-domain: add rk3568 support
  dt-bindings: power: add rk3568-pmu-io-domain support
  bus: ixp4xx: return on error in ixp4xx_exp_probe()
  soc: renesas: Prefer memcpy() over strcpy()
  firmware: tegra: Stop using seq_get_buf()
  soc/tegra: fuse: Enable fuse clock on suspend for Tegra124
  soc/tegra: fuse: Add runtime PM support
  soc/tegra: fuse: Clear fuse->clk on driver probe failure
  soc/tegra: pmc: Prevent racing with cpuilde driver
  soc/tegra: bpmp: Remove unused including 
  dt-bindings: soc: ti: pruss: Add dma-coherent property
  soc: ti: Remove pm_runtime_irq_safe() usage for smartreflex
  soc: ti: pruss: Enable support for ICSSG subsystems on K3 AM64x SoCs
  dt-bindings: soc: ti: pruss: Update bindings for K3 AM64x SoCs
  firmware: arm_scmi: Use WARN_ON() to check configured transports
  firmware: arm_scmi: Fix boolconv.cocci warnings
  soc: mediatek: mmsys: Fix missing UFOE component in mt8173 table routing
  soc: mediatek: mmsys: add MT8365 support
  ...

power: supply: max17042_battery: more robust chip type checks

2021-08-17T13:33:52+00:00

Prepared by checking the datasheets of max17042, max17047/50
and max170455 for differences in register maps.

Signed-off-by: Sebastian Krzyszkowiak 
Signed-off-by: Sebastian Reichel

power: supply: max17042_battery: fix typo in MAx17042_TOFF

2021-08-17T13:33:52+00:00

Signed-off-by: Sebastian Krzyszkowiak 
Signed-off-by: Sebastian Reichel

power: supply: max17042_battery: clean up MAX17055_V_empty

2021-08-17T13:33:52+00:00

This register is same as in MAX17047 and MAX17050, so there's no need
for custom casing it.

Signed-off-by: Sebastian Krzyszkowiak 
Signed-off-by: Sebastian Reichel

soc: ti: Remove pm_runtime_irq_safe() usage for smartreflex

2021-08-10T22:51:22+00:00

For the smartreflex device, we need to disable smartreflex on SoC idle,
and have been using pm_runtime_irq_safe() to do that. But we want to
remove the irq_safe usage as PM runtime takes a permanent usage count
on the parent device with it.

In order to remove the need for pm_runtime_irq_safe(), let's gate
the clock directly in the driver. This removes the need to call PM runtime
during idle, and allows us to switch to using CPU_PM in the following
patch.

Note that the smartreflex interconnect target module is configured for smart
idle, but the clock does not have autoidle capability, and needs to be gated
manually. If the clock supported autoidle, we would not need to even gate
the clock.

With this change, we can now remove the related quirk flags for ti-sysc
also.

Signed-off-by: Tony Lindgren 
Signed-off-by: Santosh Shilimkar

power: ab8500: remove unused header

2021-06-03T16:40:15+00:00

The ab8500.h header in linux/power is not referenced/included, so can be
safely removed.

Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Sebastian Reichel

power: supply: bq27xxx: Add support for BQ78Z100

2021-03-21T20:29:26+00:00

Add support for TI BQ78Z100, I2C interface gas gauge.
It provides a fully integrated safety protection
and authentication for 1 to 2-series cell Li-Ion and
Li-Polymer battery packs.

The patch was tested with BQ78Z100 equipment.

CASE I:  Discharging:
	POWER_SUPPLY_NAME=bq78z100-0
	POWER_SUPPLY_STATUS=Discharging
	POWER_SUPPLY_PRESENT=1
	POWER_SUPPLY_VOLTAGE_NOW=3386000
	POWER_SUPPLY_CURRENT_NOW=-5000
	POWER_SUPPLY_CAPACITY=27
	POWER_SUPPLY_CAPACITY_LEVEL=Normal
	POWER_SUPPLY_TEMP=269
	POWER_SUPPLY_TIME_TO_EMPTY_NOW=1249920
	POWER_SUPPLY_TECHNOLOGY=Li-ion
	POWER_SUPPLY_CHARGE_FULL=6494000
	POWER_SUPPLY_CHARGE_NOW=1736000
	POWER_SUPPLY_CHARGE_FULL_DESIGN=6000000
	POWER_SUPPLY_CYCLE_COUNT=1
	POWER_SUPPLY_POWER_AVG=-20000
	POWER_SUPPLY_HEALTH=Good
	POWER_SUPPLY_MANUFACTURER=Texas Instruments

CASE II : No discharging current:
	POWER_SUPPLY_NAME=bq78z100-0
	POWER_SUPPLY_STATUS=Not charging
	POWER_SUPPLY_PRESENT=1
	POWER_SUPPLY_VOLTAGE_NOW=3386000
	POWER_SUPPLY_CURRENT_NOW=0
	POWER_SUPPLY_CAPACITY=27
	POWER_SUPPLY_CAPACITY_LEVEL=Normal
	POWER_SUPPLY_TEMP=270
	POWER_SUPPLY_TECHNOLOGY=Li-ion
	POWER_SUPPLY_CHARGE_FULL=6494000
	POWER_SUPPLY_CHARGE_NOW=1734000
	POWER_SUPPLY_CHARGE_FULL_DESIGN=6000000
	POWER_SUPPLY_CYCLE_COUNT=1
	POWER_SUPPLY_POWER_AVG=0
	POWER_SUPPLY_HEALTH=Good
	POWER_SUPPLY_MANUFACTURER=Texas Instruments

Signed-off-by: LI Qingwu 
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Sebastian Reichel

power: supply: bq27xxx: fix power_avg for newer ICs

2021-03-15T01:26:03+00:00

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