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

[Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>]

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@oss.qualcomm.com>
>>>> ---
>>>>    .../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.

>>
>>>> +    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@oss.qualcomm.com>
>>>> +
>>>> +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
with new dt property for each subsystem instance id. Please let us know 
if you are fine, we can use that.

>>
>>
>>> Why these are not SoC specific?
>>
>>
>> They are not soc specific because the qmi thermal mitigation interface
>> exposed by CDSP is architecturally
>>
>> identical across multiple SOCS.
> 
> I have doubts on that but anyway if you want exception from standard
> compatible rules you must come with arguments in terms of hardware and
> firmware. Above is not enough. Everyone claims that.
> 
>>
>>
>>>> +
>>>> +patternProperties:
>>>> +  "cdsp-tmd[0-9]*$":
>>>> +    type: object
>>> No, you do not need childnode. See writing bindings (covers exactly this
>>> case).
>>
>>
>> Each subsystem may support multiple thermal mitigation devices through
>> remote TMD service. So
>>
>> need childnode to distinguish for different mitigations.
> 
> NAK
> 

As each subsystem supports multiple cooling devices, So introduced
multiple child nodes for cooling binding in thermal zone.

> 
> 
> Best regards,
> Krzysztof