linux-stable.git/drivers/power, branch linux-6.16.y Linux kernel stable tree power: supply: bq27xxx: restrict no-battery detection to bq27000 2025-09-25T09:16:46+00:00 H. Nikolaus Schaller hns@goldelico.com 2025-08-23T10:34:57+00:00 a4ee54e68282bcdc3e0d6eab05aae644837269b2 commit 1e451977e1703b6db072719b37cd1b8e250b9cc9 upstream. There are fuel gauges in the bq27xxx series (e.g. bq27z561) which may in some cases report 0xff as the value of BQ27XXX_REG_FLAGS that should not be interpreted as "no battery" like for a disconnected battery with some built in bq27000 chip. So restrict the no-battery detection originally introduced by commit 3dd843e1c26a ("bq27000: report missing device better.") to the bq27000. There is no need to backport further because this was hidden before commit f16d9fb6cf03 ("power: supply: bq27xxx: Retrieve again when busy") Fixes: f16d9fb6cf03 ("power: supply: bq27xxx: Retrieve again when busy") Suggested-by: Jerry Lv <Jerry.Lv@axis.com> Cc: stable@vger.kernel.org Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Link: https://lore.kernel.org/r/dd979fa6855fd051ee5117016c58daaa05966e24.1755945297.git.hns@goldelico.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 1e451977e1703b6db072719b37cd1b8e250b9cc9 upstream.

There are fuel gauges in the bq27xxx series (e.g. bq27z561) which may in some
cases report 0xff as the value of BQ27XXX_REG_FLAGS that should not be
interpreted as "no battery" like for a disconnected battery with some built
in bq27000 chip.

So restrict the no-battery detection originally introduced by

    commit 3dd843e1c26a ("bq27000: report missing device better.")

to the bq27000.

There is no need to backport further because this was hidden before

	commit f16d9fb6cf03 ("power: supply: bq27xxx: Retrieve again when busy")

Fixes: f16d9fb6cf03 ("power: supply: bq27xxx: Retrieve again when busy")
Suggested-by: Jerry Lv <Jerry.Lv@axis.com>
Cc: stable@vger.kernel.org
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Link: https://lore.kernel.org/r/dd979fa6855fd051ee5117016c58daaa05966e24.1755945297.git.hns@goldelico.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
power: supply: bq27xxx: fix error return in case of no bq27000 hdq battery 2025-09-25T09:16:46+00:00 H. Nikolaus Schaller hns@goldelico.com 2025-08-23T10:34:56+00:00 d18d7035ecb8c992c17330da90b7d3f336afcfa7 commit 2c334d038466ac509468fbe06905a32d202117db upstream. Since commit commit f16d9fb6cf03 ("power: supply: bq27xxx: Retrieve again when busy") the console log of some devices with hdq enabled but no bq27000 battery (like e.g. the Pandaboard) is flooded with messages like: [ 34.247833] power_supply bq27000-battery: driver failed to report 'status' property: -1 as soon as user-space is finding a /sys entry and trying to read the "status" property. It turns out that the offending commit changes the logic to now return the value of cache.flags if it is <0. This is likely under the assumption that it is an error number. In normal errors from bq27xxx_read() this is indeed the case. But there is special code to detect if no bq27000 is installed or accessible through hdq/1wire and wants to report this. In that case, the cache.flags are set historically by commit 3dd843e1c26a ("bq27000: report missing device better.") to constant -1 which did make reading properties return -ENODEV. So everything appeared to be fine before the return value was passed upwards. Now the -1 is returned as -EPERM instead of -ENODEV, triggering the error condition in power_supply_format_property() which then floods the console log. So we change the detection of missing bq27000 battery to simply set cache.flags = -ENODEV instead of -1. Fixes: f16d9fb6cf03 ("power: supply: bq27xxx: Retrieve again when busy") Cc: Jerry Lv <Jerry.Lv@axis.com> Cc: stable@vger.kernel.org Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Link: https://lore.kernel.org/r/692f79eb6fd541adb397038ea6e750d4de2deddf.1755945297.git.hns@goldelico.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 2c334d038466ac509468fbe06905a32d202117db upstream.

