mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
To: Qianhui Xu <xiaqinghuan@mail.ustc.edu.cn>,
	linux-pm@vger.kernel.org, Sebastian Reichel <sre@kernel.org>
Cc: linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Fenglin Wu <fenglin.wu@oss.qualcomm.com>
Subject: Re: [PATCH] power: supply: qcom_battmgr: do not report power_now on SM8750
Date: Thu, 15 Oct 2026 15:27:43 +0200	[thread overview]
Message-ID: <b957c95e-89b9-4e62-9e88-0c5754771511@oss.qualcomm.com> (raw)
In-Reply-To: <d3a67d47-9072-4094-85a0-7e1b75e08314@oss.qualcomm.com>

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;

  reply	other threads:[~2026-10-15 13:27 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-13  0:21 Qianhui Xu
2026-10-15 13:27 ` Konrad Dybcio
2026-10-15 13:27   ` Konrad Dybcio [this message]
2026-10-19  2:03     ` Fenglin Wu
2026-10-21  8:48 ` Konrad Dybcio

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b957c95e-89b9-4e62-9e88-0c5754771511@oss.qualcomm.com \
    --to=konrad.dybcio@oss.qualcomm.com \
    --cc=fenglin.wu@oss.qualcomm.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=sre@kernel.org \
    --cc=xiaqinghuan@mail.ustc.edu.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®