summaryrefslogtreecommitdiff
path: root/drivers/power
AgeCommit message (Collapse)AuthorFilesLines
2021-03-04power: reset: at91-sama5d2_shdwc: fix wkupdbc maskClaudiu Beznea1-1/+1
[ Upstream commit 95aa21a3f1183260db1b0395e03df5bebc5ed641 ] According to datasheet WKUPDBC mask is b/w bits 26..24. Fixes: f80cb48843987 ("power: reset: at91-shdwc: add new shutdown controller driver") Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30power: supply: bq24190_charger: fix reference leakZhang Qilong1-5/+15
[ Upstream commit b2f6cb78eaa1cad57dd3fe11d0458cd4fae9a584 ] pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to call pm_runtime_put_noidle will result in reference leak in callers(bq24190_sysfs_show, bq24190_charger_get_property, bq24190_charger_set_property, bq24190_battery_get_property, bq24190_battery_set_property), so we should fix it. Fixes: f385e6e2a1532 ("power: bq24190_charger: Use PM runtime autosuspend") Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30power: supply: axp288_charger: Fix HP Pavilion x2 10 DMI matchingHans de Goede1-11/+17
[ Upstream commit a0f1ccd96c7049377d892a4299b6d5e47ec9179d ] Commit 9c80662a74cd ("power: supply: axp288_charger: Add special handling for HP Pavilion x2 10") added special handling for HP Pavilion x2 10 models which use the weird combination of a Type-C connector and the non Type-C aware AXP288 PMIC. This special handling was activated by a DMI match a the product-name of "HP Pavilion x2 Detachable". Recently I've learned that there are also older "HP Pavilion x2 Detachable" models with an AXP288 PMIC + a micro-usb connector where we should not activate the special handling for the Type-C connectors. Extend the matching to also match on the DMI board-name and match on the 2 boards (one Bay Trail based one Cherry Trail based) of which we are certain that they use the AXP288 + Type-C connector combination. Note the DSDT code from these older (AXP288 + micro-USB) models contains some AML code (which never runs under Linux) which reads the micro-USB connector id-pin and if it is pulled to ground, which would normally mean the port is in host mode!, then it sets the input-current-limit to 3A, it seems HP is using the micro-USB port as a charging only connector and identifies their own 3A capable charger though this hack which is a major violation of the USB specs. Note HP also hardcodes a 2A limit when the id-pin is not pulled to ground, which is also in violation of the specs. I've no intention to add support for HP's hack to support 3A charging on these older models. By making the DMI matches for the Type-C equipped models workaround more tighter, these older models will be treated just like any other AXP288 + micro-USB equipped device and the input-current limit will follow the BC 1.2 spec (using the defacto standard values there where the BC 1.2 spec defines a range). Fixes: 9c80662a74cd ("power: supply: axp288_charger: Add special handling for HP Pavilion x2 10") BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1896924 Signed-off-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-11-05power: supply: test_power: add missing newlines when printing parameters by ↵Xiongfeng Wang1-0/+6
sysfs [ Upstream commit c07fa6c1631333f02750cf59f22b615d768b4d8f ] When I cat some module parameters by sysfs, it displays as follows. It's better to add a newline for easy reading. root@syzkaller:~# cd /sys/module/test_power/parameters/ root@syzkaller:/sys/module/test_power/parameters# cat ac_online onroot@syzkaller:/sys/module/test_power/parameters# cat battery_present trueroot@syzkaller:/sys/module/test_power/parameters# cat battery_health goodroot@syzkaller:/sys/module/test_power/parameters# cat battery_status dischargingroot@syzkaller:/sys/module/test_power/parameters# cat battery_technology LIONroot@syzkaller:/sys/module/test_power/parameters# cat usb_online onroot@syzkaller:/sys/module/test_power/parameters# Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-05power: supply: bq27xxx: report "not charging" on all typesKrzysztof Kozlowski1-2/+4
[ Upstream commit 7bf738ba110722b63e9dc8af760d3fb2aef25593 ] Commit 6f24ff97e323 ("power: supply: bq27xxx_battery: Add the BQ27Z561 Battery monitor") and commit d74534c27775 ("power: bq27xxx_battery: Add support for additional bq27xxx family devices") added support for new device types by copying most of the code and adding necessary quirks. However they did not copy the code in bq27xxx_battery_status() responsible for returning POWER_SUPPLY_STATUS_NOT_CHARGING. Unify the bq27xxx_battery_status() so for all types when charger is supplied, it will return "not charging" status. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-01power: supply: max17040: Correct voltage readingJonathan Bakker1-1/+1
[ 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 Rix1-2/+4
[ 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-24power: supply: smb347-charger: IRQSTAT_D is volatileDmitry Osipenko1-0/+1
[ 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-24power: supply: lp8788: Fix an error handling path in 'lp8788_charger_probe()'Christophe JAILLET1-16/+2
[ 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-24power: supply: bq24257_charger: Replace depends on REGMAP_I2C with selectEnric Balletbo i Serra1-1/+1
[ 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: supply: core: fix memory leak in HWMON error pathQiushi Wu1-1/+1
commit 1d7a7128a2e9e1f137c99b0a44e94d70a77343e3 upstream. In function power_supply_add_hwmon_sysfs(), psyhw->props is allocated by bitmap_zalloc(). But this pointer is not deallocated when devm_add_action fail, which lead to a memory leak bug. To fix this, we replace devm_add_action with devm_add_action_or_reset. Cc: stable@kernel.org Fixes: e67d4dfc9ff19 ("power: supply: Add HWMON compatibility layer") Signed-off-by: Qiushi Wu <wu000273@umn.edu> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-22power: supply: core: fix HWMON temperature labelsMichał Mirosław1-1/+1
commit 6b20464ad9fb5fd76ef6f219ce62156aa9639dcc upstream. tempX_label files are swapped compared to what power_supply_hwmon_temp_to_property() uses. Make them match. Cc: stable@vger.kernel.org Fixes: e67d4dfc9ff1 ("power: supply: Add HWMON compatibility layer") Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-22power: vexpress: add suppress_bind_attrs to trueAnders Roxell1-0/+1
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 Miller1-2/+2
[ 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 Osipenko1-1/+4
[ 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-08power: supply: axp288_charger: Add special handling for HP Pavilion x2 10Hans de Goede1-1/+56
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 Asbroeck1-1/+1
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-02-11power: supply: axp20x_ac_power: Fix reporting online statusSamuel Holland1-6/+25
commit 1c51aad8475d670ad58ae60adc9d32342381df8d upstream. AXP803/AXP813 have a flag that enables/disables the AC power supply input. This flag does not affect the status bits in PWR_INPUT_STATUS. Its effect can be verified by checking the battery charge/discharge state (bit 2 of PWR_INPUT_STATUS), or by examining the current draw on the AC input. Take this flag into account when getting the ONLINE property of the AC input, on PMICs where this flag is present. Fixes: 7693b5643fd2 ("power: supply: add AC power supply driver for AXP813") Cc: stable@vger.kernel.org Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-01power/supply: ingenic-battery: Don't change scale if there's only onePaul Cercueil1-4/+11
commit 86b9182df8bb12610d4d6feac45a69f3ed57bfd2 upstream. The ADC in the JZ4740 can work either in high-precision mode with a 2.5V range, or in low-precision mode with a 7.5V range. The code in place in this driver will select the proper scale according to the maximum voltage of the battery. The JZ4770 however only has one mode, with a 6.6V range. If only one scale is available, there's no need to change it (and nothing to change it to), and trying to do so will fail with -EINVAL. Fixes: fb24ccfbe1e0 ("power: supply: add Ingenic JZ47xx battery driver.") Signed-off-by: Paul Cercueil <paul@crapouillou.net> Acked-by: Artur Rojek <contact@artur-rojek.eu> Cc: stable@vger.kernel.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-26power: supply: bd70528: Add MODULE_ALIAS to allow module auto loadingMatti Vaittinen1-0/+1
[ Upstream commit 9480029fe5c24d482efad38dc631bd555fc7afe2 ] The bd70528 charger driver is probed by MFD driver. Add MODULE_ALIAS in order to allow udev to load the module when MFD sub-device cell for charger is added. Fixes: f8c7f7ddd8ef0 ("power: supply: Initial support for ROHM BD70528 PMIC charger block") Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31power: supply: cpcap-battery: Check voltage before orderly_poweroffTony Lindgren1-3/+5
[ Upstream commit 639c1524da3b273d20c42ff2387d08eb4b12e903 ] We can get the low voltage interrupt trigger sometimes way too early, maybe because of CPU load spikes. This causes orderly_poweroff() be called too easily. Let's check the voltage before orderly_poweroff in case it was not yet a permanent condition. We will be getting more interrupts anyways if the condition persists. Let's also show the measured voltages for low battery and battery empty warnings since we have them. Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Pavel Machek <pavel@ucw.cz> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-09-22Merge tag 'for-v5.4' of ↵Linus Torvalds13-116/+232
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply Pull power supply and reset updates from Sebastian Reichel: "Core: - Ensure HWMON devices are registered with valid names - Fix device wakeup code Drivers: - bq25890_charger: Add BQ25895 support - axp288_fuel_gauge: Add Minix Neo Z83-4 to blacklist - sc27xx: improve battery calibration - misc small fixes all over drivers" * tag 'for-v5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: (24 commits) power: supply: cpcap-charger: Enable vbus boost voltage power: supply: sc27xx: Add POWER_SUPPLY_PROP_CALIBRATE attribute power: supply: sc27xx: Optimize the battery capacity calibration power: supply: sc27xx: Make sure the alarm capacity is larger than 0 power: supply: sc27xx: Fix the the accuracy issue of coulomb calculation power: supply: sc27xx: Fix conditon to enable the FGU interrupt power: supply: sc27xx: Add POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN attribute power: supply: max77650: add MODULE_ALIAS() power: supply: isp1704: remove redundant assignment to variable ret power: supply: bq25890_charger: Add the BQ25895 part power: supply: sc27xx: Replace devm_add_action() followed by failure action with devm_add_action_or_reset() power: supply: sc27xx: Introduce local variable 'struct device *dev' power: reset: reboot-mode: Fix author email format power: supply: ab8500: remove set but not used variables 'vbup33_vrtcn' and 'bup_vch_range' power: supply: max17042_battery: Fix a typo in function names power: reset: gpio-restart: Fix typo when gpio reset is not found power: supply: Init device wakeup after device_add() power: supply: ab8500_charger: Mark expected switch fall-through power: supply: sbs-battery: only return health when battery present MAINTAINERS: N900: Remove isp1704_charger.h record ...
2019-09-22Merge tag 'mips_5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linuxLinus Torvalds3-433/+0
Pull MIPS updates from Paul Burton: "Main MIPS changes: - boot_mem_map is removed, providing a nice cleanup made possible by the recent removal of bootmem. - Some fixes to atomics, in general providing compiler barriers for smp_mb__{before,after}_atomic plus fixes specific to Loongson CPUs or MIPS32 systems using cmpxchg64(). - Conversion to the new generic VDSO infrastructure courtesy of Vincenzo Frascino. - Removal of undefined behavior in set_io_port_base(), fixing the behavior of some MIPS kernel configurations when built with recent clang versions. - Initial MIPS32 huge page support, functional on at least Ingenic SoCs. - pte_special() is now supported for some configurations, allowing among other things generic fast GUP to be used. - Miscellaneous fixes & cleanups. And platform specific changes: - Major improvements to Ingenic SoC support from Paul Cercueil, mostly enabled by the inclusion of the new TCU (timer-counter unit) drivers he's spent a very patient year or so working on. Plus some fixes for X1000 SoCs from Zhou Yanjie. - Netgear R6200 v1 systems are now supported by the bcm47xx platform. - DT updates for BMIPS, Lantiq & Microsemi Ocelot systems" * tag 'mips_5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux: (89 commits) MIPS: Detect bad _PFN_SHIFT values MIPS: Disable pte_special() for MIPS32 with RiXi MIPS: ralink: deactivate PCI support for SOC_MT7621 mips: compat: vdso: Use legacy syscalls as fallback MIPS: Drop Loongson _CACHE_* definitions MIPS: tlbex: Remove cpu_has_local_ebase MIPS: tlbex: Simplify r3k check MIPS: Select R3k-style TLB in Kconfig MIPS: PCI: refactor ioc3 special handling mips: remove ioremap_cachable mips/atomic: Fix smp_mb__{before,after}_atomic() mips/atomic: Fix loongson_llsc_mb() wreckage mips/atomic: Fix cmpxchg64 barriers MIPS: Octeon: remove duplicated include from dma-octeon.c firmware: bcm47xx_nvram: Allow COMPILE_TEST firmware: bcm47xx_nvram: Correct size_t printf format MIPS: Treat Loongson Extensions as ASEs MIPS: Remove dev_err() usage after platform_get_irq() MIPS: dts: mscc: describe the PTP ready interrupt MIPS: dts: mscc: describe the PTP register range ...
2019-09-20Merge tag 'tag-chrome-platform-for-v5.4' of ↵Linus Torvalds2-3/+4
git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux Pull chrome platform updates from Benson Leung: "CrOS EC / MFD Migration: - Move cros_ec core driver from mfd into chrome platform. Wilco EC: - Add batt_ppid_info command to Wilco telemetry driver. CrOS EC: - cros_ec_rpmsg : Add support to inform EC of suspend/resume status - cros_ec_rpmsg : Fix race condition on probe failed - cros_ec_chardev : Add a poll handler to receive MKBP events Misc: - bugfixes in cros_usbpd_logger and cros_ec_ishtp" * tag 'tag-chrome-platform-for-v5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux: platform/chrome: cros_usbpd_logger: null check create_singlethread_workqueue platform/chrome: cros_ec_chardev: Add a poll handler to receive MKBP events platform/chrome: cros_ec_rpmsg: Fix race with host command when probe failed platform/chrome: chromeos_tbmc: Report wake events mfd: cros_ec: Use mfd_add_hotplug_devices() helper mfd: cros_ec: Add convenience struct to define autodetectable CrOS EC subdevices mfd: cros_ec: Add convenience struct to define dedicated CrOS EC MCUs mfd: cros_ec: Use kzalloc and cros_ec_cmd_xfer_status helper mfd / platform: cros_ec: Reorganize platform and mfd includes mfd / platform: cros_ec: Rename config to a better name mfd: cros_ec: Switch to use the new cros-ec-chardev driver mfd / platform: cros_ec: Miscellaneous character device to talk with the EC mfd / platform: cros_ec: Move cros-ec core driver out from MFD mfd / platform: cros_ec: Handle chained ECs as platform devices platform/chrome: cros_ec_rpmsg: Add host command AP sleep state support platform/chrome: chromeos_laptop: drop checks of NULL-safe functions platform/chrome: wilco_ec: Add batt_ppid_info command to telemetry driver
2019-09-03power: supply: cpcap-charger: Enable vbus boost voltageTony Lindgren1-3/+20
We are currently not enabling VBUS boost for cpcap when in host mode. This means the VBUS is fed at the battery voltage level, which can cause flakeyness enumerating devices. Looks like the boost control for VBUS is CPCAP_BIT_VBUS_SWITCH that we must enable in the charger for nice 4.92 V VBUS output. And looks like we must not use the STBY pin enabling but must instead use manual VBUS control in phy-cpcap-usb. We want to do this in cpcap_charger_vbus_work() and also set a flag for feeding_vbus to avoid races between USB detection and charger detection, and disable charging if feeding_vbus is set. Cc: Jacopo Mondi <jacopo@jmondi.org> Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: Marcel Partap <mpartap@gmx.net> Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Michael Scott <hashcode0f@gmail.com> Cc: NeKit <nekit1000@gmail.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-09-03power: supply: sc27xx: Add POWER_SUPPLY_PROP_CALIBRATE attributeYuanjiang Yu1-8/+19
Add the 'POWER_SUPPLY_PROP_CALIBRATE' attribute to allow chareger manager to calibrate the battery capacity. Signed-off-by: Yuanjiang Yu <yuanjiang.yu@unisoc.com> Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-09-02power: supply: sc27xx: Optimize the battery capacity calibrationYuanjiang Yu1-35/+92
This patch factors out the capacity calibration into one single function to calibrate the battery capacity, and adding more abnormal cases to calibrate the capacity when the OCV value is not matchable with current capacity. Moreover we also allow to calibrate the capacity when charger magager tries to get current capacity to make sure we give a correct capacity for userspace. Signed-off-by: Yuanjiang Yu <yuanjiang.yu@unisoc.com> Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-09-02power: supply: sc27xx: Make sure the alarm capacity is larger than 0Yuanjiang Yu1-0/+2
We must make sure the alarm capacity is larger than 0, to help to calibrate the low battery capacity. Signed-off-by: Yuanjiang Yu <yuanjiang.yu@unisoc.com> Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-09-02power: supply: sc27xx: Fix the the accuracy issue of coulomb calculationYuanjiang Yu1-7/+4
The Spreadtrum fuel gauge will multiply by 2 for counting the coulomb counter to improve the accuracy, which means the value saved in fuel gauge is: coulomb counter * 2 * 1000ma_adc. Thus fix the conversion formular to improve the accuracy of calculating the battery capacity. Signed-off-by: Yuanjiang Yu <yuanjiang.yu@unisoc.com> Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-09-02power: supply: sc27xx: Fix conditon to enable the FGU interruptYuanjiang Yu1-1/+2
We should allow to enable FGU interrupt to adjust the battery capacity, when charging status is POWER_SUPPLY_STATUS_DISCHARGING. Signed-off-by: Yuanjiang Yu <yuanjiang.yu@unisoc.com> Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-09-02power: supply: sc27xx: Add POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN attributeYuanjiang Yu1-0/+5
Add POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN attribute to provide the battery's design capacity for charger manager to calculate the charging counter. Signed-off-by: Yuanjiang Yu <yuanjiang.yu@unisoc.com> Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-09-02power: supply: max77650: add MODULE_ALIAS()Bartosz Golaszewski1-0/+1
Define a MODULE_ALIAS() in the charger sub-driver for max77650 so that the appropriate module gets loaded together with the core mfd driver. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-09-02power: supply: isp1704: remove redundant assignment to variable retColin Ian King1-1/+1
The variable ret is being assigned with a value that is never read and it is being updated later with a new value. The assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-09-02power: supply: bq25890_charger: Add the BQ25895 partAngus Ainslie (Purism)1-4/+8
The BQ25895 is almost identical to the BQ25890. Signed-off-by: Angus Ainslie (Purism) <angus@akkea.ca> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-09-02power: supply: sc27xx: Replace devm_add_action() followed by failure action ↵Fuqian Huang1-2/+1
with devm_add_action_or_reset() devm_add_action_or_reset() is introduced as a helper function which internally calls devm_add_action(). If devm_add_action() fails then it will execute the action mentioned and return the error code. This reduce source code size (avoid writing the action twice) and reduce the likelyhood of bugs. Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com> Reviewed-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-09-02power: supply: sc27xx: Introduce local variable 'struct device *dev'Fuqian Huang1-23/+24
Introduce local variable 'struct device *dev' and use it instead of dereferencing it repeatly. Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com> Reviewed-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-09-02power: reset: reboot-mode: Fix author email formatMatwey V. Kornilov1-1/+1
Closing angle bracket was missing. Signed-off-by: Matwey V. Kornilov <matwey@sai.msu.ru> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-09-02power: supply: ab8500: remove set but not used variables 'vbup33_vrtcn' and ↵YueHaibing1-7/+0
'bup_vch_range' Fixes gcc '-Wunused-but-set-variable' warnings: drivers/power/supply/ab8500_charger.c: In function ab8500_charger_init_hw_registers: drivers/power/supply/ab8500_charger.c:3013:24: warning: variable vbup33_vrtcn set but not used [-Wunused-but-set-variable] drivers/power/supply/ab8500_charger.c:3013:5: warning: variable bup_vch_range set but not used [-Wunused-but-set-variable] Fixes: 4c4268dc97c4 ("power: supply: ab8500: Drop AB8540/9540 support") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-09-02power: supply: max17042_battery: Fix a typo in function namesChristophe JAILLET1-4/+4
It is likely that 'max10742_[un]lock_model()' functions should be 'max17042_[un]lock_model()' (0 and 7 switched in 10742) Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-09-02power: reset: gpio-restart: Fix typo when gpio reset is not foundMichal Simek1-1/+1
Trivial patch which just corrects error message. Fixes: 371bb20d6927 ("power: Add simple gpio-restart driver") Signed-off-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-09-02mfd / platform: cros_ec: Reorganize platform and mfd includesEnric Balletbo i Serra1-2/+3
There is a bit of mess between cros-ec mfd includes and platform includes. For example, we have a linux/mfd/cros_ec.h include that exports the interface implemented in platform/chrome/cros_ec_proto.c. Or we have a linux/mfd/cros_ec_commands.h file that is non related to the multifunction device (in the sense that is not exporting any function of the mfd device). This causes crossed includes between mfd and platform/chrome subsystems and makes the code difficult to read, apart from creating 'curious' situations where a platform/chrome driver includes a linux/mfd/cros_ec.h file just to get the exported functions that are implemented in another platform/chrome driver. In order to have a better separation on what the cros-ec multifunction driver does and what the cros-ec core provides move and rework the affected includes doing: - Move cros_ec_commands.h to include/linux/platform_data/cros_ec_commands.h - Get rid of the parts that are implemented in the platform/chrome/cros_ec_proto.c driver from include/linux/mfd/cros_ec.h to a new file include/linux/platform_data/cros_ec_proto.h - Update all the drivers with the new includes, so - Drivers that only need to know about the protocol include - linux/platform_data/cros_ec_proto.h - linux/platform_data/cros_ec_commands.h - Drivers that need to know about the cros-ec mfd device also include - linux/mfd/cros_ec.h Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Tested-by: Gwendal Grignou <gwendal@chromium.org> Series changes: 3 - Fix dereferencing pointer to incomplete type 'struct cros_ec_dev' (lkp) Signed-off-by: Lee Jones <lee.jones@linaro.org>
2019-09-02mfd / platform: cros_ec: Move cros-ec core driver out from MFDEnric Balletbo i Serra1-1/+1
Now, the ChromeOS EC core driver has nothing related to an MFD device, so move that driver from the MFD subsystem to the platform/chrome subsystem. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Thierry Reding <thierry.reding@gmail.com> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Tested-by: Gwendal Grignou <gwendal@chromium.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2019-09-02power: supply: Init device wakeup after device_add()Stephen Boyd1-5/+5
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>
2019-09-02power: supply: ab8500_charger: Mark expected switch fall-throughGustavo A. R. Silva1-0/+1
Mark switch cases where we are expecting to fall through. This patch fixes the following warning (Building: allmodconfig arm): drivers/power/supply/ab8500_charger.c:738:6: warning: this statement may fall through [-Wimplicit-fallthrough=] Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-09-02power: supply: sbs-battery: only return health when battery presentMichael Nosthoff1-9/+16
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>
2019-09-02power: supply: sbs-battery: use correct flags fieldMichael Nosthoff1-1/+1
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>
2019-09-01power: supply: axp288_fuel_gauge: Add Minix Neo Z83-4 to the blacklistHans de Goede1-0/+7
The Minix Neo Z83-4 is another mini PC using the AXP288 PMIC where the EFI code does not disable the charger part of the PMIC causing us to report battery readings (of always 100%) to userspace even though there is no battery in this wall-outlet powered device. Add it to the blacklist to avoid the bogus battery status reporting. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-09-01power: supply: axp288_fuel_gauge: Sort the DMI blacklist alphabeticallyHans de Goede1-6/+7
The blacklist is getting big enough that it is good to have some sort of fixed order for it, sort it alphabetically. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-09-01power: supply: register HWMON devices with valid namesRomain Izard1-1/+14
With the introduction of the HWMON compatibility layer to the power supply framework in Linux 5.3, all power supply devices' names can be used directly to create HWMON devices with the same names. But HWMON has rules on allowable names that are different from those used in the power supply framework. The dash character is forbidden, as it is used by the libsensors library in userspace as a separator, whereas this character is used in the device names in more than half of the existing power supply drivers. This last case is consistent with the typical naming usage with MFD and Device Tree. This leads to warnings in the kernel log, with the format: power_supply gpio-charger: hwmon: \ 'gpio-charger' is not a valid name attribute, please fix Add a protection to power_supply_add_hwmon_sysfs() that replaces any dash in the device name with an underscore when registering with the HWMON framework. Other forbidden characters (star, slash, space, tab, newline) are not replaced, as they are not in common use. Fixes: e67d4dfc9ff1 ("power: supply: Add HWMON compatibility layer") Signed-off-by: Romain Izard <romain.izard.pro@gmail.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-08-21power: supply: ab8500_charger: Mark expected switch fall-throughGustavo A. R. Silva1-0/+1
Mark switch cases where we are expecting to fall through. Fix the following warning (Building: allmodconfig arm): drivers/power/supply/ab8500_charger.c: In function ‘ab8500_charger_max_usb_curr’: drivers/power/supply/ab8500_charger.c:738:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (di->vbus_detected) { ^ drivers/power/supply/ab8500_charger.c:745:2: note: here case USB_STAT_HM_IDGND: ^~~~ Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
generated by cgit v1.2.3 (git 2.39.0) at 2026-01-23 15:57:41 +0300