Re: [PATCH v3 1/8] dt-bindings: remoteproc: qcom,pas: add thermal mitigation properties

[Krzysztof Kozlowski <krzk@kernel.org>]

On 18/06/2026 09:17, Daniel Lezcano wrote:
> On 6/16/26 06:21, Krzysztof Kozlowski wrote:
>> On 15/06/2026 14:30, Daniel Lezcano wrote:
>>> Hi Gaurav,
>>>>>> thanks for review, shall i use driver data, which is basically pas
>>>>>> data structure like below:
>>>>>>
>>>>>> static const struct qcom_pas_data {
>>>>>>       .crash_reason_smem = 601,
>>>>>>       .firmware_name = "cdsp.mdt",
>>>>>>       .tmd_names = (const char *[]){"xyz", NULL},
>>>>>>       .num_tmds = 1,
>>>>>>
>>>>>> Is something like above acceptable? and this will also help to filter
>>>>>> tmd names as well?
>>>>>
>>>>>
>>>>> How the thermal framework will bind the thermal zone with the TMD ?
>>>>> (node pointer, id) ?
>>>>>
>>>>
>>>> Hi Daniel,
>>>>
>>>> thanks for review.
>>>>
>>>> With id only, in this case instead of taking tmd names from device tree,
>>>> qmi_tmd will take tmd name from pas_data(driver) and register with the
>>>> cooling framework with id only. Please let us know if this looks fine.
>>> May be I'm missing something but:
>>>
>>>    - The QMI TMD returns a list of names, not ids
>>>    - The QMI TMD may return the list in different order than assumed
>>>    - The cooling map index points to the name of the TMD in the DT
>>>    - This name is used to match the name in the aformentionned list
>>>    - The index in the list and the id in the DT can differ
>>>
>>> Krzysztof , I don't get why having the TMD names as properties is wrong,
>>> they describes the existing TMDs on the system and the cooling maps
>>> index points to the one to be connected with thermal zone.
>>
>>
>> 'xxx-names' have a fixed meaning in DT by convention - assign
>> identifiable strings to the 'xxx'. I miss the property 'tmd' in such
>> case - its definition and meaning. Where is it?
>>
>> But maybe you just want list of strings, so I am open to discuss it - I
>> don't understand the need for this property and commit and property
>> description tell me nothing.
>>
>> Really, this commit message is basically non-existing. It explains what
>> it did and provides that much explanation WHY:
>>
>> "- tmd-names (thermal mitigation device names)"
>>
>> Really? This is the explanation why this change is being made, why this
>> property is needed?
>>
>> So sure, describe the problem being solved and WHY this problem is being
>> solved that way. Maybe it will fit DT.
> 
> Ok, I understand
> 
> Let me try to clarify.
> 
> When the QMI TMD protocol is initialized, the list of available TMDs 
> provided by the service is requested. They are identified by a *string* 
> not a numerical id.
> 
> We can not assume the list is always in the same order because the QMI 
> TMD is a separate subsystem and the interface is the protocol. The 
> protocol does not refer to any TMD with an index but its name. 
> Hardcoding an index here is not possible.

Still given device (remoteproc) will provide a fixed, one name for TMD.
That name is fully deducible from the compatible.

> 
> The name identifies the TMD we connect to and in return we receive a 
> handler to use when sending the QMI messages.
> 
> That is for the driver part.
> 
> I understand for the DT, it is possible to not give the tmd-names 
> because the it can go into the driver's data structure.
> 
> But the thermal framework won't be able to associate a cooling device 
> (one TMD) with a thermal zone because the cooling mapping must point to 
> a cooling device in the DT.
> 
> Initially, Gaurav sent a description where each TMD was a child node of 
> the remote proc node. And you rightfully told us it is no longer the way 
> to go as stated in the documentation. And you suggested to replace the 
> child nodes with an array with the tmd-names and add an index in the 
> cooling map pointing to this array.

There was only one child node. It was one-to-one mapping, thus I don't
think I suggested using any tmd-names.

Here is the code:
https://lore.kernel.org/linux-devicetree/20251223123227.1317244-4-gaurav.kohli@oss.qualcomm.com/

and I clearly see one cooling only:

+  cooling:
+    $ref: /schemas/thermal/qcom,qmi-cooling.yaml#

Therefore I still do not see the need of tmd-names. You know the name of
cooling device, because you have strict one-to-one mapping.


> 
> The thermal framework has been extended to support this new format and 
> associate the cooling device with the thermal zone. This change is now 
> upstream for v7.2 [1]
> 
> The resulting implementation is the driver gets the tmd-names array 
> property. For each name, it connects to the QMI TMD and register the 
> cooling device with the index corresponding to the name position on the 
> tmd-names array.
> 
> On the other side, the thermal framework parses the cooling-map, gets 
> the index and do the association (binding).
> 
> The tmd-names array property replaces the child nodes and allows to do 
> the mapping between the string based identifier with a numerical id.
> 
> I hope that clarifies the approach.
> 
>    -- Daniel
> 
> [1] 
> https://lore.kernel.org/all/20260526140802.1059293-12-daniel.lezcano@oss.qualcomm.com/


Best regards,
Krzysztof