[RESEND PATCH 0/3] power: supply: max17040: report charging status from a gpio-charger

[RESEND PATCH 0/3] power: supply: max17040: report charging status from a gpio-charger

[Hugo Karlsson]

Hi,

Resending with LKML and the remaining MAX17040 reviewers in Cc, which
I missed the first time. No changes since the original posting:
https://lore.kernel.org/linux-pm/20261108144548.190622-1-huggek@klattorp.se/

I work on OpenFlight [1], an open-source golf launch monitor built on a
Raspberry Pi 5 with a Geekworm X1202 UPS board. The board pairs a
MAX1704x fuel gauge at I2C address 0x36 with a GPIO that is high while
input power is present.

With the gauge and a gpio-charger described in DT and linked by
power-supplies, the battery still always reports status "Unknown", and
capacity reads above 100 when the cell is full (103 here). Desktop
battery indicators then show the wrong state, so we have been shipping
a patched taskbar plugin to work around it.

Patch 1 passes the device fwnode to the power supply core. Without it,
power-supplies is never parsed, so the supplier status lookup added in
commit f4b782af61ae never finds a supplier.

Patch 2 covers suppliers that only report "online", such as a
gpio-charger without a charge-status GPIO: the status is derived from
power_supply_am_i_supplied(), and the battery now sends a change event
when its supplier changes.

Patch 3 clamps the reported capacity to 100.

The series is based on for-next. I tested it on a Raspberry Pi 5 with an
X1202, on rpi-6.18.y (6.18.50), where max17040_battery.c only differs
in the style of the i2c_device_id table:

  stock driver:          status Unknown, capacity 103
  on mains at 100 %:     Full, capacity 100
  unplugged:             Discharging
  plugged in at 98 %:    Charging

The battery's uevent follows the charger's within 1 ms.

Related changes for the same boards, for context:
  - Raspberry Pi overlay that links the gauge to the charger [2]
  - Raspberry Pi OS taskbar battery plugin reading capacity [3]

The patches and changelogs were written with Claude Code
(claude-opus-5-5) from my description of the problem. I reviewed them
and did the hardware testing above.

[1] https://github.com/open-flight/openflight
[2] https://github.com/raspberrypi/linux/pull/7744
[3] https://github.com/raspberrypi-ui/pplug-batt/pull/17

Thanks,
Hugo

Hugo Karlsson (3):
  power: supply: max17040: pass the device fwnode to the power supply
    core
  power: supply: max17040: derive status from an online supplier
  power: supply: max17040: clamp the reported capacity to 100 %

 drivers/power/supply/max17040_battery.c | 28 +++++++++++++++++++++++--
 1 file changed, 26 insertions(+), 2 deletions(-)

-- 
2.55.0.windows.5

[RESEND PATCH 1/3] power: supply: max17040: pass the device fwnode to the power supply core

[Hugo Karlsson]

Since commit f4b782af61ae ("power: max17040: pass status property from
supplier") the driver forwards POWER_SUPPLY_PROP_STATUS to its supplier,
and the DT binding documents a power-supplies property for naming that
supplier. The driver never passes its device node to
devm_power_supply_register(), however, so the power supply core cannot
parse power-supplies and the battery never gets a supplier from
firmware. The status lookup then always returns -ENODEV and userspace
sees POWER_SUPPLY_STATUS_UNKNOWN.

Set psy_cfg.fwnode the way max17042_battery and cw2015_battery already
do.

Fixes: f4b782af61ae ("power: max17040: pass status property from supplier")
Assisted-by: Claude:claude-opus-5-5 [Claude Code]
Signed-off-by: Hugo Karlsson <huggek@klattorp.se>
---
 drivers/power/supply/max17040_battery.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/power/supply/max17040_battery.c b/drivers/power/supply/max17040_battery.c
index 16e42de284..4cb26eca56 100644
--- a/drivers/power/supply/max17040_battery.c
+++ b/drivers/power/supply/max17040_battery.c
@@ -499,6 +499,7 @@ static int max17040_probe(struct i2c_client *client)
 
 	i2c_set_clientdata(client, chip);
 	psy_cfg.drv_data = chip;
+	psy_cfg.fwnode = dev_fwnode(&client->dev);
 
 	/* Switch to devm_iio_channel_get_optional when available  */
 	chip->channel_temp = devm_iio_channel_get(&client->dev, "temp");
-- 
2.55.0.windows.5

[RESEND PATCH 2/3] power: supply: max17040: derive status from an online supplier

[Hugo Karlsson]

The MAX1704x gauges cannot tell whether the cell is charging, so
POWER_SUPPLY_PROP_STATUS is taken from a supplier. A supplier that only
reports input power, such as a gpio-charger without a charge-status
GPIO, has no STATUS property, and the battery then reports
POWER_SUPPLY_STATUS_UNKNOWN even though the core knows whether it is
being supplied.

This is the case on the Geekworm X1202/X1206 UPS boards for the
Raspberry Pi 5, which pair a MAX1704x gauge with a GPIO that signals input
power.

When no supplier reports a status, fall back to
power_supply_am_i_supplied(): report Discharging when no supplier is
online, Full when one is online and the gauge reads 100 %, and Charging
otherwise. Keep Unknown when the battery has no supplier at all.

Also notify userspace when a supplier changes, so the status follows
the charger being plugged in or removed without waiting for the next
SOC change.

Assisted-by: Claude:claude-opus-5-5 [Claude Code]
Signed-off-by: Hugo Karlsson <huggek@klattorp.se>
---
 drivers/power/supply/max17040_battery.c | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/power/supply/max17040_battery.c b/drivers/power/supply/max17040_battery.c
index 4cb26eca56..d93c3daebb 100644
--- a/drivers/power/supply/max17040_battery.c
+++ b/drivers/power/supply/max17040_battery.c
@@ -228,6 +228,26 @@ static int max17040_get_online(struct max17040_chip *chip)
 	return 1;
 }
 
