kernel/linux.git/drivers/power/supply, branch v5.6.17

power: supply: axp288_fuel_gauge: Broaden vendor check for Intel Compute Sticks.

2020-04-23T08:38:20+00:00

[ 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 Reviewed-by: Hans de Goede Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin

power: supply: bq27xxx_battery: Silence deferred-probe error

2020-04-23T08:38:03+00:00

[ 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 Reviewed-by: Andrew F. Davis Reviewed-by: Pali Rohár Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin

power: supply: axp288_charger: Add special handling for HP Pavilion x2 10

2020-04-08T07:11:08+00:00

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 Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman

Merge tag 'tag-chrome-platform-for-v5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux

2020-02-04T07:17:41+00:00

Pull chrome platform updates from Benson Leung: "CrOS EC: - Refactoring of some of cros_ec's headers: include/linux/mfd/cros_ec.h now removed, new cros_ec.h added to drivers/platform/chrome which contains shared operations of cros_ec transport drivers. - Response tracing in cros_ec_proto Wilco EC: - Fix unregistration order. - Fix keyboard backlight probing on systems without keyboard backlight - Minor cleanup (newlines in printks, COMPILE_TEST) Misc: - chromeos_laptop converted to use i2c_new_scanned_device instead of i2c_new_probed_device" * tag 'tag-chrome-platform-for-v5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux: platform/chrome: cros_ec: Match implementation with headers platform/chrome: cros_ec: Drop unaligned.h include platform/chrome: wilco_ec: Allow wilco to be compiled in COMPILE_TEST platform/chrome: wilco_ec: Add newlines to printks platform/chrome: wilco_ec: Fix unregistration order cros_ec: treewide: Remove 'include/linux/mfd/cros_ec.h' platform/chrome: cros_ec_ishtp: Make init_lock static platform/chrome: chromeos_laptop: Convert to i2c_new_scanned_device platform/chrome: cros_ec_lpc: Use platform_get_irq_optional() for optional IRQs platform/chrome: cros_ec_proto: Add response tracing platform/chrome: cros_ec_trace: Match trace commands with EC commands

power: supply: ipaq_micro_battery: remove unneeded semicolon

2020-01-17T01:13:00+00:00

Fixes coccicheck warning: ./drivers/power/supply/ipaq_micro_battery.c:188:2-3: Unneeded semicolon ./drivers/power/supply/ipaq_micro_battery.c:152:3-4: Unneeded semicolon ./drivers/power/supply/ipaq_micro_battery.c:171:2-3: Unneeded semicolon Signed-off-by: Chen Zhou Signed-off-by: Sebastian Reichel

power: supply: bq25890_charger: fix incorrect error return when bq25890_field_read fails

2020-01-16T19:35:57+00:00

Currently a read failure by bq25890_field_read on F_DEV_REV is returning an error in id instead of rev. Fix this by returning the value in rev. Addresses-Coverity: ("Copy-paste error") Fixes: d20267c9a98e ("power: supply: bq25890_charger: Add support of BQ25892 and BQ25896 chips") Signed-off-by: Colin Ian King Signed-off-by: Sebastian Reichel

power: supply: axp20x_usb_power: Only poll while offline

2020-01-15T20:41:38+00:00

Investigation on the AXP803 shows that VBUS_PLUGIN/VBUS_REMOVAL IRQs are triggered on the rising/falling edge of AXP20X_PWR_STATUS_VBUS_USED. The reason IRQs do not arrive while N_VBUSEN/DRIVEVBUS is high is because AXP20X_PWR_STATUS_VBUS_USED also never goes high. This also means that if VBUS is online, a VBUS_REMOVAL IRQ is received immediately on setting N_VBUSEN/DRIVEVBUS high (and VBUS_PLUGIN shortly after it is set back low). This was also verified to be the case when manually offlining VBUS through AXP20X_VBUS_PATH_SELECT. As long as VBUS is online, a present->absent transition necessarily implies an online->offline transition. Since will cause an IRQ, there is no need to poll while VBUS is online. To ensure the driver's view of VBUS online status remains accurate, unconditionally poll once when receiving an IRQ and when resuming. If VBUS is still online at that time, polling will cease until the next VBUS_REMOVAL IRQ. Reviewed-by: Chen-Yu Tsai Signed-off-by: Samuel Holland Signed-off-by: Sebastian Reichel

power: supply: axp20x_usb_power: Add wakeup control

2020-01-15T20:40:59+00:00

The USB power supply input can be used as a wakeup source. Hook up the VBUS_PLUGIN IRQ to trigger wakeup based on userspace configuration. To do this, we must remember the list of IRQs for the life of the device. To know how much space to allocate for the flexible array member, we switch from using a NULL sentinel to using an array length. Because we now depend on the specific order of the IRQs (we assume VBUS_PLUGIN is first and always present), failing to acquire an IRQ during probe must be a fatal error. To avoid spuriously waking up the system when the USB power supply is not configured as a wakeup source, we must explicitly disable all non- wake IRQs during system suspend. This is because the SoC's NMI input is shared among all IRQs on the AXP PMIC. Due to the use of regmap-irq, the individual IRQs within the PMIC are nested threaded interrupts, and are therefore not automatically disabled during system suspend. The upshot is that if any other device within the MFD (such as the power key) is an enabled wakeup source, all enabled IRQs within the PMIC will cause wakeup. We still need to call enable_irq_wake() when we *do* want wakeup, in case those other wakeup sources on the PMIC are all disabled. Reviewed-by: Chen-Yu Tsai Signed-off-by: Samuel Holland Signed-off-by: Sebastian Reichel

power: supply: axp20x_usb_power: Allow offlining

2020-01-15T20:37:45+00:00

AXP803/AXP813 have a flag that enables/disables the USB power supply input. Allow control of this flag via the ONLINE property on those variants. It may be necessary to offline the USB power supply input when using the USB port in OTG mode, or to allow userspace to disable charging. When the USB VBUS input is disabled via the PATH_SEL bit, the VBUS_USED bit in PWR_INPUT_STATUS is cleared, so there is no change needed when getting the property. Reviewed-by: Chen-Yu Tsai Signed-off-by: Samuel Holland Signed-off-by: Sebastian Reichel

power: supply: axp20x_usb_power: Use a match structure

2020-01-15T20:36:34+00:00

Instead of ad-hoc variant ID checks throughout the code, let's start moving the variant-specific details to a match structure. This allows for future flexibility, and it better matches the other axp20x power supply drivers. This commit removes most variant checks from axp20x_usb_power_probe(). Other parts of the driver still do ID matching; they are left unchanged for now. Reviewed-by: Chen-Yu Tsai Signed-off-by: Samuel Holland Signed-off-by: Sebastian Reichel