Re: [PATCH v2 2/8] dt-bindings: thermal: Add qcom,qmi-cooling yaml bindings

[Krzysztof Kozlowski]

On 11/02/2026 08:37, Gaurav Kohli wrote:
> 
> 
> On 2/8/2026 3:36 PM, Krzysztof Kozlowski wrote:
>> On 29/01/2026 13:06, Gaurav Kohli wrote:
>>>
>>> On 1/28/2026 4:57 PM, Krzysztof Kozlowski wrote:
>>>> On Tue, Jan 27, 2026 at 09:27:16PM +0530, Gaurav Kohli wrote:
>>>>> The cooling subnode of a remoteproc represents a client of the Thermal
>>>>> Mitigation Device QMI service running on it. Each subnode of the cooling
>>>>> node represents a single control exposed by the service.
>>>>>
>>>>> Signed-off-by: Gaurav Kohli <gaurav.kohli@xxxxxxxxxxxxxxxx>
>>>>> ---
>>>>>    .../bindings/remoteproc/qcom,pas-common.yaml  |  6 ++
>>>>>    .../bindings/thermal/qcom,qmi-cooling.yaml    | 72 +++++++++++++++++++
>>>>>    2 files changed, 78 insertions(+)
>>>>>    create mode 100644 Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
>>>>> index 68c17bf18987..6a736161d5ae 100644
>>>>> --- a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
>>>>> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
>>>>> @@ -80,6 +80,12 @@ properties:
>>>>>          and devices related to the ADSP.
>>>>>        unevaluatedProperties: false
>>>>>    
>>>>> +  cooling:
>>>>> +    $ref: /schemas/thermal/qcom,qmi-cooling.yaml#
>>>>> +    description:
>>>>> +      Cooling subnode which represents the cooling devices exposed by the Modem.
>>>> I do not see the reason why you need 3 (!!!) children here. Everything
>>>> should be folded here.
>>>
>>>
>>> Thanks Krzysztof for review.
>>>
>>> Each subsystem may support multiple thermal mitigation devices through
>>> remote TMD service.
>>>
>>> Because of this multiplicity, introduced separate binding file.
>>
>> This explains nothing. Subsystem does not matter for the binding. My
>> comment stays.
>>
> 
> thanks for this suggestion, we will use qcom,pas-common.yaml to define 
> bindings and avoid creating new file.

I asked not to create any children nodes.

> 
>>>
>>>>> +    unevaluatedProperties: false
>>>>> +
>>>>>    required:
>>>>>      - clocks
>>>>>      - clock-names
>>>>> diff --git a/Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml b/Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml
>>>>> new file mode 100644
>>>>> index 000000000000..0dd3bd84c176
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml
>>>>> @@ -0,0 +1,72 @@
>>>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>>>> +
>>>>> +%YAML 1.2
>>>>> +---
>>>>> +$id: http://devicetree.org/schemas/thermal/qcom,qmi-cooling.yaml#
>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>> +
>>>>> +title: Qualcomm QMI based thermal mitigation (TMD) cooling devices
>>>>> +
>>>>> +maintainers:
>>>>> +  - Gaurav Kohli <gaurav.kohli@xxxxxxxxxxxxxxxx>
>>>>> +
>>>>> +description:
>>>>> +  Qualcomm QMI-based TMD cooling devices are used to mitigate thermal conditions
>>>>> +  across multiple remote subsystems. These devices operate based on junction
>>>>> +  temperature sensors (TSENS) associated with thermal zones for each subsystem.
>>>>> +
>>>>> +properties:
>>>>> +  compatible:
>>>>> +    enum:
>>>>> +      - qcom,qmi-cooling-cdsp
>>>>> +      - qcom,qmi-cooling-cdsp1
>>>> What are the differences between them?
>>>
>>>
>>> Some SOcs support multiple CDSP/NSP instances. Each instance requires
>>> it's own
>>>
>>> compatible string to distinguish.
>>
>> Why? What are the differences?
>>
>> I will not ask third time, but just respond with NAK.
>>
> 
> For Leman's, we have multiple NSP subsystem to support compute and each 
> instance has it's own firmware and separate hardware like below for cdsp
> 
> Below data is from lemans.dtsi for cdsp subsystem:
> -> remoteproc@26300000 {
> ->  remoteproc@2a300000 {
> 
> That's why, we have introduced different compatible to distinguish 
> multiple instance, but we can also solve this with single compatible

You did not answer the question what are the differences, so I am not
going to ask third time. NAK.

> with new dt property for each subsystem instance id. Please let us know 

Instance IDs are not allowed, either. Please read writing bindings doc
or slides from talks.

Best regards,
Krzysztof