Since commit

	commit f16d9fb6cf03 ("power: supply: bq27xxx: Retrieve again when busy")

the console log of some devices with hdq enabled but no bq27000 battery
(like e.g. the Pandaboard) is flooded with messages like:

[   34.247833] power_supply bq27000-battery: driver failed to report 'status' property: -1

as soon as user-space is finding a /sys entry and trying to read the
"status" property.

It turns out that the offending commit changes the logic to now return the
value of cache.flags if it is <0. This is likely under the assumption that
it is an error number. In normal errors from bq27xxx_read() this is indeed
the case.

But there is special code to detect if no bq27000 is installed or accessible
through hdq/1wire and wants to report this. In that case, the cache.flags
are set historically by

	commit 3dd843e1c26a ("bq27000: report missing device better.")

to constant -1 which did make reading properties return -ENODEV. So everything
appeared to be fine before the return value was passed upwards.

Now the -1 is returned as -EPERM instead of -ENODEV, triggering the error
condition in power_supply_format_property() which then floods the console log.

So we change the detection of missing bq27000 battery to simply set

	cache.flags = -ENODEV

instead of -1.

Fixes: f16d9fb6cf03 ("power: supply: bq27xxx: Retrieve again when busy")
Cc: Jerry Lv <Jerry.Lv@axis.com>
Cc: stable@vger.kernel.org
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Link: https://lore.kernel.org/r/692f79eb6fd541adb397038ea6e750d4de2deddf.1755945297.git.hns@goldelico.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
power: supply: qcom_battmgr: Add lithium-polymer entry 2025-08-20T16:41:25+00:00 Abel Vesa abel.vesa@linaro.org 2025-05-23T10:14:22+00:00 3d846183dcc0a50447d21884b1b59f09fe13d197 [ Upstream commit 202ac22b8e2e015e6c196fd8113f3d2a62dd1afc ] On some Dell XPS 13 (9345) variants, the battery used is lithium-polymer based. Currently, this is reported as unknown technology due to the entry missing. [ 4083.135325] Unknown battery technology 'LIP' Add another check for lithium-polymer in the technology parsing callback and return that instead of unknown. Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250523-psy-qcom-battmgr-add-lipo-entry-v1-1-938c20a43a25@linaro.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 202ac22b8e2e015e6c196fd8113f3d2a62dd1afc ]

On some Dell XPS 13 (9345) variants, the battery used is lithium-polymer
based. Currently, this is reported as unknown technology due to the entry
missing.

[ 4083.135325] Unknown battery technology 'LIP'

Add another check for lithium-polymer in the technology parsing callback
and return that instead of unknown.

Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250523-psy-qcom-battmgr-add-lipo-entry-v1-1-938c20a43a25@linaro.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
power: supply: max1720x correct capacity computation 2025-08-15T14:38:59+00:00 Thomas Antoine t.antoine@uclouvain.be 2025-05-23T12:51:44+00:00 559583605accb8917a82085ab9570a71d005c39f [ Upstream commit 58ae036172b5f051a19a32eba94a3e5eb37bf47e ] From the datasheet of the MAX17201/17205, the LSB should be "5.0μVh/RSENSE". The current computation sets it at 0.5mAh=5.0μVh/10mOhm, which does not take into account the value of rsense (which is in 10µV steps) which can be different from 10mOhm. Change the computation to fit the specs. Fixes: 479b6d04964b ("power: supply: add support for MAX1720x standalone fuel gauge") Signed-off-by: Thomas Antoine <t.antoine@uclouvain.be> Link: https://lore.kernel.org/r/20250523-b4-gs101_max77759_fg-v4-1-b49904e35a34@uclouvain.be Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 58ae036172b5f051a19a32eba94a3e5eb37bf47e ]

From the datasheet of the MAX17201/17205, the LSB should be "5.0μVh/RSENSE".
The current computation sets it at 0.5mAh=5.0μVh/10mOhm, which does not take
into account the value of rsense (which is in 10µV steps) which can be
different from 10mOhm.

Change the computation to fit the specs.

Fixes: 479b6d04964b ("power: supply: add support for MAX1720x standalone fuel gauge")
Signed-off-by: Thomas Antoine <t.antoine@uclouvain.be>
Link: https://lore.kernel.org/r/20250523-b4-gs101_max77759_fg-v4-1-b49904e35a34@uclouvain.be
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
power: supply: qcom_pmi8998_charger: fix wakeirq 2025-08-15T14:38:59+00:00 Casey Connolly casey.connolly@linaro.org 2025-06-19T14:55:11+00:00 c0cb8f2d45564673deac1e86b8e41b1f1ed50967 [ Upstream commit 6c5393771c50fac30f08dfb6d2f65f4f2cfeb8c7 ] Unloading and reloading the driver (e.g. when built as a module) currently leads to errors trying to enable wake IRQ since it's already enabled. Use devm to manage this for us so it correctly gets disabled when removing the driver. Additionally, call device_init_wakeup() so that charger attach/remove will trigger a wakeup by default. Fixes: 8648aeb5d7b7 ("power: supply: add Qualcomm PMI8998 SMB2 Charger driver") Signed-off-by: Casey Connolly <casey.connolly@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250619-smb2-smb5-support-v1-3-ac5dec51b6e1@linaro.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 6c5393771c50fac30f08dfb6d2f65f4f2cfeb8c7 ]

Unloading and reloading the driver (e.g. when built as a module)
currently leads to errors trying to enable wake IRQ since it's already
enabled.

Use devm to manage this for us so it correctly gets disabled when
removing the driver.

Additionally, call device_init_wakeup() so that charger attach/remove
will trigger a wakeup by default.

Fixes: 8648aeb5d7b7 ("power: supply: add Qualcomm PMI8998 SMB2 Charger driver")
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250619-smb2-smb5-support-v1-3-ac5dec51b6e1@linaro.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
power: supply: max14577: Handle NULL pdata when CONFIG_OF is not set 2025-08-15T14:38:59+00:00 Charles Han hanchunchao@inspur.com 2025-05-19T06:16:01+00:00 3aa2a86264f63b80902b612f7067574cea464027 [ Upstream commit 2937f5d2e24eefef8cb126244caec7fe3307f724 ] When the kernel is not configured CONFIG_OF, the max14577_charger_dt_init function returns NULL. Fix the max14577_charger_probe functionby returning -ENODATA instead of potentially passing a NULL pointer to PTR_ERR. This fixes the below smatch warning: max14577_charger_probe() warn: passing zero to 'PTR_ERR' Fixes: e30110e9c96f ("charger: max14577: Configure battery-dependent settings from DTS and sysfs") Signed-off-by: Charles Han <hanchunchao@inspur.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250519061601.8755-1-hanchunchao@inspur.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 2937f5d2e24eefef8cb126244caec7fe3307f724 ]

When the kernel is not configured  CONFIG_OF, the max14577_charger_dt_init
function returns NULL. Fix the max14577_charger_probe functionby returning
-ENODATA instead of potentially passing a NULL pointer to PTR_ERR.

This fixes the below smatch warning:
max14577_charger_probe() warn: passing zero to 'PTR_ERR'

Fixes: e30110e9c96f ("charger: max14577: Configure battery-dependent settings from DTS and sysfs")
Signed-off-by: Charles Han <hanchunchao@inspur.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250519061601.8755-1-hanchunchao@inspur.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
power: reset: POWER_RESET_TORADEX_EC should depend on ARCH_MXC 2025-08-15T14:38:59+00:00 Geert Uytterhoeven geert+renesas@glider.be 2025-05-06T13:01:27+00:00 6deb84a4e86c79e819cfb4bbf93214b8e747abe1 [ Upstream commit 22e4d29f081df8a10f1c062d3d952bb876eb9bdc ] The Toradex Embedded Controller is currently only present on Toradex SMARC iMX8MP and iMX95 SoMs. Hence add a dependency on ARCH_MXC, to prevent asking the user about this driver when configuring a kernel without NXP i.MX SoC family support. Fixes: 18672fe12367ed44 ("power: reset: add Toradex Embedded Controller") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/1ef0beb1e09bf914650f9f9885a33af06772540d.1746536287.git.geert+renesas@glider.be Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 22e4d29f081df8a10f1c062d3d952bb876eb9bdc ]

The Toradex Embedded Controller is currently only present on Toradex
SMARC iMX8MP and iMX95 SoMs.  Hence add a dependency on ARCH_MXC, to
prevent asking the user about this driver when configuring a kernel
without NXP i.MX SoC family support.

Fixes: 18672fe12367ed44 ("power: reset: add Toradex Embedded Controller")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/1ef0beb1e09bf914650f9f9885a33af06772540d.1746536287.git.geert+renesas@glider.be
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
power: supply: cpcap-charger: Fix null check for power_supply_get_by_name 2025-08-15T14:38:59+00:00 Charles Han hanchunchao@inspur.com 2025-05-19T02:47:41+00:00 27001e4f146624c4b3389b029bdc0f8049819560 [ Upstream commit d9fa3aae08f99493e67fb79413c0e95d30fca5e9 ] In the cpcap_usb_detect() function, the power_supply_get_by_name() function may return `NULL` instead of an error pointer. To prevent potential null pointer dereferences, Added a null check. Fixes: eab4e6d953c1 ("power: supply: cpcap-charger: get the battery inserted infomation from cpcap-battery") Signed-off-by: Charles Han <hanchunchao@inspur.com> Link: https://lore.kernel.org/r/20250519024741.5846-1-hanchunchao@inspur.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit d9fa3aae08f99493e67fb79413c0e95d30fca5e9 ]

In the cpcap_usb_detect() function, the power_supply_get_by_name()
function may return `NULL` instead of an error pointer.
To prevent potential null pointer dereferences, Added a null check.

Fixes: eab4e6d953c1 ("power: supply: cpcap-charger: get the battery inserted infomation from cpcap-battery")
Signed-off-by: Charles Han <hanchunchao@inspur.com>
Link: https://lore.kernel.org/r/20250519024741.5846-1-hanchunchao@inspur.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
power: sequencing: qcom-wcn: fix bluetooth-wifi copypasta for WCN6855 2025-08-15T14:38:29+00:00 Konrad Dybcio konrad.dybcio@oss.qualcomm.com 2025-06-25T15:55:43+00:00 6b150a46fab48d2cf9eb047196c0fc6f8664478a [ Upstream commit 07d59dec6795428983a840de85aa02febaf7e01b ] Prevent a name conflict (which is surprisingly not caught by the framework). Fixes: bd4c8bafcf50 ("power: sequencing: qcom-wcn: improve support for wcn6855") Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250625-topic-wcn6855_pwrseq-v1-1-cfb96d599ff8@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 07d59dec6795428983a840de85aa02febaf7e01b ]

Prevent a name conflict (which is surprisingly not caught by the
framework).

Fixes: bd4c8bafcf50 ("power: sequencing: qcom-wcn: improve support for wcn6855")
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250625-topic-wcn6855_pwrseq-v1-1-cfb96d599ff8@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
power: supply: test-power: Test access to extended power supply 2025-07-07T12:19:49+00:00 Armin Wolf W_Armin@gmx.de 2025-06-27T20:51:23+00:00 a5f354232118751fe43be6ac896f8d6e7d7418b5 Test that power supply extensions can access properties of their power supply using power_supply_get_property_direct(). This both ensures that the functionality works and serves as an example for future driver developers. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20250627205124.250433-2-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> 
Test that power supply extensions can access properties of their
power supply using power_supply_get_property_direct(). This both
ensures that the functionality works and serves as an example for
future driver developers.

Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://lore.kernel.org/r/20250627205124.250433-2-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>