Re: [PATCH v2 4/4] dt-bindings: power: supply: max17042: Allow monitored-battery

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Infinite retry loop in `max17042_init_worker` on permanent configuration error for MAX17055 devices.
--

--- Patch [4]: [PATCH v2 4/4] dt-bindings: power: supply: max17042: Allow monitored-battery ---
commit 442f6d786e796de83bd68c7855b401281db302f3
Author: Vincent Cloutier <vincent@cloutier.co>

dt-bindings: power: supply: max17042: Allow monitored-battery

The MAX17042 family binding references the generic power-supply schema,
but its additionalProperties restriction means generic properties must
also be admitted explicitly. Allow monitored-battery so these fuel gauges
can reference the physical battery whose characteristics they consume.

> diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml
> index 242b33f2bcba5..ace684159e0e2 100644
> --- a/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml
> +++ b/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml
> @@ -67,6 +67,8 @@ properties:
>        Voltage threshold to report battery as over voltage (in mV).
>        Default is not to report over-voltage events.
>  
> +  monitored-battery: true
> +

[Severity: High]
Does allowing monitored-battery expose an infinite retry loop in the driver
for MAX17055 devices?

If a MAX17055 device is configured with a voltage-max-design-microvolt >
4.275V but lacks charge-full-design-microamp-hours (or lacks a shunt
resistor), enable_vchg_override is set but config->design_cap remains 0.

During initialization, max17055_override_battery_values() attempts to read
the uninitialized (0) DesignCap and dQAcc registers directly from the
hardware. Since they evaluate to 0, it returns a permanent -ERANGE error:

drivers/power/supply/max17042_battery.c:max17055_override_battery_values() {
...
	ret = regmap_read(map, MAX17042_DesignCap, &design_cap);
...
	if (!design_cap || !dqacc)
		return -ERANGE;
...
}

However, max17042_init_worker() intercepts this error and blindly requeues
the initialization work for MAX17055 devices on any failure:

drivers/power/supply/max17042_battery.c:max17042_init_worker() {
...
	if (ret) {
		if (chip->chip_type == MAXIM_DEVICE_TYPE_MAX17055) {
			dev_warn_ratelimited(chip->dev,
				"initialization failed: %d, retrying\n", ret);
			queue_delayed_work(system_freezable_wq, &chip->work,
				msecs_to_jiffies(MAX17055_INIT_RETRY_DELAY_MS));
...
}

Because the hardware registers continually read as 0, this creates an
infinite retry loop triggered by valid, non-malicious device tree
configurations, leading to missing battery status and log spam.

>    power-supplies: true
>  
>  required:

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720011144.1280219-1-vincent.cloutier@icloud.com?part=4