linux/drivers/power, branch v5.1

Merge tag 'for-v5.1-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply

2019-05-01T21:57:23Z

Pull power supply fixes from Sebastian Reichel: "Two more fixes for the 5.1 cycle. One division by zero fix in a specific driver and one core workaround for bad userspace behaviour from systemd regarding uevents. IMHO this can be considered to be a userspace bug, but the debug messages are useless anyways - cpcap-battery: fix a division by zero - core: fix systemd issue due to log messages produced by uevent" * tag 'for-v5.1-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: power: supply: sysfs: prevent endless uevent loop with CONFIG_POWER_SUPPLY_DEBUG power: supply: cpcap-battery: Fix division by zero

power: supply: sysfs: prevent endless uevent loop with CONFIG_POWER_SUPPLY_DEBUG

2019-04-25T22:06:56Z

Fix a similar endless event loop as was done in commit 8dcf32175b4e ("i2c: prevent endless uevent loop with CONFIG_I2C_DEBUG_CORE"): The culprit is the dev_dbg printk in the i2c uevent handler. If this is activated (for instance by CONFIG_I2C_DEBUG_CORE) it results in an endless loop with systemd-journald. This happens if user-space scans the system log and reads the uevent file to get information about a newly created device, which seems fair use to me. Unfortunately reading the "uevent" file uses the same function that runs for creating the uevent for a new device, generating the next syslog entry Both CONFIG_I2C_DEBUG_CORE and CONFIG_POWER_SUPPLY_DEBUG were reported in https://bugs.freedesktop.org/show_bug.cgi?id=76886 but only former seems to have been fixed. Drop debug prints as it was done in I2C subsystem to resolve the issue. Signed-off-by: Andrey Smirnov Cc: Chris Healy Cc: linux-pm@vger.kernel.org Signed-off-by: Sebastian Reichel

drivers: power: supply: goldfish_battery: Fix bogus SPDX identifier

2019-04-15T09:16:31Z

spdxcheck.py complains: drivers/power/supply/goldfish_battery.c: 1:28 Invalid License ID: GPL which is correct because GPL is not a valid identifier. Of course this could have been caught by checkpatch.pl _before_ submitting or merging the patch. WARNING: 'SPDX-License-Identifier: GPL' is not supported in LICENSES/... #19: FILE: drivers/power/supply/goldfish_battery.c:1: +// SPDX-License-Identifier: GPL Which is absolutely hillarious as the commit introducing this wreckage says in the changelog: There was a checkpatch complain: "Missing or malformed SPDX-License-Identifier tag". Oh well. Replacing a checkpatch warning by a different checkpatch warning is a really useful exercise. Use the proper GPL-2.0 identifier which is what the boiler plate in the file had originally. Fixes: e75e3a125b40 ("drivers: power: supply: goldfish_battery: Put an SPDX tag") Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman

power: supply: cpcap-battery: Fix division by zero

2019-04-09T22:53:20Z

If called fast enough so samples do not increment, we can get division by zero in kernel: __div0 cpcap_battery_cc_raw_div cpcap_battery_get_property power_supply_get_property.part.1 power_supply_get_property power_supply_show_property power_supply_uevent Fixes: 874b2adbed12 ("power: supply: cpcap-battery: Add a battery driver") Signed-off-by: Tony Lindgren Acked-by: Pavel Machek Signed-off-by: Sebastian Reichel

power: reset: at91-reset: add support for sam9x60 SoC

2019-02-19T23:41:01Z

Add support for additional reset causes and the proper compatibility string for sam9x60 SoC. The restart function is the same as the samx7. Signed-off-by: Nicolas Ferre Reviewed-by: Alexandre Belloni Signed-off-by: Sebastian Reichel

max17042_battery: fix potential use-after-free on device remove

2019-02-19T23:36:52Z

The work which is scheduled on a POR boot is potentially left pending or running until after the device module is removed, which could result in a use-after-free. Fix by registering a cancel/sync callback, which gets executed as part of standard resource unwinding. This issue was detected with the help of Coccinelle. Signed-off-by: Sven Van Asbroeck Reviewed-by: Hans de Goede Signed-off-by: Sebastian Reichel

power: supply: core: Add a field to support battery max voltage

2019-02-19T23:33:08Z

Add a field for "voltage_max_design_uv" to present fully charged battery voltage. Signed-off-by: Artur Rojek Signed-off-by: Sebastian Reichel

bq27x00: use cached flags

2019-02-19T23:26:38Z

The flags were just read by bq27xxx_battery_update(), no need to read them again. Signed-off-by: Arthur Demchenkov Reviewed-by: Andrew F. Davis Signed-off-by: Sebastian Reichel

power: supply: ds2782: fix possible use-after-free on remove

2019-02-12T22:27:16Z

In remove(), use cancel_delayed_work_sync() to cancel the delayed work. Otherwise there's a chance that this work will continue to run until after the device has been removed. While we're here, fix the deallocation order in remove(), to correspond to the inverse of the probe() allocation order. This guarantees that any remaining work can run to completion with all driver structures still intact. This issue was detected with the help of Coccinelle. Signed-off-by: Sven Van Asbroeck Signed-off-by: Sebastian Reichel

power: supply: bq25890: show max charge current/voltage as configured

2019-01-23T21:29:45Z

Use firmware-provided limits for POWER_SUPPLY_*_MAX properties instead of chip max values. This will reflect the battery limits as those are the important ones. Signed-off-by: Michał Mirosław Signed-off-by: Sebastian Reichel