+/*
+ * Used when no supplier reports a status, e.g. a gpio-charger that only
+ * signals input power: derive the status from whether a supplier is online.
+ */
+static int max17040_get_supplied_status(struct power_supply *psy,
+					struct max17040_chip *chip)
+{
+	int ret;
+
+	ret = power_supply_am_i_supplied(psy);
+	if (ret < 0)
+		return POWER_SUPPLY_STATUS_UNKNOWN;
+	if (!ret)
+		return POWER_SUPPLY_STATUS_DISCHARGING;
+	if (max17040_get_soc(chip) >= 100)
+		return POWER_SUPPLY_STATUS_FULL;
+
+	return POWER_SUPPLY_STATUS_CHARGING;
+}
+
 static int max17040_get_of_data(struct max17040_chip *chip)
 {
 	struct device *dev = &chip->client->dev;
@@ -423,7 +443,7 @@ static int max17040_get_property(struct power_supply *psy,
 	case POWER_SUPPLY_PROP_STATUS:
 		ret = power_supply_get_property_from_supplier(psy, psp, val);
 		if (ret == -ENODEV)
-			val->intval = POWER_SUPPLY_STATUS_UNKNOWN;
+			val->intval = max17040_get_supplied_status(psy, chip);
 		else if (ret)
 			return ret;
 		break;
@@ -467,6 +487,7 @@ static const struct power_supply_desc max17040_battery_desc = {
 	.get_property		= max17040_get_property,
 	.set_property		= max17040_set_property,
 	.property_is_writeable  = max17040_prop_writeable,
+	.external_power_changed	= power_supply_changed,
 	.properties		= max17040_battery_props,
 	.num_properties		= ARRAY_SIZE(max17040_battery_props),
 };
-- 
2.55.0.windows.5

[RESEND PATCH 3/3] power: supply: max17040: clamp the reported capacity to 100 %

[Hugo Karlsson]

The SOC register can read above 100 % when the cell is fully charged,
and max17040_get_soc() passes the raw value through, so
POWER_SUPPLY_PROP_CAPACITY reports values above 100. The ABI defines
capacity as a percentage, and userspace that rejects values above 100
then shows a full battery as empty.

Clamp the value to 100.

Assisted-by: Claude:claude-opus-5-5 [Claude Code]
Signed-off-by: Hugo Karlsson <huggek@klattorp.se>
---
 drivers/power/supply/max17040_battery.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/power/supply/max17040_battery.c b/drivers/power/supply/max17040_battery.c
index d93c3daebb..98574dcfb5 100644
--- a/drivers/power/supply/max17040_battery.c
+++ b/drivers/power/supply/max17040_battery.c
@@ -14,6 +14,7 @@
 #include <linux/i2c.h>
 #include <linux/delay.h>
 #include <linux/interrupt.h>
+#include <linux/minmax.h>
 #include <linux/power_supply.h>
 #include <linux/of.h>
 #include <linux/regmap.h>
@@ -210,7 +211,8 @@ static int max17040_get_soc(struct max17040_chip *chip)
 	if (ret)
 		return ret;
 
-	return soc >> (chip->quirk_double_soc ? 9 : 8);
+	/* the register overshoots 100 % when the cell is full */
+	return min(soc >> (chip->quirk_double_soc ? 9 : 8), 100U);
 }
 
 static int max17040_get_version(struct max17040_chip *chip)
-- 
2.55.0.windows.5

Re: [RESEND PATCH 1/3] power: supply: max17040: pass the device fwnode to the power supply core

[Svyatoslav Ryhel]

нд, 8 лист. 2026 р. о 17:43 Hugo Karlsson <huggek@klattorp.se> пише:
>
> Since commit f4b782af61ae ("power: max17040: pass status property from
> supplier") the driver forwards POWER_SUPPLY_PROP_STATUS to its supplier,
> and the DT binding documents a power-supplies property for naming that
> supplier. The driver never passes its device node to
> devm_power_supply_register(), however, so the power supply core cannot
> parse power-supplies and the battery never gets a supplier from
> firmware. The status lookup then always returns -ENODEV and userspace
> sees POWER_SUPPLY_STATUS_UNKNOWN.
>
> Set psy_cfg.fwnode the way max17042_battery and cw2015_battery already
> do.
>
> Fixes: f4b782af61ae ("power: max17040: pass status property from supplier")
> Assisted-by: Claude:claude-opus-5-5 [Claude Code]
> Signed-off-by: Hugo Karlsson <huggek@klattorp.se>
> ---
>  drivers/power/supply/max17040_battery.c | 1 +
>  1 file changed, 1 insertion(+)
>

Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # LG P895
Reviewed-by: Svyatoslav Ryhel <clamor95@gmail.com>

Re: [RESEND PATCH 3/3] power: supply: max17040: clamp the reported capacity to 100 %

[Svyatoslav Ryhel]

нд, 8 лист. 2026 р. о 17:43 Hugo Karlsson <huggek@klattorp.se> пише:
>
> The SOC register can read above 100 % when the cell is fully charged,
> and max17040_get_soc() passes the raw value through, so
> POWER_SUPPLY_PROP_CAPACITY reports values above 100. The ABI defines
> capacity as a percentage, and userspace that rejects values above 100
> then shows a full battery as empty.
>
> Clamp the value to 100.
>
> Assisted-by: Claude:claude-opus-5-5 [Claude Code]
> Signed-off-by: Hugo Karlsson <huggek@klattorp.se>
> ---
>  drivers/power/supply/max17040_battery.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/power/supply/max17040_battery.c b/drivers/power/supply/max17040_battery.c
> index d93c3daebb..98574dcfb5 100644
> --- a/drivers/power/supply/max17040_battery.c
> +++ b/drivers/power/supply/max17040_battery.c
> @@ -14,6 +14,7 @@
>  #include <linux/i2c.h>
>  #include <linux/delay.h>
>  #include <linux/interrupt.h>
> +#include <linux/minmax.h>
>  #include <linux/power_supply.h>
>  #include <linux/of.h>
>  #include <linux/regmap.h>
> @@ -210,7 +211,8 @@ static int max17040_get_soc(struct max17040_chip *chip)
>         if (ret)
>                 return ret;
>
> -       return soc >> (chip->quirk_double_soc ? 9 : 8);
> +       /* the register overshoots 100 % when the cell is full */
> +       return min(soc >> (chip->quirk_double_soc ? 9 : 8), 100U);
>  }
>
>  static int max17040_get_version(struct max17040_chip *chip)
> --
> 2.55.0.windows.5
>

Reviewed-by: Svyatoslav Ryhel <clamor95@gmail.com>

Re: [RESEND PATCH 0/3] power: supply: max17040: report charging status from a gpio-charger

[Sebastian Reichel]

On Sun, 08 Nov 2026 16:42:37 +0100, Hugo Karlsson wrote:
> Resending with LKML and the remaining MAX17040 reviewers in Cc, which
> I missed the first time. No changes since the original posting:
> https://lore.kernel.org/linux-pm/20261108144548.190622-1-huggek@klattorp.se/
> 
> I work on OpenFlight [1], an open-source golf launch monitor built on a
> Raspberry Pi 5 with a Geekworm X1202 UPS board. The board pairs a
> MAX1704x fuel gauge at I2C address 0x36 with a GPIO that is high while
> input power is present.
> 
> [...]

Applied, thanks!

[1/3] power: supply: max17040: pass the device fwnode to the power supply core
      commit: d7dc0a8b24674fc902fac8b66f1affb32cefb9cc
[2/3] power: supply: max17040: derive status from an online supplier
      commit: e41d85503762f5526c640de07ad8631906eae68d
[3/3] power: supply: max17040: clamp the reported capacity to 100 %
      commit: 7071d4750856abbc68dfe431acc58a1d45dd42e8

Best regards,
-- 
Sebastian Reichel <sebastian.reichel@collabora.com>

Re: [RESEND PATCH 1/3] power: supply: max17040: pass the device fwnode to the power supply core

[Krzysztof Kozlowski]

On 08/11/2026 16:42, Hugo Karlsson wrote:
> Since commit f4b782af61ae ("power: max17040: pass status property from
> supplier") the driver forwards POWER_SUPPLY_PROP_STATUS to its supplier,
> and the DT binding documents a power-supplies property for naming that
> supplier. The driver never passes its device node to
> devm_power_supply_register(), however, so the power supply core cannot
> parse power-supplies and the battery never gets a supplier from
> firmware. The status lookup then always returns -ENODEV and userspace
> sees POWER_SUPPLY_STATUS_UNKNOWN.
> 
> Set psy_cfg.fwnode the way max17042_battery and cw2015_battery already
> do.
> 
> Fixes: f4b782af61ae ("power: max17040: pass status property from supplier")
> Assisted-by: Claude:claude-opus-5-5 [Claude Code]

If you are resending, then at least you could run checkpatch.

Please run scripts/checkpatch.pl on the patches and fix reported
warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
patches and (probably) fix more warnings. Some warnings can be ignored,
especially from --strict run, but the code here looks like it needs a
fix. Feel free to get in touch if the warning is not clear.

Best regards,
Krzysztof

Re: [RESEND PATCH 1/3] power: supply: max17040: pass the device fwnode to the power supply core

[Hugo Karlsson]

 > Please run scripts/checkpatch.pl on the patches and fix reported
 > warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
 > patches and (probably) fix more warnings.

Thanks, sorry in regards to that. I ran both, the only findings are
for the "Assisted-by: " line, which checkpatch does not recognise
("Non-standard signature" and "Unrecognized email address"); --strict
reports no checks on the code itself

It seems it was removed in 1e035297ffda at the 13 October as Sebasation 
could just drop it on the applied series, but that´s maybe something I 
need to do myself and send a patch v2? Or is that just cosmetic?


Hugo

On 09/11/2026 08:30, Krzysztof Kozlowski wrote:
> On 08/11/2026 16:42, Hugo Karlsson wrote:
>> Since commit f4b782af61ae ("power: max17040: pass status property from
>> supplier") the driver forwards POWER_SUPPLY_PROP_STATUS to its supplier,
>> and the DT binding documents a power-supplies property for naming that
>> supplier. The driver never passes its device node to
>> devm_power_supply_register(), however, so the power supply core cannot
>> parse power-supplies and the battery never gets a supplier from
>> firmware. The status lookup then always returns -ENODEV and userspace
>> sees POWER_SUPPLY_STATUS_UNKNOWN.
>>
>> Set psy_cfg.fwnode the way max17042_battery and cw2015_battery already
>> do.
>>
>> Fixes: f4b782af61ae ("power: max17040: pass status property from supplier")
>> Assisted-by: Claude:claude-opus-5-5 [Claude Code]
> If you are resending, then at least you could run checkpatch.
>
> Please run scripts/checkpatch.pl on the patches and fix reported
> warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
> patches and (probably) fix more warnings. Some warnings can be ignored,
> especially from --strict run, but the code here looks like it needs a
> fix. Feel free to get in touch if the warning is not clear.
>
> Best regards,
> Krzysztof

Re: [RESEND PATCH 1/3] power: supply: max17040: pass the device fwnode to the power supply core

[Krzysztof Kozlowski]

On 09/11/2026 09:53, Hugo Karlsson wrote:
>  > Please run scripts/checkpatch.pl on the patches and fix reported
>  > warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
>  > patches and (probably) fix more warnings.
> 
> Thanks, sorry in regards to that. I ran both, the only findings are
> for the "Assisted-by: " line, which checkpatch does not recognise
> ("Non-standard signature" and "Unrecognized email address"); --strict
> reports no checks on the code itself
> 
> It seems it was removed in 1e035297ffda at the 13 October as Sebasation 
> could just drop it on the applied series, but that´s maybe something I 
> need to do myself and send a patch v2? Or is that just cosmetic?

It's cosmetic, please drop assisted-by if you send v2.

Best regards,
Krzysztof