[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