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

[Konrad Dybcio]

On 8/19/26 10:37 AM, 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 <zstaseg@xxxxxxxxx>
>>>
>>> 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 <zstaseg@xxxxxxxxx>
>>> ---
>>>   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.
> 
> Since this is an RFC: do you think this approach is better than what I described in cover letter? (manually shifting property IDs)

Krzysztof is trying to say that even though the device is based on the
7325 SoC, what the kernel today knows as "pmic glink on sm7325" is not
compatible with the customized firmware on your device, so the fallback
compatible should be dropped, as it suggests that is the case

Konrad