linux-stable.git/drivers/power, branch v5.4.285 Linux kernel stable tree power: reset: brcmstb: Do not go into infinite loop if reset fails 2024-11-08T15:20:38+00:00 Andrew Davis afd@ti.com 2024-06-10T14:28:36+00:00 d35ad25f9848fd3b6448868da7c97e6bf754a421 [ Upstream commit cf8c39b00e982fa506b16f9d76657838c09150cb ] There may be other backup reset methods available, do not halt here so that other reset methods can be tried. Signed-off-by: Andrew Davis <afd@ti.com> Reviewed-by: Dhruva Gole <d-gole@ti.com> Acked-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20240610142836.168603-5-afd@ti.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit cf8c39b00e982fa506b16f9d76657838c09150cb ]

There may be other backup reset methods available, do not halt
here so that other reset methods can be tried.

Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://lore.kernel.org/r/20240610142836.168603-5-afd@ti.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
power: supply: max17042_battery: Fix SOC threshold calc w/ no current sense 2024-11-08T15:20:28+00:00 Artur Weber aweber.kernel@gmail.com 2024-08-17T10:51:14+00:00 65af6f4a72c6f2a5ba12eb5197846da79f30b6b6 [ Upstream commit 3a3acf839b2cedf092bdd1ff65b0e9895df1656b ] Commit 223a3b82834f ("power: supply: max17042_battery: use VFSOC for capacity when no rsns") made it so that capacity on systems without current sensing would be read from VFSOC instead of RepSOC. However, the SOC threshold calculation still read RepSOC to get the SOC regardless of the current sensing option state. Fix this by applying the same conditional to determine which register should be read. This also seems to be the intended behavior as per the datasheet - SOC alert config value in MiscCFG on setups without current sensing is set to a value of 0b11, indicating SOC alerts being generated based on VFSOC, instead of 0b00 which indicates SOC alerts being generated based on RepSOC. This fixes an issue on the Galaxy S3/Midas boards, where the alert interrupt would be constantly retriggered, causing high CPU usage on idle (around ~12%-15%). Fixes: e5f3872d2044 ("max17042: Add support for signalling change in SOC") Signed-off-by: Artur Weber <aweber.kernel@gmail.com> Reviewed-by: Henrik Grimler <henrik@grimler.se> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240817-max17042-soc-threshold-fix-v1-1-72b45899c3cc@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 3a3acf839b2cedf092bdd1ff65b0e9895df1656b ]

Commit 223a3b82834f ("power: supply: max17042_battery: use VFSOC for
capacity when no rsns") made it so that capacity on systems without
current sensing would be read from VFSOC instead of RepSOC. However,
the SOC threshold calculation still read RepSOC to get the SOC
regardless of the current sensing option state.

Fix this by applying the same conditional to determine which register
should be read.

This also seems to be the intended behavior as per the datasheet - SOC
alert config value in MiscCFG on setups without current sensing is set
to a value of 0b11, indicating SOC alerts being generated based on
VFSOC, instead of 0b00 which indicates SOC alerts being generated based
on RepSOC.

This fixes an issue on the Galaxy S3/Midas boards, where the alert
interrupt would be constantly retriggered, causing high CPU usage
on idle (around ~12%-15%).

Fixes: e5f3872d2044 ("max17042: Add support for signalling change in SOC")
Signed-off-by: Artur Weber <aweber.kernel@gmail.com>
Reviewed-by: Henrik Grimler <henrik@grimler.se>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240817-max17042-soc-threshold-fix-v1-1-72b45899c3cc@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
power: supply: axp20x_battery: Remove design from min and max voltage 2024-11-08T15:20:28+00:00 Chris Morgan macromorgan@hotmail.com 2024-08-21T21:54:43+00:00 575ea801cc230cb0bf6d460c55235355815b03c4 [ Upstream commit 61978807b00f8a1817b0e5580981af1cd2f428a5 ] The POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN and POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN values should be immutable properties of the battery, but for this driver they are writable values and used as the minimum and maximum values for charging. Remove the DESIGN designation from these values. Fixes: 46c202b5f25f ("power: supply: add battery driver for AXP20X and AXP22X PMICs") Suggested-by: Chen-Yu Tsai <wens@kernel.org> Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240821215456.962564-3-macroalpha82@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 61978807b00f8a1817b0e5580981af1cd2f428a5 ]

The POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN and
POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN values should be immutable
properties of the battery, but for this driver they are writable values
and used as the minimum and maximum values for charging. Remove the
DESIGN designation from these values.

Fixes: 46c202b5f25f ("power: supply: add battery driver for AXP20X and AXP22X PMICs")
Suggested-by: Chen-Yu Tsai <wens@kernel.org>
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240821215456.962564-3-macroalpha82@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
power: supply: axp20x_battery: allow disabling battery charging 2024-11-08T15:20:28+00:00 Hermann Lauer Hermann.Lauer@iwr.uni-heidelberg.de 2021-05-12T10:58:56+00:00 206734f55745e43f9aaf5d24075acf4b8127ff73 [ Upstream commit 6a0fcc87c9e35191d37a8819fdab9d30e523515b ] Allow disabling and re-enabling battery charging of an axp209 PMIC through a writable status property. With the current driver code charging is always on. This works on the axp209 of Banana {Pi M1+,Pro} and should work on all AXP chips. Signed-off-by: Hermann.Lauer@uni-heidelberg.de Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Stable-dep-of: 61978807b00f ("power: supply: axp20x_battery: Remove design from min and max voltage") Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 6a0fcc87c9e35191d37a8819fdab9d30e523515b ]

Allow disabling and re-enabling battery charging of an axp209 PMIC
through a writable status property. With the current driver code
charging is always on.

This works on the axp209 of Banana {Pi M1+,Pro} and should work on all
AXP chips.

Signed-off-by: Hermann.Lauer@uni-heidelberg.de
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Stable-dep-of: 61978807b00f ("power: supply: axp20x_battery: Remove design from min and max voltage")
Signed-off-by: Sasha Levin <sashal@kernel.org>
power: supply: axp288_charger: Round constant_charge_voltage writes down 2024-08-19T03:33:52+00:00 Hans de Goede hdegoede@redhat.com 2024-07-17T20:03:33+00:00 f8fe71c64923f2dfe18a8968f32168a20277be00 commit 81af7f2342d162e24ac820c10e68684d9f927663 upstream. Round constant_charge_voltage writes down to the first supported lower value, rather then rounding them up to the first supported higher value. This fixes e.g. writing 4250000 resulting in a value of 4350000 which might be dangerous, instead writing 4250000 will now result in a safe 4200000 value. Fixes: 843735b788a4 ("power: axp288_charger: axp288 charger driver") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240717200333.56669-2-hdegoede@redhat.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 81af7f2342d162e24ac820c10e68684d9f927663 upstream.

Round constant_charge_voltage writes down to the first supported lower
value, rather then rounding them up to the first supported higher value.

This fixes e.g. writing 4250000 resulting in a value of 4350000 which
might be dangerous, instead writing 4250000 will now result in a safe
4200000 value.

Fixes: 843735b788a4 ("power: axp288_charger: axp288 charger driver")
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240717200333.56669-2-hdegoede@redhat.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
power: supply: axp288_charger: Fix constant_charge_voltage writes 2024-08-19T03:33:52+00:00 Hans de Goede hdegoede@redhat.com 2024-07-17T20:03:32+00:00 1031a0e7c2934b1704f460533b2db1548966e8d1 commit b34ce4a59cfe9cd0d6f870e6408e8ec88a964585 upstream. info->max_cv is in millivolts, divide the microvolt value being written to constant_charge_voltage by 1000 *before* clamping it to info->max_cv. Before this fix the code always tried to set constant_charge_voltage to max_cv / 1000 = 4 millivolt, which ends up in setting it to 4.1V which is the lowest supported value. Fixes: 843735b788a4 ("power: axp288_charger: axp288 charger driver") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240717200333.56669-1-hdegoede@redhat.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit b34ce4a59cfe9cd0d6f870e6408e8ec88a964585 upstream.

