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

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

2019-12-05T14:34:17+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-25T08:52:32+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-25T08:52:32+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-25T08:52:22+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: reset: at91-poweroff: do not procede if at91_shdwc is allocated

2019-11-25T08:52:21+00:00

[ Upstream commit 9f1e44774be578fb92776add95f1fcaf8284d692 ]

There should be only one instance of struct shdwc in the system. This is
referenced through at91_shdwc. Return in probe if at91_shdwc is already
allocated.

Signed-off-by: Claudiu Beznea 
Acked-by: Nicolas Ferre 
Signed-off-by: Sebastian Reichel 
Signed-off-by: Sasha Levin

power: supply: ab8500_fg: silence uninitialized variable warnings

2019-11-25T08:52:21+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: ratelimit property read error message

2019-10-05T10:30:09+00:00

[ Upstream commit 87a2b65fc855e6be50f791c2ebbb492541896827 ]

This adds rate limiting to the message that is printed when reading a
power supply property via sysfs returns an error. This will prevent
userspace applications from unintentionally dDOSing the system by
continuously reading a property that returns an error.

Signed-off-by: David Lechner 
Signed-off-by: Sebastian Reichel 
Signed-off-by: Sasha Levin

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

2019-05-25T16:26:56+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: axp288_charger: Fix unchecked return value

2019-05-21T16:48:56+00:00

commit c3422ad5f84a66739ec6a37251ca27638c85b6be upstream.

Currently there is no check on platform_get_irq() return value
in case it fails, hence never actually reporting any errors and
causing unexpected behavior when using such value as argument
for function regmap_irq_get_virq().

Fix this by adding a proper check, a message reporting any errors
and returning *pirq*

Addresses-Coverity-ID: 1443940 ("Improper use of negative value")
Fixes: 843735b788a4 ("power: axp288_charger: axp288 charger driver")
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva 
Reviewed-by: Hans de Goede 
Signed-off-by: Sebastian Reichel 
Signed-off-by: Greg Kroah-Hartman

power: supply: charger-manager: Fix incorrect return value

2019-03-27T05:13:05+00:00

commit f25a646fbe2051527ad9721853e892d13a99199e upstream.

Fix incorrect return value.

Signed-off-by: Baolin Wang 
Signed-off-by: Sebastian Reichel 
Signed-off-by: Greg Kroah-Hartman