linux-stable.git/drivers/power/supply, branch linux-5.0.y

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

2019-05-25T16:22:27+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: cpcap-battery: Fix division by zero

2019-05-25T16:22:25+00:00

[ Upstream commit dbe7208c6c4aec083571f2ec742870a0d0edbea3 ]

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

power: supply: axp288_fuel_gauge: Add ACEPC T8 and T11 mini PCs to the blacklist

2019-05-22T05:38:35+00:00

commit 9274c78305e12c5f461bec15f49c38e0f32ca705 upstream.

The ACEPC T8 and T11 Cherry Trail Z8350 mini PCs use an AXP288 and as PCs,
rather then portables, they does not have a battery. Still for some
reason the AXP288 not only thinks there is a battery, it actually
thinks it is discharging while the PC is running, slowly going to
0% full, causing userspace to shutdown the system due to the battery
being critically low after a while.

This commit adds the ACEPC T8 and T11 to the axp288 fuel-gauge driver
blacklist, so that we stop reporting bogus battery readings on this device.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1690852
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede 
Signed-off-by: Sebastian Reichel 
Signed-off-by: Greg Kroah-Hartman

power: supply: axp288_charger: Fix unchecked return value

2019-05-22T05:38:35+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

cpcap-charger: generate events for userspace

2019-03-23T19:11:35+00:00

commit fd10606f93a149a9f3d37574e5385b083b4a7b32 upstream.

The driver doesn't generate uevents on charger connect/disconnect.
This leads to UPower not detecting when AC is on or off... and that is
bad.

Reported by Arthur D. on github (
https://github.com/maemo-leste/bugtracker/issues/206 ), thanks to
Merlijn Wajer for suggesting a fix.

Cc: stable@kernel.org
Signed-off-by: Pavel Machek 
Acked-by: Tony Lindgren 
Signed-off-by: Sebastian Reichel 
Signed-off-by: Greg Kroah-Hartman

power: supply: bq25890: fix BAT_COMP field definition

2018-12-17T23:21:16+00:00

According to datasheet, BAT_COMP field spans bits 5-7. The rest of the
code seems to assume this already.

Fixes: 4aeae9cb0dad ("power_supply: Add support for TI BQ25890 charger chip")
Signed-off-by: Michał Mirosław 
Signed-off-by: Sebastian Reichel

power: supply: gpio-charger: Do not use deprecated POWER_SUPPLY_TYPE_USB_*

2018-12-12T23:17:01+00:00

Signed-off-by: Sebastian Reichel

power: supply: ds2781: switch to devm_power_supply_register

2018-12-12T23:16:56+00:00

Simplify/Cleanup the driver by switching to devm_power_supply_register
and dropping the driver's remove function.

Signed-off-by: Sebastian Reichel

power: supply: ds2780: switch to devm_power_supply_register

2018-12-12T23:16:47+00:00

Simplify/Cleanup the driver by switching to devm_power_supply_register
and dropping the driver's remove function.

Signed-off-by: Sebastian Reichel

power: supply: ds2781: fix race-condition in bin attribute registration

2018-12-12T23:16:39+00:00

This is a follow-up patch to the previous one, which fixed a
race-condition during registration of the attribute group.
This fixes the same issue for the binary attributes by adding
them to the properly registered group. As a side effect the
code is further cleaned up.

Signed-off-by: Sebastian Reichel