Re: [PATCH 1/2] bindings: power: supply: qcom,pmic-glink: Document thermal-mitigation

[Krzysztof Kozlowski <krzk@kernel.org>]

On 15/06/2026 12:46, Dhruvin Rajpura wrote:
> On Wed, Jun 10, 2026 at 2:34 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> 
>>
>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>>> +    description:
>>> +      Array of fast charge current limit values for different system
>> thermal
>>> +      mitigation levels. This should be a flat array that denotes the
>> maximum
>>> +      charging current (in uA) for each thermal level. Elements should
>> be listed
>>> +      in monotonically decreasing (non-increasing) order.
>>
>> What is a thermal level? How do you define it? How does it map to
>> thermal bindings?
>>
> 
> A thermal level corresponds to a cooling state in the Linux
> thermal framework. The driver registers a thermal cooling device
> with N states, where state 0 represents no throttling (hardware
> maximum FCC queried from firmware via BATT_CHG_CTRL_LIM_MAX)
> and states 1..N map to the array entries in decreasing current
> order.
> 
> When a thermal zone trips, the thermal framework calls
> set_cur_state(N) which sends the corresponding current value
> to the firmware via BATT_CHG_CTRL_LIM over PMIC GLink,
> limiting the battery charging current to reduce heat generation.
> 
> The array must be monotonically decreasing since higher cooling
> states represent more aggressive throttling requiring lower
> charging currents.
> 
> Will add this explanation to the binding patch commit message
> in the next version.


+Cc Daniel, Zhang and Lukasz,

This feels like broader problem, so should not be done only in this one
aspect for Qualcomm device. IMO, there should be a generic binding for
defining charging constraints and mapping them to thermal zones. That's
not only about current, but might be about voltage or charging level
speed (consider quick charging with lower amps but higher voltage).  Or
actually power is the factor here, not even current and voltage.

This should be solved in generic way. Both from the point of charger's
OPP-like data but also cooling cells for the charger.

One more thing:
Please use subject prefixes matching the subsystem. You can get them for
example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
your patch is touching. For bindings, the preferred subjects are
explained here:
https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters


Best regards,
Krzysztof