linux-stable.git/drivers/power, branch v4.4.217

power: supply: ltc2941-battery-gauge: fix use-after-free

2020-02-14T21:29:56+00:00

commit a60ec78d306c6548d4adbc7918b587a723c555cc upstream.

This driver's remove path calls cancel_delayed_work().
However, that function does not wait until the work function
finishes. This could mean that the work function is still
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
that the work is properly cancelled, no longer running, and
unable to re-schedule itself.

This issue was detected with the help of Coccinelle.

Cc: stable 
Signed-off-by: Sven Van Asbroeck 
Signed-off-by: Sebastian Reichel 
Signed-off-by: Greg Kroah-Hartman

power: supply: Init device wakeup after device_add()

2020-01-29T09:21:47+00:00

[ Upstream commit 8288022284859acbcc3cf1a073a1e2692d6c2543 ]

We may want to use the device pointer in device_init_wakeup() with
functions that expect the device to already be added with device_add().
For example, if we were to link the device initializing wakeup to
something in sysfs such as a class for wakeups we'll run into an error.
It looks like this code was written with the assumption that the device
would be added before initializing wakeup due to the order of operations
in power_supply_unregister().

Let's change the order of operations so we don't run into problems here.

Fixes: 948dcf966228 ("power_supply: Prevent suspend until power supply events are processed")
Cc: Greg Kroah-Hartman 
Cc: Tri Vo 
Cc: Kalesh Singh 
Cc: Ravi Chandra Sadineni 
Cc: Viresh Kumar 
Signed-off-by: Stephen Boyd 
Acked-by: Rafael J. Wysocki 
Signed-off-by: Sebastian Reichel 
Signed-off-by: Sasha Levin

PM / AVS: SmartReflex: NULL check before some freeing functions is not needed

2019-12-05T14:26:40+00:00

[ Upstream commit 14d338a857f05f894ba3badd9e6d3039c68b8180 ]

NULL check before some freeing functions is not needed.

Signed-off-by: Thomas Meyer 
Reviewed-by: Kevin Hilman 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

power: supply: twl4030_charger: disable eoc interrupt on linear charge

2019-11-25T14:54:02+00:00

[ Upstream commit 079cdff3d0a09c5da10ae1be35def7a116776328 ]

This avoids getting woken up from suspend after power interruptions
when the bci wrongly thinks the battery is full just because
of input current going low because of low input power

Signed-off-by: Andreas Kemnade 
Signed-off-by: Sebastian Reichel 
Signed-off-by: Sasha Levin

power: supply: twl4030_charger: fix charging current out-of-bounds

2019-11-25T14:54:02+00:00

[ Upstream commit 8314c212f995bc0d06b54ad02ef0ab4089781540 ]

the charging current uses unsigned int variables, if we step back
if the current is still low, we would run into negative which
means setting the target to a huge value.
Better add checks here.

Signed-off-by: Andreas Kemnade 
Signed-off-by: Sebastian Reichel 
Signed-off-by: Sasha Levin

power: supply: max8998-charger: Fix platform data retrieval

2019-11-25T14:53:59+00:00

[ Upstream commit cb90a2c6f77fe9b43d1e3f759bb2f13fe7fa1811 ]

Since the max8998 MFD driver supports instantiation by DT, platform data
retrieval is handled in MFD probe and cell drivers should get use
the pdata field of max8998_dev struct to obtain them.

Fixes: ee999fb3f17f ("mfd: max8998: Add support for Device Tree")
Signed-off-by: Tomasz Figa 
Signed-off-by: Paweł Chmiel 
Signed-off-by: Sebastian Reichel 
Signed-off-by: Sasha Levin

power: supply: ab8500_fg: silence uninitialized variable warnings

2019-11-25T14:53:58+00:00

[ Upstream commit 54baff8d4e5dce2cef61953b1dc22079cda1ddb1 ]

If kstrtoul() fails then we print "charge_full" when it's uninitialized.
The debug printk doesn't add anything so I deleted it and cleaned these
two functions up a bit.

Signed-off-by: Dan Carpenter 
Signed-off-by: Sebastian Reichel 
Signed-off-by: Sasha Levin

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

2019-06-11T10:23:49+00:00

[ Upstream commit 349ced9984ff540ce74ca8a0b2e9b03dc434b9dd ]

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 
Signed-off-by: Sasha Levin

power: supply: olpc_battery: correct the temperature units

2019-01-13T09:05:34+00:00

commit ed54ffbe554f0902689fd6d1712bbacbacd11376 upstream.

According to [1] and [2], the temperature values are in tenths of degree
Celsius. Exposing the Celsius value makes the battery appear on fire:

  $ upower -i /org/freedesktop/UPower/devices/battery_olpc_battery
  ...
      temperature:         236.9 degrees C

Tested on OLPC XO-1 and OLPC XO-1.75 laptops.

[1] include/linux/power_supply.h
[2] Documentation/power/power_supply_class.txt

Fixes: fb972873a767 ("[BATTERY] One Laptop Per Child power/battery driver")
Cc: stable@vger.kernel.org
Signed-off-by: Lubomir Rintel 
Acked-by: Pavel Machek 
Signed-off-by: Sebastian Reichel 
Signed-off-by: Greg Kroah-Hartman

power: vexpress: fix corruption in notifier registration

2018-10-10T06:52:04+00:00

[ Upstream commit 09bebb1adb21ecd04adf7ccb3b06f73e3a851e93 ]

Vexpress platforms provide two different restart handlers: SYS_REBOOT
that restart the entire system, while DB_RESET only restarts the
daughter board containing the CPU. DB_RESET is overridden by SYS_REBOOT
if it exists.

notifier_chain_register used in register_restart_handler by design
relies on notifiers to be registered once only, however vexpress restart
notifier can get registered twice. When this happen it corrupts list
of notifiers, as result some notifiers can be not called on proper
event, traverse on list can be cycled forever, and second unregister
can access already freed memory.

So far, since this was the only restart handler in the system, no issue
was observed even if the same notifier was registered twice. However
commit 6c5c0d48b686 ("watchdog: sp805: add restart handler") added
support for SP805 restart handlers and since the system under test
contains two vexpress restart and two SP805 watchdog instances, it was
observed that during the boot traversing the restart handler list looped
forever as there's a cycle in that list resulting in boot hang.

This patch fixes the issues by ensuring that the notifier is installed
only once.

Cc: Sebastian Reichel 
Signed-off-by: Sudeep Holla 
Fixes: 46c99ac66222 ("power/reset: vexpress: Register with kernel restart handler")
Signed-off-by: Sebastian Reichel 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman