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

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

[Qianhui Xu]

From: Xu Qianhui <xiaqinghuan@mail.ustc.edu.cn>

The SM8750 QBG firmware fills BATT_POWER_NOW via its maximum-load updater
instead of an instantaneous measurement: the property getter indexes
context + 0x6a8 + 4 * property, so property 22 (BATT_POWER_NOW) reads the
offset written by the maximum-load path.  Exposing that as power_now makes
userspace report e.g. 89 W while the battery is charging below 1 W, or
above 100 W while discharging at about 4 W.

The SM8750 PMIC GLINK node is already described in DT
("qcom,sm8750-pmic-glink" in sm8750-mtp/qrd), but the driver has no entry
for it, so it falls back to QCOM_BATTMGR_SM8350 and advertises POWER_NOW.

Add the SM8750 variant and a battery descriptor that reuses the SM8550
properties without POWER_NOW.  The property array is reordered so that
POWER_NOW is the last entry, which keeps the new descriptor a two-line
addition; property ordering itself is not ABI.

Voltage, current, charge counters and the charge-control thresholds are
retained.

Tested on Lenovo Legion Y700 Gen4 (TB322FC, SM8750P): charging and
discharging, UPower state-of-charge and rate are unchanged and power_now
is no longer exposed.

Signed-off-by: Xu Qianhui <xiaqinghuan@mail.ustc.edu.cn>
---
 drivers/power/supply/qcom_battmgr.c | 29 +++++++++++++++++++++++++++--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/power/supply/qcom_battmgr.c b/drivers/power/supply/qcom_battmgr.c
index 7716eb9e1a..dbc98ac8a7 100644
--- a/drivers/power/supply/qcom_battmgr.c
+++ b/drivers/power/supply/qcom_battmgr.c
@@ -24,6 +24,7 @@ enum qcom_battmgr_variant {
 	QCOM_BATTMGR_SC8280XP,
 	QCOM_BATTMGR_SM8350,
 	QCOM_BATTMGR_SM8550,
+	QCOM_BATTMGR_SM8750,
 	QCOM_BATTMGR_X1E80100,
 };
 
@@ -916,9 +917,13 @@ static const enum power_supply_property sm8550_bat_props[] = {
 	POWER_SUPPLY_PROP_TIME_TO_EMPTY_AVG,
 	POWER_SUPPLY_PROP_INTERNAL_RESISTANCE,
 	POWER_SUPPLY_PROP_STATE_OF_HEALTH,
-	POWER_SUPPLY_PROP_POWER_NOW,
 	POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD,
 	POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD,
+	/*
+	 * Kept last on purpose: SM8750 reuses this list without POWER_NOW,
+	 * see sm8750_bat_psy_desc.
+	 */
+	POWER_SUPPLY_PROP_POWER_NOW,
 };
 
 static const struct power_supply_desc sm8550_bat_psy_desc = {
@@ -931,6 +936,23 @@ static const struct power_supply_desc sm8550_bat_psy_desc = {
 	.property_is_writeable = qcom_battmgr_bat_is_writeable,
 };
 
+/*
+ * The SM8750 QBG firmware fills BATT_POWER_NOW from its maximum-load updater
+ * instead of from an instantaneous measurement, so the published value is not
+ * a present power reading (it reports the maximum load, e.g. 89 W while the
+ * battery is actually charging below 1 W).  Do not advertise POWER_NOW on
+ * this platform.
+ */
+static const struct power_supply_desc sm8750_bat_psy_desc = {
+	.name = "qcom-battmgr-bat",
+	.type = POWER_SUPPLY_TYPE_BATTERY,
+	.properties = sm8550_bat_props,
+	.num_properties = ARRAY_SIZE(sm8550_bat_props) - 1,
+	.get_property = qcom_battmgr_bat_get_property,
+	.set_property = qcom_battmgr_bat_set_property,
+	.property_is_writeable = qcom_battmgr_bat_is_writeable,
+};
+
 static int qcom_battmgr_ac_get_property(struct power_supply *psy,
 					enum power_supply_property psp,
 					union power_supply_propval *val)
@@ -1617,6 +1639,7 @@ static const struct of_device_id qcom_battmgr_of_variants[] = {
 	{ .compatible = "qcom,sc8180x-pmic-glink", .data = (void *)QCOM_BATTMGR_SC8280XP },
 	{ .compatible = "qcom,sc8280xp-pmic-glink", .data = (void *)QCOM_BATTMGR_SC8280XP },
 	{ .compatible = "qcom,sm8550-pmic-glink", .data = (void *)QCOM_BATTMGR_SM8550 },
+	{ .compatible = "qcom,sm8750-pmic-glink", .data = (void *)QCOM_BATTMGR_SM8750 },
 	{ .compatible = "qcom,x1e80100-pmic-glink", .data = (void *)QCOM_BATTMGR_X1E80100 },
 	/* Unmatched devices falls back to QCOM_BATTMGR_SM8350 */
 	{}
@@ -1690,7 +1713,9 @@ static int qcom_battmgr_probe(struct auxiliary_device *adev,
 			return dev_err_probe(dev, PTR_ERR(battmgr->wls_psy),
 					     "failed to register wireless charing power supply\n");
 	} else {
-		if (battmgr->variant == QCOM_BATTMGR_SM8550)
+		if (battmgr->variant == QCOM_BATTMGR_SM8750)
+			psy_desc = &sm8750_bat_psy_desc;
+		else if (battmgr->variant == QCOM_BATTMGR_SM8550)
 			psy_desc = &sm8550_bat_psy_desc;
 		else
 			psy_desc = &sm8350_bat_psy_desc;
-- 
2.53.0

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

[Konrad Dybcio]

On 10/13/26 2:21 AM, Qianhui Xu wrote:
> From: Xu Qianhui <xiaqinghuan@mail.ustc.edu.cn>
> 
> The SM8750 QBG firmware fills BATT_POWER_NOW via its maximum-load updater
> instead of an instantaneous measurement: the property getter indexes
> context + 0x6a8 + 4 * property, so property 22 (BATT_POWER_NOW) reads the
> offset written by the maximum-load path.  Exposing that as power_now makes
> userspace report e.g. 89 W while the battery is charging below 1 W, or
> above 100 W while discharging at about 4 W.
> 
> The SM8750 PMIC GLINK node is already described in DT
> ("qcom,sm8750-pmic-glink" in sm8750-mtp/qrd), but the driver has no entry
> for it, so it falls back to QCOM_BATTMGR_SM8350 and advertises POWER_NOW.
> 
> Add the SM8750 variant and a battery descriptor that reuses the SM8550
> properties without POWER_NOW.  The property array is reordered so that
> POWER_NOW is the last entry, which keeps the new descriptor a two-line
> addition; property ordering itself is not ABI.
> 
> Voltage, current, charge counters and the charge-control thresholds are
> retained.
> 
> Tested on Lenovo Legion Y700 Gen4 (TB322FC, SM8750P): charging and
> discharging, UPower state-of-charge and rate are unchanged and power_now
> is no longer exposed.
> 
> Signed-off-by: Xu Qianhui <xiaqinghuan@mail.ustc.edu.cn>
> ---

+Fenglin would we know if this is an issue on all SM8750 devices, or
perhaps something OEM-specific?

Konrad

>  drivers/power/supply/qcom_battmgr.c | 29 +++++++++++++++++++++++++++--
>  1 file changed, 27 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/power/supply/qcom_battmgr.c b/drivers/power/supply/qcom_battmgr.c
> index 7716eb9e1a..dbc98ac8a7 100644
> --- a/drivers/power/supply/qcom_battmgr.c
> +++ b/drivers/power/supply/qcom_battmgr.c
> @@ -24,6 +24,7 @@ enum qcom_battmgr_variant {
>  	QCOM_BATTMGR_SC8280XP,
>  	QCOM_BATTMGR_SM8350,
>  	QCOM_BATTMGR_SM8550,
> +	QCOM_BATTMGR_SM8750,
>  	QCOM_BATTMGR_X1E80100,
>  };
>  
> @@ -916,9 +917,13 @@ static const enum power_supply_property sm8550_bat_props[] = {
>  	POWER_SUPPLY_PROP_TIME_TO_EMPTY_AVG,
>  	POWER_SUPPLY_PROP_INTERNAL_RESISTANCE,
>  	POWER_SUPPLY_PROP_STATE_OF_HEALTH,
> -	POWER_SUPPLY_PROP_POWER_NOW,
>  	POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD,
>  	POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD,
> +	/*
> +	 * Kept last on purpose: SM8750 reuses this list without POWER_NOW,
> +	 * see sm8750_bat_psy_desc.
> +	 */
> +	POWER_SUPPLY_PROP_POWER_NOW,
>  };
>  
>  static const struct power_supply_desc sm8550_bat_psy_desc = {
> @@ -931,6 +936,23 @@ static const struct power_supply_desc sm8550_bat_psy_desc = {
>  	.property_is_writeable = qcom_battmgr_bat_is_writeable,
>  };
>  
> +/*
> + * The SM8750 QBG firmware fills BATT_POWER_NOW from its maximum-load updater
> + * instead of from an instantaneous measurement, so the published value is not
> + * a present power reading (it reports the maximum load, e.g. 89 W while the
> + * battery is actually charging below 1 W).  Do not advertise POWER_NOW on
> + * this platform.
> + */
> +static const struct power_supply_desc sm8750_bat_psy_desc = {
> +	.name = "qcom-battmgr-bat",
> +	.type = POWER_SUPPLY_TYPE_BATTERY,
> +	.properties = sm8550_bat_props,
> +	.num_properties = ARRAY_SIZE(sm8550_bat_props) - 1,
> +	.get_property = qcom_battmgr_bat_get_property,
> +	.set_property = qcom_battmgr_bat_set_property,
> +	.property_is_writeable = qcom_battmgr_bat_is_writeable,
> +};
> +
>  static int qcom_battmgr_ac_get_property(struct power_supply *psy,
>  					enum power_supply_property psp,
>  					union power_supply_propval *val)
> @@ -1617,6 +1639,7 @@ static const struct of_device_id qcom_battmgr_of_variants[] = {
>  	{ .compatible = "qcom,sc8180x-pmic-glink", .data = (void *)QCOM_BATTMGR_SC8280XP },
>  	{ .compatible = "qcom,sc8280xp-pmic-glink", .data = (void *)QCOM_BATTMGR_SC8280XP },
>  	{ .compatible = "qcom,sm8550-pmic-glink", .data = (void *)QCOM_BATTMGR_SM8550 },
> +	{ .compatible = "qcom,sm8750-pmic-glink", .data = (void *)QCOM_BATTMGR_SM8750 },
>  	{ .compatible = "qcom,x1e80100-pmic-glink", .data = (void *)QCOM_BATTMGR_X1E80100 },
>  	/* Unmatched devices falls back to QCOM_BATTMGR_SM8350 */
>  	{}
> @@ -1690,7 +1713,9 @@ static int qcom_battmgr_probe(struct auxiliary_device *adev,
>  			return dev_err_probe(dev, PTR_ERR(battmgr->wls_psy),
>  					     "failed to register wireless charing power supply\n");
>  	} else {
> -		if (battmgr->variant == QCOM_BATTMGR_SM8550)
> +		if (battmgr->variant == QCOM_BATTMGR_SM8750)
> +			psy_desc = &sm8750_bat_psy_desc;
> +		else if (battmgr->variant == QCOM_BATTMGR_SM8550)
>  			psy_desc = &sm8550_bat_psy_desc;
>  		else
>  			psy_desc = &sm8350_bat_psy_desc;

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

[Konrad Dybcio]

On 10/15/26 3:27 PM, Konrad Dybcio wrote:
> On 10/13/26 2:21 AM, Qianhui Xu wrote:
>> From: Xu Qianhui <xiaqinghuan@mail.ustc.edu.cn>
>>
>> The SM8750 QBG firmware fills BATT_POWER_NOW via its maximum-load updater
>> instead of an instantaneous measurement: the property getter indexes
>> context + 0x6a8 + 4 * property, so property 22 (BATT_POWER_NOW) reads the
>> offset written by the maximum-load path.  Exposing that as power_now makes
>> userspace report e.g. 89 W while the battery is charging below 1 W, or
>> above 100 W while discharging at about 4 W.
>>
>> The SM8750 PMIC GLINK node is already described in DT
>> ("qcom,sm8750-pmic-glink" in sm8750-mtp/qrd), but the driver has no entry
>> for it, so it falls back to QCOM_BATTMGR_SM8350 and advertises POWER_NOW.
>>
>> Add the SM8750 variant and a battery descriptor that reuses the SM8550
>> properties without POWER_NOW.  The property array is reordered so that
>> POWER_NOW is the last entry, which keeps the new descriptor a two-line
>> addition; property ordering itself is not ABI.
>>
>> Voltage, current, charge counters and the charge-control thresholds are
>> retained.
>>
>> Tested on Lenovo Legion Y700 Gen4 (TB322FC, SM8750P): charging and
>> discharging, UPower state-of-charge and rate are unchanged and power_now
>> is no longer exposed.
>>
>> Signed-off-by: Xu Qianhui <xiaqinghuan@mail.ustc.edu.cn>
>> ---
> 
> +Fenglin would we know if this is an issue on all SM8750 devices, or
> perhaps something OEM-specific?

(helps to actually Cc someone when you say you do..)

> 
> Konrad
> 
>>  drivers/power/supply/qcom_battmgr.c | 29 +++++++++++++++++++++++++++--
>>  1 file changed, 27 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/power/supply/qcom_battmgr.c b/drivers/power/supply/qcom_battmgr.c
>> index 7716eb9e1a..dbc98ac8a7 100644
>> --- a/drivers/power/supply/qcom_battmgr.c
>> +++ b/drivers/power/supply/qcom_battmgr.c
>> @@ -24,6 +24,7 @@ enum qcom_battmgr_variant {
>>  	QCOM_BATTMGR_SC8280XP,
>>  	QCOM_BATTMGR_SM8350,
>>  	QCOM_BATTMGR_SM8550,
>> +	QCOM_BATTMGR_SM8750,
>>  	QCOM_BATTMGR_X1E80100,
>>  };
>>  
>> @@ -916,9 +917,13 @@ static const enum power_supply_property sm8550_bat_props[] = {
>>  	POWER_SUPPLY_PROP_TIME_TO_EMPTY_AVG,
>>  	POWER_SUPPLY_PROP_INTERNAL_RESISTANCE,
>>  	POWER_SUPPLY_PROP_STATE_OF_HEALTH,
>> -	POWER_SUPPLY_PROP_POWER_NOW,
>>  	POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD,
>>  	POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD,
>> +	/*
>> +	 * Kept last on purpose: SM8750 reuses this list without POWER_NOW,
>> +	 * see sm8750_bat_psy_desc.
>> +	 */
>> +	POWER_SUPPLY_PROP_POWER_NOW,
>>  };
>>  
>>  static const struct power_supply_desc sm8550_bat_psy_desc = {
>> @@ -931,6 +936,23 @@ static const struct power_supply_desc sm8550_bat_psy_desc = {
>>  	.property_is_writeable = qcom_battmgr_bat_is_writeable,
>>  };
>>  
>> +/*
>> + * The SM8750 QBG firmware fills BATT_POWER_NOW from its maximum-load updater
>> + * instead of from an instantaneous measurement, so the published value is not
>> + * a present power reading (it reports the maximum load, e.g. 89 W while the
>> + * battery is actually charging below 1 W).  Do not advertise POWER_NOW on
>> + * this platform.
>> + */
>> +static const struct power_supply_desc sm8750_bat_psy_desc = {
>> +	.name = "qcom-battmgr-bat",
>> +	.type = POWER_SUPPLY_TYPE_BATTERY,
>> +	.properties = sm8550_bat_props,
>> +	.num_properties = ARRAY_SIZE(sm8550_bat_props) - 1,
>> +	.get_property = qcom_battmgr_bat_get_property,
>> +	.set_property = qcom_battmgr_bat_set_property,
>> +	.property_is_writeable = qcom_battmgr_bat_is_writeable,
>> +};
>> +
>>  static int qcom_battmgr_ac_get_property(struct power_supply *psy,
>>  					enum power_supply_property psp,
>>  					union power_supply_propval *val)
>> @@ -1617,6 +1639,7 @@ static const struct of_device_id qcom_battmgr_of_variants[] = {
>>  	{ .compatible = "qcom,sc8180x-pmic-glink", .data = (void *)QCOM_BATTMGR_SC8280XP },
>>  	{ .compatible = "qcom,sc8280xp-pmic-glink", .data = (void *)QCOM_BATTMGR_SC8280XP },
>>  	{ .compatible = "qcom,sm8550-pmic-glink", .data = (void *)QCOM_BATTMGR_SM8550 },
>> +	{ .compatible = "qcom,sm8750-pmic-glink", .data = (void *)QCOM_BATTMGR_SM8750 },
>>  	{ .compatible = "qcom,x1e80100-pmic-glink", .data = (void *)QCOM_BATTMGR_X1E80100 },
>>  	/* Unmatched devices falls back to QCOM_BATTMGR_SM8350 */
>>  	{}
>> @@ -1690,7 +1713,9 @@ static int qcom_battmgr_probe(struct auxiliary_device *adev,
>>  			return dev_err_probe(dev, PTR_ERR(battmgr->wls_psy),
>>  					     "failed to register wireless charing power supply\n");
>>  	} else {
>> -		if (battmgr->variant == QCOM_BATTMGR_SM8550)
>> +		if (battmgr->variant == QCOM_BATTMGR_SM8750)
>> +			psy_desc = &sm8750_bat_psy_desc;
>> +		else if (battmgr->variant == QCOM_BATTMGR_SM8550)
>>  			psy_desc = &sm8550_bat_psy_desc;
>>  		else
>>  			psy_desc = &sm8350_bat_psy_desc;

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

[Fenglin Wu]

On 10/15/2026 9:27 PM, Konrad Dybcio wrote:
> On 10/15/26 3:27 PM, Konrad Dybcio wrote:
>> On 10/13/26 2:21 AM, Qianhui Xu wrote:
>>> From: Xu Qianhui <xiaqinghuan@mail.ustc.edu.cn>
>>>
>>> The SM8750 QBG firmware fills BATT_POWER_NOW via its maximum-load updater
>>> instead of an instantaneous measurement: the property getter indexes
>>> context + 0x6a8 + 4 * property, so property 22 (BATT_POWER_NOW) reads the
>>> offset written by the maximum-load path.  Exposing that as power_now makes
>>> userspace report e.g. 89 W while the battery is charging below 1 W, or
>>> above 100 W while discharging at about 4 W.
>>>
>>> The SM8750 PMIC GLINK node is already described in DT
>>> ("qcom,sm8750-pmic-glink" in sm8750-mtp/qrd), but the driver has no entry
>>> for it, so it falls back to QCOM_BATTMGR_SM8350 and advertises POWER_NOW.
>>>
>>> Add the SM8750 variant and a battery descriptor that reuses the SM8550
>>> properties without POWER_NOW.  The property array is reordered so that
>>> POWER_NOW is the last entry, which keeps the new descriptor a two-line
>>> addition; property ordering itself is not ABI.
>>>
>>> Voltage, current, charge counters and the charge-control thresholds are
>>> retained.
>>>
>>> Tested on Lenovo Legion Y700 Gen4 (TB322FC, SM8750P): charging and
>>> discharging, UPower state-of-charge and rate are unchanged and power_now
>>> is no longer exposed.
>>>
>>> Signed-off-by: Xu Qianhui <xiaqinghuan@mail.ustc.edu.cn>
>>> ---
>>
>> +Fenglin would we know if this is an issue on all SM8750 devices, or
>> perhaps something OEM-specific?
> 
> (helps to actually Cc someone when you say you do..)
> 

SM8750 device supports "power_on" property in the battery management
firmware by default. Different OEMs might customized that without
supporting it.

Thanks,
Fenglin Wu

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

[Konrad Dybcio]

On 10/13/26 2:21 AM, Qianhui Xu wrote:
> From: Xu Qianhui <xiaqinghuan@mail.ustc.edu.cn>
> 
> The SM8750 QBG firmware fills BATT_POWER_NOW via its maximum-load updater
> instead of an instantaneous measurement: the property getter indexes
> context + 0x6a8 + 4 * property, so property 22 (BATT_POWER_NOW) reads the
> offset written by the maximum-load path. 

I'm having trouble parsing this.

Is that a description of what happens on the firmware side? What's a
maximum-load updater?

Konrad

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

[Qianhui Xu]

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.

What I do not have

QBG firmware sources, or a public document describing the semantics of the
BATT_POWER_NOW slot.  The "it is a maximum-load figure" reading is my
inference from the two facts above plus the vendor battery property
interface, not something I can cite.  I also cannot yet say whether this
is a property of the SM8750 firmware build, of this OEM's configuration,
or of the slot in general: Fenglin's earlier reply (default supported,
OEM can customize) would predict the latter, and confirming it needs
power_now/BATT_POWER_NOW readouts from the stock Android build on the
same unit, which I have not done.

Proposed wording

I will resend the patch with the firmware-semantics sentence removed.  The
commit message will keep only what is verifiable: on SM8750 the reported
POWER_NOW is not a present-power reading (with the two counterexamples),
the driver returns the slot as-is, and therefore this platform should not
advertise POWER_NOW.  The code change is unaffected: add the SM8750
variant and reuse the SM8550 property list without POWER_NOW.

If you happen to know the intended semantics of that slot, or know of a
QBG interface document that defines it, I would rather cite that than
describe it in my own words.  Otherwise the factual version is what I will
send.

Thanks,
Qianhui

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

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

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

[Konrad Dybcio]

On 10/23/26 9:52 AM, Qianhui Xu wrote:
> 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.

Did you try reaching out to the vendor?

Konrad

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

[Qianhui Xu]

Hi Konrad,

> Did you try reaching out to the vendor?

No, and I want to be precise about why rather than hand-wave it:

  - This tablet (Lenovo Legion Y700 Gen4, TB322FC) has no vendor channel for
    kernel sources. The public support surface is consumer warranty, not
    engineering. We are an independent bring-up, not a customer of theirs.
  - I also asked the person who is upstreaming the mainline DT for this same
    board (separate thread, private) whether a downstream tree exists publicly.
    There are partial downstream trees for sibling Lenovo tablets, but none that
    covers this unit's QBG/battery path.

So "ask the vendor" is not available to us. What I could do instead, I did:
boot the unit's own stock Android and compare it against mainline on the same
battery.

STOCK ANDROID SIDE (slot a, same unit)

  build:  Lenovo/TB322FC_PRC/TB322FC:16/BQ2A.250610.001-BP2A.250605.031.A3/\
          ZUXOS_1.5.10.259_260611_PRC:user/release-keys
  dumpsys battery:  level 94%, voltage 4309 mV, charge_counter 6439000 uAh,
                    temperature 32.3 C, status 2 (charging), health 2

Limits I hit, stated plainly: this is a user/release-keys build, so no adb
root, and SELinux denies the shell domain access to
/sys/class/power_supply/battery. I could not read the downstream kernel's own
power_now attribute. Two things I could check from userspace:

  - the Android battery stack never surfaces power_now at all: it is not in
    dumpsys battery, and a full logcat scan for power_now / BATT_POWER returns
    zero hits.
  - therefore "is power_now disabled downstream too" has no answer from a user
    build - the platform has no validated consumer of that property.

MAINLINE SIDE (same unit, same battery, same QBG firmware, minutes later)

  charge_counter 6489760 uAh, voltage_now 4285000 uV, current_now -1003000 uA,
  temp 32.1 C, capacity 94%

The shared QBG values agree with the stock numbers (charge counter within 0.8%,
voltage 24 mV, temperature 0.2 C). So the property plumbing is not the problem:
the only quantity that disagrees is POWER_NOW, and the stock stack does not use
it.

WHAT WE DO IN OUR TREE

Our SM8750 battmgr description simply does not advertise the property (the
sm8550 property list minus the trailing POWER_NOW), so on our dailies
/sys/class/power_supply/qcom-battmgr-bat has no power_now file at all - that is
what the patch you already have does.

If a readback of the raw downstream slot would settle it for you, I can unlock
and root this unit and read the value directly - it costs us a slot switch and
an unlock, so tell me if it is actually load-bearing for the patch, otherwise I
would rather keep the unit usable.

Thanks,
Xu Qianhui <xiaqinghuan@mail.ustc.edu.cn>

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

[Konrad Dybcio]

On 10/23/26 3:49 PM, Qianhui Xu wrote:
> Hi Konrad,
> 
>> Did you try reaching out to the vendor?
> 
> No, and I want to be precise about why rather than hand-wave it:
> 
>   - This tablet (Lenovo Legion Y700 Gen4, TB322FC) has no vendor channel for
>     kernel sources. The public support surface is consumer warranty, not
>     engineering. We are an independent bring-up, not a customer of theirs.
>   - I also asked the person who is upstreaming the mainline DT for this same
>     board (separate thread, private) whether a downstream tree exists publicly.
>     There are partial downstream trees for sibling Lenovo tablets, but none that
>     covers this unit's QBG/battery path.
> 
> So "ask the vendor" is not available to us. What I could do instead, I did:
> boot the unit's own stock Android and compare it against mainline on the same
> battery.

I know you're independent. Vendors generally have an obligation to
release GPL2 source code and have channels to request it. Calling
customer support will probably get you nowhere though, as it's not
the correct place.

Konrad