[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