Concerns with maintaining separate kernel device drivers for fuel-gauge and charger ICs

[aaronemassey]

    Disclaimer: I am very inexperienced, so you should probably not waste your time with me! :)

This is based on my opinion and I am sorry for being this long.
From what I am seeing, I might be late to the party. :(

Last time, I didn't saw the RFC, but now I understand it.

My biggest issue with that RFC (and that PR) is the rarity of separate charger IC and fuel gauge IC in the embedded world. Most boards that feature some kind of battery related IC have either fuel gauge IC, charger IC or an IC that combines them both. Example is MAX77818.
This device has to have two separate drivers, because it is both a fuel gauge and a charger. This isn't impossible (Linux's MFD), but I think it is unneeded complication, at least compared to Linux's power_supply.

Yes, I know, SBS is an example of separate charger and fuel gauge (SBS battery), but firstly rarely embedded device uses SBS, and secondly if you want to change charging parameters (at least in the case you can), (most of the time) you need to communicate the change to the SBS battery, and then the SBS battery will communicate the changes to the charger.

As a last example, the very integrated AXP202 from X-Powers.
Linux gets away with using 3 instances of power_supply driver: battery, ac-power, usb-power. (I am not counting the regulator interface and etc.)
With this RFC, you will need to use 4 instances of 3 drivers: 1 - battery, 1 - charger and 2 of something else for usb and ac power monitoring, for the same functionality. And they all will have some very similar APIs.
And in both cases, you will need to have some userspace driver for more advanced processing.

Originally posted by @pacodinev in #46817 (comment)

[stephanosio]

@aaronemassey should this be converted to discussion?

[aaronemassey]

Done.