Re: [PATCH] power: supply: qcom_battmgr: do not report power_now on SM8750

[Qianhui Xu]

Hi Konrad,

You are right and my previous mail was wrong. I checked the repository
you pointed at and the battery/QBG path is there. Correcting it properly,
including why I got it wrong.

What I did before was a partial clone with a sparse checkout limited to
the display, mmc and audio paths. drivers/power was never materialised,
so "there is no drivers/power/supply vendor code in the drop" was an
artefact of my own checkout, not a property of the repository. That is my
mistake and I should have caught it before writing it down.

Checked now with the GitHub contents API on main (tip 210981a0ad74,
last push 2025-11-09), no full clone:

  drivers/power/supply/qti_battery_charger.c     70657 B
  drivers/power/supply/qcom_battmgr.c            39375 B
  drivers/power/supply/qcom/qti-qbg.c            78872 B
  drivers/power/supply/qcom/qbg-core.h
  drivers/power/supply/qcom/qbg-sdam.c
  drivers/power/supply/qcom/qbg-battery-profile.c
  drivers/power/supply/qcom/battery.c

The same commit is the one I have locally and git ls-tree lists all of
them, so the content was in the tree I already had.

On your three questions, now with the sources in hand:

- Which channel does the vendor actually build? CONFIG_QTI_BATTERY_CHARGER=m
  in both arch/arm64/configs/vendor/sun_perf.config and sun_le.config
  (sun = SM8750). CONFIG_BATTERY_QCOM_BATTMGR=m appears only in the generic
  defconfig, so the SM8750 build does not use the upstream-shaped driver.

- Is the property remapped? I do not see a remap. qti_battery_charger.c has
  BATT_POWER_NOW at enum value 22, maps it to POWER_SUPPLY_PROP_POWER_NOW,
  and read_property_id() sends that id unchanged to the PMIC GLINK
  firmware. Upstream qcom_battmgr.c also uses 22 for the same slot, so both
  channels address the same property id; nothing in the vendor driver
  renumbers it.

- Does that mean power_now is trustworthy on this board? No, and I am not
  going to claim it. The vendor driver answering slot 22 only shows that
  the firmware has an answer for it. It says nothing about whether the
  value tracks load.

Two things that do not change:

The vendor's own qcom_battmgr.c is an older copy - enum qcom_battmgr_variant
has only SM8350 and SC8280XP, no SM8750 - so there is still no
upstream-shaped reference implementation for this SoC to compare against.

And qti_battery_charger.c is downstream-only: it includes
linux/soc/qcom/qti_pmic_glink.h, linux/soc/qcom/battery_charger.h and
linux/soc/qcom/panel_event_notifier.h, none of which are upstream, so
qcom_battmgr cannot reuse it. Same conclusion as before, just reached with
the sources in front of me instead of behind my own checkout mistake.

So the question from my previous mail still stands, now asked with better
information: would you take the conservative version - add the SM8750
variant, do not register POWER_NOW at all, no claim about what the slot
means - or would you rather I keep the property and only fix the commit
message? If you would prefer the numbers first, I can print slot 22 next
to current_now and voltage_now in one sample and post that before sending
anything.

Sorry for the noise, and thanks for the pointer.

Qianhui Xu