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

power/reset: arm-versatile: Fix refcount leak in versatile_reboot_probe

2022-07-29T15:27:58+00:00

[ Upstream commit 80192eff64eee9b3bc0594a47381937b94b9d65a ] of_find_matching_node_and_match() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: 0e545f57b708 ("power: reset: driver for the Versatile syscon reboot") Signed-off-by: Miaoqian Lin Reviewed-by: Linus Walleij Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin

power: supply: ab8500_fg: add missing destroy_workqueue in ab8500_fg_probe

2022-07-29T15:27:58+00:00

[ Upstream commit 0f5de2f0532229752d923c769a5b202ae437523b ] In ab8500_fg_probe, misses destroy_workqueue in error path, this patch fixes that. Fixes: 010ddb813f35 ("power: supply: ab8500_fg: Allocate wq in probe") Signed-off-by: Gao Chao Reviewed-by: Linus Walleij Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin

power: supply: core: Fix boundary conditions in interpolation

2022-07-22T08:21:57+00:00

commit 093d27bb6f2d1963f927ef59c9a2d37059175426 upstream. The functions power_supply_temp2resist_simple and power_supply_ocv2cap_simple handle boundary conditions incorrectly. The change was introduced in a4585ba2050f460f749bbaf2b67bd56c41e30283 ("power: supply: core: Use library interpolation"). There are two issues: First, the lines "high = i - 1" and "high = i" in ocv2cap have the wrong order compared to temp2resist. As a consequence, ocv2cap sets high=-1 if ocv>table[0].ocv, which causes an out-of-bounds read. Second, the logic of temp2resist is also not correct. Consider the case table[] = {{20, 100}, {10, 80}, {0, 60}}. For temp=5, we expect a resistance of 70% by interpolation. However, temp2resist sets high=low=2 and returns 60. Cc: stable@vger.kernel.org Signed-off-by: Dorian Rudolph Reviewed-by: Linus Walleij Fixes: a4585ba2050f ("power: supply: core: Use library interpolation") Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman

extcon: Fix extcon_get_extcon_dev() error handling

2022-06-14T16:45:11+00:00

[ Upstream commit 58e4a2d27d3255e4e8c507fdc13734dccc9fc4c7 ] The extcon_get_extcon_dev() function returns error pointers on error, NULL when it's a -EPROBE_DEFER defer situation, and ERR_PTR(-ENODEV) when the CONFIG_EXTCON option is disabled. This is very complicated for the callers to handle and a number of them had bugs that would lead to an Oops. In real life, there are two things which prevented crashes. First, error pointers would only be returned if there was bug in the caller where they passed a NULL "extcon_name" and none of them do that. Second, only two out of the eight drivers will build when CONFIG_EXTCON is disabled. The normal way to write this would be to return -EPROBE_DEFER directly when appropriate and return NULL when CONFIG_EXTCON is disabled. Then the error handling is simple and just looks like: dev->edev = extcon_get_extcon_dev(acpi_dev_name(adev)); if (IS_ERR(dev->edev)) return PTR_ERR(dev->edev); For the two drivers which can build with CONFIG_EXTCON disabled, then extcon_get_extcon_dev() will now return NULL which is not treated as an error and the probe will continue successfully. Those two drivers are "typec_fusb302" and "max8997-battery". In the original code, the typec_fusb302 driver had an 800ms hang in tcpm_get_current_limit() but now that function is a no-op. For the max8997-battery driver everything should continue working as is. Signed-off-by: Dan Carpenter Reviewed-by: Hans de Goede Reviewed-by: Heikki Krogerus Reviewed-by: Guenter Roeck Acked-by: Sebastian Reichel Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin

power: supply: ab8500_fg: Allocate wq in probe

2022-06-14T16:44:49+00:00

[ Upstream commit 010ddb813f3554cbbf8bd13b731452236a2c8017 ] The workqueue is allocated in bind() but all interrupts are registered in probe(). Some interrupts put work on the workqueue, which can have bad side effects. Allocate the workqueue in probe() instead, destroy it in .remove() and make unbind() simply flush the workqueue. Fixes: 1c1f13a006ed ("power: supply: ab8500: Move to componentized binding") Signed-off-by: Linus Walleij Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin

power: supply: axp288_fuel_gauge: Drop BIOS version check from "T3 MRD" DMI quirk

2022-06-14T16:44:49+00:00

[ Upstream commit f61509a6f0b70f5bedea34efaf8065621689bd7a ] Some "T3 MRD" mini-PCs / HDMI-sticks without a battery use a different value then "5.11" for their DMI BIOS version field. Drop the BIOS version check so that the no-battery "T3 MRD" DMI quirk applies to these too. Fixes: 3a06b912a5ce ("power: supply: axp288_fuel_gauge: Make "T3 MRD" no_battery_list DMI entry more generic") Signed-off-by: Hans de Goede Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin

power: supply: axp288_fuel_gauge: Fix battery reporting on the One Mix 1

2022-06-14T16:44:49+00:00

[ Upstream commit 34f243e9fb5ace1ca760c72e366247eaeff430c0 ] Commit 3a06b912a5ce ("power: supply: axp288_fuel_gauge: Make "T3 MRD" no_battery_list DMI entry more generic") added a generic no-battery DMI match for many mini-PCs / HDMI-sticks which use "T3 MRD" as their DMI board-name. It turns out that the One Mix 1 mini laptop also uses "T3 MRD" for its DMI boardname and it also has its chassis-type wrongly set to a value of "3" (desktop). This was causing the axp288_fuel_gauge driver to disable battery reporting because this matches the no-battery DMI list entry for generic "T3 MRD" mini-PCs. Change the no-battery DMI list into a quirks DMI list and add a specific match for the One Mix 1 mini laptop before the generic "T3 MRD" no-battery quirk entry to fix this. Fixes: 3a06b912a5ce ("power: supply: axp288_fuel_gauge: Make "T3 MRD" no_battery_list DMI entry more generic") Signed-off-by: Hans de Goede Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin

power: supply: core: Initialize struct to zero

2022-06-14T16:44:48+00:00

[ Upstream commit e56a4be2843c95c08cf8421dc1f8e880cafbaf91 ] As we rely on pointers in the battery info to be zero-initialized such as in the helper function power_supply_supports_vbat2ri() we certainly need to allocate the struct power_supply_battery_info with kzalloc() as well. Else this happens: Unable to handle kernel paging request at virtual address 00280000 (...) PC is at power_supply_vbat2ri+0x50/0x12c LR is at ab8500_fg_battery_resistance+0x34/0x108 Fixes: e9e7d165b4b0 ("power: supply: Support VBAT-to-Ri lookup tables") Signed-off-by: Linus Walleij Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin

power: supply: Reset err after not finding static battery

2022-04-13T10:05:22+00:00

Otherwise power_supply_get_battery_info always returns -ENODEV on devices that do not have a static battery, even when a simple battery is found. Fixes: c8aee3f41cb8 ("power: supply: Static data for Samsung batteries") Signed-off-by: Yassine Oudjana Reviewed-by: Linus Walleij Signed-off-by: Sebastian Reichel

power: supply: samsung-sdi-battery: Add missing charge restart voltages

2022-04-13T10:05:22+00:00

Two of the batteries were missing charging restart voltages, meaning they can drain if the algorithm relies on restarting charging at this voltage. Fix it up. Fixes: c8aee3f41cb8 ("power: supply: Static data for Samsung batteries") Signed-off-by: Linus Walleij Signed-off-by: Sebastian Reichel