info->max_cv is in millivolts, divide the microvolt value being written
to constant_charge_voltage by 1000 *before* clamping it to info->max_cv.

Before this fix the code always tried to set constant_charge_voltage
to max_cv / 1000 = 4 millivolt, which ends up in setting it to 4.1V
which is the lowest supported value.

Fixes: 843735b788a4 ("power: axp288_charger: axp288 charger driver")
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240717200333.56669-1-hdegoede@redhat.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
power: rt9455: hide unused rt9455_boost_voltage_values 2024-05-17T09:43:48+00:00 Arnd Bergmann arnd@arndb.de 2024-04-03T08:06:27+00:00 8ade209260c4e0adc618882c2b3d7f968c66b8c1 [ Upstream commit 452d8950db3e839aba1bb13bc5378f4bac11fa04 ] The rt9455_boost_voltage_values[] array is only used when USB PHY support is enabled, causing a W=1 warning otherwise: drivers/power/supply/rt9455_charger.c:200:18: error: 'rt9455_boost_voltage_values' defined but not used [-Werror=unused-const-variable=] Enclose the definition in the same #ifdef as the references to it. Fixes: e86d69dd786e ("power_supply: Add support for Richtek RT9455 battery charger") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20240403080702.3509288-10-arnd@kernel.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 452d8950db3e839aba1bb13bc5378f4bac11fa04 ]

The rt9455_boost_voltage_values[] array is only used when USB PHY
support is enabled, causing a W=1 warning otherwise:

drivers/power/supply/rt9455_charger.c:200:18: error: 'rt9455_boost_voltage_values' defined but not used [-Werror=unused-const-variable=]

Enclose the definition in the same #ifdef as the references to it.

Fixes: e86d69dd786e ("power_supply: Add support for Richtek RT9455 battery charger")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20240403080702.3509288-10-arnd@kernel.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
power: supply: bq27xxx-i2c: Do not free non existing IRQ 2024-03-06T14:36:09+00:00 Hans de Goede hdegoede@redhat.com 2024-02-15T15:51:33+00:00 7394abc8926adee6a817bab10797e0adc898af77 [ Upstream commit 2df70149e73e79783bcbc7db4fa51ecef0e2022c ] The bq27xxx i2c-client may not have an IRQ, in which case client->irq will be 0. bq27xxx_battery_i2c_probe() already has an if (client->irq) check wrapping the request_threaded_irq(). But bq27xxx_battery_i2c_remove() unconditionally calls free_irq(client->irq) leading to: [ 190.310742] ------------[ cut here ]------------ [ 190.310843] Trying to free already-free IRQ 0 [ 190.310861] WARNING: CPU: 2 PID: 1304 at kernel/irq/manage.c:1893 free_irq+0x1b8/0x310 Followed by a backtrace when unbinding the driver. Add an if (client->irq) to bq27xxx_battery_i2c_remove() mirroring probe() to fix this. Fixes: 444ff00734f3 ("power: supply: bq27xxx: Fix I2C IRQ race on remove") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240215155133.70537-1-hdegoede@redhat.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 2df70149e73e79783bcbc7db4fa51ecef0e2022c ]

The bq27xxx i2c-client may not have an IRQ, in which case
client->irq will be 0. bq27xxx_battery_i2c_probe() already has
an if (client->irq) check wrapping the request_threaded_irq().

But bq27xxx_battery_i2c_remove() unconditionally calls
free_irq(client->irq) leading to:

[  190.310742] ------------[ cut here ]------------
[  190.310843] Trying to free already-free IRQ 0
[  190.310861] WARNING: CPU: 2 PID: 1304 at kernel/irq/manage.c:1893 free_irq+0x1b8/0x310

