Re: [PATCH 2/2] power: supply: qcom_battmgr: Add thermal mitigation support

[Konrad Dybcio]

On 6/11/26 1:32 PM, Dhruvin Rajpura wrote:
> On Tue, Jun 9, 2026 at 3:12 PM Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx>
> wrote:
> 
>> On 6/9/26 11:16 AM, DhruvinRajpura wrote:
>>> From: Dhruvin Rajpura <drajpura@xxxxxxxxxxxxxxxx>

[...]

>>> +static int qcom_battmgr_parse_dt(struct qcom_battmgr *battmgr)
>>> +{
>>> +     struct device_node *node = battmgr->dev->of_node;
>>> +     int len, ret;
>>> +
>>> +     ret = of_property_count_elems_of_size(node,
>> "qcom,thermal-mitigation", sizeof(u32));
>>> +     if (ret == -EINVAL)
>>> +             return 0;               /* property not defined, thermal
>> mitigation disabled */
>>> +     if (ret <= 0)
>>> +             return ret;              /* real error, propagate */
>>
>> Does battmgr really expect the OS to house this information? Can we not
>> retrieve it from the running firmware?
>>
> 
> The firmware exposes only a single maximum FCC value via
> BATT_CHG_CTRL_LIM_MAX, not a set of discrete throttle levels.
> The thermal mitigation levels represent a platform policy
> decision - how aggressively to throttle charging at each
> thermal state - which varies per platform based on thermal
> design, battery capacity and use case requirements.
> 
> That said, if the preference is to avoid DT for this and instead
> derive levels programmatically from the firmware maximum, we
> could generate N evenly spaced levels between 0 and
> BATT_CHG_CTRL_LIM_MAX. However this would reduce platform
> flexibility. Happy to discuss the preferred approach.

Following up on what Krzysztof brought up in the other branch of this
thread, does battmgr only allow to throttle the charging current, or
are there toggles for e.g. power too?

And does the reported max limit current adapt to the selected PD voltage
level? (I would assume that's a stupid question, but never hurts to
confirm..)

Konrad