[PATCH 0/2] power: supply: qcom_battmgr: report charge levels on SM8350-class firmware

[Jan-Michael Brummer]

On SM8350-class firmware (everything that is not SC8280XP/X1E80100) the
battery reports no usable charge level to userspace: charge_full and
charge_full_design fail with -ENODATA and there is no charge_now at all.
As a consequence UPower cannot derive an absolute energy level and never
shows a runtime estimate - the UI is limited to "charging"/"discharging".

Patch 1 is the actual bug: battmgr->unit is only populated from a
BATTMGR_BAT_INFO response, which this firmware class never sends, so the
mAh guard on the CHARGE_* properties always rejects them. The values are
fetched from the firmware and stored on every access, they are just
thrown away again.

Patch 2 adds CHARGE_NOW. There is no dedicated firmware property for it,
but BATT_CHG_COUNTER carries the remaining charge rather than a
monotonic counter on this firmware. This is the part I am least sure
about, since it does not match the charge_counter semantics described in
Documentation/ABI/testing/sysfs-class-power. Two measurements across the
SoC range agree with the reported capacity to within a percent, so at
least on this platform the interpretation holds. Happy to drop this
patch or to collect a full discharge curve if you prefer.

Both patches were tested on a Fairphone 5 (QCM6490) running
postmarketOS. Before the series:

    energy:              0 Wh
    energy-full:         0 Wh
    energy-rate:         12.4713 W
    percentage:          59%

After, discharging and charging:

    energy:              14.4347 Wh       energy:              15.6003 Wh
    energy-full:         16.8807 Wh       energy-full:         18.1505 Wh
    energy-rate:         3.39313 W        energy-rate:         7.3492 W
    time to empty:       4.3 hours        time to full:        20.8 minutes

Two observations that are out of scope here but worth recording:

  - power_now reports 72097076 while current_now * voltage_now gives
    ~11.9 W, and qcom-battmgr-usb/current_now reports 11078000 against
    an input_current_limit of 3000000. Both look like unscaled firmware
    values. UPower does not use either, so this series is unaffected.

  - state_of_health reports 100 while charge_full/charge_full_design
    works out to 96.6%, so the firmware appears to derive the two
    independently.

The time-to-full estimate is optimistic compared to the firmware's own
time_to_full_avg because UPower extrapolates linearly and does not model
the CV taper. That is expected and not a regression.

Jan-Michael Brummer (2):
  power: supply: qcom_battmgr: fix CHARGE_FULL* on SM8350-class firmware
  power: supply: qcom_battmgr: expose CHARGE_NOW on SM8350-class
    firmware

 drivers/power/supply/qcom_battmgr.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)