linux-stable.git/drivers/power, branch v4.4.232 Linux kernel stable tree power: supply: smb347-charger: IRQSTAT_D is volatile 2020-06-30T00:07:51+00:00 Dmitry Osipenko digetx@gmail.com 2020-03-29T16:15:44+00:00 3e40ef30c08f50225dac881bcaa1ad9a7cc938f6 [ Upstream commit c32ea07a30630ace950e07ffe7a18bdcc25898e1 ] Fix failure when USB cable is connected: smb347 2-006a: reading IRQSTAT_D failed Fixes: 1502cfe19bac ("smb347-charger: Fix battery status reporting logic for charger faults") Tested-by: David Heidelberg <david@ixit.cz> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: David Heidelberg <david@ixit.cz> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit c32ea07a30630ace950e07ffe7a18bdcc25898e1 ]

Fix failure when USB cable is connected:
smb347 2-006a: reading IRQSTAT_D failed

Fixes: 1502cfe19bac ("smb347-charger: Fix battery status reporting logic for charger faults")

Tested-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
power: vexpress: add suppress_bind_attrs to true 2020-06-20T08:23:24+00:00 Anders Roxell anders.roxell@linaro.org 2020-05-27T11:26:04+00:00 ac62bc83bfd73ae20eca64604d8f447cffb69a2f commit 73174acc9c75960af2daa7dcbdb9781fc0d135cb upstream. Make sure that the POWER_RESET_VEXPRESS driver won't have bind/unbind attributes available via the sysfs, so lets be explicit here and use ".suppress_bind_attrs = true" to prevent userspace from doing something silly. Link: https://lore.kernel.org/r/20200527112608.3886105-2-anders.roxell@linaro.org Cc: stable@vger.kernel.org Signed-off-by: Anders Roxell <anders.roxell@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 73174acc9c75960af2daa7dcbdb9781fc0d135cb upstream.

Make sure that the POWER_RESET_VEXPRESS driver won't have bind/unbind
attributes available via the sysfs, so lets be explicit here and use
".suppress_bind_attrs = true" to prevent userspace from doing something
silly.

