[HuggeK]

The Geekworm X120x UPS boards for the Pi 5 (X1202, X1206) are normally set up with dtoverlay=i2c-sensor,max17040 plus dtoverlay=gpio-charger,gpio=6,.... Nothing links the two, so the battery can't tell whether it is charging. This overlay creates both nodes and links them with power-supplies.

The link only reaches the battery's status once max17040 honours power-supplies. It doesn't today, because the driver never passes its fwnode to the power supply core. That fix is now on linux-pm: max17040 series.

Tested on a Pi 5 (6.18.50) with an X1202:

• Stock driver: battery and charger appear as before (status=Unknown, capacity=103).
• With the max17040 series: on mains it reports status=Full and capacity=100. Unplugging it switches to Discharging. Plugging it back in gives Charging below 100 % (seen at 98 %) and Full at 100 %. The battery sends its uevent within 1 ms of the charger's.

Written with help from Claude Code.

🤖 Generated with Claude Code

[HuggeK]

Our problem: open-flight/openflight#337

[pelwell]

What you have submitted looks fine - it has passed all the tests. However, it did make me think about the use of a pinctrl node purely to set a pull bias on a pin. This is something that can also be specified in the gpio declaration using GPIO_FLAG_xxx flags. You would need to add a #include for the flags declarations, and replace:

        gpios = <&gpio 6 0>;

with:

        gpios = <&gpio 6 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>;

Would you mind making this additional change? See #7746 for some examples.

[pelwell]

P.S. Good luck with upstreaming your driver changes - it can be a brutal process. If you let us know when they are accepted we will happily back-port it to our current kernels.

[HuggeK]

P.S. Good luck with upstreaming your driver changes - it can be a brutal process. If you let us know when they are accepted we will happily back-port it to our current kernels.

I feared the same in regards to that, have heard horror storries but I think it passed? I may be naive of not understanding the process completely. See: https://lore.kernel.org/lkml/179418738021.1255445.3214315853336545090.b4-ty@b4/

[pelwell]

Congratulations on your success. Those commits have not appeared in linux-next yet - drop a reply here when they do and I'll do the back-port.

[HuggeK]

Congratulations on your success. Those commits have not appeared in linux-next yet - drop a reply here when they do and I'll do the back-port.

Thanks. Looks to me like they are in Linux-next now: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/drivers/power/supply/max17040_battery.c

So it would only be open-flight/openflight#319 that's in the way to get it working 100% then.

[pelwell]

Your upstreamed patches are now in rpi-6.18.y:
a74b7d1 power: supply: max17040: pass the device fwnode to the power supply core
a273c8d power: supply: max17040: derive status from an online supplier
e9b9343 power: supply: max17040: clamp the reported capacity to 100 %

and they're on the way to the new kernels.