[PATCH 0/2] power: supply: max17040: fix error-path state handling

[PATCH 0/2] power: supply: max17040: fix error-path state handling

[Jianing Li]

This series fixes two independent error paths in the MAX17040 family
driver. The first keeps the cached alert threshold unchanged when the
register access fails. The second propagates an IRQ request failure,
avoiding successful binding with neither SOC alerts nor initialized
polling work on MAX17048 and MAX17049.

The second issue is specific to configurations using an alert IRQ; it
does not affect a MAX17040 running without interrupts.

Both issues are present in Torvalds' master at
6628e7d4c6b25c8d18f1345e3a20d21829aae7e4 and in the power-supply for-next
file checked on 2026-11-02. This series is based on that master version.

Validation: a standalone C harness extracts the original driver setter,
probe, suspend/resume and work helpers and mocks register, IRQ and managed
resource operations. It reproduces the cache inconsistency on -EIO and
the uninitialized-work path on IRQ request errors. All 30 checks pass
with the patches, including no-IRQ polling, successful IRQ setup, invalid
thresholds and the double-SOC conversion. Both patches pass checkpatch.

This is software fault-injection testing; no full kernel build or
hardware runtime test was performed.

Jianing Li (2):
  power: supply: max17040: preserve alert threshold on write failure
  power: supply: max17040: fail probe when requesting the alert IRQ
    fails

 drivers/power/supply/max17040_battery.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

-- 
2.23.0.windows.1

[PATCH 1/2] power: supply: max17040: preserve alert threshold on write failure

[Jianing Li]

max17040_set_property() updates chip->low_soc_alert even when programming
the new threshold fails. A failed write to capacity_alert_min therefore
changes the value returned by subsequent reads despite the error reported
to the caller.

On models with an alert interrupt, max17040_thread_handler() also uses
this cached value when rearming the alert, so a later interrupt can apply
a threshold whose write previously failed.

Return the register access error before updating the cached threshold.

Fixes: 2f38dc4d9190 ("power: supply: max17040: Add POWER_SUPPLY_PROP_CAPACITY_ALERT_MIN")
Cc: stable@vger.kernel.org
Signed-off-by: Jianing Li <m13940358460@163.com>
---
 drivers/power/supply/max17040_battery.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/power/supply/max17040_battery.c b/drivers/power/supply/max17040_battery.c
index 16e42de..f415876 100644
--- a/drivers/power/supply/max17040_battery.c
+++ b/drivers/power/supply/max17040_battery.c
@@ -384,6 +384,9 @@ static int max17040_set_property(struct power_supply *psy,
 			break;
 		}
 		ret = max17040_set_low_soc_alert(chip, val->intval);
+		if (ret)
+			return ret;
+
 		chip->low_soc_alert = val->intval;
 		break;
 	default:
-- 
2.23.0.windows.1

[PATCH 2/2] power: supply: max17040: fail probe when requesting the alert IRQ fails

[Jianing Li]

MAX17048 and MAX17049 skip polling work initialization when an IRQ is
available because SOC alerts replace polling. If requesting that IRQ
fails, max17040_probe() clears client->irq and returns success anyway.
The driver then has neither an interrupt handler nor a polling worker.

Clearing client->irq also makes the suspend and resume callbacks take
the polling path, which operates on an uninitialized delayed work item.

Propagate the IRQ request error instead of registering a device with
inconsistent interrupt and polling state. The managed resources unwind
the already registered power supply and, for polling models, cancel any
queued work.

Fixes: ee2d433cb473 ("power: supply: max17040: Support soc alert")
Cc: stable@vger.kernel.org
Signed-off-by: Jianing Li <m13940358460@163.com>
---
 drivers/power/supply/max17040_battery.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/power/supply/max17040_battery.c b/drivers/power/supply/max17040_battery.c
index f415876..6f97051 100644
--- a/drivers/power/supply/max17040_battery.c
+++ b/drivers/power/supply/max17040_battery.c
@@ -562,11 +562,9 @@ static int max17040_probe(struct i2c_client *client)
 
 	if (enable_irq) {
 		ret = max17040_enable_alert_irq(chip);
-		if (ret) {
-			client->irq = 0;
-			dev_warn(&client->dev,
-				 "Failed to get IRQ err %d\n", ret);
-		}
+		if (ret)
+			return dev_err_probe(&client->dev, ret,
+					     "Failed to get IRQ\n");
 	}
 
 	return 0;
-- 
2.23.0.windows.1

Re: [PATCH 2/2] power: supply: max17040: fail probe when requesting the alert IRQ fails

[Krzysztof Kozlowski]

On 02/11/2026 08:31, Jianing Li wrote:
> MAX17048 and MAX17049 skip polling work initialization when an IRQ is
> available because SOC alerts replace polling. If requesting that IRQ
> fails, max17040_probe() clears client->irq and returns success anyway.
> The driver then has neither an interrupt handler nor a polling worker.
> 
> Clearing client->irq also makes the suspend and resume callbacks take
> the polling path, which operates on an uninitialized delayed work item.
> 
> Propagate the IRQ request error instead of registering a device with
> inconsistent interrupt and polling state. The managed resources unwind
> the already registered power supply and, for polling models, cancel any
> queued work.

That's LLM commit msg and you are not suppose to use LLM for that.

Best regards,
Krzysztof