Link: https://lore.kernel.org/r/20200527112608.3886105-2-anders.roxell@linaro.org
Cc: stable@vger.kernel.org
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
power_supply: tps65217-charger: Fix NULL deref during property export 2020-05-10T08:26:22+00:00 Marcin Niestroj m.niestroj@grinn-global.com 2016-06-14T13:29:24+00:00 396250c2041a9190e1d8199dfb2598c461de4343 commit 362761299eea7dfc3a4870551de36e08758b9254 upstream. This bug leads to: [ 1.906411] Unable to handle kernel NULL pointer dereference at virtual address 0000000c [ 1.914878] pgd = c0004000 [ 1.917786] [0000000c] *pgd=00000000 [ 1.921536] Internal error: Oops: 5 [#1] SMP ARM [ 1.926357] Modules linked in: [ 1.929556] CPU: 0 PID: 14 Comm: kworker/0:1 Not tainted 4.4.5 #18 [ 1.936006] Hardware name: Generic AM33XX (Flattened Device Tree) [ 1.942383] Workqueue: events power_supply_changed_work [ 1.947842] task: de2c41c0 ti: de2c8000 task.ti: de2c8000 [ 1.953483] PC is at tps65217_ac_get_property+0x14/0x28 [ 1.958937] LR is at tps65217_ac_get_property+0x10/0x28 Driver was trying to use drv_data in property get handler. However drv_data was not set, so it caused NULL pointer dereference. This patch properly sets drv_data during probe by power_supply_config parameter, so the property get handler works as desired. Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com> Fixes: 3636859b280c ("power_supply: Add support for tps65217-charger") Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 362761299eea7dfc3a4870551de36e08758b9254 upstream.

This bug leads to:

[    1.906411] Unable to handle kernel NULL pointer dereference at virtual address 0000000c
[    1.914878] pgd = c0004000
[    1.917786] [0000000c] *pgd=00000000
[    1.921536] Internal error: Oops: 5 [#1] SMP ARM
[    1.926357] Modules linked in:
[    1.929556] CPU: 0 PID: 14 Comm: kworker/0:1 Not tainted 4.4.5 #18
[    1.936006] Hardware name: Generic AM33XX (Flattened Device Tree)
[    1.942383] Workqueue: events power_supply_changed_work
[    1.947842] task: de2c41c0 ti: de2c8000 task.ti: de2c8000
[    1.953483] PC is at tps65217_ac_get_property+0x14/0x28
[    1.958937] LR is at tps65217_ac_get_property+0x10/0x28

Driver was trying to use drv_data in property get handler. However drv_data
was not set, so it caused NULL pointer dereference. This patch properly
sets drv_data during probe by power_supply_config parameter, so the
property get handler works as desired.

Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Fixes: 3636859b280c ("power_supply: Add support for tps65217-charger")
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
power: bq27xxx_battery: Fix bq27541 AveragePower register address 2020-05-10T08:26:22+00:00 Liu Xiang liu.xiang6@zte.com.cn 2016-01-09T14:10:39+00:00 698c2e984f0833cb86bf12b4782e79d1c9b3ae1d commit 265b60497a57da56a4be7d5c72983ae89dc0765e upstream. Currently in bq27541 driver, the average power register address is incorrectly set to 0x76, which would result in an error: bq27xxx-battery 2-0055: error reading average power register 10: -11 According to the bq27541 datasheet, fix this problem by setting the average power register address to 0x24. Fixes: d74534c27775 ("power: bq27xxx_battery: Add support for additional bq27xxx family devices") Signed-off-by: Liu Xiang <liu.xiang6@zte.com.cn> Acked-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 265b60497a57da56a4be7d5c72983ae89dc0765e upstream.

Currently in bq27541 driver, the average power register address is
incorrectly set to 0x76, which would result in an error:
bq27xxx-battery 2-0055: error reading average power register  10: -11
According to the bq27541 datasheet, fix this problem by setting
the average power register address to 0x24.

Fixes: d74534c27775 ("power: bq27xxx_battery: Add support for additional bq27xxx family devices")
Signed-off-by: Liu Xiang <liu.xiang6@zte.com.cn>
Acked-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
power: test_power: correctly handle empty writes 2020-05-10T08:26:22+00:00 Sasha Levin sasha.levin@oracle.com 2015-12-22T17:43:36+00:00 b9bf9131b1a44e56d47b63cbb2ccf834d1d64d8c commit 6b9140f39c2aaf76791197fbab0839c0e4af56e8 upstream. Writing 0 length data into test_power makes it access an invalid array location and kill the system. Fixes: f17ef9b2d ("power: Make test_power driver more dynamic.") Signed-off-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 6b9140f39c2aaf76791197fbab0839c0e4af56e8 upstream.

Writing 0 length data into test_power makes it access an invalid array
location and kill the system.

Fixes: f17ef9b2d ("power: Make test_power driver more dynamic.")
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
power: bq27xxx: fix register numbers of bq27500 2020-05-10T08:26:22+00:00 H. Nikolaus Schaller hns@goldelico.com 2015-12-17T10:12:54+00:00 a87674fe985b9319ecbbb4098355653793b688cb commit 099867a16a0fa9fd5aafc32e3b1a6f8a90f17834 upstream. bug: according to data sheet some register numbers are wrong. tested: no Fixes: d74534c27775 ("power: bq27xxx_battery: Add support for additional bq27xxx family devices") Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Acked-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 099867a16a0fa9fd5aafc32e3b1a6f8a90f17834 upstream.

bug: according to data sheet some register numbers are wrong.

tested: no

Fixes: d74534c27775 ("power: bq27xxx_battery: Add support for additional bq27xxx family devices")
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Acked-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
power: bq27xxx: fix reading for bq27000 and bq27010 2020-05-10T08:26:22+00:00 H. Nikolaus Schaller hns@goldelico.com 2015-12-17T10:12:53+00:00 4617c0bff4039f843339f1d40dd69d722aa8986b commit 549d7b317c761dbf4ed0c2945aec3acc9ca7ae14 upstream. bug: the driver reports funny capacity values: root@letux:/sys/class/power_supply/bq27000-battery# cat uevent POWER_SUPPLY_NAME=bq27000-battery POWER_SUPPLY_STATUS=Charging POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_VOLTAGE_NOW=3702000 POWER_SUPPLY_CURRENT_NOW=-464635 POWER_SUPPLY_CAPACITY=1536 <- over 100% is magic POWER_SUPPLY_CAPACITY_LEVEL=Normal POWER_SUPPLY_TEMP=311 POWER_SUPPLY_TIME_TO_FULL_NOW=10440 POWER_SUPPLY_TECHNOLOGY=Li-ion POWER_SUPPLY_CHARGE_FULL=805450 POWER_SUPPLY_CHARGE_NOW=1068 POWER_SUPPLY_CHARGE_FULL_DESIGN=8844998 <- battery has just 1200 mAh POWER_SUPPLY_CYCLE_COUNT=21 POWER_SUPPLY_ENERGY_NOW=0 POWER_SUPPLY_POWER_AVG=0 POWER_SUPPLY_HEALTH=Good POWER_SUPPLY_MANUFACTURER=Texas Instruments reason: the state of charge and the design capacity register are single byte only. The design capacity returns the higer order byte. tested: GTA04 with Openmoko/FIC HF08x battery (using hdq) Fixes: d74534c27775 ("power: bq27xxx_battery: Add support for additional bq27xxx family devices") Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Acked-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 549d7b317c761dbf4ed0c2945aec3acc9ca7ae14 upstream.

bug: the driver reports funny capacity values:

root@letux:/sys/class/power_supply/bq27000-battery# cat uevent
POWER_SUPPLY_NAME=bq27000-battery
POWER_SUPPLY_STATUS=Charging
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_VOLTAGE_NOW=3702000
POWER_SUPPLY_CURRENT_NOW=-464635
POWER_SUPPLY_CAPACITY=1536			<- over 100% is magic
POWER_SUPPLY_CAPACITY_LEVEL=Normal
POWER_SUPPLY_TEMP=311
POWER_SUPPLY_TIME_TO_FULL_NOW=10440
POWER_SUPPLY_TECHNOLOGY=Li-ion
POWER_SUPPLY_CHARGE_FULL=805450
POWER_SUPPLY_CHARGE_NOW=1068
POWER_SUPPLY_CHARGE_FULL_DESIGN=8844998	<- battery has just 1200 mAh
POWER_SUPPLY_CYCLE_COUNT=21
POWER_SUPPLY_ENERGY_NOW=0
POWER_SUPPLY_POWER_AVG=0
POWER_SUPPLY_HEALTH=Good
POWER_SUPPLY_MANUFACTURER=Texas Instruments

reason: the state of charge and the design capacity register are single
byte only. The design capacity returns the higer order byte.

tested: GTA04 with Openmoko/FIC HF08x battery (using hdq)

Fixes: d74534c27775 ("power: bq27xxx_battery: Add support for additional bq27xxx family devices")
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Acked-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
power: ipaq-micro-battery: freeing the wrong variable 2020-05-10T08:26:13+00:00 Dan Carpenter dan.carpenter@oracle.com 2016-03-18T09:00:51+00:00 c0f2f472326a647a6fccb5a55b2f16312073d969 commit b9223da41794030a5dfd5106c34ed1b98255e2ae upstream. We accidentally free "micro_ac_power" which is an error pointer and it leads to an oops. We intended to free "micro_batt_power". Fixes: a2c1d531854c ('power_supply: ipaq_micro_battery: Check return values in probe') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit b9223da41794030a5dfd5106c34ed1b98255e2ae upstream.

We accidentally free "micro_ac_power" which is an error pointer and it
leads to an oops.  We intended to free "micro_batt_power".

Fixes: a2c1d531854c ('power_supply: ipaq_micro_battery: Check return values in probe')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
power: supply: axp288_charger: Fix unchecked return value 2020-04-13T08:31:32+00:00 Gustavo A. R. Silva gustavo@embeddedor.com 2019-03-18T16:14:39+00:00 8872445ae5cd3653c2f49cdb2c46536cd4895ddb 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 <gustavo@embeddedor.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Nobuhiro Iwamatsu (CIP) <nobuhiro1.iwamatsu@toshiba.co.jp> 
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 <gustavo@embeddedor.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Nobuhiro Iwamatsu (CIP) <nobuhiro1.iwamatsu@toshiba.co.jp>
power: supply: ltc2941-battery-gauge: fix use-after-free 2020-02-14T21:29:56+00:00 Sven Van Asbroeck thesven73@gmail.com 2019-09-19T15:11:37+00:00 fd97ed8c874dc479d868ad33311ad227ff0c98ee 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 <stable@vger.kernel.org> Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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 <stable@vger.kernel.org>
Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>