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

[Qianhui Xu]

Hi Konrad,

Answering the three questions directly, then what I can offer instead.

(i) Downstream kernel sources

No. I have no downstream kernel source for this device. What I have is
the prebuilt Android boot image from the vendor plus its extracted
config, so I cannot statically check how their QBG/PMIC GLINK client
populates the battery property buffer. Anything I said about the
downstream side would be a guess, so I am not going to make one.

(ii) Are the properties remapped?

I cannot prove it either way from the kernel side. There is indirect
evidence that we are not the only ones seeing something odd with that
slot on this SoC: the elden port that another group maintains carries a
battmgr patch for SM8750 that also stops advertising POWER_NOW, adapted
from h0cheung/tb322fc-linux-kernel (see
reference/upstream-armadaos-freedom/patches/0149-power-supply-qcom-battmgr-sm8750-reporting.patch,
derived from that tree at 6f97250ead15). Their comment says SM8750
reports a maximum-load value instead of live power, which is the same
observation I made. That is two independent ports of the same board
family, not two independent SoCs, so it argues against "my unit only"
and says nothing about SM8750 in general.

(iii) Does the downstream read return garbage?

Unknown. I have no observability channel into the stock Android kernel on
this unit -- no serial console, no bootloader-level kernel log handoff I
can rely on. The only comparison I can produce is kernel side: what the
driver reports versus what current_now * voltage_now says in the same
sample.

What I can do instead

A concrete, cheap criterion: print the raw 32-bit value the driver reads
for BATT_POWER_NOW together with current_now and voltage_now in the same
read, either from debugfs or one printk in
qcom_battmgr_bat_get_property(). If the raw slot is stable across load
changes while current_now * voltage_now tracks the load, the slot is not
a present-power measurement regardless of what it is. I am happy to
collect that and post it as a reply with the numbers.

A question for you

Would you accept the conservative version for now: add the SM8750
variant but do not register POWER_NOW at all, without claiming anything
about what the slot means? That removes the wrong values from userspace
without guessing at register semantics, and it is what my patch already
does. If you would rather see the property kept and only the commit
message fixed, say so and I will do that instead.

Depending on your answer I will either send v4 along those lines or drop
the property change and withdraw that part of the series.

Thanks,
Qianhui Xu