Followed by a backtrace when unbinding the driver. Add
an if (client->irq) to bq27xxx_battery_i2c_remove() mirroring
probe() to fix this.

Fixes: 444ff00734f3 ("power: supply: bq27xxx: Fix I2C IRQ race on remove")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240215155133.70537-1-hdegoede@redhat.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
power: supply: Fix logic checking if system is running from battery 2023-06-21T13:44:09+00:00 Mario Limonciello mario.limonciello@amd.com 2023-05-16T18:25:40+00:00 b31586747bae34b81425042c9c046da831451457 [ Upstream commit 95339f40a8b652b5b1773def31e63fc53c26378a ] The logic used for power_supply_is_system_supplied() counts all power supplies and assumes that the system is running from AC if there is either a non-battery power-supply reporting to be online or if no power-supplies exist at all. The second rule is for desktop systems, that don't have any battery/charger devices. These systems will incorrectly report to be powered from battery once a device scope power-supply is registered (e.g. a HID device), since these power-supplies increase the counter. Apart from HID devices, recent dGPUs provide UCSI power supplies on a desktop systems. The dGPU by default doesn't have anything plugged in so it's 'offline'. This makes power_supply_is_system_supplied() return 0 with a count of 1 meaning all drivers that use this get a wrong judgement. To fix this case adjust the logic to also examine the scope of the power supply. If the power supply is deemed a device power supply, then don't count it. Cc: Evan Quan <Evan.Quan@amd.com> Suggested-by: Lijo Lazar <Lijo.Lazar@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 95339f40a8b652b5b1773def31e63fc53c26378a ]

The logic used for power_supply_is_system_supplied() counts all power
supplies and assumes that the system is running from AC if there is
either a non-battery power-supply reporting to be online or if no
power-supplies exist at all.

The second rule is for desktop systems, that don't have any
battery/charger devices. These systems will incorrectly report to be
powered from battery once a device scope power-supply is registered
(e.g. a HID device), since these power-supplies increase the counter.

Apart from HID devices, recent dGPUs provide UCSI power supplies on a
desktop systems. The dGPU by default doesn't have anything plugged in so
it's 'offline'. This makes power_supply_is_system_supplied() return 0
with a count of 1 meaning all drivers that use this get a wrong judgement.

To fix this case adjust the logic to also examine the scope of the power
supply. If the power supply is deemed a device power supply, then don't
count it.

Cc: Evan Quan <Evan.Quan@amd.com>
Suggested-by: Lijo Lazar <Lijo.Lazar@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
power: supply: Ratelimit no data debug output 2023-06-21T13:44:09+00:00 Marek Vasut marex@denx.de 2023-03-05T20:52:26+00:00 d26edc403c0a7fc6a56a221c50e7e47e69f235a9 [ Upstream commit 155c45a25679f571c2ae57d10db843a9dfc63430 ] Reduce the amount of output this dev_dbg() statement emits into logs, otherwise if system software polls the sysfs entry for data and keeps getting -ENODATA, it could end up filling the logs up. This does in fact make systemd journald choke, since during boot the sysfs power supply entries are polled and if journald starts at the same time, the journal is just being repeatedly filled up, and the system stops on trying to start journald without booting any further. Signed-off-by: Marek Vasut <marex@denx.de> 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> 
[ Upstream commit 155c45a25679f571c2ae57d10db843a9dfc63430 ]

Reduce the amount of output this dev_dbg() statement emits into logs,
otherwise if system software polls the sysfs entry for data and keeps
getting -ENODATA, it could end up filling the logs up.

This does in fact make systemd journald choke, since during boot the
sysfs power supply entries are polled and if journald starts at the
same time, the journal is just being repeatedly filled up, and the
system stops on trying to start journald without booting any further.

Signed-off-by: Marek Vasut <marex@denx.de>
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>