From: Jan-Michael Brummer <jan.brummer@tabos.org>
To: sre@kernel.org
Cc: andersson@kernel.org, neil.armstrong@linaro.org,
linux-arm-msm@vger.kernel.org, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org,
Jan-Michael Brummer <jan.brummer@tabos.org>
Subject: [PATCH 0/2] power: supply: qcom_battmgr: report charge levels on SM8350-class firmware
Date: Sat, 29 Aug 2026 07:45:44 +0200 [thread overview]
Message-ID: <20260829054546.86210-1-jan.brummer@tabos.org> (raw)
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(-)
next reply other threads:[~2026-08-29 5:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-29 5:45 Jan-Michael Brummer [this message]
2026-08-29 5:45 ` [PATCH 1/2] power: supply: qcom_battmgr: fix CHARGE_FULL* " Jan-Michael Brummer
2026-08-29 5:45 ` [PATCH 2/2] power: supply: qcom_battmgr: expose CHARGE_NOW " Jan-Michael Brummer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260829054546.86210-1-jan.brummer@tabos.org \
--to=jan.brummer@tabos.org \
--cc=andersson@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=sre@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®