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

From: Gaurav Kohli

Date: Thu Jan 29 2026 - 07:07:04 EST



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.

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


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


+
+ description:
+ Each subnode which represents qmi communication to CDSP.
+
+ properties:
+ label:
+ maxItems: 1
+
+ "#cooling-cells":
+ $ref: /schemas/thermal/thermal-cooling-devices.yaml#/properties/#cooling-cells
+
+ required:
+ - label
+ - "#cooling-cells"
+
+ additionalProperties: false
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ remoteproc-cdsp {
+ cooling {
+ compatible = "qcom,qmi-cooling-cdsp";
+
+ cdsp_tmd0: cdsp-tmd0 {
+ label = "cdsp_sw";
+ #cooling-cells = <2>;
+ };
+ };
+ };
+
+ - |
+ remoteproc-cdsp1 {
No, don't create unnecessary examples. Please read some slides from
earlier talks so you won't need 10 iterations.


Sure, will update this.


Best regards,
Krzysztof