aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/power
AgeCommit message (Collapse)Author
2020-10-01power: supply: max17040: Correct voltage readingJonathan Bakker
[ Upstream commit 0383024f811aa469df258039807810fc3793a105 ] According to the datasheet available at (1), the bottom four bits are always zero and the actual voltage is 1.25x this value in mV. Since the kernel API specifies that voltages should be in uV, it should report 1250x the shifted value. 1) https://datasheets.maximintegrated.com/en/ds/MAX17040-MAX17041.pdf Signed-off-by: Jonathan Bakker <xc-racer2@live.ca> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-08-19power: supply: check if calc_soc succeeded in pm860x_init_batteryTom Rix
[ Upstream commit ccf193dee1f0fff55b556928591f7818bac1b3b1 ] clang static analysis flags this error 88pm860x_battery.c:522:19: warning: Assigned value is garbage or undefined [core.uninitialized.Assign] info->start_soc = soc; ^ ~~~ soc is set by calling calc_soc. But calc_soc can return without setting soc. So check the return status and bail similarly to other checks in pm860x_init_battery and initialize soc to silence the warning. Fixes: a830d28b48bf ("power_supply: Enable battery-charger for 88pm860x") Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-25power: supply: smb347-charger: IRQSTAT_D is volatileDmitry Osipenko
[ 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>
2020-06-25power: supply: lp8788: Fix an error handling path in 'lp8788_charger_probe()'Christophe JAILLET
[ Upstream commit 934ed3847a4ebc75b655659c4d2349ba4337941c ] In the probe function, in case of error, resources allocated in 'lp8788_setup_adc_channel()' must be released. This can be achieved easily by using the devm_ variant of 'iio_channel_get()'. This has the extra benefit to simplify the remove function and to axe the 'lp8788_release_adc_channel()' function which is now useless. Fixes: 98a276649358 ("power_supply: Add new lp8788 charger driver") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-25power: supply: bq24257_charger: Replace depends on REGMAP_I2C with selectEnric Balletbo i Serra
[ Upstream commit 87c3d579c8ed0eaea6b1567d529a8daa85a2bc6c ] regmap is a library function that gets selected by drivers that need it. No driver modules should depend on it. Depending on REGMAP_I2C makes this driver only build if another driver already selected REGMAP_I2C, as the symbol can't be selected through the menu kernel configuration. Fixes: 2219a935963e ("power_supply: Add TI BQ24257 charger driver") Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-22power: vexpress: add suppress_bind_attrs to trueAnders Roxell
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>
2020-04-23power: supply: axp288_fuel_gauge: Broaden vendor check for Intel Compute Sticks.Jeffery Miller
[ Upstream commit e42fe5b29ac07210297e75f36deefe54edbdbf80 ] The Intel Compute Stick `STK1A32SC` can have a system vendor of "Intel(R) Client Systems". Broaden the Intel Compute Stick DMI checks so that they match "Intel Corporation" as well as "Intel(R) Client Systems". This fixes an issue where the STK1A32SC compute sticks were still exposing a battery with the existing blacklist entry. Signed-off-by: Jeffery Miller <jmiller@neverware.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23power: supply: bq27xxx_battery: Silence deferred-probe errorDmitry Osipenko
[ Upstream commit 583b53ece0b0268c542a1eafadb62e3d4b0aab8c ] The driver fails to probe with -EPROBE_DEFER if battery's power supply (charger driver) isn't ready yet and this results in a bit noisy error message in KMSG during kernel's boot up. Let's silence the harmless error message. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Pali Rohár <pali@kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-13power: supply: axp288_charger: Add special handling for HP Pavilion x2 10Hans de Goede
commit 9c80662a74cd2a5d1113f5c69d027face963a556 upstream. Some HP Pavilion x2 10 models use an AXP288 for charging and fuel-gauge. We use a native power_supply / PMIC driver in this case, because on most models with an AXP288 the ACPI AC / Battery code is either completely missing or relies on custom / proprietary ACPI OpRegions which Linux does not implement. The native drivers mostly work fine, but there are 2 problems: 1. These model uses a Type-C connector for charging which the AXP288 does not support. As long as a Type-A charger (which uses the USB data pins for charger type detection) is used everything is fine. But if a Type-C charger is used (such as the charger shipped with the device) then the charger is not recognized. So we end up slowly discharging the device even though a charger is connected, because we are limiting the current from the charger to 500mA. To make things worse this happens with the device's official charger. Looking at the ACPI tables HP has "solved" the problem of the AXP288 not being able to recognize Type-C chargers by simply always programming the input-current-limit at 3000mA and relying on a Vhold setting of 4.7V (normally 4.4V) to limit the current intake if the charger cannot handle this. 2. If no charger is connected when the machine boots then it boots with the vbus-path disabled. On other devices this is done when a 5V boost converter is active to avoid the PMIC trying to charge from the 5V boost output. This is done when an OTG host cable is inserted and the ID pin on the micro-B receptacle is pulled low, the ID pin has an ACPI event handler associated with it which re-enables the vbus-path when the ID pin is pulled high when the OTG cable is removed. The Type-C connector has no ID pin, there is no ID pin handler and there appears to be no 5V boost converter, so we end up not charging because the vbus-path is disabled, until we unplug the charger which automatically clears the vbus-path disable bit and then on the second plug-in of the adapter we start charging. The HP Pavilion x2 10 models with an AXP288 do have mostly working ACPI AC / Battery code which does not rely on custom / proprietary ACPI OpRegions. So one possible solution would be to blacklist the AXP288 native power_supply drivers and add the HP Pavilion x2 10 with AXP288 DMI ids to the list of devices which should use the ACPI AC / Battery code even though they have an AXP288 PMIC. This would require changes to 4 files: drivers/acpi/ac.c, drivers/power/supply/axp288_charger.c, drivers/acpi/battery.c and drivers/power/supply/axp288_fuel_gauge.c. Beside needing adding the same DMI matches to 4 different files, this approach also triggers problem 2. from above, but then when suspended, during suspend the machine will not wakeup because the vbus path is disabled by the AML code when not charging, so the Vbus low-to-high IRQ is not triggered, the CPU never wakes up and the device does not charge even though the user likely things it is charging, esp. since the charge status LED is directly coupled to an adapter being plugged in and does not reflect actual charging. This could be worked by enabling vbus-path explicitly from say the axp288_charger driver's suspend handler. So neither situation is ideal, in both cased we need to explicitly enable the vbus-path to work around different variants of problem 2 above, this requires a quirk in the axp288_charger code. If we go the route of using the ACPI AC / Battery drivers then we need modifications to 3 other drivers; and we need to partially disable the axp288_charger code, while at the same time keeping it around to enable vbus-path on suspend. OTOH we can copy the hardcoding of 3A input-current-limit (we never touch Vhold, so that would stay at 4.7V) to the axp288_charger code, which needs changes regardless, then we concentrate all special handling of this interesting device model in the axp288_charger code. That is what this commit does. Cc: stable@vger.kernel.org BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1791098 Signed-off-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>
2020-02-11power: supply: ltc2941-battery-gauge: fix use-after-freeSven Van Asbroeck
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>
2020-01-27power: supply: Init device wakeup after device_add()Stephen Boyd
[ 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 <gregkh@linuxfoundation.org> Cc: Tri Vo <trong@android.com> Cc: Kalesh Singh <kaleshsingh@google.com> Cc: Ravi Chandra Sadineni <ravisadineni@chromium.org> Cc: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-17power: supply: cpcap-battery: Fix signed counter sample registerTony Lindgren
[ Upstream commit c68b901ac4fa969db8917b6a9f9b40524a690d20 ] The accumulator sample register is signed 32-bits wide register on droid 4. And only the earlier version of cpcap has a signed 24-bits wide register. We're currently passing it around as unsigned, so let's fix that and use sign_extend32() for the earlier revision. Signed-off-by: Tony Lindgren <tony@atomide.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-05PM / AVS: SmartReflex: NULL check before some freeing functions is not neededThomas Meyer
[ Upstream commit 14d338a857f05f894ba3badd9e6d3039c68b8180 ] NULL check before some freeing functions is not needed. Signed-off-by: Thomas Meyer <thomas@m3y3r.de> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20power: supply: twl4030_charger: disable eoc interrupt on linear chargeAndreas Kemnade
[ 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 <andreas@kemnade.info> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20power: supply: twl4030_charger: fix charging current out-of-boundsAndreas Kemnade
[ 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 <andreas@kemnade.info> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20power: supply: max8998-charger: Fix platform data retrievalTomasz Figa
[ 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 <tomasz.figa@gmail.com> Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20power: reset: at91-poweroff: do not procede if at91_shdwc is allocatedClaudiu Beznea
[ 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 <claudiu.beznea@microchip.com> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20power: supply: ab8500_fg: silence uninitialized variable warningsDan Carpenter
[ 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 <dan.carpenter@oracle.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-06power: supply: max14656: fix potential use-after-freeSven Van Asbroeck
[ Upstream commit 252fbeb86ceffa549af9842cefca2412d53a7653 ] Explicitly cancel/sync the irq_work delayed work, otherwise there's a chance that it will run after the device is removed, which would result in a use-after-free. Note that cancel/sync should happen: - after irq's have been disabled, as the isr re-schedules the work - before the power supply is unregistered, because the work func uses the power supply handle. Cc: Alexander Kurz <akurz@blala.de> Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-11power: supply: sbs-battery: only return health when battery presentMichael Nosthoff
commit fe55e770327363304c4111423e6f7ff3c650136d upstream. when the battery is set to sbs-mode and no gpio detection is enabled "health" is always returning a value even when the battery is not present. All other fields return "not present". This leads to a scenario where the driver is constantly switching between "present" and "not present" state. This generates a lot of constant traffic on the i2c. This commit changes the response of "health" to an error when the battery is not responding leading to a consistent "not present" state. Fixes: 76b16f4cdfb8 ("power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats") Cc: <stable@vger.kernel.org> Signed-off-by: Michael Nosthoff <committed@heine.so> Reviewed-by: Brian Norris <briannorris@chromium.org> Tested-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-11power: supply: sbs-battery: use correct flags fieldMichael Nosthoff
commit 99956a9e08251a1234434b492875b1eaff502a12 upstream. the type flag is stored in the chip->flags field not in the client->flags field. This currently leads to never using the ti specific health function as client->flags doesn't use that bit. So it's always falling back to the general one. Fixes: 76b16f4cdfb8 ("power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats") Cc: <stable@vger.kernel.org> Signed-off-by: Michael Nosthoff <committed@heine.so> Reviewed-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-01power: supply: sysfs: ratelimit property read error messageDavid Lechner
[ 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 <david@lechnology.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-06-15power: supply: max14656: fix potential use-before-allocSven Van Asbroeck
[ Upstream commit 0cd0e49711556d2331a06b1117b68dd786cb54d2 ] Call order on probe(): - max14656_hw_init() enables interrupts on the chip - devm_request_irq() starts processing interrupts, isr could be called immediately - isr: schedules delayed work (irq_work) - irq_work: calls power_supply_changed() - devm_power_supply_register() registers the power supply Depending on timing, it's possible that power_supply_changed() is called on an unregistered power supply structure. Fix by registering the power supply before requesting the irq. Cc: Alexander Kurz <akurz@blala.de> Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-25power: supply: sysfs: prevent endless uevent loop with CONFIG_POWER_SUPPLY_DEBUGAndrey Smirnov
[ 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 <andrew.smirnov@gmail.com> Cc: Chris Healy <cphealy@gmail.com> Cc: linux-pm@vger.kernel.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-25power: supply: cpcap-battery: Fix division by zeroTony Lindgren
[ 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 <tony@atomide.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-22power: supply: axp288_fuel_gauge: Add ACEPC T8 and T11 mini PCs to the blacklistHans de Goede
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 <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-22power: supply: axp288_charger: Fix unchecked return valueGustavo A. R. Silva
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>
2019-03-27power: supply: charger-manager: Fix incorrect return valueBaolin Wang
commit f25a646fbe2051527ad9721853e892d13a99199e upstream. Fix incorrect return value. Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-23cpcap-charger: generate events for userspacePavel Machek
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 <pavel@ucw.cz> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-13power: supply: olpc_battery: correct the temperature unitsLubomir Rintel
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 <lkundrak@v3.sk> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-11-13power: supply: twl4030-charger: fix OF sibling-node lookupJohan Hovold
commit 9844fb2e351311210e6660a9a1c62d17424a6145 upstream. Use the new of_get_compatible_child() helper to lookup the usb sibling node instead of using of_find_compatible_node(), which searches the entire tree from a given start node and thus can return an unrelated (non-sibling) node. This also addresses a potential use-after-free (e.g. after probe deferral) as the tree-wide helper drops a reference to its first argument (i.e. the parent device node). While at it, also fix the related phy-node reference leak. Fixes: f5e4edb8c888 ("power: twl4030_charger: find associated phy by more reliable means.") Cc: stable <stable@vger.kernel.org> # 4.2 Cc: NeilBrown <neilb@suse.de> Cc: Felipe Balbi <felipe.balbi@linux.intel.com> Cc: Sebastian Reichel <sre@kernel.org> Reviewed-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-23treewide: convert ISO_8859-1 text comments to utf-8Arnd Bergmann
Almost all files in the kernel are either plain text or UTF-8 encoded. A couple however are ISO_8859-1, usually just a few characters in a C comments, for historic reasons. This converts them all to UTF-8 for consistency. Link: http://lkml.kernel.org/r/20180724111600.4158975-1-arnd@arndb.de Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Simon Horman <horms@verge.net.au> [IPVS portion] Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> [IIO] Acked-by: Michael Ellerman <mpe@ellerman.id.au> [powerpc] Acked-by: Rob Herring <robh@kernel.org> Cc: Joe Perches <joe@perches.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Samuel Ortiz <sameo@linux.intel.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Rob Herring <robh+dt@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-08-21Merge tag 'for-v4.19' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply Pull power supply and reset updates from Sebastian Reichel: - Improve support for TI bq20z75 in sbs-battery - Add Qualcomm PM8xxx reboot driver - Add cros-ec USBPD charger driver - Move ds2760 battery driver from w1 to power-supply and add DT support - Misc fixes * tag 'for-v4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: (28 commits) power: supply: bq27xxx: Update comments power: supply: max77693_charger: fix unintentional fall-through power: supply: mark expected switch fall-throughs power: supply: lego_ev3_battery: fix Vce offset power: supply: lego_ev3_battery: Don't ignore iio_read_channel_processed() return value power: supply: ds2760_battery: add devicetree probing power: supply: ds2760_battery: merge ds2760 supply driver with its w1 slave companion w1: core: match sub-nodes of bus masters in devicetree dt-bindings: w1: document bindings for ds2760 battery monitor dt-bindings: w1: document generic onewire bindings power: supply: adp5061: Fix a couple off by ones dt-bindings: power: reset: qcom: Add resin binding adp5061: New driver for ADP5061 I2C battery charger power: generic-adc-battery: check for duplicate properties copied from iio channels power: generic-adc-battery: fix out-of-bounds write when copying channel properties power: supply: axp288_charger: Fix initial constant_charge_current value power: supply: ab8500: stop using getnstimeofday64() power: gemini-poweroff: Avoid more spurious poweroffs power: vexpress: fix corruption in notifier registration power: remove possible deadlock when unregistering power_supply ...
2018-08-16Merge branch 'psy-fixes' into psy-nextSebastian Reichel
Signed-off-by: Sebastian Reichel <sre@kernel.org>
2018-07-24power: supply: bq27xxx: Update commentsLiu Xiang
The URL of bq27441-g1 and bq27426 are missing and bq27520-g4 is duplicated. Signed-off-by: Liu Xiang <liu.xiang6@zte.com.cn> Reviewed-by: Pali Rohár <pali.rohar@gmail.com> Acked-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-07-23power: supply: max77693_charger: fix unintentional fall-throughGustavo A. R. Silva
It seems that a *break* is missing in order to avoid a fall-through. Otherwise, the calculation of *data* makes no sense. Addresses-Coverity-ID: 1271172 ("Missing break in switch") Fixes: 87c2d9067893 ("power: max77693: Add charger driver for Maxim 77693") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-07-23power: supply: mark expected switch fall-throughsGustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 1394724 ("Missing break in switch") Addresses-Coverity-ID: 114958 ("Missing break in switch") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-07-22power: supply: lego_ev3_battery: fix Vce offsetDavid Lechner
This fixes the value that accounts for the Vce of a transistor in the LEGO MINDSTORMS EV3 power supply driver. The old value (200mV) was the max value from the data sheet. After testing, the actual value has been found to be 50mV. By using 50mV we get a more accurate voltage indication. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-07-22power: supply: lego_ev3_battery: Don't ignore iio_read_channel_processed() ↵David Lechner
return value This changes the LEGO MINDSTORMS EV3 power supply driver to return an error if iio_read_channel_processed() fails. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-07-22Merge tag 'ds2760-for-v4.19-signed' into psy-nextSebastian Reichel
Immutable branch for moving ds2760 driver from w1 to power supply Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-07-11power: supply: ds2760_battery: add devicetree probingDaniel Mack
Add a matching table for devicetree probing, and optionally set the module parameter variables from DT properties. Signed-off-by: Daniel Mack <daniel@zonque.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-07-11power: supply: ds2760_battery: merge ds2760 supply driver with its w1 slave ↵Daniel Mack
companion This patch removes the w1 slave driver that used to register the w1 family and instanciate a platform device at runtime. The code now lives in the supply driver instead to avoid that level of indirection. The old device name "ds2760-battery.0" is preserved, so userspace applications can access the same virtual device nodes as before. Note that because the w1 core does not currently have a framework for suspend/resume, the driver now registers a PM notifier callback. Signed-off-by: Daniel Mack <daniel@zonque.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-07-11power: supply: adp5061: Fix a couple off by onesDan Carpenter
We end up reading one element beyond the end of the adp5061_vmax[] array here. Fixes: fe8e81b7e899 ("adp5061: New driver for ADP5061 I2C battery charger") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-07-07headers: separate linux/mod_devicetable.h from linux/platform_device.hRandy Dunlap
At over 4000 #includes, <linux/platform_device.h> is the 9th most #included header file in the Linux kernel. It does not need <linux/mod_devicetable.h>, so drop that header and explicitly add <linux/mod_devicetable.h> to source files that need it. 4146 #include <linux/platform_device.h> After this patch, there are 225 files that use <linux/mod_devicetable.h>, for a reduction of around 3900 times that <linux/mod_devicetable.h> does not have to be read & parsed. 225 #include <linux/mod_devicetable.h> This patch was build-tested on 20 different arch-es. It also makes these drivers SubmitChecklist#1 compliant. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kbuild test robot <lkp@intel.com> # drivers/media/platform/vimc/ Reported-by: kbuild test robot <lkp@intel.com> # drivers/pinctrl/pinctrl-u300.c Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-07-06adp5061: New driver for ADP5061 I2C battery chargerStefan Popa
This patch adds basic support for Analog Devices I2C programmable linear battery charger. With this driver, some parameters can be read and configured such as: * trickle charge current level (PRECHARGE_CURRENT) * trickle charge voltage threshold (VOLTAGE_MIN) * weak charge threshold (VOLTAGE_AVG) * constant current (CONSTANT_CHARGE_CURRENT) * constant charge voltage limit (CONSTANT_CHARGE_VOLTAGE_MAX) * battery full (CAPACITY_LEVEL) * input current limit (INPUT_CURRENT_LIMIT) * charger status (STATUS) * battery status (CAPACITY_LEVEL) * termination current (CHARGE_TERM_CURRENT) Datasheet: http://www.analog.com/media/en/technical-documentation/data-sheets/ADP5061.pdf Signed-off-by: Stefan Popa <stefan.popa@analog.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-07-06power: generic-adc-battery: check for duplicate properties copied from iio ↵H. Nikolaus Schaller
channels If an iio channel defines a basic property, there are duplicate entries in /sys/class/power/*/uevent. So add a check to avoid duplicates. Since all channels may be duplicates, we have to modify the related error check. Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Cc: stable@vger.kernel.org Fixes: e60fea794e6e ("power: battery: Generic battery driver using IIO") Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-07-06power: generic-adc-battery: fix out-of-bounds write when copying channel ↵H. Nikolaus Schaller
properties We did have sporadic problems in the pinctrl framework during boot where a pin group name unexpectedly became NULL leading to a NULL dereference in strcmp. Detailled analysis of the failing cases did reveal that there were two devm allocated objects close to each other. The second one was the affected group_desc in pinmux and the first one was the psy_desc->properties buffer of the gab driver. Review of the gab code showed that the address calculation for one memcpy() is wrong. It does properties + sizeof(type) * index but C is defined to do the index multiplication already for pointer + integer additions. Hence the factor was applied twice and the memcpy() does write outside of the properties buffer. Sometimes it happened to be the pinctrl and triggered the strcmp(NULL). Anyways, it is overkill to use a memcpy() here instead of a simple assignment, which is easier to read and has less risk for wrong address calculations. So we change code to a simple assignment. If we initialize the index to the first free location, we can even remove the local variable 'properties'. This bug seems to exist right from the beginning in 3.7-rc1 in commit e60fea794e6e ("power: battery: Generic battery driver using IIO") Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Cc: stable@vger.kernel.org Fixes: e60fea794e6e ("power: battery: Generic battery driver using IIO") Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-07-06power: supply: axp288_charger: Fix initial constant_charge_current valueHans de Goede
We should look at val which contains the value read from the register, not ret which is always 0 on a successful read. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Fixes: eac53b3664f59 ("power: supply: axp288_charger: Drop platform_data dependency") Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-07-06power: supply: ab8500: stop using getnstimeofday64()Arnd Bergmann
getnstimeofday64() is deprecated in favor of the ktime_get() family. The direct replacement would be ktime_get_real_ts64(), but we only need the seconds value, and it seems better to use boottime than real time to avoid unexpected behavior with a concurrent settimeofday(). ktime_get_seconds() might also work, but it seems better to use boottime than monotonic time since I assume that the charging process continues during suspend. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-07-06power: gemini-poweroff: Avoid more spurious poweroffsLinus Walleij
Even after the previous fix I have experienced more spurious poweroffs on the gemini SoC. After this fix it finally seems to go away. Fixes: f7a388d6cd1c ("power: reset: Add a driver for the Gemini poweroff") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>