kernel/git/stable/linux.git/drivers/power, branch linux-5.13.y

power: supply: max17042: handle fails of reading status register

2021-09-18T11:41:46+00:00

commit 54784ffa5b267f57161eb8fbb811499f22a0a0bf upstream. Reading status register can fail in the interrupt handler. In such case, the regmap_read() will not store anything useful under passed 'val' variable and random stack value will be used to determine type of interrupt. Handle the regmap_read() failure to avoid handling interrupt type and triggering changed power supply event based on random stack value. Fixes: 39e7213edc4f ("max17042_battery: Support regmap to access device's registers") Cc: Signed-off-by: Krzysztof Kozlowski Reviewed-by: Hans de Goede Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman

power: supply: cw2015: use dev_err_probe to allow deferred probe

2021-09-15T08:00:32+00:00

[ Upstream commit ad1abe476995d97bfe7546ea91bb4f3dcdfbf3ab ] Deal with deferred probe using dev_err_probe so the error is handled and avoid logging lots probe defer information like the following: [ 9.125121] cw2015 4-0062: Failed to register power supply [ 9.211131] cw2015 4-0062: Failed to register power supply Fixes: b4c7715c10c1 ("power: supply: add CellWise cw2015 fuel gauge driver") Signed-off-by: Peter Robinson Reviewed-by: Javier Martinez Canillas Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin

power: supply: max17042_battery: fix typo in MAx17042_TOFF

2021-09-15T08:00:29+00:00

[ Upstream commit ed0d0a0506025f06061325cedae1bbebd081620a ] Signed-off-by: Sebastian Krzyszkowiak Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin

power: supply: smb347-charger: Add missing pin control activation

2021-09-15T08:00:29+00:00

[ Upstream commit efe2175478d5237949e33c84d9a722fc084b218c ] Pin control needs to be activated by setting the enable bit, otherwise hardware rejects all pin changes. Previously this stayed unnoticed on Nexus 7 because pin control was enabled by default after rebooting from downstream kernel, which uses driver that enables the bit and charger registers are non-volatile until power supply (battery) is disconnected. Configure the pin control enable bit. This fixes the potentially never-enabled charging on devices that use pin control. Signed-off-by: Dmitry Osipenko Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin

power: supply: axp288_fuel_gauge: Report register-address on readb / writeb errors

2021-09-15T08:00:27+00:00

[ Upstream commit caa534c3ba40c6e8352b42cbbbca9ba481814ac8 ] When fuel_gauge_reg_readb()/_writeb() fails, report which register we were trying to read / write when the error happened. Also reword the message a bit: - Drop the axp288 prefix, dev_err() already prints this - Switch from telegram / abbreviated style to a normal sentence, aligning the message with those from fuel_gauge_read_*bit_word() Signed-off-by: Hans de Goede Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin

power: supply: ab8500: Call battery population once

2021-08-08T07:06:53+00:00

[ Upstream commit 7e2bb83c617f8fccc04db7d03f105a06b9d491a9 ] The code was calling ab8500_bm_of_probe() in four different spots effectively overwriting the same configuration three times. This was done because probe order was uncertain. Since we now used componentized probe, call it only once while probing the main charging component. Signed-off-by: Linus Walleij Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin

power: supply: rt5033_battery: Fix device tree enumeration

2021-07-20T14:00:28+00:00

[ Upstream commit f3076cd8d1d5fa64b5e1fa5affc045c2fc123baa ] The fuel gauge in the RT5033 PMIC has its own I2C bus and interrupt line. Therefore, it is not actually part of the RT5033 MFD and needs its own of_match_table to probe properly. Also, given that it's independent of the MFD, there is actually no need to make the Kconfig depend on MFD_RT5033. Although the driver uses the shared header, there is no compile or runtime dependency on the RT5033 MFD driver. Cc: Beomho Seo Cc: Chanwoo Choi Fixes: b847dd96e659 ("power: rt5033_battery: Add RT5033 Fuel gauge device driver") Signed-off-by: Stephan Gerhold Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin

power: supply: surface-charger: Fix type of integer variable

2021-07-20T14:00:28+00:00

[ Upstream commit 601423bc0c06467d019cf2a446962a5bf1b5e330 ] The ac->state field is __le32, not u32. So change the variable we're temporarily storing it in to __le32 as well. Reported-by: kernel test robot Fixes: e61ffb344591 ("power: supply: Add AC driver for Surface Aggregator Module") Signed-off-by: Maximilian Luz Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin

power: supply: surface_battery: Fix battery event handling

2021-07-20T14:00:27+00:00

[ Upstream commit e633f33d2669cb54db2846f9cde08662d254dbd3 ] The battery subsystem of the Surface Aggregator Module EC requires us to register the battery notifier with instance ID 0. However, battery events are actually sent with the instance ID corresponding to the device, which is nonzero. Thus, the strict-matching approach doesn't work here and will discard events that the driver is expected to handle. To fix this we have to fall back on notifier matching by target-category only and have to manually check the instance ID in the notifier callback. Fixes: 167f77f7d0b3 ("power: supply: Add battery driver for Surface Aggregator Module") Signed-off-by: Maximilian Luz Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin

power: supply: axp288_fuel_gauge: Make "T3 MRD" no_battery_list DMI entry more generic

2021-07-20T14:00:26+00:00

[ Upstream commit 3a06b912a5ce494d7b7300b12719c562be7b566f ] It turns out that the "T3 MRD" DMI_BOARD_NAME value is used in a lot of different Cherry Trail x5-z8300 / x5-z8350 based Mini-PC / HDMI-stick models from Ace PC / Meegopad / MinisForum / Wintel (and likely also other vendors). Most of the other DMI strings on these boxes unfortunately contain various generic values like "Default string" or "$(DEFAULT_STRING)", so we cannot match on them. These devices do have their chassis-type correctly set to a value of "3" (desktop) which is a pleasant surprise, so also match on that. This should avoid the quirk accidentally also getting applied to laptops / tablets (which do actually have a battery). Although in my quite large database of Bay and Cherry Trail based devices DMIdecode dumps I don't have any laptops / tables with a board-name of "T3 MRD", so this should not be an issue. BugLink: https://askubuntu.com/questions/1206714/how-can-a-mini-pc-be-stopped-from-being-detected-as-a-laptop-with-a-battery/ Signed-off-by: Hans de Goede Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin