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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <546faeda-d896-403c-a449-5c9b0cd7159e@kernel.org>
Date: Sun, 8 Feb 2026 11:06:27 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Gaurav Kohli <gaurav.kohli@....qualcomm.com>
Cc: andersson@...nel.org, mathieu.poirier@...aro.org, robh@...nel.org,
 krzk+dt@...nel.org, conor+dt@...nel.org, rui.zhang@...el.com,
 lukasz.luba@....com, konradybcio@...nel.org, mani@...nel.org,
 casey.connolly@...aro.org, amit.kucheria@....qualcomm.com,
 linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
 manaf.pallikunhi@....qualcomm.com
Subject: Re: [PATCH v2 2/8] dt-bindings: thermal: Add qcom,qmi-cooling yaml
 bindings

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@....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.

> 
>>> +    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@....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.

> 
> 
>> 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



Best regards,
Krzysztof