Re: [PATCH v2 2/3] power: supply: qcom_battmgr: add Xiaomi taoyao support

On 19/08/2026 10:37, Stanislav Zaikin wrote:
> On 8/19/26 9:11 AM, Krzysztof Kozlowski wrote:
>> On Tue, Aug 18, 2026 at 05:10:38PM +0200, user.email wrote:
>>> From: Stanislav Zaikin <[email protected]>
>>>
>>> The Xiaomi taoyao firmware defines an additional BATT_CONSTANT_CURRENT
>>> property (ID 12) between BATT_CHG_CTRL_LIM_MAX and BATT_TEMP, shifting
>>> all higher battery property IDs by one.
>>>
>>> Signed-off-by: Stanislav Zaikin <[email protected]>
>>> ---
>>>   drivers/power/supply/qcom_battmgr.c | 86 +++++++++++++++++++++++++++--
>>>   1 file changed, 82 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/power/supply/qcom_battmgr.c b/drivers/power/supply/qcom_battmgr.c
>>> index 490137a23d00..390d7c75e36f 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_SM8350,
>>>   	QCOM_BATTMGR_SM8550,
>>>   	QCOM_BATTMGR_X1E80100,
>>> +	QCOM_BATTMGR_TAOYAO,
>>
>> T < X, do not introduce entries in random order
> 
> Hello Krzysztof,
> Thank you for the review.
> 
> Will fix in v3.
> 
>>> @@ -1381,6 +1453,11 @@ static void qcom_battmgr_sm8350_callback(struct qcom_battmgr *battmgr,
>>>   	switch (opcode) {
>>>   	case BATTMGR_BAT_PROPERTY_GET:
>>>   		property = le32_to_cpu(resp->intval.property);
>>> +
>>> +		if (battmgr->variant == QCOM_BATTMGR_TAOYAO &&
>>> +		    property < ARRAY_SIZE(taoyao_to_canonical))
>>> +			property = taoyao_to_canonical[property];
>>
>> So device is or is not compatible with sm7325? Above code suggests that
>> it is not. How does it work when bound by sm7325 compatible?
> 
> The device is sm7325-based and when bound to sm7325-pmic-glink it falls 
> back to QCOM_BATTMGR_SM8350 property map. However, due to shifted 
> property IDs baked into taoyao's firmware the parsing of roughly the 2nd 
> half of properties is broken.
> 
> And any userspace process that reads the battery properties via sysfs 
> suffers from 1s timeouts and it basically hangs my DE.

So basically it is not compatible with sm7325-pmic-glink and it should
be expressed/fixed. I wonder though how was the DTS even tested in this
matter.

> 
> Since this is an RFC: do you think this approach is better than what I 
> described in cover letter? (manually shifting property IDs)

Every patch is RFC... or are you saying this is a RFC in a meaning it is
 not ready for review?

> 
>>> @@ -1617,6 +1694,7 @@ static const struct of_device_id qcom_battmgr_of_variants[] = {
>>>   	{ .compatible = "qcom,sc8280xp-pmic-glink", .data = (void *)QCOM_BATTMGR_SC8280XP },
>>>   	{ .compatible = "qcom,sm8550-pmic-glink", .data = (void *)QCOM_BATTMGR_SM8550 },
>>>   	{ .compatible = "qcom,x1e80100-pmic-glink", .data = (void *)QCOM_BATTMGR_X1E80100 },
>>> +	{ .compatible = "xiaomi,taoyao-pmic-glink", .data = (void *)QCOM_BATTMGR_TAOYAO },
>>
>> And here as well wrong order
> 
> Will fix in v3.
> 
> --
> Best regards,
> Stanislav
> 


Best regards,
Krzysztof