linux.git/drivers/power, branch v5.12.5

power: supply: bq25980: Move props from battery node

2021-05-14T08:52:38+00:00

[ Upstream commit 04722cec1436c732d39153ce6ae2ebf71ac3ade7 ]

Currently POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT and
POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE are exposed on
the battery node and this is incorrect.

This patch exposes both of them on the charger node rather
than the battery node.

Fixes: 5069185fc18e ("power: supply: bq25980: Add support for the BQ259xx family")
Signed-off-by: Ricardo Rivera-Matos 
Signed-off-by: Sebastian Reichel 
Signed-off-by: Sasha Levin

power: supply: bq27xxx: fix sign of current_now for newer ICs

2021-05-14T08:52:35+00:00

[ Upstream commit b67fdcb7099e9c640bad625c4dd6399debb3376a ]

Commit cd060b4d0868 ("power: supply: bq27xxx: fix polarity of current_now")
changed the sign of current_now for all bq27xxx variants, but on BQ28Z610
I'm now seeing negated values *with* that patch.

The GTA04/Openmoko device that was used for testing uses a BQ27000 or
BQ27010 IC, so I assume only the BQ27XXX_O_ZERO code path was incorrect.
Revert the behaviour for newer ICs.

Fixes: cd060b4d0868 "power: supply: bq27xxx: fix polarity of current_now"
Signed-off-by: Matthias Schiffer 
Signed-off-by: Sebastian Reichel 
Signed-off-by: Sasha Levin

power: supply: cpcap-battery: fix invalid usage of list cursor

2021-05-12T06:39:53+00:00

[ Upstream commit d0a43c12ee9f57ddb284272187bd18726c2c2c98 ]

Fix invalid usage of a list_for_each_entry in cpcap_battery_irq_thread().
Empty list or fully traversed list points to list head, which is not
NULL (and before the first element containing real data).

Signed-off-by: Guangqing Zhu 
Reviewed-by: Tony Lindgren 
Reviewed-by: Carl Philipp Klemm 
Tested-by: Carl Philipp Klemm 
Signed-off-by: Sebastian Reichel 
Signed-off-by: Sasha Levin

power: supply: s3c_adc_battery: fix possible use-after-free in s3c_adc_bat_remove()

2021-05-12T06:39:49+00:00

[ Upstream commit 68ae256945d2abe9036a7b68af4cc65aff79d5b7 ]

This driver's remove path calls cancel_delayed_work(). However, that
function does not wait until the work function finishes. This means
that the callback function may still be running after the driver's
remove function has finished, which would result in a use-after-free.

Fix by calling cancel_delayed_work_sync(), which ensures that
the work is properly cancelled, no longer running, and unable
to re-schedule itself.

Reported-by: Hulk Robot 
Signed-off-by: Yang Yingliang 
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Sebastian Reichel 
Signed-off-by: Sasha Levin

power: supply: generic-adc-battery: fix possible use-after-free in gab_remove()

2021-05-12T06:39:49+00:00

[ Upstream commit b6cfa007b3b229771d9588970adb4ab3e0487f49 ]

This driver's remove path calls cancel_delayed_work(). However, that
function does not wait until the work function finishes. This means
that the callback function may still be running after the driver's
remove function has finished, which would result in a use-after-free.

Fix by calling cancel_delayed_work_sync(), which ensures that
the work is properly cancelled, no longer running, and unable
to re-schedule itself.

Reported-by: Hulk Robot 
Signed-off-by: Yang Yingliang 
Signed-off-by: Sebastian Reichel 
Signed-off-by: Sasha Levin

power: supply: cpcap-charger: Add usleep to cpcap charger to avoid usb plug bounce

2021-05-12T06:39:48+00:00

[ Upstream commit 751faedf06e895a17e985a88ef5b6364ffd797ed ]

Adds 80000 us sleep when the usb cable is plugged in to hopefully avoid
bouncing contacts.

Upon pluging in the usb cable vbus will bounce for some time, causing cpcap to
dissconnect charging due to detecting an undervoltage condition. This is a
scope of vbus on xt894 while quickly inserting the usb cable with firm force,
probed at the far side of the usb socket and vbus loaded with approx 1k:
http://uvos.xyz/maserati/usbplug.jpg.

As can clearly be seen, vbus is all over the place for the first 15 ms or so
with a small blip at ~40 ms this causes the cpcap to trip up and disable
charging again.

The delay helps cpcap_usb_detect avoid the worst of this. It is, however, still
not ideal as strong vibrations can cause the issue to reapear any time during
charging. I have however not been able to cause the device to stop charging due
to this in practice as it is hard to vibrate the device such that the vbus pins
start bouncing again but cpcap_usb_detect is not called again due to a detected
disconnect/reconnect event.

Signed-off-by: Carl Philipp Klemm 
Tested-by: Tony Lindgren 
Signed-off-by: Sebastian Reichel 
Signed-off-by: Sasha Levin

power: supply: cpcap-charger: fix small mistake in current to register conversion

2021-05-12T06:39:48+00:00

[ Upstream commit 8a5a0cc13aa927eac7a9eb3ca82dfc1f82cfc28d ]

Signed-off-by: Carl Philipp Klemm 
Acked-by: Tony Lindgren 
Signed-off-by: Sebastian Reichel 
Signed-off-by: Sasha Levin

power: supply: Use IRQF_ONESHOT

2021-05-12T06:39:44+00:00

[ Upstream commit 2469b836fa835c67648acad17d62bc805236a6ea ]

Fixes coccicheck error:

drivers/power/supply/pm2301_charger.c:1089:7-27: ERROR:
drivers/power/supply/lp8788-charger.c:502:8-28: ERROR:
drivers/power/supply/tps65217_charger.c:239:8-33: ERROR:
drivers/power/supply/tps65090-charger.c:303:8-33: ERROR:

Threaded IRQ with no primary handler requested without IRQF_ONESHOT

Signed-off-by: dongjian 
Signed-off-by: Sebastian Reichel 
Signed-off-by: Sasha Levin

power: supply: bq27xxx: fix power_avg for newer ICs

2021-05-12T06:39:44+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: use kobj_to_dev()

2021-01-28T00:31:42+00:00

Use kobj_to_dev() instead of open-coding it

Signed-off-by: Jian Dong 
Signed-off-by: Sebastian Reichel