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

[Konrad Dybcio]

On 10/21/26 3:49 PM, Qianhui Xu wrote:
> Hi Konrad,
> 
> You are right, and thanks for stopping on that sentence.  "Maximum-load
> updater" is a phrase I invented; it is not a QBG or battmgr term from any
> document, so I should not have used it in a commit message.  Let me
> restate what I actually observed and what I am and am not claiming.
> 
> What the driver does (no bug here)
> 
> qcom_battmgr_bat_get_property() does not sample anything.  For a given
> power_supply property N it reads the 32-bit slot that the QBG
> notification buffer reserves for that property (in the SM8750 variant the
> battery property array starts at context + 0x6a8 and is indexed by
> property id, so BATT_POWER_NOW, id 22, is context + 0x6a8 + 4 * 22).
> The driver faithfully returns whatever firmware left there.
> 
> What I observed on the unit
> 
>   - charging, actual input well under 1 W: power_now reported ~89 W
>   - discharging, actual draw ~4 W:           power_now reported >100 W
>   - current_now * voltage_now in the same samples stays in the expected
>     magnitude range, i.e. the other battery properties are consistent
> 
> So on this platform the BATT_POWER_NOW slot does not hold a measurement of
> present power; it holds something closer to a configured/estimated ceiling.
> That is a statement about the value, and it is reproducible on my unit.

So it indeed seems like the OEM modifications are the culprit here. Do
you have downstream kernel sources for this device? Are the properties
remapped? Is power_now disabled there too? If not, can you read it on
a downstream kernel and see if it also returns garbage?

Konrad