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

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

[Hugo Karlsson]

Adding the other MAX17040 reviewers, LKML, and Svyatoslav as the
author of the commit in the Fixes: tag, whom I missed when sending.
Sorry for the noise.

//Hugo

On 08/11/2026 15:45, Hugo Karlsson wrote:
> Hi,
>
> 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(-)
>

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

[Svyatoslav Ryhel]

нд, 8 лист. 2026 р. о 17:09 Hugo Karlsson <huggek@klattorp.se> пише:
>
> Adding the other MAX17040 reviewers, LKML, and Svyatoslav as the
> author of the commit in the Fixes: tag, whom I missed when sending.
> Sorry for the noise.
>

I do not see your patches on https://lore.kernel.org/lkml/

> //Hugo
>
> On 08/11/2026 15:45, Hugo Karlsson wrote:
> > Hi,
> >
> > 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(-)
> >

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

[Hugo Karlsson]

Thanks, I've resent the series with LKML: 
https://lore.kernel.org/lkml/20261108154241.198160-1-huggek@klattorp.se/

//Hugo, completely new on the sending side of mailing lists

On 08/11/2026 16:20, Svyatoslav Ryhel wrote:
> нд, 8 лист. 2026 р. о 17:09 Hugo Karlsson <huggek@klattorp.se> пише:
>> Adding the other MAX17040 reviewers, LKML, and Svyatoslav as the
>> author of the commit in the Fixes: tag, whom I missed when sending.
>> Sorry for the noise.
>>
> I do not see your patches on https://lore.kernel.org/lkml/
>
>> //Hugo
>>
>> On 08/11/2026 15:45, Hugo Karlsson wrote:
>>> Hi,
>>>
>>> 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(-)
>>>