[PATCH v1 0/8] Add RemoteProc cooling support

[PATCH v1 0/8] Add RemoteProc cooling support

[Gaurav Kohli]

This series introduces a generic remote proc cooling framework to control 
thermal sensors located on remote subsystem like modem, dsp etc.
Communications with these subsystems occurs through various channels, for example, 
QMI interface for Qualcomm.
 
The Framework provides an abstraction layer between thermal subsytem and vendor
specific remote subsystem. Vendor drivers are expected to implement callback 
and registration mechanisms with cooling framework to control cooling
devices.

This patchset also revives earlier discussions of QMI based TMD cooling
devices discussion posted on below series by Casey: 
https://lore.kernel.org/linux-devicetree/20230905-caleb-qmi_cooling-v1-0-5aa39d4164a7@linaro.org/

That series introduced Qualcomm QMI-based TMD cooling devices which 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 and registering with remoteproc 
cooling framework for cooling registration.

This patch series has a compilation/runtime dependency on another series [1].

[1] https://lore.kernel.org/linux-devicetree/20250822042316.1762153-1-quic_gkohli@quicinc.com/

Casey Connolly (2):
  remoteproc: qcom: probe all child devices
  thermal: qcom: add qmi-cooling driver

Gaurav Kohli (6):
  thermal: Add Remote Proc cooling driver
  dt-bindings: thermal: Add qcom,qmi-cooling yaml bindings
  arm64: dts: qcom: Enable cdsp qmi tmd devices for lemans
  arm64: dts: qcom: Enable cdsp qmi tmd devices for talos
  arm64: dts: qcom: Enable cdsp qmi tmd devices for kodiak
  arm64: dts: qcom: Enable cdsp qmi tmd devices for monaco

 .../bindings/remoteproc/qcom,pas-common.yaml  |   6 +
 .../bindings/thermal/qcom,qmi-cooling.yaml    |  99 ++++
 MAINTAINERS                                   |   8 +
 arch/arm64/boot/dts/qcom/kodiak.dtsi          |  36 ++
 arch/arm64/boot/dts/qcom/lemans.dtsi          | 138 ++++-
 arch/arm64/boot/dts/qcom/monaco.dtsi          |  92 ++++
 arch/arm64/boot/dts/qcom/talos.dtsi           |  23 +
 drivers/remoteproc/qcom_q6v5.c                |   4 +
 drivers/remoteproc/qcom_q6v5_mss.c            |   8 -
 drivers/soc/qcom/Kconfig                      |  13 +
 drivers/soc/qcom/Makefile                     |   1 +
 drivers/soc/qcom/qmi-cooling.c                | 498 ++++++++++++++++++
 drivers/soc/qcom/qmi-cooling.h                | 428 +++++++++++++++
 drivers/thermal/Kconfig                       |  11 +
 drivers/thermal/Makefile                      |   2 +
 drivers/thermal/qcom/qmi-cooling.h            | 428 +++++++++++++++
 drivers/thermal/remoteproc_cooling.c          | 154 ++++++
 include/linux/remoteproc_cooling.h            |  52 ++
 18 files changed, 1981 insertions(+), 20 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml
 create mode 100644 drivers/soc/qcom/qmi-cooling.c
 create mode 100644 drivers/soc/qcom/qmi-cooling.h
 create mode 100644 drivers/thermal/qcom/qmi-cooling.h
 create mode 100644 drivers/thermal/remoteproc_cooling.c
 create mode 100644 include/linux/remoteproc_cooling.h

-- 
2.34.1

[PATCH v1 1/8] thermal: Add Remote Proc cooling driver

[Gaurav Kohli]

Add a new generic driver for thermal cooling devices that control
remote processors (modem, DSP, etc.) through various communication
channels.

This driver provides an abstraction layer between the thermal
subsystem and vendor-specific remote processor communication
mechanisms.

Suggested-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
---
 MAINTAINERS                          |   8 ++
 drivers/thermal/Kconfig              |  11 ++
 drivers/thermal/Makefile             |   2 +
 drivers/thermal/remoteproc_cooling.c | 154 +++++++++++++++++++++++++++
 include/linux/remoteproc_cooling.h   |  52 +++++++++
 5 files changed, 227 insertions(+)
 create mode 100644 drivers/thermal/remoteproc_cooling.c
 create mode 100644 include/linux/remoteproc_cooling.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 679e5f11e672..c1ba87315cdf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -25935,6 +25935,14 @@ F:	drivers/thermal/cpufreq_cooling.c
 F:	drivers/thermal/cpuidle_cooling.c
 F:	include/linux/cpu_cooling.h
 
+THERMAL/REMOTEPROC_COOLING
+M:	Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
+L:	linux-pm@vger.kernel.org
+S:	Supported
+F:	drivers/thermal/remoteproc_cooling.c
+F:	include/linux/remoteproc_cooling.h
+
+
 THERMAL/POWER_ALLOCATOR
 M:	Lukasz Luba <lukasz.luba@arm.com>
 L:	linux-pm@vger.kernel.org
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index b10080d61860..31e92be34387 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -229,6 +229,17 @@ config PCIE_THERMAL
 
 	  If you want this support, you should say Y here.
 
+
+config REMOTEPROC_THERMAL
+	bool "Remote processor cooling support"
+	help
+	  This implements a generic cooling mechanism for remote processors
+	  (modem, DSP, etc.) that allows vendor-specific implementations to
+	  register thermal cooling devices and provide callbacks for thermal
+	  mitigation.
+
+	  If you want this support, you should say Y here.
+
 config THERMAL_EMULATION
 	bool "Thermal emulation mode support"
 	help
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index bb21e7ea7fc6..ae747dde54fe 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -34,6 +34,8 @@ thermal_sys-$(CONFIG_DEVFREQ_THERMAL) += devfreq_cooling.o
 
 thermal_sys-$(CONFIG_PCIE_THERMAL) += pcie_cooling.o
 
+thermal_sys-$(CONFIG_REMOTEPROC_THERMAL) += remoteproc_cooling.o
+
 obj-$(CONFIG_K3_THERMAL)	+= k3_bandgap.o k3_j72xx_bandgap.o
 # platform thermal drivers
 obj-y				+= broadcom/
diff --git a/drivers/thermal/remoteproc_cooling.c b/drivers/thermal/remoteproc_cooling.c
new file mode 100644
index 000000000000..a1f948cbde0f
--- /dev/null
+++ b/drivers/thermal/remoteproc_cooling.c
@@ -0,0 +1,154 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Remote Processor Cooling Device
+ *
+ * Copyright (c) 2025, Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#include <linux/err.h>
+#include <linux/export.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/slab.h>
+#include <linux/thermal.h>
+
+#define REMOTEPROC_PREFIX		"rproc_"
+
+struct remoteproc_cooling_ops {
+	int (*get_max_level)(void *devdata, unsigned long *level);
+	int (*get_cur_level)(void *devdata, unsigned long *level);
+	int (*set_cur_level)(void *devdata, unsigned long level);
+};
+
+/**
+ * struct remoteproc_cdev - Remote processor cooling device
+ * @cdev: Thermal cooling device handle
+ * @ops: Vendor-specific operation callbacks
+ * @devdata: Private data for vendor implementation
+ * @np: Device tree node associated with this cooling device
+ * @lock: Mutex to protect cooling device operations
+ */
+struct remoteproc_cdev {
+	struct thermal_cooling_device *cdev;
+	const struct remoteproc_cooling_ops *ops;
+	void *devdata;
+	struct device_node *np;
+	struct mutex lock;
+};
+
+
+/* Thermal cooling device callbacks */
+
+static int remoteproc_get_max_state(struct thermal_cooling_device *cdev,
+				    unsigned long *state)
+{
+	struct remoteproc_cdev *rproc_cdev = cdev->devdata;
+	int ret;
+
+	if (!rproc_cdev || !rproc_cdev->ops)
+		return -EINVAL;
+
+	mutex_lock(&rproc_cdev->lock);
+	ret = rproc_cdev->ops->get_max_level(rproc_cdev->devdata, state);
+	mutex_unlock(&rproc_cdev->lock);
+
+	return ret;
+}
+
+static int remoteproc_get_cur_state(struct thermal_cooling_device *cdev,
+				    unsigned long *state)
+{
+	struct remoteproc_cdev *rproc_cdev = cdev->devdata;
+	int ret;
+
+	if (!rproc_cdev || !rproc_cdev->ops)
+		return -EINVAL;
+
+	mutex_lock(&rproc_cdev->lock);
+	ret = rproc_cdev->ops->get_cur_level(rproc_cdev->devdata, state);
+	mutex_unlock(&rproc_cdev->lock);
+
+	return ret;
+}
+
+static int remoteproc_set_cur_state(struct thermal_cooling_device *cdev,
+				    unsigned long state)
+{
+	struct remoteproc_cdev *rproc_cdev = cdev->devdata;
+	int ret;
+
+	if (!rproc_cdev || !rproc_cdev->ops)
+		return -EINVAL;
+
+	mutex_lock(&rproc_cdev->lock);
+	ret = rproc_cdev->ops->set_cur_level(rproc_cdev->devdata, state);
+	mutex_unlock(&rproc_cdev->lock);
+
+	return ret;
+}
+
+static const struct thermal_cooling_device_ops remoteproc_cooling_ops = {
+	.get_max_state = remoteproc_get_max_state,
+	.get_cur_state = remoteproc_get_cur_state,
+	.set_cur_state = remoteproc_set_cur_state,
+};
+
+struct remoteproc_cdev *
+remoteproc_cooling_register(struct device_node *np,
+			     const char *name, const struct remoteproc_cooling_ops *ops,
+			     void *devdata)
+{
+	struct remoteproc_cdev *rproc_cdev;
+	struct thermal_cooling_device *cdev;
+	int ret;
+
+	if (!name || !ops) {
+		return ERR_PTR(-EINVAL);
+	}
+
+	rproc_cdev = kzalloc(sizeof(*rproc_cdev), GFP_KERNEL);
+	if (!rproc_cdev)
+		return ERR_PTR(-ENOMEM);
+
+	rproc_cdev->ops = ops;
+	rproc_cdev->devdata = devdata;
+	rproc_cdev->np = np;
+	mutex_init(&rproc_cdev->lock);
+
+	char *rproc_name __free(kfree) =
+		kasprintf(GFP_KERNEL, REMOTEPROC_PREFIX "%s", name);
+	/* Register with thermal framework */
+	if (np) {
+		cdev = thermal_of_cooling_device_register(np, rproc_name, rproc_cdev,
+							  &remoteproc_cooling_ops);
+	}
+
+	if (IS_ERR(cdev)) {
+		ret = PTR_ERR(cdev);
+		goto free_rproc_cdev;
+	}
+
+	rproc_cdev->cdev = cdev;
+
+	return rproc_cdev;
+
+free_rproc_cdev:
+	kfree(rproc_cdev);
+	return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(remoteproc_cooling_register);
+
+void remoteproc_cooling_unregister(struct remoteproc_cdev *rproc_cdev)
+{
+	if (!rproc_cdev)
+		return;
+
+	thermal_cooling_device_unregister(rproc_cdev->cdev);
+	mutex_destroy(&rproc_cdev->lock);
+	kfree(rproc_cdev);
+}
+EXPORT_SYMBOL_GPL(remoteproc_cooling_unregister);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Remote Processor Cooling Device");
diff --git a/include/linux/remoteproc_cooling.h b/include/linux/remoteproc_cooling.h
new file mode 100644
index 000000000000..ef94019d220d
--- /dev/null
+++ b/include/linux/remoteproc_cooling.h
@@ -0,0 +1,52 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Remote Processor Cooling Device
+ *
+ * Copyright (c) 2025, Qualcomm Innovation Center
+ */
+
+#ifndef __REMOTEPROC_COOLING_H__
+#define __REMOTEPROC_COOLING_H__
+
+#include <linux/thermal.h>
+
+struct device;
+struct device_node;
+
+struct remoteproc_cooling_ops {
+	int (*get_max_level)(void *devdata, unsigned long *level);
+	int (*get_cur_level)(void *devdata, unsigned long *level);
+	int (*set_cur_level)(void *devdata, unsigned long level);
+};
+
+struct remoteproc_cdev;
+
+#ifdef CONFIG_REMOTEPROC_THERMAL
+
+struct remoteproc_cdev *
+remoteproc_cooling_register(struct device_node *np,
+			     const char *name,
+			     const struct remoteproc_cooling_ops *ops,
+			     void *devdata);
+
+void remoteproc_cooling_unregister(struct remoteproc_cdev *rproc_cdev);
+
+#else /* !CONFIG_REMOTEPROC_THERMAL */
+
+static inline struct remoteproc_cdev *
+remoteproc_cooling_register(struct device_node *np,
+			     const char *name,
+			     const struct remoteproc_cooling_ops *ops,
+			     void *devdata)
+{
+	return ERR_PTR(-EINVAL);
+}
+
+static inline void
+remoteproc_cooling_unregister(struct remoteproc_cdev *rproc_cdev)
+{
+}
+
+#endif /* CONFIG_REMOTEPROC_THERMAL */
+
+#endif /* __REMOTEPROC_COOLING_H__ */
-- 
2.34.1

Re: [PATCH v1 1/8] thermal: Add Remote Proc cooling driver

[Dmitry Baryshkov]

On Tue, Dec 23, 2025 at 06:02:20PM +0530, Gaurav Kohli wrote:
> Add a new generic driver for thermal cooling devices that control
> remote processors (modem, DSP, etc.) through various communication
> channels.
> 
> This driver provides an abstraction layer between the thermal
> subsystem and vendor-specific remote processor communication
> mechanisms.

This driver simply wraps 3 callbacks. Please explain in the commit
message, why do we need it? Why can't the consumer of this API simply
provide those callbacks directly?

> 
> Suggested-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
> ---
>  MAINTAINERS                          |   8 ++
>  drivers/thermal/Kconfig              |  11 ++
>  drivers/thermal/Makefile             |   2 +
>  drivers/thermal/remoteproc_cooling.c | 154 +++++++++++++++++++++++++++
>  include/linux/remoteproc_cooling.h   |  52 +++++++++
>  5 files changed, 227 insertions(+)
>  create mode 100644 drivers/thermal/remoteproc_cooling.c
>  create mode 100644 include/linux/remoteproc_cooling.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 679e5f11e672..c1ba87315cdf 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -25935,6 +25935,14 @@ F:	drivers/thermal/cpufreq_cooling.c
>  F:	drivers/thermal/cpuidle_cooling.c
>  F:	include/linux/cpu_cooling.h
>  
> +THERMAL/REMOTEPROC_COOLING
> +M:	Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
> +L:	linux-pm@vger.kernel.org
> +S:	Supported
> +F:	drivers/thermal/remoteproc_cooling.c
> +F:	include/linux/remoteproc_cooling.h
> +
> +
>  THERMAL/POWER_ALLOCATOR
>  M:	Lukasz Luba <lukasz.luba@arm.com>
>  L:	linux-pm@vger.kernel.org
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index b10080d61860..31e92be34387 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -229,6 +229,17 @@ config PCIE_THERMAL
>  
>  	  If you want this support, you should say Y here.
>  
> +
> +config REMOTEPROC_THERMAL
> +	bool "Remote processor cooling support"

Why this is 'bool' rather than 'tristate'?

> +	help
> +	  This implements a generic cooling mechanism for remote processors
> +	  (modem, DSP, etc.) that allows vendor-specific implementations to
> +	  register thermal cooling devices and provide callbacks for thermal
> +	  mitigation.
> +
> +	  If you want this support, you should say Y here.
> +
>  config THERMAL_EMULATION
>  	bool "Thermal emulation mode support"
>  	help
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index bb21e7ea7fc6..ae747dde54fe 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -34,6 +34,8 @@ thermal_sys-$(CONFIG_DEVFREQ_THERMAL) += devfreq_cooling.o
>  
>  thermal_sys-$(CONFIG_PCIE_THERMAL) += pcie_cooling.o
>  
> +thermal_sys-$(CONFIG_REMOTEPROC_THERMAL) += remoteproc_cooling.o
> +
>  obj-$(CONFIG_K3_THERMAL)	+= k3_bandgap.o k3_j72xx_bandgap.o
>  # platform thermal drivers
>  obj-y				+= broadcom/
> diff --git a/drivers/thermal/remoteproc_cooling.c b/drivers/thermal/remoteproc_cooling.c
> new file mode 100644
> index 000000000000..a1f948cbde0f
> --- /dev/null
> +++ b/drivers/thermal/remoteproc_cooling.c
> @@ -0,0 +1,154 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Remote Processor Cooling Device
> + *
> + * Copyright (c) 2025, Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#include <linux/err.h>
> +#include <linux/export.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of.h>
> +#include <linux/slab.h>
> +#include <linux/thermal.h>
> +
> +#define REMOTEPROC_PREFIX		"rproc_"
> +
> +struct remoteproc_cooling_ops {
> +	int (*get_max_level)(void *devdata, unsigned long *level);
> +	int (*get_cur_level)(void *devdata, unsigned long *level);
> +	int (*set_cur_level)(void *devdata, unsigned long level);
> +};
> +
> +/**
> + * struct remoteproc_cdev - Remote processor cooling device
> + * @cdev: Thermal cooling device handle
> + * @ops: Vendor-specific operation callbacks
> + * @devdata: Private data for vendor implementation
> + * @np: Device tree node associated with this cooling device
> + * @lock: Mutex to protect cooling device operations
> + */
> +struct remoteproc_cdev {
> +	struct thermal_cooling_device *cdev;
> +	const struct remoteproc_cooling_ops *ops;
> +	void *devdata;
> +	struct device_node *np;
> +	struct mutex lock;
> +};
> +
> +
> +/* Thermal cooling device callbacks */
> +
> +static int remoteproc_get_max_state(struct thermal_cooling_device *cdev,
> +				    unsigned long *state)
> +{
> +	struct remoteproc_cdev *rproc_cdev = cdev->devdata;
> +	int ret;
> +
> +	if (!rproc_cdev || !rproc_cdev->ops)
> +		return -EINVAL;
> +
> +	mutex_lock(&rproc_cdev->lock);
> +	ret = rproc_cdev->ops->get_max_level(rproc_cdev->devdata, state);
> +	mutex_unlock(&rproc_cdev->lock);
> +
> +	return ret;
> +}
> +
> +static int remoteproc_get_cur_state(struct thermal_cooling_device *cdev,
> +				    unsigned long *state)
> +{
> +	struct remoteproc_cdev *rproc_cdev = cdev->devdata;
> +	int ret;
> +
> +	if (!rproc_cdev || !rproc_cdev->ops)
> +		return -EINVAL;
> +
> +	mutex_lock(&rproc_cdev->lock);
> +	ret = rproc_cdev->ops->get_cur_level(rproc_cdev->devdata, state);
> +	mutex_unlock(&rproc_cdev->lock);
> +
> +	return ret;
> +}
> +
> +static int remoteproc_set_cur_state(struct thermal_cooling_device *cdev,
> +				    unsigned long state)
> +{
> +	struct remoteproc_cdev *rproc_cdev = cdev->devdata;
> +	int ret;
> +
> +	if (!rproc_cdev || !rproc_cdev->ops)
> +		return -EINVAL;
> +
> +	mutex_lock(&rproc_cdev->lock);
> +	ret = rproc_cdev->ops->set_cur_level(rproc_cdev->devdata, state);
> +	mutex_unlock(&rproc_cdev->lock);
> +
> +	return ret;
> +}
> +
> +static const struct thermal_cooling_device_ops remoteproc_cooling_ops = {
> +	.get_max_state = remoteproc_get_max_state,
> +	.get_cur_state = remoteproc_get_cur_state,
> +	.set_cur_state = remoteproc_set_cur_state,
> +};
> +
> +struct remoteproc_cdev *
> +remoteproc_cooling_register(struct device_node *np,
> +			     const char *name, const struct remoteproc_cooling_ops *ops,
> +			     void *devdata)
> +{
> +	struct remoteproc_cdev *rproc_cdev;
> +	struct thermal_cooling_device *cdev;
> +	int ret;
> +
> +	if (!name || !ops) {
> +		return ERR_PTR(-EINVAL);
> +	}
> +
> +	rproc_cdev = kzalloc(sizeof(*rproc_cdev), GFP_KERNEL);
> +	if (!rproc_cdev)
> +		return ERR_PTR(-ENOMEM);
> +
> +	rproc_cdev->ops = ops;
> +	rproc_cdev->devdata = devdata;
> +	rproc_cdev->np = np;
> +	mutex_init(&rproc_cdev->lock);
> +
> +	char *rproc_name __free(kfree) =
> +		kasprintf(GFP_KERNEL, REMOTEPROC_PREFIX "%s", name);
> +	/* Register with thermal framework */
> +	if (np) {
> +		cdev = thermal_of_cooling_device_register(np, rproc_name, rproc_cdev,
> +							  &remoteproc_cooling_ops);
> +	}
> +
> +	if (IS_ERR(cdev)) {
> +		ret = PTR_ERR(cdev);
> +		goto free_rproc_cdev;
> +	}

So, if np == NULL, we register nothing, but still return 0 (aka no
error). Why?

> +
> +	rproc_cdev->cdev = cdev;
> +
> +	return rproc_cdev;
> +
> +free_rproc_cdev:
> +	kfree(rproc_cdev);
> +	return ERR_PTR(ret);
> +}
> +EXPORT_SYMBOL_GPL(remoteproc_cooling_register);
> +
> +void remoteproc_cooling_unregister(struct remoteproc_cdev *rproc_cdev)
> +{
> +	if (!rproc_cdev)
> +		return;
> +
> +	thermal_cooling_device_unregister(rproc_cdev->cdev);
> +	mutex_destroy(&rproc_cdev->lock);
> +	kfree(rproc_cdev);
> +}
> +EXPORT_SYMBOL_GPL(remoteproc_cooling_unregister);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("Remote Processor Cooling Device");
> diff --git a/include/linux/remoteproc_cooling.h b/include/linux/remoteproc_cooling.h
> new file mode 100644
> index 000000000000..ef94019d220d
> --- /dev/null
> +++ b/include/linux/remoteproc_cooling.h
> @@ -0,0 +1,52 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Remote Processor Cooling Device
> + *
> + * Copyright (c) 2025, Qualcomm Innovation Center
> + */
> +
> +#ifndef __REMOTEPROC_COOLING_H__
> +#define __REMOTEPROC_COOLING_H__
> +
> +#include <linux/thermal.h>
> +
> +struct device;
> +struct device_node;
> +
> +struct remoteproc_cooling_ops {
> +	int (*get_max_level)(void *devdata, unsigned long *level);
> +	int (*get_cur_level)(void *devdata, unsigned long *level);
> +	int (*set_cur_level)(void *devdata, unsigned long level);
> +};
> +
> +struct remoteproc_cdev;
> +
> +#ifdef CONFIG_REMOTEPROC_THERMAL
> +
> +struct remoteproc_cdev *
> +remoteproc_cooling_register(struct device_node *np,
> +			     const char *name,
> +			     const struct remoteproc_cooling_ops *ops,
> +			     void *devdata);
> +
> +void remoteproc_cooling_unregister(struct remoteproc_cdev *rproc_cdev);
> +
> +#else /* !CONFIG_REMOTEPROC_THERMAL */
> +
> +static inline struct remoteproc_cdev *
> +remoteproc_cooling_register(struct device_node *np,
> +			     const char *name,
> +			     const struct remoteproc_cooling_ops *ops,
> +			     void *devdata)
> +{
> +	return ERR_PTR(-EINVAL);
> +}
> +
> +static inline void
> +remoteproc_cooling_unregister(struct remoteproc_cdev *rproc_cdev)
> +{
> +}
> +
> +#endif /* CONFIG_REMOTEPROC_THERMAL */
> +
> +#endif /* __REMOTEPROC_COOLING_H__ */
> -- 
> 2.34.1
> 

-- 
With best wishes
Dmitry

Re: [PATCH v1 1/8] thermal: Add Remote Proc cooling driver

[Gaurav Kohli]

On 12/24/2025 12:53 AM, Dmitry Baryshkov wrote:
> On Tue, Dec 23, 2025 at 06:02:20PM +0530, Gaurav Kohli wrote:
>> Add a new generic driver for thermal cooling devices that control
>> remote processors (modem, DSP, etc.) through various communication
>> channels.
>>
>> This driver provides an abstraction layer between the thermal
>> subsystem and vendor-specific remote processor communication
>> mechanisms.
> This driver simply wraps 3 callbacks. Please explain in the commit
> message, why do we need it? Why can't the consumer of this API simply
> provide those callbacks directly?


thanks for review, sure i will update in next post.


>> Suggested-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
>> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>> ---
>>   MAINTAINERS                          |   8 ++
>>   drivers/thermal/Kconfig              |  11 ++
>>   drivers/thermal/Makefile             |   2 +
>>   drivers/thermal/remoteproc_cooling.c | 154 +++++++++++++++++++++++++++
>>   include/linux/remoteproc_cooling.h   |  52 +++++++++
>>   5 files changed, 227 insertions(+)
>>   create mode 100644 drivers/thermal/remoteproc_cooling.c
>>   create mode 100644 include/linux/remoteproc_cooling.h
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 679e5f11e672..c1ba87315cdf 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -25935,6 +25935,14 @@ F:	drivers/thermal/cpufreq_cooling.c
>>   F:	drivers/thermal/cpuidle_cooling.c
>>   F:	include/linux/cpu_cooling.h
>>   
>> +THERMAL/REMOTEPROC_COOLING
>> +M:	Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>> +L:	linux-pm@vger.kernel.org
>> +S:	Supported
>> +F:	drivers/thermal/remoteproc_cooling.c
>> +F:	include/linux/remoteproc_cooling.h
>> +
>> +
>>   THERMAL/POWER_ALLOCATOR
>>   M:	Lukasz Luba <lukasz.luba@arm.com>
>>   L:	linux-pm@vger.kernel.org
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index b10080d61860..31e92be34387 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -229,6 +229,17 @@ config PCIE_THERMAL
>>   
>>   	  If you want this support, you should say Y here.
>>   
>> +
>> +config REMOTEPROC_THERMAL
>> +	bool "Remote processor cooling support"
> Why this is 'bool' rather than 'tristate'?


tristate will be fine, will update this.


>
>> +	help
>> +	  This implements a generic cooling mechanism for remote processors
>> +	  (modem, DSP, etc.) that allows vendor-specific implementations to
>> +	  register thermal cooling devices and provide callbacks for thermal
>> +	  mitigation.
>> +
>> +	  If you want this support, you should say Y here.
>> +
>>   config THERMAL_EMULATION
>>   	bool "Thermal emulation mode support"
>>   	help
>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
>> index bb21e7ea7fc6..ae747dde54fe 100644
>> --- a/drivers/thermal/Makefile
>> +++ b/drivers/thermal/Makefile
>> @@ -34,6 +34,8 @@ thermal_sys-$(CONFIG_DEVFREQ_THERMAL) += devfreq_cooling.o
>>   
>>   thermal_sys-$(CONFIG_PCIE_THERMAL) += pcie_cooling.o
>>   
>> +thermal_sys-$(CONFIG_REMOTEPROC_THERMAL) += remoteproc_cooling.o
>> +
>>   obj-$(CONFIG_K3_THERMAL)	+= k3_bandgap.o k3_j72xx_bandgap.o
>>   # platform thermal drivers
>>   obj-y				+= broadcom/
>> diff --git a/drivers/thermal/remoteproc_cooling.c b/drivers/thermal/remoteproc_cooling.c
>> new file mode 100644
>> index 000000000000..a1f948cbde0f
>> --- /dev/null
>> +++ b/drivers/thermal/remoteproc_cooling.c
>> @@ -0,0 +1,154 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Remote Processor Cooling Device
>> + *
>> + * Copyright (c) 2025, Qualcomm Innovation Center, Inc. All rights reserved.
>> + */
>> +
>> +#include <linux/err.h>
>> +#include <linux/export.h>
>> +#include <linux/module.h>
>> +#include <linux/mutex.h>
>> +#include <linux/of.h>
>> +#include <linux/slab.h>
>> +#include <linux/thermal.h>
>> +
>> +#define REMOTEPROC_PREFIX		"rproc_"
>> +
>> +struct remoteproc_cooling_ops {
>> +	int (*get_max_level)(void *devdata, unsigned long *level);
>> +	int (*get_cur_level)(void *devdata, unsigned long *level);
>> +	int (*set_cur_level)(void *devdata, unsigned long level);
>> +};
>> +
>> +/**
>> + * struct remoteproc_cdev - Remote processor cooling device
>> + * @cdev: Thermal cooling device handle
>> + * @ops: Vendor-specific operation callbacks
>> + * @devdata: Private data for vendor implementation
>> + * @np: Device tree node associated with this cooling device
>> + * @lock: Mutex to protect cooling device operations
>> + */
>> +struct remoteproc_cdev {
>> +	struct thermal_cooling_device *cdev;
>> +	const struct remoteproc_cooling_ops *ops;
>> +	void *devdata;
>> +	struct device_node *np;
>> +	struct mutex lock;
>> +};
>> +
>> +
>> +/* Thermal cooling device callbacks */
>> +
>> +static int remoteproc_get_max_state(struct thermal_cooling_device *cdev,
>> +				    unsigned long *state)
>> +{
>> +	struct remoteproc_cdev *rproc_cdev = cdev->devdata;
>> +	int ret;
>> +
>> +	if (!rproc_cdev || !rproc_cdev->ops)
>> +		return -EINVAL;
>> +
>> +	mutex_lock(&rproc_cdev->lock);
>> +	ret = rproc_cdev->ops->get_max_level(rproc_cdev->devdata, state);
>> +	mutex_unlock(&rproc_cdev->lock);
>> +
>> +	return ret;
>> +}
>> +
>> +static int remoteproc_get_cur_state(struct thermal_cooling_device *cdev,
>> +				    unsigned long *state)
>> +{
>> +	struct remoteproc_cdev *rproc_cdev = cdev->devdata;
>> +	int ret;
>> +
>> +	if (!rproc_cdev || !rproc_cdev->ops)
>> +		return -EINVAL;
>> +
>> +	mutex_lock(&rproc_cdev->lock);
>> +	ret = rproc_cdev->ops->get_cur_level(rproc_cdev->devdata, state);
>> +	mutex_unlock(&rproc_cdev->lock);
>> +
>> +	return ret;
>> +}
>> +
>> +static int remoteproc_set_cur_state(struct thermal_cooling_device *cdev,
>> +				    unsigned long state)
>> +{
>> +	struct remoteproc_cdev *rproc_cdev = cdev->devdata;
>> +	int ret;
>> +
>> +	if (!rproc_cdev || !rproc_cdev->ops)
>> +		return -EINVAL;
>> +
>> +	mutex_lock(&rproc_cdev->lock);
>> +	ret = rproc_cdev->ops->set_cur_level(rproc_cdev->devdata, state);
>> +	mutex_unlock(&rproc_cdev->lock);
>> +
>> +	return ret;
>> +}
>> +
>> +static const struct thermal_cooling_device_ops remoteproc_cooling_ops = {
>> +	.get_max_state = remoteproc_get_max_state,
>> +	.get_cur_state = remoteproc_get_cur_state,
>> +	.set_cur_state = remoteproc_set_cur_state,
>> +};
>> +
>> +struct remoteproc_cdev *
>> +remoteproc_cooling_register(struct device_node *np,
>> +			     const char *name, const struct remoteproc_cooling_ops *ops,
>> +			     void *devdata)
>> +{
>> +	struct remoteproc_cdev *rproc_cdev;
>> +	struct thermal_cooling_device *cdev;
>> +	int ret;
>> +
>> +	if (!name || !ops) {
>> +		return ERR_PTR(-EINVAL);
>> +	}
>> +
>> +	rproc_cdev = kzalloc(sizeof(*rproc_cdev), GFP_KERNEL);
>> +	if (!rproc_cdev)
>> +		return ERR_PTR(-ENOMEM);
>> +
>> +	rproc_cdev->ops = ops;
>> +	rproc_cdev->devdata = devdata;
>> +	rproc_cdev->np = np;
>> +	mutex_init(&rproc_cdev->lock);
>> +
>> +	char *rproc_name __free(kfree) =
>> +		kasprintf(GFP_KERNEL, REMOTEPROC_PREFIX "%s", name);
>> +	/* Register with thermal framework */
>> +	if (np) {
>> +		cdev = thermal_of_cooling_device_register(np, rproc_name, rproc_cdev,
>> +							  &remoteproc_cooling_ops);
>> +	}
>> +
>> +	if (IS_ERR(cdev)) {
>> +		ret = PTR_ERR(cdev);
>> +		goto free_rproc_cdev;
>> +	}
> So, if np == NULL, we register nothing, but still return 0 (aka no
> error). Why?
>
>> +
>> +	rproc_cdev->cdev = cdev;
>> +
>> +	return rproc_cdev;
>> +
>> +free_rproc_cdev:
>> +	kfree(rproc_cdev);
>> +	return ERR_PTR(ret);
>> +}
>> +EXPORT_SYMBOL_GPL(remoteproc_cooling_register);
>> +
>> +void remoteproc_cooling_unregister(struct remoteproc_cdev *rproc_cdev)
>> +{
>> +	if (!rproc_cdev)
>> +		return;
>> +
>> +	thermal_cooling_device_unregister(rproc_cdev->cdev);
>> +	mutex_destroy(&rproc_cdev->lock);
>> +	kfree(rproc_cdev);
>> +}
>> +EXPORT_SYMBOL_GPL(remoteproc_cooling_unregister);
>> +
>> +MODULE_LICENSE("GPL");
>> +MODULE_DESCRIPTION("Remote Processor Cooling Device");
>> diff --git a/include/linux/remoteproc_cooling.h b/include/linux/remoteproc_cooling.h
>> new file mode 100644
>> index 000000000000..ef94019d220d
>> --- /dev/null
>> +++ b/include/linux/remoteproc_cooling.h
>> @@ -0,0 +1,52 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * Remote Processor Cooling Device
>> + *
>> + * Copyright (c) 2025, Qualcomm Innovation Center
>> + */
>> +
>> +#ifndef __REMOTEPROC_COOLING_H__
>> +#define __REMOTEPROC_COOLING_H__
>> +
>> +#include <linux/thermal.h>
>> +
>> +struct device;
>> +struct device_node;
>> +
>> +struct remoteproc_cooling_ops {
>> +	int (*get_max_level)(void *devdata, unsigned long *level);
>> +	int (*get_cur_level)(void *devdata, unsigned long *level);
>> +	int (*set_cur_level)(void *devdata, unsigned long level);
>> +};
>> +
>> +struct remoteproc_cdev;
>> +
>> +#ifdef CONFIG_REMOTEPROC_THERMAL
>> +
>> +struct remoteproc_cdev *
>> +remoteproc_cooling_register(struct device_node *np,
>> +			     const char *name,
>> +			     const struct remoteproc_cooling_ops *ops,
>> +			     void *devdata);
>> +
>> +void remoteproc_cooling_unregister(struct remoteproc_cdev *rproc_cdev);
>> +
>> +#else /* !CONFIG_REMOTEPROC_THERMAL */
>> +
>> +static inline struct remoteproc_cdev *
>> +remoteproc_cooling_register(struct device_node *np,
>> +			     const char *name,
>> +			     const struct remoteproc_cooling_ops *ops,
>> +			     void *devdata)
>> +{
>> +	return ERR_PTR(-EINVAL);
>> +}
>> +
>> +static inline void
>> +remoteproc_cooling_unregister(struct remoteproc_cdev *rproc_cdev)
>> +{
>> +}
>> +
>> +#endif /* CONFIG_REMOTEPROC_THERMAL */
>> +
>> +#endif /* __REMOTEPROC_COOLING_H__ */
>> -- 
>> 2.34.1
>>

Re: [PATCH v1 1/8] thermal: Add Remote Proc cooling driver

[Bjorn Andersson]

On Tue, Dec 23, 2025 at 06:02:20PM +0530, Gaurav Kohli wrote:
> Add a new generic driver for thermal cooling devices that control
> remote processors (modem, DSP, etc.) through various communication
> channels.
> 
> This driver provides an abstraction layer between the thermal
> subsystem and vendor-specific remote processor communication
> mechanisms.
> 
> Suggested-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
> ---
>  MAINTAINERS                          |   8 ++
>  drivers/thermal/Kconfig              |  11 ++
>  drivers/thermal/Makefile             |   2 +
>  drivers/thermal/remoteproc_cooling.c | 154 +++++++++++++++++++++++++++
>  include/linux/remoteproc_cooling.h   |  52 +++++++++
>  5 files changed, 227 insertions(+)
>  create mode 100644 drivers/thermal/remoteproc_cooling.c
>  create mode 100644 include/linux/remoteproc_cooling.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 679e5f11e672..c1ba87315cdf 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -25935,6 +25935,14 @@ F:	drivers/thermal/cpufreq_cooling.c
>  F:	drivers/thermal/cpuidle_cooling.c
>  F:	include/linux/cpu_cooling.h
>  
> +THERMAL/REMOTEPROC_COOLING
> +M:	Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
> +L:	linux-pm@vger.kernel.org
> +S:	Supported
> +F:	drivers/thermal/remoteproc_cooling.c
> +F:	include/linux/remoteproc_cooling.h
> +
> +

Two empty lines here...

>  THERMAL/POWER_ALLOCATOR
>  M:	Lukasz Luba <lukasz.luba@arm.com>
>  L:	linux-pm@vger.kernel.org
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index b10080d61860..31e92be34387 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -229,6 +229,17 @@ config PCIE_THERMAL
>  
>  	  If you want this support, you should say Y here.
>  
> +

And two here...

> +config REMOTEPROC_THERMAL
> +	bool "Remote processor cooling support"
> +	help
> +	  This implements a generic cooling mechanism for remote processors
> +	  (modem, DSP, etc.) that allows vendor-specific implementations to
> +	  register thermal cooling devices and provide callbacks for thermal
> +	  mitigation.
> +
> +	  If you want this support, you should say Y here.
> +
>  config THERMAL_EMULATION
>  	bool "Thermal emulation mode support"
>  	help
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index bb21e7ea7fc6..ae747dde54fe 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -34,6 +34,8 @@ thermal_sys-$(CONFIG_DEVFREQ_THERMAL) += devfreq_cooling.o
>  
>  thermal_sys-$(CONFIG_PCIE_THERMAL) += pcie_cooling.o
>  
> +thermal_sys-$(CONFIG_REMOTEPROC_THERMAL) += remoteproc_cooling.o
> +
>  obj-$(CONFIG_K3_THERMAL)	+= k3_bandgap.o k3_j72xx_bandgap.o
>  # platform thermal drivers
>  obj-y				+= broadcom/
> diff --git a/drivers/thermal/remoteproc_cooling.c b/drivers/thermal/remoteproc_cooling.c
> new file mode 100644
> index 000000000000..a1f948cbde0f
> --- /dev/null
> +++ b/drivers/thermal/remoteproc_cooling.c
> @@ -0,0 +1,154 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Remote Processor Cooling Device
> + *
> + * Copyright (c) 2025, Qualcomm Innovation Center, Inc. All rights reserved.

No, that's not the right one.

> + */
> +
> +#include <linux/err.h>
> +#include <linux/export.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of.h>
> +#include <linux/slab.h>
> +#include <linux/thermal.h>
> +
> +#define REMOTEPROC_PREFIX		"rproc_"
> +
> +struct remoteproc_cooling_ops {
> +	int (*get_max_level)(void *devdata, unsigned long *level);
> +	int (*get_cur_level)(void *devdata, unsigned long *level);
> +	int (*set_cur_level)(void *devdata, unsigned long level);
> +};
> +
> +/**
> + * struct remoteproc_cdev - Remote processor cooling device
> + * @cdev: Thermal cooling device handle
> + * @ops: Vendor-specific operation callbacks
> + * @devdata: Private data for vendor implementation
> + * @np: Device tree node associated with this cooling device
> + * @lock: Mutex to protect cooling device operations
> + */
> +struct remoteproc_cdev {
> +	struct thermal_cooling_device *cdev;
> +	const struct remoteproc_cooling_ops *ops;
> +	void *devdata;
> +	struct device_node *np;

This is a local variable in remoteproc_cooling_register().

> +	struct mutex lock;
> +};
> +
> +
> +/* Thermal cooling device callbacks */
> +
> +static int remoteproc_get_max_state(struct thermal_cooling_device *cdev,
> +				    unsigned long *state)
> +{
> +	struct remoteproc_cdev *rproc_cdev = cdev->devdata;
> +	int ret;
> +
> +	if (!rproc_cdev || !rproc_cdev->ops)

How is this possible? Is there some race condition or something that you
need to guard against?

> +		return -EINVAL;
> +
> +	mutex_lock(&rproc_cdev->lock);
> +	ret = rproc_cdev->ops->get_max_level(rproc_cdev->devdata, state);
> +	mutex_unlock(&rproc_cdev->lock);
> +
> +	return ret;
> +}
> +
> +static int remoteproc_get_cur_state(struct thermal_cooling_device *cdev,
> +				    unsigned long *state)
> +{
> +	struct remoteproc_cdev *rproc_cdev = cdev->devdata;
> +	int ret;
> +
> +	if (!rproc_cdev || !rproc_cdev->ops)
> +		return -EINVAL;
> +
> +	mutex_lock(&rproc_cdev->lock);
> +	ret = rproc_cdev->ops->get_cur_level(rproc_cdev->devdata, state);
> +	mutex_unlock(&rproc_cdev->lock);
> +
> +	return ret;
> +}
> +
> +static int remoteproc_set_cur_state(struct thermal_cooling_device *cdev,
> +				    unsigned long state)
> +{
> +	struct remoteproc_cdev *rproc_cdev = cdev->devdata;
> +	int ret;
> +
> +	if (!rproc_cdev || !rproc_cdev->ops)
> +		return -EINVAL;
> +
> +	mutex_lock(&rproc_cdev->lock);
> +	ret = rproc_cdev->ops->set_cur_level(rproc_cdev->devdata, state);
> +	mutex_unlock(&rproc_cdev->lock);
> +
> +	return ret;
> +}
> +
> +static const struct thermal_cooling_device_ops remoteproc_cooling_ops = {
> +	.get_max_state = remoteproc_get_max_state,
> +	.get_cur_state = remoteproc_get_cur_state,
> +	.set_cur_state = remoteproc_set_cur_state,
> +};
> +
> +struct remoteproc_cdev *
> +remoteproc_cooling_register(struct device_node *np,
> +			     const char *name, const struct remoteproc_cooling_ops *ops,
> +			     void *devdata)
> +{
> +	struct remoteproc_cdev *rproc_cdev;
> +	struct thermal_cooling_device *cdev;
> +	int ret;
> +
> +	if (!name || !ops) {
> +		return ERR_PTR(-EINVAL);
> +	}
> +
> +	rproc_cdev = kzalloc(sizeof(*rproc_cdev), GFP_KERNEL);
> +	if (!rproc_cdev)
> +		return ERR_PTR(-ENOMEM);
> +
> +	rproc_cdev->ops = ops;
> +	rproc_cdev->devdata = devdata;
> +	rproc_cdev->np = np;
> +	mutex_init(&rproc_cdev->lock);
> +
> +	char *rproc_name __free(kfree) =
> +		kasprintf(GFP_KERNEL, REMOTEPROC_PREFIX "%s", name);
> +	/* Register with thermal framework */

Technically it's "Optionally register with thermal framework" but that's
immediately understood by the name of the function you're calling. What
isn't clear, and where a comment would be beneficial would be to
document why it's optional (or rather conditional on np).

> +	if (np) {
> +		cdev = thermal_of_cooling_device_register(np, rproc_name, rproc_cdev,
> +							  &remoteproc_cooling_ops);
> +	}
> +
> +	if (IS_ERR(cdev)) {
> +		ret = PTR_ERR(cdev);
> +		goto free_rproc_cdev;
> +	}
> +
> +	rproc_cdev->cdev = cdev;
> +
> +	return rproc_cdev;
> +
> +free_rproc_cdev:
> +	kfree(rproc_cdev);
> +	return ERR_PTR(ret);
> +}
> +EXPORT_SYMBOL_GPL(remoteproc_cooling_register);
> +
> +void remoteproc_cooling_unregister(struct remoteproc_cdev *rproc_cdev)
> +{
> +	if (!rproc_cdev)
> +		return;
> +
> +	thermal_cooling_device_unregister(rproc_cdev->cdev);
> +	mutex_destroy(&rproc_cdev->lock);
> +	kfree(rproc_cdev);
> +}
> +EXPORT_SYMBOL_GPL(remoteproc_cooling_unregister);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("Remote Processor Cooling Device");
> diff --git a/include/linux/remoteproc_cooling.h b/include/linux/remoteproc_cooling.h
> new file mode 100644
> index 000000000000..ef94019d220d
> --- /dev/null
> +++ b/include/linux/remoteproc_cooling.h
> @@ -0,0 +1,52 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Remote Processor Cooling Device
> + *
> + * Copyright (c) 2025, Qualcomm Innovation Center

That was never the right one.

> + */
> +
> +#ifndef __REMOTEPROC_COOLING_H__
> +#define __REMOTEPROC_COOLING_H__
> +
> +#include <linux/thermal.h>
> +
> +struct device;
> +struct device_node;
> +
> +struct remoteproc_cooling_ops {
> +	int (*get_max_level)(void *devdata, unsigned long *level);
> +	int (*get_cur_level)(void *devdata, unsigned long *level);
> +	int (*set_cur_level)(void *devdata, unsigned long level);
> +};
> +
> +struct remoteproc_cdev;
> +
> +#ifdef CONFIG_REMOTEPROC_THERMAL
> +
> +struct remoteproc_cdev *
> +remoteproc_cooling_register(struct device_node *np,
> +			     const char *name,
> +			     const struct remoteproc_cooling_ops *ops,
> +			     void *devdata);
> +
> +void remoteproc_cooling_unregister(struct remoteproc_cdev *rproc_cdev);
> +
> +#else /* !CONFIG_REMOTEPROC_THERMAL */
> +
> +static inline struct remoteproc_cdev *
> +remoteproc_cooling_register(struct device_node *np,
> +			     const char *name,
> +			     const struct remoteproc_cooling_ops *ops,
> +			     void *devdata)
> +{
> +	return ERR_PTR(-EINVAL);

This means that if I build my kernel with CONFIG_REMOTEPROC_THERMAL=n it
will not just disable remoteproc thermal management, but my remoteproc
driver will stop probing.

The remoteproc thermal feature isn't critical to the remtoeproc, so
wouldn't it make more sense to return 0 here and let the remoteproc
continue to operate in such configuration?

Regards,
Bjorn

> +}
> +
> +static inline void
> +remoteproc_cooling_unregister(struct remoteproc_cdev *rproc_cdev)
> +{
> +}
> +
> +#endif /* CONFIG_REMOTEPROC_THERMAL */
> +
> +#endif /* __REMOTEPROC_COOLING_H__ */
> -- 
> 2.34.1
> 

Re: [PATCH v1 1/8] thermal: Add Remote Proc cooling driver

[Gaurav Kohli]

On 1/3/2026 8:35 PM, Bjorn Andersson wrote:
> On Tue, Dec 23, 2025 at 06:02:20PM +0530, Gaurav Kohli wrote:
>> Add a new generic driver for thermal cooling devices that control
>> remote processors (modem, DSP, etc.) through various communication
>> channels.
>>
>> This driver provides an abstraction layer between the thermal
>> subsystem and vendor-specific remote processor communication
>> mechanisms.
>>
>> Suggested-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
>> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>> ---
>>   MAINTAINERS                          |   8 ++
>>   drivers/thermal/Kconfig              |  11 ++
>>   drivers/thermal/Makefile             |   2 +
>>   drivers/thermal/remoteproc_cooling.c | 154 +++++++++++++++++++++++++++
>>   include/linux/remoteproc_cooling.h   |  52 +++++++++
>>   5 files changed, 227 insertions(+)
>>   create mode 100644 drivers/thermal/remoteproc_cooling.c
>>   create mode 100644 include/linux/remoteproc_cooling.h
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 679e5f11e672..c1ba87315cdf 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -25935,6 +25935,14 @@ F:	drivers/thermal/cpufreq_cooling.c
>>   F:	drivers/thermal/cpuidle_cooling.c
>>   F:	include/linux/cpu_cooling.h
>>   
>> +THERMAL/REMOTEPROC_COOLING
>> +M:	Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>> +L:	linux-pm@vger.kernel.org
>> +S:	Supported
>> +F:	drivers/thermal/remoteproc_cooling.c
>> +F:	include/linux/remoteproc_cooling.h
>> +
>> +
> Two empty lines here...


thanks, will fix.


>
>>   THERMAL/POWER_ALLOCATOR
>>   M:	Lukasz Luba <lukasz.luba@arm.com>
>>   L:	linux-pm@vger.kernel.org
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index b10080d61860..31e92be34387 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -229,6 +229,17 @@ config PCIE_THERMAL
>>   
>>   	  If you want this support, you should say Y here.
>>   
>> +
> And two here...
>
>> +config REMOTEPROC_THERMAL
>> +	bool "Remote processor cooling support"
>> +	help
>> +	  This implements a generic cooling mechanism for remote processors
>> +	  (modem, DSP, etc.) that allows vendor-specific implementations to
>> +	  register thermal cooling devices and provide callbacks for thermal
>> +	  mitigation.
>> +
>> +	  If you want this support, you should say Y here.
>> +
>>   config THERMAL_EMULATION
>>   	bool "Thermal emulation mode support"
>>   	help
>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
>> index bb21e7ea7fc6..ae747dde54fe 100644
>> --- a/drivers/thermal/Makefile
>> +++ b/drivers/thermal/Makefile
>> @@ -34,6 +34,8 @@ thermal_sys-$(CONFIG_DEVFREQ_THERMAL) += devfreq_cooling.o
>>   
>>   thermal_sys-$(CONFIG_PCIE_THERMAL) += pcie_cooling.o
>>   
>> +thermal_sys-$(CONFIG_REMOTEPROC_THERMAL) += remoteproc_cooling.o
>> +
>>   obj-$(CONFIG_K3_THERMAL)	+= k3_bandgap.o k3_j72xx_bandgap.o
>>   # platform thermal drivers
>>   obj-y				+= broadcom/
>> diff --git a/drivers/thermal/remoteproc_cooling.c b/drivers/thermal/remoteproc_cooling.c
>> new file mode 100644
>> index 000000000000..a1f948cbde0f
>> --- /dev/null
>> +++ b/drivers/thermal/remoteproc_cooling.c
>> @@ -0,0 +1,154 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Remote Processor Cooling Device
>> + *
>> + * Copyright (c) 2025, Qualcomm Innovation Center, Inc. All rights reserved.
> No, that's not the right one.


will update this.


>
>> + */
>> +
>> +#include <linux/err.h>
>> +#include <linux/export.h>
>> +#include <linux/module.h>
>> +#include <linux/mutex.h>
>> +#include <linux/of.h>
>> +#include <linux/slab.h>
>> +#include <linux/thermal.h>
>> +
>> +#define REMOTEPROC_PREFIX		"rproc_"
>> +
>> +struct remoteproc_cooling_ops {
>> +	int (*get_max_level)(void *devdata, unsigned long *level);
>> +	int (*get_cur_level)(void *devdata, unsigned long *level);
>> +	int (*set_cur_level)(void *devdata, unsigned long level);
>> +};
>> +
>> +/**
>> + * struct remoteproc_cdev - Remote processor cooling device
>> + * @cdev: Thermal cooling device handle
>> + * @ops: Vendor-specific operation callbacks
>> + * @devdata: Private data for vendor implementation
>> + * @np: Device tree node associated with this cooling device
>> + * @lock: Mutex to protect cooling device operations
>> + */
>> +struct remoteproc_cdev {
>> +	struct thermal_cooling_device *cdev;
>> +	const struct remoteproc_cooling_ops *ops;
>> +	void *devdata;
>> +	struct device_node *np;
> This is a local variable in remoteproc_cooling_register().
>
>> +	struct mutex lock;
>> +};
>> +
>> +
>> +/* Thermal cooling device callbacks */
>> +
>> +static int remoteproc_get_max_state(struct thermal_cooling_device *cdev,
>> +				    unsigned long *state)
>> +{
>> +	struct remoteproc_cdev *rproc_cdev = cdev->devdata;
>> +	int ret;
>> +
>> +	if (!rproc_cdev || !rproc_cdev->ops)
> How is this possible? Is there some race condition or something that you
> need to guard against?


Ideally this can be controlled from the calling driver only, so i can 
remove this.


>
>> +		return -EINVAL;
>> +
>> +	mutex_lock(&rproc_cdev->lock);
>> +	ret = rproc_cdev->ops->get_max_level(rproc_cdev->devdata, state);
>> +	mutex_unlock(&rproc_cdev->lock);
>> +
>> +	return ret;
>> +}
>> +
>> +static int remoteproc_get_cur_state(struct thermal_cooling_device *cdev,
>> +				    unsigned long *state)
>> +{
>> +	struct remoteproc_cdev *rproc_cdev = cdev->devdata;
>> +	int ret;
>> +
>> +	if (!rproc_cdev || !rproc_cdev->ops)
>> +		return -EINVAL;
>> +
>> +	mutex_lock(&rproc_cdev->lock);
>> +	ret = rproc_cdev->ops->get_cur_level(rproc_cdev->devdata, state);
>> +	mutex_unlock(&rproc_cdev->lock);
>> +
>> +	return ret;
>> +}
>> +
>> +static int remoteproc_set_cur_state(struct thermal_cooling_device *cdev,
>> +				    unsigned long state)
>> +{
>> +	struct remoteproc_cdev *rproc_cdev = cdev->devdata;
>> +	int ret;
>> +
>> +	if (!rproc_cdev || !rproc_cdev->ops)
>> +		return -EINVAL;
>> +
>> +	mutex_lock(&rproc_cdev->lock);
>> +	ret = rproc_cdev->ops->set_cur_level(rproc_cdev->devdata, state);
>> +	mutex_unlock(&rproc_cdev->lock);
>> +
>> +	return ret;
>> +}
>> +
>> +static const struct thermal_cooling_device_ops remoteproc_cooling_ops = {
>> +	.get_max_state = remoteproc_get_max_state,
>> +	.get_cur_state = remoteproc_get_cur_state,
>> +	.set_cur_state = remoteproc_set_cur_state,
>> +};
>> +
>> +struct remoteproc_cdev *
>> +remoteproc_cooling_register(struct device_node *np,
>> +			     const char *name, const struct remoteproc_cooling_ops *ops,
>> +			     void *devdata)
>> +{
>> +	struct remoteproc_cdev *rproc_cdev;
>> +	struct thermal_cooling_device *cdev;
>> +	int ret;
>> +
>> +	if (!name || !ops) {
>> +		return ERR_PTR(-EINVAL);
>> +	}
>> +
>> +	rproc_cdev = kzalloc(sizeof(*rproc_cdev), GFP_KERNEL);
>> +	if (!rproc_cdev)
>> +		return ERR_PTR(-ENOMEM);
>> +
>> +	rproc_cdev->ops = ops;
>> +	rproc_cdev->devdata = devdata;
>> +	rproc_cdev->np = np;
>> +	mutex_init(&rproc_cdev->lock);
>> +
>> +	char *rproc_name __free(kfree) =
>> +		kasprintf(GFP_KERNEL, REMOTEPROC_PREFIX "%s", name);
>> +	/* Register with thermal framework */
> Technically it's "Optionally register with thermal framework" but that's
> immediately understood by the name of the function you're calling. What
> isn't clear, and where a comment would be beneficial would be to
> document why it's optional (or rather conditional on np).


Sure will add comment.


>
>> +	if (np) {
>> +		cdev = thermal_of_cooling_device_register(np, rproc_name, rproc_cdev,
>> +							  &remoteproc_cooling_ops);
>> +	}
>> +
>> +	if (IS_ERR(cdev)) {
>> +		ret = PTR_ERR(cdev);
>> +		goto free_rproc_cdev;
>> +	}
>> +
>> +	rproc_cdev->cdev = cdev;
>> +
>> +	return rproc_cdev;
>> +
>> +free_rproc_cdev:
>> +	kfree(rproc_cdev);
>> +	return ERR_PTR(ret);
>> +}
>> +EXPORT_SYMBOL_GPL(remoteproc_cooling_register);
>> +
>> +void remoteproc_cooling_unregister(struct remoteproc_cdev *rproc_cdev)
>> +{
>> +	if (!rproc_cdev)
>> +		return;
>> +
>> +	thermal_cooling_device_unregister(rproc_cdev->cdev);
>> +	mutex_destroy(&rproc_cdev->lock);
>> +	kfree(rproc_cdev);
>> +}
>> +EXPORT_SYMBOL_GPL(remoteproc_cooling_unregister);
>> +
>> +MODULE_LICENSE("GPL");
>> +MODULE_DESCRIPTION("Remote Processor Cooling Device");
>> diff --git a/include/linux/remoteproc_cooling.h b/include/linux/remoteproc_cooling.h
>> new file mode 100644
>> index 000000000000..ef94019d220d
>> --- /dev/null
>> +++ b/include/linux/remoteproc_cooling.h
>> @@ -0,0 +1,52 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * Remote Processor Cooling Device
>> + *
>> + * Copyright (c) 2025, Qualcomm Innovation Center
> That was never the right one.
>
>> + */
>> +
>> +#ifndef __REMOTEPROC_COOLING_H__
>> +#define __REMOTEPROC_COOLING_H__
>> +
>> +#include <linux/thermal.h>
>> +
>> +struct device;
>> +struct device_node;
>> +
>> +struct remoteproc_cooling_ops {
>> +	int (*get_max_level)(void *devdata, unsigned long *level);
>> +	int (*get_cur_level)(void *devdata, unsigned long *level);
>> +	int (*set_cur_level)(void *devdata, unsigned long level);
>> +};
>> +
>> +struct remoteproc_cdev;
>> +
>> +#ifdef CONFIG_REMOTEPROC_THERMAL
>> +
>> +struct remoteproc_cdev *
>> +remoteproc_cooling_register(struct device_node *np,
>> +			     const char *name,
>> +			     const struct remoteproc_cooling_ops *ops,
>> +			     void *devdata);
>> +
>> +void remoteproc_cooling_unregister(struct remoteproc_cdev *rproc_cdev);
>> +
>> +#else /* !CONFIG_REMOTEPROC_THERMAL */
>> +
>> +static inline struct remoteproc_cdev *
>> +remoteproc_cooling_register(struct device_node *np,
>> +			     const char *name,
>> +			     const struct remoteproc_cooling_ops *ops,
>> +			     void *devdata)
>> +{
>> +	return ERR_PTR(-EINVAL);
> This means that if I build my kernel with CONFIG_REMOTEPROC_THERMAL=n it
> will not just disable remoteproc thermal management, but my remoteproc
> driver will stop probing.
>
> The remoteproc thermal feature isn't critical to the remtoeproc, so
> wouldn't it make more sense to return 0 here and let the remoteproc
> continue to operate in such configuration?


Yes it will work, as probe of this child node won't impact the remote 
proc probe, as we are not returning error condition there during 
of_platform_populate.

But yes, this should not block remote proc probe in any condition, so 
return 0 is more better option. will update this.


>
> Regards,
> Bjorn
>
>> +}
>> +
>> +static inline void
>> +remoteproc_cooling_unregister(struct remoteproc_cdev *rproc_cdev)
>> +{
>> +}
>> +
>> +#endif /* CONFIG_REMOTEPROC_THERMAL */
>> +
>> +#endif /* __REMOTEPROC_COOLING_H__ */
>> -- 
>> 2.34.1
>>

Re: [PATCH v1 1/8] thermal: Add Remote Proc cooling driver

[Zhongqiu Han]

On 12/23/2025 8:32 PM, Gaurav Kohli wrote:
> Add a new generic driver for thermal cooling devices that control
> remote processors (modem, DSP, etc.) through various communication
> channels.
> 
> This driver provides an abstraction layer between the thermal
> subsystem and vendor-specific remote processor communication
> mechanisms.
> 
> Suggested-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
> ---
>   MAINTAINERS                          |   8 ++
>   drivers/thermal/Kconfig              |  11 ++
>   drivers/thermal/Makefile             |   2 +
>   drivers/thermal/remoteproc_cooling.c | 154 +++++++++++++++++++++++++++
>   include/linux/remoteproc_cooling.h   |  52 +++++++++
>   5 files changed, 227 insertions(+)
>   create mode 100644 drivers/thermal/remoteproc_cooling.c
>   create mode 100644 include/linux/remoteproc_cooling.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 679e5f11e672..c1ba87315cdf 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -25935,6 +25935,14 @@ F:	drivers/thermal/cpufreq_cooling.c
>   F:	drivers/thermal/cpuidle_cooling.c
>   F:	include/linux/cpu_cooling.h
>   
> +THERMAL/REMOTEPROC_COOLING
> +M:	Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
> +L:	linux-pm@vger.kernel.org
> +S:	Supported
> +F:	drivers/thermal/remoteproc_cooling.c
> +F:	include/linux/remoteproc_cooling.h
> +
> +
>   THERMAL/POWER_ALLOCATOR
>   M:	Lukasz Luba <lukasz.luba@arm.com>
>   L:	linux-pm@vger.kernel.org
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index b10080d61860..31e92be34387 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -229,6 +229,17 @@ config PCIE_THERMAL
>   
>   	  If you want this support, you should say Y here.
>   
> +
> +config REMOTEPROC_THERMAL
> +	bool "Remote processor cooling support"

Hi Gaurav,

May I know any depends here?

> +	help
> +	  This implements a generic cooling mechanism for remote processors
> +	  (modem, DSP, etc.) that allows vendor-specific implementations to
> +	  register thermal cooling devices and provide callbacks for thermal
> +	  mitigation.
> +
> +	  If you want this support, you should say Y here.
> +
>   config THERMAL_EMULATION
>   	bool "Thermal emulation mode support"
>   	help
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index bb21e7ea7fc6..ae747dde54fe 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -34,6 +34,8 @@ thermal_sys-$(CONFIG_DEVFREQ_THERMAL) += devfreq_cooling.o
>   
>   thermal_sys-$(CONFIG_PCIE_THERMAL) += pcie_cooling.o
>   
> +thermal_sys-$(CONFIG_REMOTEPROC_THERMAL) += remoteproc_cooling.o
> +
>   obj-$(CONFIG_K3_THERMAL)	+= k3_bandgap.o k3_j72xx_bandgap.o
>   # platform thermal drivers
>   obj-y				+= broadcom/
> diff --git a/drivers/thermal/remoteproc_cooling.c b/drivers/thermal/remoteproc_cooling.c
> new file mode 100644
> index 000000000000..a1f948cbde0f
> --- /dev/null
> +++ b/drivers/thermal/remoteproc_cooling.c
> @@ -0,0 +1,154 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Remote Processor Cooling Device
> + *
> + * Copyright (c) 2025, Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#include <linux/err.h>
> +#include <linux/export.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of.h>
> +#include <linux/slab.h>
> +#include <linux/thermal.h>
> +
> +#define REMOTEPROC_PREFIX		"rproc_"
> +
> +struct remoteproc_cooling_ops {
> +	int (*get_max_level)(void *devdata, unsigned long *level);
> +	int (*get_cur_level)(void *devdata, unsigned long *level);
> +	int (*set_cur_level)(void *devdata, unsigned long level);
> +};
It's better to have a document to explain member?

And may I know why double define here(another is in .h file)? should it
include .h file remoteproc_cooling.h ?


> +
> +/**
> + * struct remoteproc_cdev - Remote processor cooling device
> + * @cdev: Thermal cooling device handle
> + * @ops: Vendor-specific operation callbacks
> + * @devdata: Private data for vendor implementation
> + * @np: Device tree node associated with this cooling device
> + * @lock: Mutex to protect cooling device operations
> + */
> +struct remoteproc_cdev {
> +	struct thermal_cooling_device *cdev;
> +	const struct remoteproc_cooling_ops *ops;
> +	void *devdata;
> +	struct device_node *np;
> +	struct mutex lock;
> +};
> +
> +
> +/* Thermal cooling device callbacks */
> +
> +static int remoteproc_get_max_state(struct thermal_cooling_device *cdev,
> +				    unsigned long *state)
> +{
> +	struct remoteproc_cdev *rproc_cdev = cdev->devdata;
> +	int ret;
> +
> +	if (!rproc_cdev || !rproc_cdev->ops)
> +		return -EINVAL;
> +
> +	mutex_lock(&rproc_cdev->lock);
> +	ret = rproc_cdev->ops->get_max_level(rproc_cdev->devdata, state);
> +	mutex_unlock(&rproc_cdev->lock);
> +
> +	return ret;
> +}
> +
> +static int remoteproc_get_cur_state(struct thermal_cooling_device *cdev,
> +				    unsigned long *state)
> +{
> +	struct remoteproc_cdev *rproc_cdev = cdev->devdata;
> +	int ret;
> +
> +	if (!rproc_cdev || !rproc_cdev->ops)
> +		return -EINVAL;
> +
> +	mutex_lock(&rproc_cdev->lock);
> +	ret = rproc_cdev->ops->get_cur_level(rproc_cdev->devdata, state);
> +	mutex_unlock(&rproc_cdev->lock);
> +
> +	return ret;
> +}
> +
> +static int remoteproc_set_cur_state(struct thermal_cooling_device *cdev,
> +				    unsigned long state)
> +{
> +	struct remoteproc_cdev *rproc_cdev = cdev->devdata;
> +	int ret;
> +
> +	if (!rproc_cdev || !rproc_cdev->ops)
> +		return -EINVAL;
> +
> +	mutex_lock(&rproc_cdev->lock);
> +	ret = rproc_cdev->ops->set_cur_level(rproc_cdev->devdata, state);
> +	mutex_unlock(&rproc_cdev->lock);
> +
> +	return ret;
> +}
> +
> +static const struct thermal_cooling_device_ops remoteproc_cooling_ops = {
> +	.get_max_state = remoteproc_get_max_state,
> +	.get_cur_state = remoteproc_get_cur_state,
> +	.set_cur_state = remoteproc_set_cur_state,
> +};
> +
> +struct remoteproc_cdev *
> +remoteproc_cooling_register(struct device_node *np,
> +			     const char *name, const struct remoteproc_cooling_ops *ops,
> +			     void *devdata)
> +{
> +	struct remoteproc_cdev *rproc_cdev;
> +	struct thermal_cooling_device *cdev;
> +	int ret;
> +
> +	if (!name || !ops) {
> +		return ERR_PTR(-EINVAL);
> +	}
> +

May I know which ops callbacks are required and which are optional?
If the callback is optional, should we check for null before calling it?


> +	rproc_cdev = kzalloc(sizeof(*rproc_cdev), GFP_KERNEL);
> +	if (!rproc_cdev)
> +		return ERR_PTR(-ENOMEM);
> +
> +	rproc_cdev->ops = ops;
> +	rproc_cdev->devdata = devdata;
> +	rproc_cdev->np = np;
> +	mutex_init(&rproc_cdev->lock);
> +
> +	char *rproc_name __free(kfree) =
> +		kasprintf(GFP_KERNEL, REMOTEPROC_PREFIX "%s", name);

It should have a NULL check when alloc memory.


> +	/* Register with thermal framework */
> +	if (np) {
> +		cdev = thermal_of_cooling_device_register(np, rproc_name, rproc_cdev,
> +							  &remoteproc_cooling_ops);
> +	}
> +
> +	if (IS_ERR(cdev)) {
> +		ret = PTR_ERR(cdev);
> +		goto free_rproc_cdev;
> +	}
> +
> +	rproc_cdev->cdev = cdev;
> +
> +	return rproc_cdev;
> +
> +free_rproc_cdev:
> +	kfree(rproc_cdev);
> +	return ERR_PTR(ret);
> +}
> +EXPORT_SYMBOL_GPL(remoteproc_cooling_register);
> +
> +void remoteproc_cooling_unregister(struct remoteproc_cdev *rproc_cdev)
> +{
> +	if (!rproc_cdev)
> +		return;
> +
> +	thermal_cooling_device_unregister(rproc_cdev->cdev);
> +	mutex_destroy(&rproc_cdev->lock);
> +	kfree(rproc_cdev);
> +}
> +EXPORT_SYMBOL_GPL(remoteproc_cooling_unregister);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("Remote Processor Cooling Device");
> diff --git a/include/linux/remoteproc_cooling.h b/include/linux/remoteproc_cooling.h
> new file mode 100644
> index 000000000000..ef94019d220d
> --- /dev/null
> +++ b/include/linux/remoteproc_cooling.h
> @@ -0,0 +1,52 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Remote Processor Cooling Device
> + *
> + * Copyright (c) 2025, Qualcomm Innovation Center
> + */
> +
> +#ifndef __REMOTEPROC_COOLING_H__
> +#define __REMOTEPROC_COOLING_H__
> +
> +#include <linux/thermal.h>
> +
> +struct device;
> +struct device_node;
> +
> +struct remoteproc_cooling_ops {
> +	int (*get_max_level)(void *devdata, unsigned long *level);
> +	int (*get_cur_level)(void *devdata, unsigned long *level);
> +	int (*set_cur_level)(void *devdata, unsigned long level);
> +};
> +
> +struct remoteproc_cdev;
> +
> +#ifdef CONFIG_REMOTEPROC_THERMAL
> +
> +struct remoteproc_cdev *
> +remoteproc_cooling_register(struct device_node *np,
> +			     const char *name,
> +			     const struct remoteproc_cooling_ops *ops,
> +			     void *devdata);
> +
> +void remoteproc_cooling_unregister(struct remoteproc_cdev *rproc_cdev);
> +
> +#else /* !CONFIG_REMOTEPROC_THERMAL */
> +
> +static inline struct remoteproc_cdev *
> +remoteproc_cooling_register(struct device_node *np,
> +			     const char *name,
> +			     const struct remoteproc_cooling_ops *ops,
> +			     void *devdata)
> +{
> +	return ERR_PTR(-EINVAL);
> +}
> +
> +static inline void
> +remoteproc_cooling_unregister(struct remoteproc_cdev *rproc_cdev)
> +{
> +}
> +
> +#endif /* CONFIG_REMOTEPROC_THERMAL */
> +
> +#endif /* __REMOTEPROC_COOLING_H__ */


-- 
Thx and BRs,
Zhongqiu Han

Re: [PATCH v1 1/8] thermal: Add Remote Proc cooling driver

[Gaurav Kohli]

On 1/8/2026 5:29 PM, Zhongqiu Han wrote:
> On 12/23/2025 8:32 PM, Gaurav Kohli wrote:
>> Add a new generic driver for thermal cooling devices that control
>> remote processors (modem, DSP, etc.) through various communication
>> channels.
>>
>> This driver provides an abstraction layer between the thermal
>> subsystem and vendor-specific remote processor communication
>> mechanisms.
>>
>> Suggested-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
>> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>> ---
>>   MAINTAINERS                          |   8 ++
>>   drivers/thermal/Kconfig              |  11 ++
>>   drivers/thermal/Makefile             |   2 +
>>   drivers/thermal/remoteproc_cooling.c | 154 +++++++++++++++++++++++++++
>>   include/linux/remoteproc_cooling.h   |  52 +++++++++
>>   5 files changed, 227 insertions(+)
>>   create mode 100644 drivers/thermal/remoteproc_cooling.c
>>   create mode 100644 include/linux/remoteproc_cooling.h
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 679e5f11e672..c1ba87315cdf 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -25935,6 +25935,14 @@ F:    drivers/thermal/cpufreq_cooling.c
>>   F:    drivers/thermal/cpuidle_cooling.c
>>   F:    include/linux/cpu_cooling.h
>>   +THERMAL/REMOTEPROC_COOLING
>> +M:    Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>> +L:    linux-pm@vger.kernel.org
>> +S:    Supported
>> +F:    drivers/thermal/remoteproc_cooling.c
>> +F:    include/linux/remoteproc_cooling.h
>> +
>> +
>>   THERMAL/POWER_ALLOCATOR
>>   M:    Lukasz Luba <lukasz.luba@arm.com>
>>   L:    linux-pm@vger.kernel.org
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index b10080d61860..31e92be34387 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -229,6 +229,17 @@ config PCIE_THERMAL
>>           If you want this support, you should say Y here.
>>   +
>> +config REMOTEPROC_THERMAL
>> +    bool "Remote processor cooling support"
>
> Hi Gaurav,
>
> May I know any depends here?


Thanks for review.

Apologies for the late reply,  this was missed on my end.

This does not require a dependency, as error check is there for cooling 
registration api.


>
>> +    help
>> +      This implements a generic cooling mechanism for remote processors
>> +      (modem, DSP, etc.) that allows vendor-specific implementations to
>> +      register thermal cooling devices and provide callbacks for 
>> thermal
>> +      mitigation.
>> +
>> +      If you want this support, you should say Y here.
>> +
>>   config THERMAL_EMULATION
>>       bool "Thermal emulation mode support"
>>       help
>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
>> index bb21e7ea7fc6..ae747dde54fe 100644
>> --- a/drivers/thermal/Makefile
>> +++ b/drivers/thermal/Makefile
>> @@ -34,6 +34,8 @@ thermal_sys-$(CONFIG_DEVFREQ_THERMAL) += 
>> devfreq_cooling.o
>>     thermal_sys-$(CONFIG_PCIE_THERMAL) += pcie_cooling.o
>>   +thermal_sys-$(CONFIG_REMOTEPROC_THERMAL) += remoteproc_cooling.o
>> +
>>   obj-$(CONFIG_K3_THERMAL)    += k3_bandgap.o k3_j72xx_bandgap.o
>>   # platform thermal drivers
>>   obj-y                += broadcom/
>> diff --git a/drivers/thermal/remoteproc_cooling.c 
>> b/drivers/thermal/remoteproc_cooling.c
>> new file mode 100644
>> index 000000000000..a1f948cbde0f
>> --- /dev/null
>> +++ b/drivers/thermal/remoteproc_cooling.c
>> @@ -0,0 +1,154 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Remote Processor Cooling Device
>> + *
>> + * Copyright (c) 2025, Qualcomm Innovation Center, Inc. All rights 
>> reserved.
>> + */
>> +
>> +#include <linux/err.h>
>> +#include <linux/export.h>
>> +#include <linux/module.h>
>> +#include <linux/mutex.h>
>> +#include <linux/of.h>
>> +#include <linux/slab.h>
>> +#include <linux/thermal.h>
>> +
>> +#define REMOTEPROC_PREFIX        "rproc_"
>> +
>> +struct remoteproc_cooling_ops {
>> +    int (*get_max_level)(void *devdata, unsigned long *level);
>> +    int (*get_cur_level)(void *devdata, unsigned long *level);
>> +    int (*set_cur_level)(void *devdata, unsigned long level);
>> +};
> It's better to have a document to explain member?
>
> And may I know why double define here(another is in .h file)? should it
> include .h file remoteproc_cooling.h ?
>

Sure, i will add comment for each callback and will fix this double 
definition.


>
>> +
>> +/**
>> + * struct remoteproc_cdev - Remote processor cooling device
>> + * @cdev: Thermal cooling device handle
>> + * @ops: Vendor-specific operation callbacks
>> + * @devdata: Private data for vendor implementation
>> + * @np: Device tree node associated with this cooling device
>> + * @lock: Mutex to protect cooling device operations
>> + */
>> +struct remoteproc_cdev {
>> +    struct thermal_cooling_device *cdev;
>> +    const struct remoteproc_cooling_ops *ops;
>> +    void *devdata;
>> +    struct device_node *np;
>> +    struct mutex lock;
>> +};
>> +
>> +
>> +/* Thermal cooling device callbacks */
>> +
>> +static int remoteproc_get_max_state(struct thermal_cooling_device 
>> *cdev,
>> +                    unsigned long *state)
>> +{
>> +    struct remoteproc_cdev *rproc_cdev = cdev->devdata;
>> +    int ret;
>> +
>> +    if (!rproc_cdev || !rproc_cdev->ops)
>> +        return -EINVAL;
>> +
>> +    mutex_lock(&rproc_cdev->lock);
>> +    ret = rproc_cdev->ops->get_max_level(rproc_cdev->devdata, state);
>> +    mutex_unlock(&rproc_cdev->lock);
>> +
>> +    return ret;
>> +}
>> +
>> +static int remoteproc_get_cur_state(struct thermal_cooling_device 
>> *cdev,
>> +                    unsigned long *state)
>> +{
>> +    struct remoteproc_cdev *rproc_cdev = cdev->devdata;
>> +    int ret;
>> +
>> +    if (!rproc_cdev || !rproc_cdev->ops)
>> +        return -EINVAL;
>> +
>> +    mutex_lock(&rproc_cdev->lock);
>> +    ret = rproc_cdev->ops->get_cur_level(rproc_cdev->devdata, state);
>> +    mutex_unlock(&rproc_cdev->lock);
>> +
>> +    return ret;
>> +}
>> +
>> +static int remoteproc_set_cur_state(struct thermal_cooling_device 
>> *cdev,
>> +                    unsigned long state)
>> +{
>> +    struct remoteproc_cdev *rproc_cdev = cdev->devdata;
>> +    int ret;
>> +
>> +    if (!rproc_cdev || !rproc_cdev->ops)
>> +        return -EINVAL;
>> +
>> +    mutex_lock(&rproc_cdev->lock);
>> +    ret = rproc_cdev->ops->set_cur_level(rproc_cdev->devdata, state);
>> +    mutex_unlock(&rproc_cdev->lock);
>> +
>> +    return ret;
>> +}
>> +
>> +static const struct thermal_cooling_device_ops 
>> remoteproc_cooling_ops = {
>> +    .get_max_state = remoteproc_get_max_state,
>> +    .get_cur_state = remoteproc_get_cur_state,
>> +    .set_cur_state = remoteproc_set_cur_state,
>> +};
>> +
>> +struct remoteproc_cdev *
>> +remoteproc_cooling_register(struct device_node *np,
>> +                 const char *name, const struct 
>> remoteproc_cooling_ops *ops,
>> +                 void *devdata)
>> +{
>> +    struct remoteproc_cdev *rproc_cdev;
>> +    struct thermal_cooling_device *cdev;
>> +    int ret;
>> +
>> +    if (!name || !ops) {
>> +        return ERR_PTR(-EINVAL);
>> +    }
>> +
>
> May I know which ops callbacks are required and which are optional?
> If the callback is optional, should we check for null before calling it?
>

Actually all are mandatory for cooling api, will put null check for all 
to be on safer side.


>
>> +    rproc_cdev = kzalloc(sizeof(*rproc_cdev), GFP_KERNEL);
>> +    if (!rproc_cdev)
>> +        return ERR_PTR(-ENOMEM);
>> +
>> +    rproc_cdev->ops = ops;
>> +    rproc_cdev->devdata = devdata;
>> +    rproc_cdev->np = np;
>> +    mutex_init(&rproc_cdev->lock);
>> +
>> +    char *rproc_name __free(kfree) =
>> +        kasprintf(GFP_KERNEL, REMOTEPROC_PREFIX "%s", name);
>
> It should have a NULL check when alloc memory.
>
>

Thanks for pointing this, will update this.


>> +    /* Register with thermal framework */
>> +    if (np) {
>> +        cdev = thermal_of_cooling_device_register(np, rproc_name, 
>> rproc_cdev,
>> +                              &remoteproc_cooling_ops);
>> +    }
>> +
>> +    if (IS_ERR(cdev)) {
>> +        ret = PTR_ERR(cdev);
>> +        goto free_rproc_cdev;
>> +    }
>> +
>> +    rproc_cdev->cdev = cdev;
>> +
>> +    return rproc_cdev;
>> +
>> +free_rproc_cdev:
>> +    kfree(rproc_cdev);
>> +    return ERR_PTR(ret);
>> +}
>> +EXPORT_SYMBOL_GPL(remoteproc_cooling_register);
>> +
>> +void remoteproc_cooling_unregister(struct remoteproc_cdev *rproc_cdev)
>> +{
>> +    if (!rproc_cdev)
>> +        return;
>> +
>> +    thermal_cooling_device_unregister(rproc_cdev->cdev);
>> +    mutex_destroy(&rproc_cdev->lock);
>> +    kfree(rproc_cdev);
>> +}
>> +EXPORT_SYMBOL_GPL(remoteproc_cooling_unregister);
>> +
>> +MODULE_LICENSE("GPL");
>> +MODULE_DESCRIPTION("Remote Processor Cooling Device");
>> diff --git a/include/linux/remoteproc_cooling.h 
>> b/include/linux/remoteproc_cooling.h
>> new file mode 100644
>> index 000000000000..ef94019d220d
>> --- /dev/null
>> +++ b/include/linux/remoteproc_cooling.h
>> @@ -0,0 +1,52 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * Remote Processor Cooling Device
>> + *
>> + * Copyright (c) 2025, Qualcomm Innovation Center
>> + */
>> +
>> +#ifndef __REMOTEPROC_COOLING_H__
>> +#define __REMOTEPROC_COOLING_H__
>> +
>> +#include <linux/thermal.h>
>> +
>> +struct device;
>> +struct device_node;
>> +
>> +struct remoteproc_cooling_ops {
>> +    int (*get_max_level)(void *devdata, unsigned long *level);
>> +    int (*get_cur_level)(void *devdata, unsigned long *level);
>> +    int (*set_cur_level)(void *devdata, unsigned long level);
>> +};
>> +
>> +struct remoteproc_cdev;
>> +
>> +#ifdef CONFIG_REMOTEPROC_THERMAL
>> +
>> +struct remoteproc_cdev *
>> +remoteproc_cooling_register(struct device_node *np,
>> +                 const char *name,
>> +                 const struct remoteproc_cooling_ops *ops,
>> +                 void *devdata);
>> +
>> +void remoteproc_cooling_unregister(struct remoteproc_cdev *rproc_cdev);
>> +
>> +#else /* !CONFIG_REMOTEPROC_THERMAL */
>> +
>> +static inline struct remoteproc_cdev *
>> +remoteproc_cooling_register(struct device_node *np,
>> +                 const char *name,
>> +                 const struct remoteproc_cooling_ops *ops,
>> +                 void *devdata)
>> +{
>> +    return ERR_PTR(-EINVAL);
>> +}
>> +
>> +static inline void
>> +remoteproc_cooling_unregister(struct remoteproc_cdev *rproc_cdev)
>> +{
>> +}
>> +
>> +#endif /* CONFIG_REMOTEPROC_THERMAL */
>> +
>> +#endif /* __REMOTEPROC_COOLING_H__ */
>
>

Re: [PATCH v1 1/8] thermal: Add Remote Proc cooling driver

[Lukasz Luba]

Hi Gaurav,

On 12/23/25 12:32, Gaurav Kohli wrote:
> Add a new generic driver for thermal cooling devices that control
> remote processors (modem, DSP, etc.) through various communication
> channels.
> 
> This driver provides an abstraction layer between the thermal
> subsystem and vendor-specific remote processor communication
> mechanisms.

Is this the patch about proposing the new cooling
device type at last LPC2025 conference (what we've discussed with Amit)?

There was some feedback asking you to add a bit more description
into this patch header, please do that (with some background as well).

> 
> Suggested-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
> ---
>   MAINTAINERS                          |   8 ++
>   drivers/thermal/Kconfig              |  11 ++
>   drivers/thermal/Makefile             |   2 +
>   drivers/thermal/remoteproc_cooling.c | 154 +++++++++++++++++++++++++++
>   include/linux/remoteproc_cooling.h   |  52 +++++++++
>   5 files changed, 227 insertions(+)
>   create mode 100644 drivers/thermal/remoteproc_cooling.c
>   create mode 100644 include/linux/remoteproc_cooling.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 679e5f11e672..c1ba87315cdf 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -25935,6 +25935,14 @@ F:	drivers/thermal/cpufreq_cooling.c
>   F:	drivers/thermal/cpuidle_cooling.c
>   F:	include/linux/cpu_cooling.h
>   
> +THERMAL/REMOTEPROC_COOLING
> +M:	Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
> +L:	linux-pm@vger.kernel.org
> +S:	Supported
> +F:	drivers/thermal/remoteproc_cooling.c
> +F:	include/linux/remoteproc_cooling.h
> +
> +
>   THERMAL/POWER_ALLOCATOR
>   M:	Lukasz Luba <lukasz.luba@arm.com>
>   L:	linux-pm@vger.kernel.org
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index b10080d61860..31e92be34387 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -229,6 +229,17 @@ config PCIE_THERMAL
>   
>   	  If you want this support, you should say Y here.
>   
> +
> +config REMOTEPROC_THERMAL
> +	bool "Remote processor cooling support"
> +	help
> +	  This implements a generic cooling mechanism for remote processors
> +	  (modem, DSP, etc.) that allows vendor-specific implementations to
> +	  register thermal cooling devices and provide callbacks for thermal
> +	  mitigation.
> +
> +	  If you want this support, you should say Y here.
> +
>   config THERMAL_EMULATION
>   	bool "Thermal emulation mode support"
>   	help
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index bb21e7ea7fc6..ae747dde54fe 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -34,6 +34,8 @@ thermal_sys-$(CONFIG_DEVFREQ_THERMAL) += devfreq_cooling.o
>   
>   thermal_sys-$(CONFIG_PCIE_THERMAL) += pcie_cooling.o
>   
> +thermal_sys-$(CONFIG_REMOTEPROC_THERMAL) += remoteproc_cooling.o
> +
>   obj-$(CONFIG_K3_THERMAL)	+= k3_bandgap.o k3_j72xx_bandgap.o
>   # platform thermal drivers
>   obj-y				+= broadcom/
> diff --git a/drivers/thermal/remoteproc_cooling.c b/drivers/thermal/remoteproc_cooling.c
> new file mode 100644
> index 000000000000..a1f948cbde0f
> --- /dev/null
> +++ b/drivers/thermal/remoteproc_cooling.c
> @@ -0,0 +1,154 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Remote Processor Cooling Device
> + *
> + * Copyright (c) 2025, Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#include <linux/err.h>
> +#include <linux/export.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of.h>
> +#include <linux/slab.h>
> +#include <linux/thermal.h>
> +
> +#define REMOTEPROC_PREFIX		"rproc_"
> +
> +struct remoteproc_cooling_ops {
> +	int (*get_max_level)(void *devdata, unsigned long *level);
> +	int (*get_cur_level)(void *devdata, unsigned long *level);
> +	int (*set_cur_level)(void *devdata, unsigned long level);
> +};

1. There is no comment for struct and the functions like you did below.
2. Why you need those 3 callbacks?
    It looks like they are simple wrappers on stuff in
    'struct thermal_cooling_device_ops'.
    Please try to get rid of them and re-use the existing fwk callbacks.

> +
> +/**
> + * struct remoteproc_cdev - Remote processor cooling device
> + * @cdev: Thermal cooling device handle
> + * @ops: Vendor-specific operation callbacks
> + * @devdata: Private data for vendor implementation
> + * @np: Device tree node associated with this cooling device
> + * @lock: Mutex to protect cooling device operations
> + */
> +struct remoteproc_cdev {

Please use the full naming:
remoteproc_cooling_device

> +	struct thermal_cooling_device *cdev;

You don't need to keep it here. AFAICS it's only
used in the 'unregister' function. Please check my
comment here and then remove this pointer.
(It creates uneseccery linkage between those devices).

> +	const struct remoteproc_cooling_ops *ops;

So here it can be simply:
struct thermal_cooling_device_ops cooling_ops;

> +	void *devdata;
> +	struct device_node *np;

This 'np' is also not used, remove it please.

> +	struct mutex lock;
> +};
> +
> +
> +/* Thermal cooling device callbacks */
> +
> +static int remoteproc_get_max_state(struct thermal_cooling_device *cdev,
> +				    unsigned long *state)
> +{
> +	struct remoteproc_cdev *rproc_cdev = cdev->devdata;
> +	int ret;
> +
> +	if (!rproc_cdev || !rproc_cdev->ops)
> +		return -EINVAL;

This mustn't be changed in runtime accidenly. We don't guard in
cpufreq-/devfreq- cooling these callbacks that way. Please drop them.

> +
> +	mutex_lock(&rproc_cdev->lock);
> +	ret = rproc_cdev->ops->get_max_level(rproc_cdev->devdata, state);
> +	mutex_unlock(&rproc_cdev->lock);
> +
> +	return ret;
> +}
> +
> +static int remoteproc_get_cur_state(struct thermal_cooling_device *cdev,
> +				    unsigned long *state)
> +{
> +	struct remoteproc_cdev *rproc_cdev = cdev->devdata;
> +	int ret;
> +
> +	if (!rproc_cdev || !rproc_cdev->ops)
> +		return -EINVAL;

as above

> +
> +	mutex_lock(&rproc_cdev->lock);
> +	ret = rproc_cdev->ops->get_cur_level(rproc_cdev->devdata, state);
> +	mutex_unlock(&rproc_cdev->lock);
> +
> +	return ret;
> +}
> +
> +static int remoteproc_set_cur_state(struct thermal_cooling_device *cdev,
> +				    unsigned long state)
> +{
> +	struct remoteproc_cdev *rproc_cdev = cdev->devdata;
> +	int ret;
> +
> +	if (!rproc_cdev || !rproc_cdev->ops)
> +		return -EINVAL;

as above

> +
> +	mutex_lock(&rproc_cdev->lock);
> +	ret = rproc_cdev->ops->set_cur_level(rproc_cdev->devdata, state);
> +	mutex_unlock(&rproc_cdev->lock);
> +
> +	return ret;
> +}
> +
> +static const struct thermal_cooling_device_ops remoteproc_cooling_ops = {
> +	.get_max_state = remoteproc_get_max_state,
> +	.get_cur_state = remoteproc_get_cur_state,
> +	.set_cur_state = remoteproc_set_cur_state,
> +};
> +
> +struct remoteproc_cdev *
> +remoteproc_cooling_register(struct device_node *np,
> +			     const char *name, const struct remoteproc_cooling_ops *ops,
> +			     void *devdata)

Since this is based on device_node, please align to the naming
convention from cpufreq-/devfreq-cooling and use prefix 'of_'

of_remoteproc_cooling_register()

> +{
> +	struct remoteproc_cdev *rproc_cdev;
> +	struct thermal_cooling_device *cdev;
> +	int ret;
> +
> +	if (!name || !ops) {

IMO you should check the '!np' here, not the lines below.
We can simply bail out very early.

> +		return ERR_PTR(-EINVAL);
> +	}
> +
> +	rproc_cdev = kzalloc(sizeof(*rproc_cdev), GFP_KERNEL);
> +	if (!rproc_cdev)
> +		return ERR_PTR(-ENOMEM);
> +
> +	rproc_cdev->ops = ops;
> +	rproc_cdev->devdata = devdata;
> +	rproc_cdev->np = np;
> +	mutex_init(&rproc_cdev->lock);
> +
> +	char *rproc_name __free(kfree) =
> +		kasprintf(GFP_KERNEL, REMOTEPROC_PREFIX "%s", name);
> +	/* Register with thermal framework */
> +	if (np) {

Too late to test 'np'.

> +		cdev = thermal_of_cooling_device_register(np, rproc_name, rproc_cdev,
> +							  &remoteproc_cooling_ops);
> +	}
> +
> +	if (IS_ERR(cdev)) {

This check should be just below the line when you get the 'cdev'

> +		ret = PTR_ERR(cdev);
> +		goto free_rproc_cdev;
> +	}
> +
> +	rproc_cdev->cdev = cdev;
> +
> +	return rproc_cdev;
> +
> +free_rproc_cdev:
> +	kfree(rproc_cdev);
> +	return ERR_PTR(ret);
> +}
> +EXPORT_SYMBOL_GPL(remoteproc_cooling_register);
> +
> +void remoteproc_cooling_unregister(struct remoteproc_cdev *rproc_cdev)

Change the API to be alined with cpufreq-cooling and devfreq-cooling
types of devices, so:

void remoteproc_cooling_unregister(struct thermal_cooling_device *cdev)

You still should be able to get the rptoc_cdev like:

rproc_cdev = cdev->devdata;

and free it.

> +{
> +	if (!rproc_cdev)
> +		return;
> +
> +	thermal_cooling_device_unregister(rproc_cdev->cdev);
> +	mutex_destroy(&rproc_cdev->lock);
> +	kfree(rproc_cdev);
> +}
> +EXPORT_SYMBOL_GPL(remoteproc_cooling_unregister);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("Remote Processor Cooling Device");
> diff --git a/include/linux/remoteproc_cooling.h b/include/linux/remoteproc_cooling.h
> new file mode 100644
> index 000000000000..ef94019d220d
> --- /dev/null
> +++ b/include/linux/remoteproc_cooling.h
> @@ -0,0 +1,52 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Remote Processor Cooling Device
> + *
> + * Copyright (c) 2025, Qualcomm Innovation Center
> + */
> +
> +#ifndef __REMOTEPROC_COOLING_H__
> +#define __REMOTEPROC_COOLING_H__
> +
> +#include <linux/thermal.h>
> +
> +struct device;
> +struct device_node;
> +
> +struct remoteproc_cooling_ops {
> +	int (*get_max_level)(void *devdata, unsigned long *level);
> +	int (*get_cur_level)(void *devdata, unsigned long *level);
> +	int (*set_cur_level)(void *devdata, unsigned long level);
> +};

That duplicate w/ .c file content.
We don't need this in the header, please follow the cpufreq-/devfreq-
design.

> +
> +struct remoteproc_cdev;
> +
> +#ifdef CONFIG_REMOTEPROC_THERMAL
> +
> +struct remoteproc_cdev *
> +remoteproc_cooling_register(struct device_node *np,
> +			     const char *name,
> +			     const struct remoteproc_cooling_ops *ops,
> +			     void *devdata);
> +
> +void remoteproc_cooling_unregister(struct remoteproc_cdev *rproc_cdev);
> +
> +#else /* !CONFIG_REMOTEPROC_THERMAL */
> +
> +static inline struct remoteproc_cdev *
> +remoteproc_cooling_register(struct device_node *np,
> +			     const char *name,
> +			     const struct remoteproc_cooling_ops *ops,
> +			     void *devdata)
> +{
> +	return ERR_PTR(-EINVAL);
> +}

Function naming convention here as well


Regards,
Lukasz

Re: [PATCH v1 1/8] thermal: Add Remote Proc cooling driver

[Gaurav Kohli]

On 2/2/2026 4:29 PM, Lukasz Luba wrote:
> Hi Gaurav,
> 
> On 12/23/25 12:32, Gaurav Kohli wrote:
>> Add a new generic driver for thermal cooling devices that control
>> remote processors (modem, DSP, etc.) through various communication
>> channels.
>>
>> This driver provides an abstraction layer between the thermal
>> subsystem and vendor-specific remote processor communication
>> mechanisms.
> 
> Is this the patch about proposing the new cooling
> device type at last LPC2025 conference (what we've discussed with Amit)?
> 

thanks Lukasz for review, yes this is the same.
sorry for late reply, was on leave last week.

> There was some feedback asking you to add a bit more description
> into this patch header, please do that (with some background as well).
> 

Sure, will update.

>>
>> Suggested-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
>> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>> ---
>>   MAINTAINERS                          |   8 ++
>>   drivers/thermal/Kconfig              |  11 ++
>>   drivers/thermal/Makefile             |   2 +
>>   drivers/thermal/remoteproc_cooling.c | 154 +++++++++++++++++++++++++++
>>   include/linux/remoteproc_cooling.h   |  52 +++++++++
>>   5 files changed, 227 insertions(+)
>>   create mode 100644 drivers/thermal/remoteproc_cooling.c
>>   create mode 100644 include/linux/remoteproc_cooling.h
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 679e5f11e672..c1ba87315cdf 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -25935,6 +25935,14 @@ F:    drivers/thermal/cpufreq_cooling.c
>>   F:    drivers/thermal/cpuidle_cooling.c
>>   F:    include/linux/cpu_cooling.h
>> +THERMAL/REMOTEPROC_COOLING
>> +M:    Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>> +L:    linux-pm@vger.kernel.org
>> +S:    Supported
>> +F:    drivers/thermal/remoteproc_cooling.c
>> +F:    include/linux/remoteproc_cooling.h
>> +
>> +
>>   THERMAL/POWER_ALLOCATOR
>>   M:    Lukasz Luba <lukasz.luba@arm.com>
>>   L:    linux-pm@vger.kernel.org
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index b10080d61860..31e92be34387 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -229,6 +229,17 @@ config PCIE_THERMAL
>>         If you want this support, you should say Y here.
>> +
>> +config REMOTEPROC_THERMAL
>> +    bool "Remote processor cooling support"
>> +    help
>> +      This implements a generic cooling mechanism for remote processors
>> +      (modem, DSP, etc.) that allows vendor-specific implementations to
>> +      register thermal cooling devices and provide callbacks for thermal
>> +      mitigation.
>> +
>> +      If you want this support, you should say Y here.
>> +
>>   config THERMAL_EMULATION
>>       bool "Thermal emulation mode support"
>>       help
>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
>> index bb21e7ea7fc6..ae747dde54fe 100644
>> --- a/drivers/thermal/Makefile
>> +++ b/drivers/thermal/Makefile
>> @@ -34,6 +34,8 @@ thermal_sys-$(CONFIG_DEVFREQ_THERMAL) += 
>> devfreq_cooling.o
>>   thermal_sys-$(CONFIG_PCIE_THERMAL) += pcie_cooling.o
>> +thermal_sys-$(CONFIG_REMOTEPROC_THERMAL) += remoteproc_cooling.o
>> +
>>   obj-$(CONFIG_K3_THERMAL)    += k3_bandgap.o k3_j72xx_bandgap.o
>>   # platform thermal drivers
>>   obj-y                += broadcom/
>> diff --git a/drivers/thermal/remoteproc_cooling.c b/drivers/thermal/ 
>> remoteproc_cooling.c
>> new file mode 100644
>> index 000000000000..a1f948cbde0f
>> --- /dev/null
>> +++ b/drivers/thermal/remoteproc_cooling.c
>> @@ -0,0 +1,154 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Remote Processor Cooling Device
>> + *
>> + * Copyright (c) 2025, Qualcomm Innovation Center, Inc. All rights 
>> reserved.
>> + */
>> +
>> +#include <linux/err.h>
>> +#include <linux/export.h>
>> +#include <linux/module.h>
>> +#include <linux/mutex.h>
>> +#include <linux/of.h>
>> +#include <linux/slab.h>
>> +#include <linux/thermal.h>
>> +
>> +#define REMOTEPROC_PREFIX        "rproc_"
>> +
>> +struct remoteproc_cooling_ops {
>> +    int (*get_max_level)(void *devdata, unsigned long *level);
>> +    int (*get_cur_level)(void *devdata, unsigned long *level);
>> +    int (*set_cur_level)(void *devdata, unsigned long level);
>> +};
> 
> 1. There is no comment for struct and the functions like you did below.
> 2. Why you need those 3 callbacks?
>     It looks like they are simple wrappers on stuff in
>     'struct thermal_cooling_device_ops'.
>     Please try to get rid of them and re-use the existing fwk callbacks.
> 

thanks for this suggestion, i will use thermal_cooling_device_ops directly.

>> +
>> +/**
>> + * struct remoteproc_cdev - Remote processor cooling device
>> + * @cdev: Thermal cooling device handle
>> + * @ops: Vendor-specific operation callbacks
>> + * @devdata: Private data for vendor implementation
>> + * @np: Device tree node associated with this cooling device
>> + * @lock: Mutex to protect cooling device operations
>> + */
>> +struct remoteproc_cdev {
> 
> Please use the full naming:
> remoteproc_cooling_device
> 
>> +    struct thermal_cooling_device *cdev;
> 
> You don't need to keep it here. AFAICS it's only
> used in the 'unregister' function. Please check my
> comment here and then remove this pointer.
> (It creates uneseccery linkage between those devices).
> 
>> +    const struct remoteproc_cooling_ops *ops;
> 
> So here it can be simply:
> struct thermal_cooling_device_ops cooling_ops;
> 

yes, i will use this as part of remoteproc_cooling_device struct.

>> +    void *devdata;
>> +    struct device_node *np;
> 
> This 'np' is also not used, remove it please.
> 
>> +    struct mutex lock;
>> +};
>> +
>> +
>> +/* Thermal cooling device callbacks */
>> +
>> +static int remoteproc_get_max_state(struct thermal_cooling_device *cdev,
>> +                    unsigned long *state)
>> +{
>> +    struct remoteproc_cdev *rproc_cdev = cdev->devdata;
>> +    int ret;
>> +
>> +    if (!rproc_cdev || !rproc_cdev->ops)
>> +        return -EINVAL;
> 
> This mustn't be changed in runtime accidenly. We don't guard in
> cpufreq-/devfreq- cooling these callbacks that way. Please drop them.

Sure, let me rewrite this and update in next version.

> 
>> +
>> +    mutex_lock(&rproc_cdev->lock);
>> +    ret = rproc_cdev->ops->get_max_level(rproc_cdev->devdata, state);
>> +    mutex_unlock(&rproc_cdev->lock);
>> +
>> +    return ret;
>> +}
>> +
>> +static int remoteproc_get_cur_state(struct thermal_cooling_device *cdev,
>> +                    unsigned long *state)
>> +{
>> +    struct remoteproc_cdev *rproc_cdev = cdev->devdata;
>> +    int ret;
>> +
>> +    if (!rproc_cdev || !rproc_cdev->ops)
>> +        return -EINVAL;
> 
> as above
> 
>> +
>> +    mutex_lock(&rproc_cdev->lock);
>> +    ret = rproc_cdev->ops->get_cur_level(rproc_cdev->devdata, state);
>> +    mutex_unlock(&rproc_cdev->lock);
>> +
>> +    return ret;
>> +}
>> +
>> +static int remoteproc_set_cur_state(struct thermal_cooling_device *cdev,
>> +                    unsigned long state)
>> +{
>> +    struct remoteproc_cdev *rproc_cdev = cdev->devdata;
>> +    int ret;
>> +
>> +    if (!rproc_cdev || !rproc_cdev->ops)
>> +        return -EINVAL;
> 
> as above
> 

will fix in all callbacks.

>> +
>> +    mutex_lock(&rproc_cdev->lock);
>> +    ret = rproc_cdev->ops->set_cur_level(rproc_cdev->devdata, state);
>> +    mutex_unlock(&rproc_cdev->lock);
>> +
>> +    return ret;
>> +}
>> +
>> +static const struct thermal_cooling_device_ops remoteproc_cooling_ops 
>> = {
>> +    .get_max_state = remoteproc_get_max_state,
>> +    .get_cur_state = remoteproc_get_cur_state,
>> +    .set_cur_state = remoteproc_set_cur_state,
>> +};
>> +
>> +struct remoteproc_cdev *
>> +remoteproc_cooling_register(struct device_node *np,
>> +                 const char *name, const struct 
>> remoteproc_cooling_ops *ops,
>> +                 void *devdata)
> 
> Since this is based on device_node, please align to the naming
> convention from cpufreq-/devfreq-cooling and use prefix 'of_'
> 
> of_remoteproc_cooling_register()
> 
>> +{
>> +    struct remoteproc_cdev *rproc_cdev;
>> +    struct thermal_cooling_device *cdev;
>> +    int ret;
>> +
>> +    if (!name || !ops) {
> 
> IMO you should check the '!np' here, not the lines below.
> We can simply bail out very early.
> 

thanks will put explicit check for np, but please let me know for non 
np, do we have to add support for non np also.
so they can directly register with thermal_cooling_device_register.

>> +        return ERR_PTR(-EINVAL);
>> +    }
>> +
>> +    rproc_cdev = kzalloc(sizeof(*rproc_cdev), GFP_KERNEL);
>> +    if (!rproc_cdev)
>> +        return ERR_PTR(-ENOMEM);
>> +
>> +    rproc_cdev->ops = ops;
>> +    rproc_cdev->devdata = devdata;
>> +    rproc_cdev->np = np;
>> +    mutex_init(&rproc_cdev->lock);
>> +
>> +    char *rproc_name __free(kfree) =
>> +        kasprintf(GFP_KERNEL, REMOTEPROC_PREFIX "%s", name);
>> +    /* Register with thermal framework */
>> +    if (np) {
> 
> Too late to test 'np'.

yes, will put a check in the start of function.

> 
>> +        cdev = thermal_of_cooling_device_register(np, rproc_name, 
>> rproc_cdev,
>> +                              &remoteproc_cooling_ops);
>> +    }
>> +
>> +    if (IS_ERR(cdev)) {
> 
> This check should be just below the line when you get the 'cdev'
> 
>> +        ret = PTR_ERR(cdev);
>> +        goto free_rproc_cdev;
>> +    }
>> +
>> +    rproc_cdev->cdev = cdev;
>> +
>> +    return rproc_cdev;
>> +
>> +free_rproc_cdev:
>> +    kfree(rproc_cdev);
>> +    return ERR_PTR(ret);
>> +}
>> +EXPORT_SYMBOL_GPL(remoteproc_cooling_register);
>> +
>> +void remoteproc_cooling_unregister(struct remoteproc_cdev *rproc_cdev)
> 
> Change the API to be alined with cpufreq-cooling and devfreq-cooling
> types of devices, so:
> 
> void remoteproc_cooling_unregister(struct thermal_cooling_device *cdev)
> 
> You still should be able to get the rptoc_cdev like:
> 
> rproc_cdev = cdev->devdata;
> 
> and free it.
> 

thanks, will change something like below
+       rproc_cdev = cdev->devdata;
+       thermal_cooling_device_unregister(cdev);

>> +{
>> +    if (!rproc_cdev)
>> +        return;
>> +
>> +    thermal_cooling_device_unregister(rproc_cdev->cdev);
>> +    mutex_destroy(&rproc_cdev->lock);
>> +    kfree(rproc_cdev);
>> +}
>> +EXPORT_SYMBOL_GPL(remoteproc_cooling_unregister);
>> +
>> +MODULE_LICENSE("GPL");
>> +MODULE_DESCRIPTION("Remote Processor Cooling Device");
>> diff --git a/include/linux/remoteproc_cooling.h b/include/linux/ 
>> remoteproc_cooling.h
>> new file mode 100644
>> index 000000000000..ef94019d220d
>> --- /dev/null
>> +++ b/include/linux/remoteproc_cooling.h
>> @@ -0,0 +1,52 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * Remote Processor Cooling Device
>> + *
>> + * Copyright (c) 2025, Qualcomm Innovation Center
>> + */
>> +
>> +#ifndef __REMOTEPROC_COOLING_H__
>> +#define __REMOTEPROC_COOLING_H__
>> +
>> +#include <linux/thermal.h>
>> +
>> +struct device;
>> +struct device_node;
>> +
>> +struct remoteproc_cooling_ops {
>> +    int (*get_max_level)(void *devdata, unsigned long *level);
>> +    int (*get_cur_level)(void *devdata, unsigned long *level);
>> +    int (*set_cur_level)(void *devdata, unsigned long level);
>> +};
> 
> That duplicate w/ .c file content.
> We don't need this in the header, please follow the cpufreq-/devfreq-
> design.
> 

Yes, with new approach of using thermal_cooling_device_ops directly can
save this.

>> +
>> +struct remoteproc_cdev;
>> +
>> +#ifdef CONFIG_REMOTEPROC_THERMAL
>> +
>> +struct remoteproc_cdev *
>> +remoteproc_cooling_register(struct device_node *np,
>> +                 const char *name,
>> +                 const struct remoteproc_cooling_ops *ops,
>> +                 void *devdata);
>> +
>> +void remoteproc_cooling_unregister(struct remoteproc_cdev *rproc_cdev);
>> +
>> +#else /* !CONFIG_REMOTEPROC_THERMAL */
>> +
>> +static inline struct remoteproc_cdev *
>> +remoteproc_cooling_register(struct device_node *np,
>> +                 const char *name,
>> +                 const struct remoteproc_cooling_ops *ops,
>> +                 void *devdata)
>> +{
>> +    return ERR_PTR(-EINVAL);
>> +}
> 
> Function naming convention here as well
> 

thanks a lot, let me rewrite as per suggestion and update in newer version.

> 
> Regards,
> Lukasz

Re: [PATCH v1 1/8] thermal: Add Remote Proc cooling driver

[Lukasz Luba]

On 2/9/26 05:28, Gaurav Kohli wrote:
> 
> 
> On 2/2/2026 4:29 PM, Lukasz Luba wrote:
>> Hi Gaurav,
>>
>> On 12/23/25 12:32, Gaurav Kohli wrote:
>>> Add a new generic driver for thermal cooling devices that control
>>> remote processors (modem, DSP, etc.) through various communication
>>> channels.
>>>
>>> This driver provides an abstraction layer between the thermal
>>> subsystem and vendor-specific remote processor communication
>>> mechanisms.
>>
>> Is this the patch about proposing the new cooling
>> device type at last LPC2025 conference (what we've discussed with Amit)?
>>
> 
> thanks Lukasz for review, yes this is the same.
> sorry for late reply, was on leave last week.
> 
>> There was some feedback asking you to add a bit more description
>> into this patch header, please do that (with some background as well).
>>
> 
> Sure, will update.
> 
>>>
>>> Suggested-by: Amit Kucheria <amit.kucheria@oss.qualcomm.com>
>>> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>>> ---


[snip]


>>> +struct remoteproc_cooling_ops {
>>> +    int (*get_max_level)(void *devdata, unsigned long *level);
>>> +    int (*get_cur_level)(void *devdata, unsigned long *level);
>>> +    int (*set_cur_level)(void *devdata, unsigned long level);
>>> +};
>>
>> 1. There is no comment for struct and the functions like you did below.
>> 2. Why you need those 3 callbacks?
>>     It looks like they are simple wrappers on stuff in
>>     'struct thermal_cooling_device_ops'.
>>     Please try to get rid of them and re-use the existing fwk callbacks.
>>
> 
> thanks for this suggestion, i will use thermal_cooling_device_ops directly.
> 
>>> +
>>> +/**
>>> + * struct remoteproc_cdev - Remote processor cooling device
>>> + * @cdev: Thermal cooling device handle
>>> + * @ops: Vendor-specific operation callbacks
>>> + * @devdata: Private data for vendor implementation
>>> + * @np: Device tree node associated with this cooling device
>>> + * @lock: Mutex to protect cooling device operations
>>> + */
>>> +struct remoteproc_cdev {
>>
>> Please use the full naming:
>> remoteproc_cooling_device
>>
>>> +    struct thermal_cooling_device *cdev;
>>
>> You don't need to keep it here. AFAICS it's only
>> used in the 'unregister' function. Please check my
>> comment here and then remove this pointer.
>> (It creates uneseccery linkage between those devices).
>>
>>> +    const struct remoteproc_cooling_ops *ops;
>>
>> So here it can be simply:
>> struct thermal_cooling_device_ops cooling_ops;
>>
> 
> yes, i will use this as part of remoteproc_cooling_device struct.
> 
>>> +    void *devdata;
>>> +    struct device_node *np;
>>
>> This 'np' is also not used, remove it please.
>>
>>> +    struct mutex lock;
>>> +};
>>> +
>>> +
>>> +/* Thermal cooling device callbacks */
>>> +
>>> +static int remoteproc_get_max_state(struct thermal_cooling_device 
>>> *cdev,
>>> +                    unsigned long *state)
>>> +{
>>> +    struct remoteproc_cdev *rproc_cdev = cdev->devdata;
>>> +    int ret;
>>> +
>>> +    if (!rproc_cdev || !rproc_cdev->ops)
>>> +        return -EINVAL;
>>
>> This mustn't be changed in runtime accidenly. We don't guard in
>> cpufreq-/devfreq- cooling these callbacks that way. Please drop them.
> 
> Sure, let me rewrite this and update in next version.
> 
>>

[snip]

>>> +
>>> +    if (!name || !ops) {
>>
>> IMO you should check the '!np' here, not the lines below.
>> We can simply bail out very early.
>>
> 
> thanks will put explicit check for np, but please let me know for non 
> np, do we have to add support for non np also.

If your code doesn't use the non-np then let's not implement it.
When there will be a new client, we can refactor slightly the existing
code and make two interfaces for the registration (similat to cpufreq
cooling).

> so they can directly register with thermal_cooling_device_register.
> 
>>> +        return ERR_PTR(-EINVAL);
>>> +    }
>>> +

[snip]

>>> +
>>> +void remoteproc_cooling_unregister(struct remoteproc_cdev *rproc_cdev)
>>
>> Change the API to be alined with cpufreq-cooling and devfreq-cooling
>> types of devices, so:
>>
>> void remoteproc_cooling_unregister(struct thermal_cooling_device *cdev)
>>
>> You still should be able to get the rptoc_cdev like:
>>
>> rproc_cdev = cdev->devdata;
>>
>> and free it.
>>
> 
> thanks, will change something like below
> +       rproc_cdev = cdev->devdata;
> +       thermal_cooling_device_unregister(cdev);

Should work, let see in the new code.


[snip]


>>> +struct remoteproc_cooling_ops {
>>> +    int (*get_max_level)(void *devdata, unsigned long *level);
>>> +    int (*get_cur_level)(void *devdata, unsigned long *level);
>>> +    int (*set_cur_level)(void *devdata, unsigned long level);
>>> +};
>>
>> That duplicate w/ .c file content.
>> We don't need this in the header, please follow the cpufreq-/devfreq-
>> design.
>>
> 
> Yes, with new approach of using thermal_cooling_device_ops directly can
> save this.

Great, looking for the the v2

> 
>>> +
>>> +struct remoteproc_cdev;
>>> +
>>> +#ifdef CONFIG_REMOTEPROC_THERMAL
>>> +
>>> +struct remoteproc_cdev *
>>> +remoteproc_cooling_register(struct device_node *np,
>>> +                 const char *name,
>>> +                 const struct remoteproc_cooling_ops *ops,
>>> +                 void *devdata);
>>> +
>>> +void remoteproc_cooling_unregister(struct remoteproc_cdev *rproc_cdev);
>>> +
>>> +#else /* !CONFIG_REMOTEPROC_THERMAL */
>>> +
>>> +static inline struct remoteproc_cdev *
>>> +remoteproc_cooling_register(struct device_node *np,
>>> +                 const char *name,
>>> +                 const struct remoteproc_cooling_ops *ops,
>>> +                 void *devdata)
>>> +{
>>> +    return ERR_PTR(-EINVAL);
>>> +}
>>
>> Function naming convention here as well
>>
> 
> thanks a lot, let me rewrite as per suggestion and update in newer version.
> 

you're welcome

[PATCH v1 2/8] remoteproc: qcom: probe all child devices

[Gaurav Kohli]

From: Casey Connolly <casey.connolly@linaro.org>

Generalise the qcom,bam-dmux child node support by probing all
remoteproc children with of_platform_populate(). This will be used to
enable support for devices which are best represented as subnodes of the
remoteproc, such as those representing QMI clients.

Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
---
 drivers/remoteproc/qcom_q6v5.c     | 4 ++++
 drivers/remoteproc/qcom_q6v5_mss.c | 8 --------
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/remoteproc/qcom_q6v5.c b/drivers/remoteproc/qcom_q6v5.c
index 58d5b85e58cd..a02839c7ed8c 100644
--- a/drivers/remoteproc/qcom_q6v5.c
+++ b/drivers/remoteproc/qcom_q6v5.c
@@ -6,6 +6,7 @@
  * Copyright (C) 2014 Sony Mobile Communications AB
  * Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
  */
+#include <linux/of_platform.h>
 #include <linux/kernel.h>
 #include <linux/platform_device.h>
 #include <linux/interconnect.h>
@@ -351,6 +352,8 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev,
 		return dev_err_probe(&pdev->dev, PTR_ERR(q6v5->path),
 				     "failed to acquire interconnect path\n");
 
+	of_platform_populate(q6v5->dev->of_node, NULL, NULL, q6v5->dev);
+
 	return 0;
 }
 EXPORT_SYMBOL_GPL(qcom_q6v5_init);
@@ -361,6 +364,7 @@ EXPORT_SYMBOL_GPL(qcom_q6v5_init);
  */
 void qcom_q6v5_deinit(struct qcom_q6v5 *q6v5)
 {
+	of_platform_depopulate(q6v5->dev);
 	qmp_put(q6v5->qmp);
 }
 EXPORT_SYMBOL_GPL(qcom_q6v5_deinit);
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
index 91940977ca89..d40565c1cc62 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -238,7 +238,6 @@ struct q6v5 {
 	struct qcom_rproc_pdm pdm_subdev;
 	struct qcom_rproc_ssr ssr_subdev;
 	struct qcom_sysmon *sysmon;
-	struct platform_device *bam_dmux;
 	bool need_mem_protection;
 	bool has_alt_reset;
 	bool has_mba_logs;
@@ -2029,7 +2028,6 @@ static int q6v5_alloc_memory_region(struct q6v5 *qproc)
 static int q6v5_probe(struct platform_device *pdev)
 {
 	const struct rproc_hexagon_res *desc;
-	struct device_node *node;
 	struct q6v5 *qproc;
 	struct rproc *rproc;
 	const char *mba_image;
@@ -2163,10 +2161,6 @@ static int q6v5_probe(struct platform_device *pdev)
 	if (ret)
 		goto remove_sysmon_subdev;
 
-	node = of_get_compatible_child(pdev->dev.of_node, "qcom,bam-dmux");
-	qproc->bam_dmux = of_platform_device_create(node, NULL, &pdev->dev);
-	of_node_put(node);
-
 	return 0;
 
 remove_sysmon_subdev:
@@ -2186,8 +2180,6 @@ static void q6v5_remove(struct platform_device *pdev)
 	struct q6v5 *qproc = platform_get_drvdata(pdev);
 	struct rproc *rproc = qproc->rproc;
 
-	if (qproc->bam_dmux)
-		of_platform_device_destroy(&qproc->bam_dmux->dev, NULL);
 	rproc_del(rproc);
 
 	qcom_q6v5_deinit(&qproc->q6v5);
-- 
2.34.1

Re: [PATCH v1 2/8] remoteproc: qcom: probe all child devices

[Dmitry Baryshkov]

On Tue, Dec 23, 2025 at 06:02:21PM +0530, Gaurav Kohli wrote:
> From: Casey Connolly <casey.connolly@linaro.org>
> 
> Generalise the qcom,bam-dmux child node support by probing all
> remoteproc children with of_platform_populate(). This will be used to
> enable support for devices which are best represented as subnodes of the
> remoteproc, such as those representing QMI clients.

Bindings first.

> 
> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
> ---
>  drivers/remoteproc/qcom_q6v5.c     | 4 ++++
>  drivers/remoteproc/qcom_q6v5_mss.c | 8 --------
>  2 files changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/remoteproc/qcom_q6v5.c b/drivers/remoteproc/qcom_q6v5.c
> index 58d5b85e58cd..a02839c7ed8c 100644
> --- a/drivers/remoteproc/qcom_q6v5.c
> +++ b/drivers/remoteproc/qcom_q6v5.c
> @@ -6,6 +6,7 @@
>   * Copyright (C) 2014 Sony Mobile Communications AB
>   * Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
>   */
> +#include <linux/of_platform.h>
>  #include <linux/kernel.h>
>  #include <linux/platform_device.h>
>  #include <linux/interconnect.h>
> @@ -351,6 +352,8 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev,
>  		return dev_err_probe(&pdev->dev, PTR_ERR(q6v5->path),
>  				     "failed to acquire interconnect path\n");
>  
> +	of_platform_populate(q6v5->dev->of_node, NULL, NULL, q6v5->dev);

Missing error handling. Also please use devm_of_platform_populate().

> +
>  	return 0;
>  }
>  EXPORT_SYMBOL_GPL(qcom_q6v5_init);
> @@ -361,6 +364,7 @@ EXPORT_SYMBOL_GPL(qcom_q6v5_init);
>   */
>  void qcom_q6v5_deinit(struct qcom_q6v5 *q6v5)
>  {
> +	of_platform_depopulate(q6v5->dev);
>  	qmp_put(q6v5->qmp);
>  }
>  EXPORT_SYMBOL_GPL(qcom_q6v5_deinit);
> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
> index 91940977ca89..d40565c1cc62 100644
> --- a/drivers/remoteproc/qcom_q6v5_mss.c
> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> @@ -238,7 +238,6 @@ struct q6v5 {
>  	struct qcom_rproc_pdm pdm_subdev;
>  	struct qcom_rproc_ssr ssr_subdev;
>  	struct qcom_sysmon *sysmon;
> -	struct platform_device *bam_dmux;
>  	bool need_mem_protection;
>  	bool has_alt_reset;
>  	bool has_mba_logs;
> @@ -2029,7 +2028,6 @@ static int q6v5_alloc_memory_region(struct q6v5 *qproc)
>  static int q6v5_probe(struct platform_device *pdev)
>  {
>  	const struct rproc_hexagon_res *desc;
> -	struct device_node *node;
>  	struct q6v5 *qproc;
>  	struct rproc *rproc;
>  	const char *mba_image;
> @@ -2163,10 +2161,6 @@ static int q6v5_probe(struct platform_device *pdev)
>  	if (ret)
>  		goto remove_sysmon_subdev;
>  
> -	node = of_get_compatible_child(pdev->dev.of_node, "qcom,bam-dmux");
> -	qproc->bam_dmux = of_platform_device_create(node, NULL, &pdev->dev);
> -	of_node_put(node);
> -
>  	return 0;
>  
>  remove_sysmon_subdev:
> @@ -2186,8 +2180,6 @@ static void q6v5_remove(struct platform_device *pdev)
>  	struct q6v5 *qproc = platform_get_drvdata(pdev);
>  	struct rproc *rproc = qproc->rproc;
>  
> -	if (qproc->bam_dmux)
> -		of_platform_device_destroy(&qproc->bam_dmux->dev, NULL);
>  	rproc_del(rproc);
>  
>  	qcom_q6v5_deinit(&qproc->q6v5);
> -- 
> 2.34.1
> 

-- 
With best wishes
Dmitry

Re: [PATCH v1 2/8] remoteproc: qcom: probe all child devices

[Bjorn Andersson]

On Tue, Dec 23, 2025 at 06:02:21PM +0530, Gaurav Kohli wrote:
> From: Casey Connolly <casey.connolly@linaro.org>
> 
> Generalise the qcom,bam-dmux child node support by probing all
> remoteproc children with of_platform_populate(). This will be used to
> enable support for devices which are best represented as subnodes of the
> remoteproc, such as those representing QMI clients.

Please flip this around, start with the description of the problem
you're trying to solve.

> 
> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>

This must have your signed-off-by, where you certifies the origin of
this patch.

> ---
>  drivers/remoteproc/qcom_q6v5.c     | 4 ++++
>  drivers/remoteproc/qcom_q6v5_mss.c | 8 --------
>  2 files changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/remoteproc/qcom_q6v5.c b/drivers/remoteproc/qcom_q6v5.c
> index 58d5b85e58cd..a02839c7ed8c 100644
> --- a/drivers/remoteproc/qcom_q6v5.c
> +++ b/drivers/remoteproc/qcom_q6v5.c
> @@ -6,6 +6,7 @@
>   * Copyright (C) 2014 Sony Mobile Communications AB
>   * Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
>   */
> +#include <linux/of_platform.h>
>  #include <linux/kernel.h>
>  #include <linux/platform_device.h>
>  #include <linux/interconnect.h>
> @@ -351,6 +352,8 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev,
>  		return dev_err_probe(&pdev->dev, PTR_ERR(q6v5->path),
>  				     "failed to acquire interconnect path\n");
>  
> +	of_platform_populate(q6v5->dev->of_node, NULL, NULL, q6v5->dev);

There are other child nodes here, in particular the GLINK and SMD edges.
Do we really want platform_devices registered for them?

Regards,
Bjorn

> +
>  	return 0;
>  }
>  EXPORT_SYMBOL_GPL(qcom_q6v5_init);
> @@ -361,6 +364,7 @@ EXPORT_SYMBOL_GPL(qcom_q6v5_init);
>   */
>  void qcom_q6v5_deinit(struct qcom_q6v5 *q6v5)
>  {
> +	of_platform_depopulate(q6v5->dev);
>  	qmp_put(q6v5->qmp);
>  }
>  EXPORT_SYMBOL_GPL(qcom_q6v5_deinit);
> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
> index 91940977ca89..d40565c1cc62 100644
> --- a/drivers/remoteproc/qcom_q6v5_mss.c
> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> @@ -238,7 +238,6 @@ struct q6v5 {
>  	struct qcom_rproc_pdm pdm_subdev;
>  	struct qcom_rproc_ssr ssr_subdev;
>  	struct qcom_sysmon *sysmon;
> -	struct platform_device *bam_dmux;
>  	bool need_mem_protection;
>  	bool has_alt_reset;
>  	bool has_mba_logs;
> @@ -2029,7 +2028,6 @@ static int q6v5_alloc_memory_region(struct q6v5 *qproc)
>  static int q6v5_probe(struct platform_device *pdev)
>  {
>  	const struct rproc_hexagon_res *desc;
> -	struct device_node *node;
>  	struct q6v5 *qproc;
>  	struct rproc *rproc;
>  	const char *mba_image;
> @@ -2163,10 +2161,6 @@ static int q6v5_probe(struct platform_device *pdev)
>  	if (ret)
>  		goto remove_sysmon_subdev;
>  
> -	node = of_get_compatible_child(pdev->dev.of_node, "qcom,bam-dmux");
> -	qproc->bam_dmux = of_platform_device_create(node, NULL, &pdev->dev);
> -	of_node_put(node);
> -
>  	return 0;
>  
>  remove_sysmon_subdev:
> @@ -2186,8 +2180,6 @@ static void q6v5_remove(struct platform_device *pdev)
>  	struct q6v5 *qproc = platform_get_drvdata(pdev);
>  	struct rproc *rproc = qproc->rproc;
>  
> -	if (qproc->bam_dmux)
> -		of_platform_device_destroy(&qproc->bam_dmux->dev, NULL);
>  	rproc_del(rproc);
>  
>  	qcom_q6v5_deinit(&qproc->q6v5);
> -- 
> 2.34.1
> 

Re: [PATCH v1 2/8] remoteproc: qcom: probe all child devices

[Gaurav Kohli]

On 1/3/2026 8:26 PM, Bjorn Andersson wrote:
> On Tue, Dec 23, 2025 at 06:02:21PM +0530, Gaurav Kohli wrote:
>> From: Casey Connolly <casey.connolly@linaro.org>
>>
>> Generalise the qcom,bam-dmux child node support by probing all
>> remoteproc children with of_platform_populate(). This will be used to
>> enable support for devices which are best represented as subnodes of the
>> remoteproc, such as those representing QMI clients.
> Please flip this around, start with the description of the problem
> you're trying to solve.
>
>> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
> This must have your signed-off-by, where you certifies the origin of
> this patch.
>
>> ---
>>   drivers/remoteproc/qcom_q6v5.c     | 4 ++++
>>   drivers/remoteproc/qcom_q6v5_mss.c | 8 --------
>>   2 files changed, 4 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/remoteproc/qcom_q6v5.c b/drivers/remoteproc/qcom_q6v5.c
>> index 58d5b85e58cd..a02839c7ed8c 100644
>> --- a/drivers/remoteproc/qcom_q6v5.c
>> +++ b/drivers/remoteproc/qcom_q6v5.c
>> @@ -6,6 +6,7 @@
>>    * Copyright (C) 2014 Sony Mobile Communications AB
>>    * Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
>>    */
>> +#include <linux/of_platform.h>
>>   #include <linux/kernel.h>
>>   #include <linux/platform_device.h>
>>   #include <linux/interconnect.h>
>> @@ -351,6 +352,8 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev,
>>   		return dev_err_probe(&pdev->dev, PTR_ERR(q6v5->path),
>>   				     "failed to acquire interconnect path\n");
>>   
>> +	of_platform_populate(q6v5->dev->of_node, NULL, NULL, q6v5->dev);
> There are other child nodes here, in particular the GLINK and SMD edges.
> Do we really want platform_devices registered for them?
>
> Regards,
> Bjorn


thanks for pointing this, can you please suggest the right approach.

This should not impact glink, as that is registering as rproc sub node, 
And we need rproc cooling as child node

of remote proc subsytem to create probe dependency only.


Can we do platform populate for specific child, would that be right 
approach. or we should create rproc cooling as independent of parent ?


>> +
>>   	return 0;
>>   }
>>   EXPORT_SYMBOL_GPL(qcom_q6v5_init);
>> @@ -361,6 +364,7 @@ EXPORT_SYMBOL_GPL(qcom_q6v5_init);
>>    */
>>   void qcom_q6v5_deinit(struct qcom_q6v5 *q6v5)
>>   {
>> +	of_platform_depopulate(q6v5->dev);
>>   	qmp_put(q6v5->qmp);
>>   }
>>   EXPORT_SYMBOL_GPL(qcom_q6v5_deinit);
>> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
>> index 91940977ca89..d40565c1cc62 100644
>> --- a/drivers/remoteproc/qcom_q6v5_mss.c
>> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
>> @@ -238,7 +238,6 @@ struct q6v5 {
>>   	struct qcom_rproc_pdm pdm_subdev;
>>   	struct qcom_rproc_ssr ssr_subdev;
>>   	struct qcom_sysmon *sysmon;
>> -	struct platform_device *bam_dmux;
>>   	bool need_mem_protection;
>>   	bool has_alt_reset;
>>   	bool has_mba_logs;
>> @@ -2029,7 +2028,6 @@ static int q6v5_alloc_memory_region(struct q6v5 *qproc)
>>   static int q6v5_probe(struct platform_device *pdev)
>>   {
>>   	const struct rproc_hexagon_res *desc;
>> -	struct device_node *node;
>>   	struct q6v5 *qproc;
>>   	struct rproc *rproc;
>>   	const char *mba_image;
>> @@ -2163,10 +2161,6 @@ static int q6v5_probe(struct platform_device *pdev)
>>   	if (ret)
>>   		goto remove_sysmon_subdev;
>>   
>> -	node = of_get_compatible_child(pdev->dev.of_node, "qcom,bam-dmux");
>> -	qproc->bam_dmux = of_platform_device_create(node, NULL, &pdev->dev);
>> -	of_node_put(node);
>> -
>>   	return 0;
>>   
>>   remove_sysmon_subdev:
>> @@ -2186,8 +2180,6 @@ static void q6v5_remove(struct platform_device *pdev)
>>   	struct q6v5 *qproc = platform_get_drvdata(pdev);
>>   	struct rproc *rproc = qproc->rproc;
>>   
>> -	if (qproc->bam_dmux)
>> -		of_platform_device_destroy(&qproc->bam_dmux->dev, NULL);
>>   	rproc_del(rproc);
>>   
>>   	qcom_q6v5_deinit(&qproc->q6v5);
>> -- 
>> 2.34.1
>>

Re: [PATCH v1 2/8] remoteproc: qcom: probe all child devices

[Gaurav Kohli]

On 1/8/2026 12:37 PM, Gaurav Kohli wrote:
>
> On 1/3/2026 8:26 PM, Bjorn Andersson wrote:
>> On Tue, Dec 23, 2025 at 06:02:21PM +0530, Gaurav Kohli wrote:
>>> From: Casey Connolly <casey.connolly@linaro.org>
>>>
>>> Generalise the qcom,bam-dmux child node support by probing all
>>> remoteproc children with of_platform_populate(). This will be used to
>>> enable support for devices which are best represented as subnodes of 
>>> the
>>> remoteproc, such as those representing QMI clients.
>> Please flip this around, start with the description of the problem
>> you're trying to solve.
>>
>>> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
>> This must have your signed-off-by, where you certifies the origin of
>> this patch.
>>
>>> ---
>>>   drivers/remoteproc/qcom_q6v5.c     | 4 ++++
>>>   drivers/remoteproc/qcom_q6v5_mss.c | 8 --------
>>>   2 files changed, 4 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/remoteproc/qcom_q6v5.c 
>>> b/drivers/remoteproc/qcom_q6v5.c
>>> index 58d5b85e58cd..a02839c7ed8c 100644
>>> --- a/drivers/remoteproc/qcom_q6v5.c
>>> +++ b/drivers/remoteproc/qcom_q6v5.c
>>> @@ -6,6 +6,7 @@
>>>    * Copyright (C) 2014 Sony Mobile Communications AB
>>>    * Copyright (c) 2012-2013, The Linux Foundation. All rights 
>>> reserved.
>>>    */
>>> +#include <linux/of_platform.h>
>>>   #include <linux/kernel.h>
>>>   #include <linux/platform_device.h>
>>>   #include <linux/interconnect.h>
>>> @@ -351,6 +352,8 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5, 
>>> struct platform_device *pdev,
>>>           return dev_err_probe(&pdev->dev, PTR_ERR(q6v5->path),
>>>                        "failed to acquire interconnect path\n");
>>>   +    of_platform_populate(q6v5->dev->of_node, NULL, NULL, q6v5->dev);
>> There are other child nodes here, in particular the GLINK and SMD edges.
>> Do we really want platform_devices registered for them?
>>
>> Regards,
>> Bjorn
>
>
> thanks for pointing this, can you please suggest the right approach.
>
> This should not impact glink, as that is registering as rproc sub 
> node, And we need rproc cooling as child node
>
> of remote proc subsytem to create probe dependency only.
>
>
> Can we do platform populate for specific child, would that be right 
> approach. or we should create rproc cooling as independent of parent ?
>

HI Bjorn,

I’d like to highlight the impact and details of placement of remoteproc 
cooling dt node:


->As a child of the remote proc subsystem node:
     In this configuration, the cooling device will only be probed once 
the corresponding remote proc subsystem itself is probed.

->Outside the remote proc subsystem, may be part of soc node:
     In this setup, the cooling device will be probed independently. It 
will wait until the remoteproc subsystem is brought up
     before completing cooling registration.
     The drawback here is that if the parent remoteproc subsystem is 
disabled, the cooling device will still undergo an
     unnecessary probe, even though it cannot be registered.

>
>>> +
>>>       return 0;
>>>   }
>>>   EXPORT_SYMBOL_GPL(qcom_q6v5_init);
>>> @@ -361,6 +364,7 @@ EXPORT_SYMBOL_GPL(qcom_q6v5_init);
>>>    */
>>>   void qcom_q6v5_deinit(struct qcom_q6v5 *q6v5)
>>>   {
>>> +    of_platform_depopulate(q6v5->dev);
>>>       qmp_put(q6v5->qmp);
>>>   }
>>>   EXPORT_SYMBOL_GPL(qcom_q6v5_deinit);
>>> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c 
>>> b/drivers/remoteproc/qcom_q6v5_mss.c
>>> index 91940977ca89..d40565c1cc62 100644
>>> --- a/drivers/remoteproc/qcom_q6v5_mss.c
>>> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
>>> @@ -238,7 +238,6 @@ struct q6v5 {
>>>       struct qcom_rproc_pdm pdm_subdev;
>>>       struct qcom_rproc_ssr ssr_subdev;
>>>       struct qcom_sysmon *sysmon;
>>> -    struct platform_device *bam_dmux;
>>>       bool need_mem_protection;
>>>       bool has_alt_reset;
>>>       bool has_mba_logs;
>>> @@ -2029,7 +2028,6 @@ static int q6v5_alloc_memory_region(struct 
>>> q6v5 *qproc)
>>>   static int q6v5_probe(struct platform_device *pdev)
>>>   {
>>>       const struct rproc_hexagon_res *desc;
>>> -    struct device_node *node;
>>>       struct q6v5 *qproc;
>>>       struct rproc *rproc;
>>>       const char *mba_image;
>>> @@ -2163,10 +2161,6 @@ static int q6v5_probe(struct platform_device 
>>> *pdev)
>>>       if (ret)
>>>           goto remove_sysmon_subdev;
>>>   -    node = of_get_compatible_child(pdev->dev.of_node, 
>>> "qcom,bam-dmux");
>>> -    qproc->bam_dmux = of_platform_device_create(node, NULL, 
>>> &pdev->dev);
>>> -    of_node_put(node);
>>> -
>>>       return 0;
>>>     remove_sysmon_subdev:
>>> @@ -2186,8 +2180,6 @@ static void q6v5_remove(struct platform_device 
>>> *pdev)
>>>       struct q6v5 *qproc = platform_get_drvdata(pdev);
>>>       struct rproc *rproc = qproc->rproc;
>>>   -    if (qproc->bam_dmux)
>>> - of_platform_device_destroy(&qproc->bam_dmux->dev, NULL);
>>>       rproc_del(rproc);
>>>         qcom_q6v5_deinit(&qproc->q6v5);
>>> -- 
>>> 2.34.1
>>>

Re: [PATCH v1 2/8] remoteproc: qcom: probe all child devices

[Dmitry Baryshkov]

On Fri, Jan 23, 2026 at 07:23:39PM +0530, Gaurav Kohli wrote:
> 
> On 1/8/2026 12:37 PM, Gaurav Kohli wrote:
> > 
> > On 1/3/2026 8:26 PM, Bjorn Andersson wrote:
> > > On Tue, Dec 23, 2025 at 06:02:21PM +0530, Gaurav Kohli wrote:
> > > > From: Casey Connolly <casey.connolly@linaro.org>
> > > > 
> > > > Generalise the qcom,bam-dmux child node support by probing all
> > > > remoteproc children with of_platform_populate(). This will be used to
> > > > enable support for devices which are best represented as
> > > > subnodes of the
> > > > remoteproc, such as those representing QMI clients.
> > > Please flip this around, start with the description of the problem
> > > you're trying to solve.
> > > 
> > > > Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
> > > This must have your signed-off-by, where you certifies the origin of
> > > this patch.
> > > 
> > > > ---
> > > >   drivers/remoteproc/qcom_q6v5.c     | 4 ++++
> > > >   drivers/remoteproc/qcom_q6v5_mss.c | 8 --------
> > > >   2 files changed, 4 insertions(+), 8 deletions(-)
> > > > 
> > > > diff --git a/drivers/remoteproc/qcom_q6v5.c
> > > > b/drivers/remoteproc/qcom_q6v5.c
> > > > index 58d5b85e58cd..a02839c7ed8c 100644
> > > > --- a/drivers/remoteproc/qcom_q6v5.c
> > > > +++ b/drivers/remoteproc/qcom_q6v5.c
> > > > @@ -6,6 +6,7 @@
> > > >    * Copyright (C) 2014 Sony Mobile Communications AB
> > > >    * Copyright (c) 2012-2013, The Linux Foundation. All rights
> > > > reserved.
> > > >    */
> > > > +#include <linux/of_platform.h>
> > > >   #include <linux/kernel.h>
> > > >   #include <linux/platform_device.h>
> > > >   #include <linux/interconnect.h>
> > > > @@ -351,6 +352,8 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5,
> > > > struct platform_device *pdev,
> > > >           return dev_err_probe(&pdev->dev, PTR_ERR(q6v5->path),
> > > >                        "failed to acquire interconnect path\n");
> > > >   +    of_platform_populate(q6v5->dev->of_node, NULL, NULL, q6v5->dev);
> > > There are other child nodes here, in particular the GLINK and SMD edges.
> > > Do we really want platform_devices registered for them?
> > > 
> > > Regards,
> > > Bjorn
> > 
> > 
> > thanks for pointing this, can you please suggest the right approach.
> > 
> > This should not impact glink, as that is registering as rproc sub node,
> > And we need rproc cooling as child node
> > 
> > of remote proc subsytem to create probe dependency only.
> > 
> > 
> > Can we do platform populate for specific child, would that be right
> > approach. or we should create rproc cooling as independent of parent ?
> > 
> 
> HI Bjorn,
> 
> I’d like to highlight the impact and details of placement of remoteproc
> cooling dt node:
> 
> 
> ->As a child of the remote proc subsystem node:
>     In this configuration, the cooling device will only be probed once the
> corresponding remote proc subsystem itself is probed.
> 
> ->Outside the remote proc subsystem, may be part of soc node:
>     In this setup, the cooling device will be probed independently. It will
> wait until the remoteproc subsystem is brought up
>     before completing cooling registration.
>     The drawback here is that if the parent remoteproc subsystem is
> disabled, the cooling device will still undergo an
>     unnecessary probe, even though it cannot be registered.

Bjorns question was different. It wasn't about pushing cooling device
outside of the remoteproc node. It is about not registering the devices.

Can we follow the approach outlined by qcom_add_smd_subdev() /
qcom_add_glink_subdev()?

-- 
With best wishes
Dmitry

Re: [PATCH v1 2/8] remoteproc: qcom: probe all child devices

[Gaurav Kohli]

On 1/24/2026 12:33 AM, Dmitry Baryshkov wrote:
> On Fri, Jan 23, 2026 at 07:23:39PM +0530, Gaurav Kohli wrote:
>> On 1/8/2026 12:37 PM, Gaurav Kohli wrote:
>>> On 1/3/2026 8:26 PM, Bjorn Andersson wrote:
>>>> On Tue, Dec 23, 2025 at 06:02:21PM +0530, Gaurav Kohli wrote:
>>>>> From: Casey Connolly <casey.connolly@linaro.org>
>>>>>
>>>>> Generalise the qcom,bam-dmux child node support by probing all
>>>>> remoteproc children with of_platform_populate(). This will be used to
>>>>> enable support for devices which are best represented as
>>>>> subnodes of the
>>>>> remoteproc, such as those representing QMI clients.
>>>> Please flip this around, start with the description of the problem
>>>> you're trying to solve.
>>>>
>>>>> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
>>>> This must have your signed-off-by, where you certifies the origin of
>>>> this patch.
>>>>
>>>>> ---
>>>>>    drivers/remoteproc/qcom_q6v5.c     | 4 ++++
>>>>>    drivers/remoteproc/qcom_q6v5_mss.c | 8 --------
>>>>>    2 files changed, 4 insertions(+), 8 deletions(-)
>>>>>
>>>>> diff --git a/drivers/remoteproc/qcom_q6v5.c
>>>>> b/drivers/remoteproc/qcom_q6v5.c
>>>>> index 58d5b85e58cd..a02839c7ed8c 100644
>>>>> --- a/drivers/remoteproc/qcom_q6v5.c
>>>>> +++ b/drivers/remoteproc/qcom_q6v5.c
>>>>> @@ -6,6 +6,7 @@
>>>>>     * Copyright (C) 2014 Sony Mobile Communications AB
>>>>>     * Copyright (c) 2012-2013, The Linux Foundation. All rights
>>>>> reserved.
>>>>>     */
>>>>> +#include <linux/of_platform.h>
>>>>>    #include <linux/kernel.h>
>>>>>    #include <linux/platform_device.h>
>>>>>    #include <linux/interconnect.h>
>>>>> @@ -351,6 +352,8 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5,
>>>>> struct platform_device *pdev,
>>>>>            return dev_err_probe(&pdev->dev, PTR_ERR(q6v5->path),
>>>>>                         "failed to acquire interconnect path\n");
>>>>>    +    of_platform_populate(q6v5->dev->of_node, NULL, NULL, q6v5->dev);
>>>> There are other child nodes here, in particular the GLINK and SMD edges.
>>>> Do we really want platform_devices registered for them?
>>>>
>>>> Regards,
>>>> Bjorn
>>>
>>> thanks for pointing this, can you please suggest the right approach.
>>>
>>> This should not impact glink, as that is registering as rproc sub node,
>>> And we need rproc cooling as child node
>>>
>>> of remote proc subsytem to create probe dependency only.
>>>
>>>
>>> Can we do platform populate for specific child, would that be right
>>> approach. or we should create rproc cooling as independent of parent ?
>>>
>> HI Bjorn,
>>
>> I’d like to highlight the impact and details of placement of remoteproc
>> cooling dt node:
>>
>>
>> ->As a child of the remote proc subsystem node:
>>      In this configuration, the cooling device will only be probed once the
>> corresponding remote proc subsystem itself is probed.
>>
>> ->Outside the remote proc subsystem, may be part of soc node:
>>      In this setup, the cooling device will be probed independently. It will
>> wait until the remoteproc subsystem is brought up
>>      before completing cooling registration.
>>      The drawback here is that if the parent remoteproc subsystem is
>> disabled, the cooling device will still undergo an
>>      unnecessary probe, even though it cannot be registered.
> Bjorns question was different. It wasn't about pushing cooling device
> outside of the remoteproc node. It is about not registering the devices.
>
> Can we follow the approach outlined by qcom_add_smd_subdev() /
> qcom_add_glink_subdev()?


Hi Dmitry,

Thanks for the review. Since the remoteproc cooling is a QMI-based 
driver, it will receive the

subsystem up notification directly. Therefore, there’s no need to make 
it a subdev node or

tie it into the init/reset sequence of remoteproc subsytem.


>

Re: [PATCH v1 2/8] remoteproc: qcom: probe all child devices

[Dmitry Baryshkov]

On Tue, Jan 27, 2026 at 09:42:10PM +0530, Gaurav Kohli wrote:
> 
> On 1/24/2026 12:33 AM, Dmitry Baryshkov wrote:
> > On Fri, Jan 23, 2026 at 07:23:39PM +0530, Gaurav Kohli wrote:
> > > On 1/8/2026 12:37 PM, Gaurav Kohli wrote:
> > > > On 1/3/2026 8:26 PM, Bjorn Andersson wrote:
> > > > > On Tue, Dec 23, 2025 at 06:02:21PM +0530, Gaurav Kohli wrote:
> > > > > > From: Casey Connolly <casey.connolly@linaro.org>
> > > > > > 
> > > > > > Generalise the qcom,bam-dmux child node support by probing all
> > > > > > remoteproc children with of_platform_populate(). This will be used to
> > > > > > enable support for devices which are best represented as
> > > > > > subnodes of the
> > > > > > remoteproc, such as those representing QMI clients.
> > > > > Please flip this around, start with the description of the problem
> > > > > you're trying to solve.
> > > > > 
> > > > > > Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
> > > > > This must have your signed-off-by, where you certifies the origin of
> > > > > this patch.
> > > > > 
> > > > > > ---
> > > > > >    drivers/remoteproc/qcom_q6v5.c     | 4 ++++
> > > > > >    drivers/remoteproc/qcom_q6v5_mss.c | 8 --------
> > > > > >    2 files changed, 4 insertions(+), 8 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/remoteproc/qcom_q6v5.c
> > > > > > b/drivers/remoteproc/qcom_q6v5.c
> > > > > > index 58d5b85e58cd..a02839c7ed8c 100644
> > > > > > --- a/drivers/remoteproc/qcom_q6v5.c
> > > > > > +++ b/drivers/remoteproc/qcom_q6v5.c
> > > > > > @@ -6,6 +6,7 @@
> > > > > >     * Copyright (C) 2014 Sony Mobile Communications AB
> > > > > >     * Copyright (c) 2012-2013, The Linux Foundation. All rights
> > > > > > reserved.
> > > > > >     */
> > > > > > +#include <linux/of_platform.h>
> > > > > >    #include <linux/kernel.h>
> > > > > >    #include <linux/platform_device.h>
> > > > > >    #include <linux/interconnect.h>
> > > > > > @@ -351,6 +352,8 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5,
> > > > > > struct platform_device *pdev,
> > > > > >            return dev_err_probe(&pdev->dev, PTR_ERR(q6v5->path),
> > > > > >                         "failed to acquire interconnect path\n");
> > > > > >    +    of_platform_populate(q6v5->dev->of_node, NULL, NULL, q6v5->dev);
> > > > > There are other child nodes here, in particular the GLINK and SMD edges.
> > > > > Do we really want platform_devices registered for them?
> > > > > 
> > > > > Regards,
> > > > > Bjorn
> > > > 
> > > > thanks for pointing this, can you please suggest the right approach.
> > > > 
> > > > This should not impact glink, as that is registering as rproc sub node,
> > > > And we need rproc cooling as child node
> > > > 
> > > > of remote proc subsytem to create probe dependency only.
> > > > 
> > > > 
> > > > Can we do platform populate for specific child, would that be right
> > > > approach. or we should create rproc cooling as independent of parent ?
> > > > 
> > > HI Bjorn,
> > > 
> > > I’d like to highlight the impact and details of placement of remoteproc
> > > cooling dt node:
> > > 
> > > 
> > > ->As a child of the remote proc subsystem node:
> > >      In this configuration, the cooling device will only be probed once the
> > > corresponding remote proc subsystem itself is probed.
> > > 
> > > ->Outside the remote proc subsystem, may be part of soc node:
> > >      In this setup, the cooling device will be probed independently. It will
> > > wait until the remoteproc subsystem is brought up
> > >      before completing cooling registration.
> > >      The drawback here is that if the parent remoteproc subsystem is
> > > disabled, the cooling device will still undergo an
> > >      unnecessary probe, even though it cannot be registered.
> > Bjorns question was different. It wasn't about pushing cooling device
> > outside of the remoteproc node. It is about not registering the devices.
> > 
> > Can we follow the approach outlined by qcom_add_smd_subdev() /
> > qcom_add_glink_subdev()?
> 
> 
> Hi Dmitry,
> 
> Thanks for the review. Since the remoteproc cooling is a QMI-based driver,
> it will receive the
> subsystem up notification directly. Therefore, there’s no need to make it a
> subdev node or
> tie it into the init/reset sequence of remoteproc subsytem.

But you've added a subnode for it (and we are discussing exactly
of_platform_populate()) call. So, you are tying it to the remoteproc
device lifecycle instead of the remoteproc subsys, which seems strange
to me. There is no cooling device if the DSP is not running.

-- 
With best wishes
Dmitry

Re: [PATCH v1 2/8] remoteproc: qcom: probe all child devices

[Gaurav Kohli]

On 1/27/2026 10:11 PM, Dmitry Baryshkov wrote:
> On Tue, Jan 27, 2026 at 09:42:10PM +0530, Gaurav Kohli wrote:
>> On 1/24/2026 12:33 AM, Dmitry Baryshkov wrote:
>>> On Fri, Jan 23, 2026 at 07:23:39PM +0530, Gaurav Kohli wrote:
>>>> On 1/8/2026 12:37 PM, Gaurav Kohli wrote:
>>>>> On 1/3/2026 8:26 PM, Bjorn Andersson wrote:
>>>>>> On Tue, Dec 23, 2025 at 06:02:21PM +0530, Gaurav Kohli wrote:
>>>>>>> From: Casey Connolly <casey.connolly@linaro.org>
>>>>>>>
>>>>>>> Generalise the qcom,bam-dmux child node support by probing all
>>>>>>> remoteproc children with of_platform_populate(). This will be used to
>>>>>>> enable support for devices which are best represented as
>>>>>>> subnodes of the
>>>>>>> remoteproc, such as those representing QMI clients.
>>>>>> Please flip this around, start with the description of the problem
>>>>>> you're trying to solve.
>>>>>>
>>>>>>> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
>>>>>> This must have your signed-off-by, where you certifies the origin of
>>>>>> this patch.
>>>>>>
>>>>>>> ---
>>>>>>>     drivers/remoteproc/qcom_q6v5.c     | 4 ++++
>>>>>>>     drivers/remoteproc/qcom_q6v5_mss.c | 8 --------
>>>>>>>     2 files changed, 4 insertions(+), 8 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/remoteproc/qcom_q6v5.c
>>>>>>> b/drivers/remoteproc/qcom_q6v5.c
>>>>>>> index 58d5b85e58cd..a02839c7ed8c 100644
>>>>>>> --- a/drivers/remoteproc/qcom_q6v5.c
>>>>>>> +++ b/drivers/remoteproc/qcom_q6v5.c
>>>>>>> @@ -6,6 +6,7 @@
>>>>>>>      * Copyright (C) 2014 Sony Mobile Communications AB
>>>>>>>      * Copyright (c) 2012-2013, The Linux Foundation. All rights
>>>>>>> reserved.
>>>>>>>      */
>>>>>>> +#include <linux/of_platform.h>
>>>>>>>     #include <linux/kernel.h>
>>>>>>>     #include <linux/platform_device.h>
>>>>>>>     #include <linux/interconnect.h>
>>>>>>> @@ -351,6 +352,8 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5,
>>>>>>> struct platform_device *pdev,
>>>>>>>             return dev_err_probe(&pdev->dev, PTR_ERR(q6v5->path),
>>>>>>>                          "failed to acquire interconnect path\n");
>>>>>>>     +    of_platform_populate(q6v5->dev->of_node, NULL, NULL, q6v5->dev);
>>>>>> There are other child nodes here, in particular the GLINK and SMD edges.
>>>>>> Do we really want platform_devices registered for them?
>>>>>>
>>>>>> Regards,
>>>>>> Bjorn
>>>>> thanks for pointing this, can you please suggest the right approach.
>>>>>
>>>>> This should not impact glink, as that is registering as rproc sub node,
>>>>> And we need rproc cooling as child node
>>>>>
>>>>> of remote proc subsytem to create probe dependency only.
>>>>>
>>>>>
>>>>> Can we do platform populate for specific child, would that be right
>>>>> approach. or we should create rproc cooling as independent of parent ?
>>>>>
>>>> HI Bjorn,
>>>>
>>>> I’d like to highlight the impact and details of placement of remoteproc
>>>> cooling dt node:
>>>>
>>>>
>>>> ->As a child of the remote proc subsystem node:
>>>>       In this configuration, the cooling device will only be probed once the
>>>> corresponding remote proc subsystem itself is probed.
>>>>
>>>> ->Outside the remote proc subsystem, may be part of soc node:
>>>>       In this setup, the cooling device will be probed independently. It will
>>>> wait until the remoteproc subsystem is brought up
>>>>       before completing cooling registration.
>>>>       The drawback here is that if the parent remoteproc subsystem is
>>>> disabled, the cooling device will still undergo an
>>>>       unnecessary probe, even though it cannot be registered.
>>> Bjorns question was different. It wasn't about pushing cooling device
>>> outside of the remoteproc node. It is about not registering the devices.
>>>
>>> Can we follow the approach outlined by qcom_add_smd_subdev() /
>>> qcom_add_glink_subdev()?
>>
>> Hi Dmitry,
>>
>> Thanks for the review. Since the remoteproc cooling is a QMI-based driver,
>> it will receive the
>> subsystem up notification directly. Therefore, there’s no need to make it a
>> subdev node or
>> tie it into the init/reset sequence of remoteproc subsytem.
> But you've added a subnode for it (and we are discussing exactly
> of_platform_populate()) call. So, you are tying it to the remoteproc
> device lifecycle instead of the remoteproc subsys, which seems strange
> to me. There is no cooling device if the DSP is not running.


For the cooling feature, we don’t need to define it as a subnode. The 
cooling subsystem becomes relevant only
after the remote subsystem is up, at which point it will receive 
add/delete notifications from the QMI server.


If child nodes must be modeled as subnodes for rproc, we can move the 
CDSP TMD out of the remoteproc and add in soc.
Is there currently a way for the remoteproc core layer to call 
of_platform_populate() without requiring a subnode?

Re: [PATCH v1 2/8] remoteproc: qcom: probe all child devices

[Konrad Dybcio]

On 1/28/26 10:39 AM, Gaurav Kohli wrote:
> 
> On 1/27/2026 10:11 PM, Dmitry Baryshkov wrote:
>> On Tue, Jan 27, 2026 at 09:42:10PM +0530, Gaurav Kohli wrote:
>>> On 1/24/2026 12:33 AM, Dmitry Baryshkov wrote:
>>>> On Fri, Jan 23, 2026 at 07:23:39PM +0530, Gaurav Kohli wrote:
>>>>> On 1/8/2026 12:37 PM, Gaurav Kohli wrote:
>>>>>> On 1/3/2026 8:26 PM, Bjorn Andersson wrote:
>>>>>>> On Tue, Dec 23, 2025 at 06:02:21PM +0530, Gaurav Kohli wrote:
>>>>>>>> From: Casey Connolly <casey.connolly@linaro.org>
>>>>>>>>
>>>>>>>> Generalise the qcom,bam-dmux child node support by probing all
>>>>>>>> remoteproc children with of_platform_populate(). This will be used to
>>>>>>>> enable support for devices which are best represented as
>>>>>>>> subnodes of the
>>>>>>>> remoteproc, such as those representing QMI clients.
>>>>>>> Please flip this around, start with the description of the problem
>>>>>>> you're trying to solve.
>>>>>>>
>>>>>>>> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
>>>>>>> This must have your signed-off-by, where you certifies the origin of
>>>>>>> this patch.
>>>>>>>
>>>>>>>> ---
>>>>>>>>     drivers/remoteproc/qcom_q6v5.c     | 4 ++++
>>>>>>>>     drivers/remoteproc/qcom_q6v5_mss.c | 8 --------
>>>>>>>>     2 files changed, 4 insertions(+), 8 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/remoteproc/qcom_q6v5.c
>>>>>>>> b/drivers/remoteproc/qcom_q6v5.c
>>>>>>>> index 58d5b85e58cd..a02839c7ed8c 100644
>>>>>>>> --- a/drivers/remoteproc/qcom_q6v5.c
>>>>>>>> +++ b/drivers/remoteproc/qcom_q6v5.c
>>>>>>>> @@ -6,6 +6,7 @@
>>>>>>>>      * Copyright (C) 2014 Sony Mobile Communications AB
>>>>>>>>      * Copyright (c) 2012-2013, The Linux Foundation. All rights
>>>>>>>> reserved.
>>>>>>>>      */
>>>>>>>> +#include <linux/of_platform.h>
>>>>>>>>     #include <linux/kernel.h>
>>>>>>>>     #include <linux/platform_device.h>
>>>>>>>>     #include <linux/interconnect.h>
>>>>>>>> @@ -351,6 +352,8 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5,
>>>>>>>> struct platform_device *pdev,
>>>>>>>>             return dev_err_probe(&pdev->dev, PTR_ERR(q6v5->path),
>>>>>>>>                          "failed to acquire interconnect path\n");
>>>>>>>>     +    of_platform_populate(q6v5->dev->of_node, NULL, NULL, q6v5->dev);
>>>>>>> There are other child nodes here, in particular the GLINK and SMD edges.
>>>>>>> Do we really want platform_devices registered for them?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Bjorn
>>>>>> thanks for pointing this, can you please suggest the right approach.
>>>>>>
>>>>>> This should not impact glink, as that is registering as rproc sub node,
>>>>>> And we need rproc cooling as child node
>>>>>>
>>>>>> of remote proc subsytem to create probe dependency only.
>>>>>>
>>>>>>
>>>>>> Can we do platform populate for specific child, would that be right
>>>>>> approach. or we should create rproc cooling as independent of parent ?
>>>>>>
>>>>> HI Bjorn,
>>>>>
>>>>> I’d like to highlight the impact and details of placement of remoteproc
>>>>> cooling dt node:
>>>>>
>>>>>
>>>>> ->As a child of the remote proc subsystem node:
>>>>>       In this configuration, the cooling device will only be probed once the
>>>>> corresponding remote proc subsystem itself is probed.
>>>>>
>>>>> ->Outside the remote proc subsystem, may be part of soc node:
>>>>>       In this setup, the cooling device will be probed independently. It will
>>>>> wait until the remoteproc subsystem is brought up
>>>>>       before completing cooling registration.
>>>>>       The drawback here is that if the parent remoteproc subsystem is
>>>>> disabled, the cooling device will still undergo an
>>>>>       unnecessary probe, even though it cannot be registered.
>>>> Bjorns question was different. It wasn't about pushing cooling device
>>>> outside of the remoteproc node. It is about not registering the devices.
>>>>
>>>> Can we follow the approach outlined by qcom_add_smd_subdev() /
>>>> qcom_add_glink_subdev()?
>>>
>>> Hi Dmitry,
>>>
>>> Thanks for the review. Since the remoteproc cooling is a QMI-based driver,
>>> it will receive the
>>> subsystem up notification directly. Therefore, there’s no need to make it a
>>> subdev node or
>>> tie it into the init/reset sequence of remoteproc subsytem.
>> But you've added a subnode for it (and we are discussing exactly
>> of_platform_populate()) call. So, you are tying it to the remoteproc
>> device lifecycle instead of the remoteproc subsys, which seems strange
>> to me. There is no cooling device if the DSP is not running.
> 
> 
> For the cooling feature, we don’t need to define it as a subnode. The cooling subsystem becomes relevant only
> after the remote subsystem is up, at which point it will receive add/delete notifications from the QMI server.
> 
> 
> If child nodes must be modeled as subnodes for rproc, we can move the CDSP TMD out of the remoteproc and add in soc.
> Is there currently a way for the remoteproc core layer to call of_platform_populate() without requiring a subnode?

I think the question is "why can't you register the remoteproc device
as a cooling_device, with perhaps #cooling-cells = <1>; instead of
any form of children?"

Konrad

Re: [PATCH v1 2/8] remoteproc: qcom: probe all child devices

[Gaurav Kohli]

On 1/28/2026 3:15 PM, Konrad Dybcio wrote:
> On 1/28/26 10:39 AM, Gaurav Kohli wrote:
>> On 1/27/2026 10:11 PM, Dmitry Baryshkov wrote:
>>> On Tue, Jan 27, 2026 at 09:42:10PM +0530, Gaurav Kohli wrote:
>>>> On 1/24/2026 12:33 AM, Dmitry Baryshkov wrote:
>>>>> On Fri, Jan 23, 2026 at 07:23:39PM +0530, Gaurav Kohli wrote:
>>>>>> On 1/8/2026 12:37 PM, Gaurav Kohli wrote:
>>>>>>> On 1/3/2026 8:26 PM, Bjorn Andersson wrote:
>>>>>>>> On Tue, Dec 23, 2025 at 06:02:21PM +0530, Gaurav Kohli wrote:
>>>>>>>>> From: Casey Connolly <casey.connolly@linaro.org>
>>>>>>>>>
>>>>>>>>> Generalise the qcom,bam-dmux child node support by probing all
>>>>>>>>> remoteproc children with of_platform_populate(). This will be used to
>>>>>>>>> enable support for devices which are best represented as
>>>>>>>>> subnodes of the
>>>>>>>>> remoteproc, such as those representing QMI clients.
>>>>>>>> Please flip this around, start with the description of the problem
>>>>>>>> you're trying to solve.
>>>>>>>>
>>>>>>>>> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
>>>>>>>> This must have your signed-off-by, where you certifies the origin of
>>>>>>>> this patch.
>>>>>>>>
>>>>>>>>> ---
>>>>>>>>>      drivers/remoteproc/qcom_q6v5.c     | 4 ++++
>>>>>>>>>      drivers/remoteproc/qcom_q6v5_mss.c | 8 --------
>>>>>>>>>      2 files changed, 4 insertions(+), 8 deletions(-)
>>>>>>>>>
>>>>>>>>> diff --git a/drivers/remoteproc/qcom_q6v5.c
>>>>>>>>> b/drivers/remoteproc/qcom_q6v5.c
>>>>>>>>> index 58d5b85e58cd..a02839c7ed8c 100644
>>>>>>>>> --- a/drivers/remoteproc/qcom_q6v5.c
>>>>>>>>> +++ b/drivers/remoteproc/qcom_q6v5.c
>>>>>>>>> @@ -6,6 +6,7 @@
>>>>>>>>>       * Copyright (C) 2014 Sony Mobile Communications AB
>>>>>>>>>       * Copyright (c) 2012-2013, The Linux Foundation. All rights
>>>>>>>>> reserved.
>>>>>>>>>       */
>>>>>>>>> +#include <linux/of_platform.h>
>>>>>>>>>      #include <linux/kernel.h>
>>>>>>>>>      #include <linux/platform_device.h>
>>>>>>>>>      #include <linux/interconnect.h>
>>>>>>>>> @@ -351,6 +352,8 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5,
>>>>>>>>> struct platform_device *pdev,
>>>>>>>>>              return dev_err_probe(&pdev->dev, PTR_ERR(q6v5->path),
>>>>>>>>>                           "failed to acquire interconnect path\n");
>>>>>>>>>      +    of_platform_populate(q6v5->dev->of_node, NULL, NULL, q6v5->dev);
>>>>>>>> There are other child nodes here, in particular the GLINK and SMD edges.
>>>>>>>> Do we really want platform_devices registered for them?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Bjorn
>>>>>>> thanks for pointing this, can you please suggest the right approach.
>>>>>>>
>>>>>>> This should not impact glink, as that is registering as rproc sub node,
>>>>>>> And we need rproc cooling as child node
>>>>>>>
>>>>>>> of remote proc subsytem to create probe dependency only.
>>>>>>>
>>>>>>>
>>>>>>> Can we do platform populate for specific child, would that be right
>>>>>>> approach. or we should create rproc cooling as independent of parent ?
>>>>>>>
>>>>>> HI Bjorn,
>>>>>>
>>>>>> I’d like to highlight the impact and details of placement of remoteproc
>>>>>> cooling dt node:
>>>>>>
>>>>>>
>>>>>> ->As a child of the remote proc subsystem node:
>>>>>>        In this configuration, the cooling device will only be probed once the
>>>>>> corresponding remote proc subsystem itself is probed.
>>>>>>
>>>>>> ->Outside the remote proc subsystem, may be part of soc node:
>>>>>>        In this setup, the cooling device will be probed independently. It will
>>>>>> wait until the remoteproc subsystem is brought up
>>>>>>        before completing cooling registration.
>>>>>>        The drawback here is that if the parent remoteproc subsystem is
>>>>>> disabled, the cooling device will still undergo an
>>>>>>        unnecessary probe, even though it cannot be registered.
>>>>> Bjorns question was different. It wasn't about pushing cooling device
>>>>> outside of the remoteproc node. It is about not registering the devices.
>>>>>
>>>>> Can we follow the approach outlined by qcom_add_smd_subdev() /
>>>>> qcom_add_glink_subdev()?
>>>> Hi Dmitry,
>>>>
>>>> Thanks for the review. Since the remoteproc cooling is a QMI-based driver,
>>>> it will receive the
>>>> subsystem up notification directly. Therefore, there’s no need to make it a
>>>> subdev node or
>>>> tie it into the init/reset sequence of remoteproc subsytem.
>>> But you've added a subnode for it (and we are discussing exactly
>>> of_platform_populate()) call. So, you are tying it to the remoteproc
>>> device lifecycle instead of the remoteproc subsys, which seems strange
>>> to me. There is no cooling device if the DSP is not running.
>>
>> For the cooling feature, we don’t need to define it as a subnode. The cooling subsystem becomes relevant only
>> after the remote subsystem is up, at which point it will receive add/delete notifications from the QMI server.
>>
>>
>> If child nodes must be modeled as subnodes for rproc, we can move the CDSP TMD out of the remoteproc and add in soc.
>> Is there currently a way for the remoteproc core layer to call of_platform_populate() without requiring a subnode?
> I think the question is "why can't you register the remoteproc device
> as a cooling_device, with perhaps #cooling-cells = <1>; instead of
> any form of children?"
>
> Konrad


thanks Konrad, for the review.

As each subsystem can expose multiple thermal mitigation devices via the 
remoteproc TMD service, so need to define child node.

Re: [PATCH v1 2/8] remoteproc: qcom: probe all child devices

[Konrad Dybcio]

On 1/30/26 8:03 AM, Gaurav Kohli wrote:
> 
> On 1/28/2026 3:15 PM, Konrad Dybcio wrote:
>> On 1/28/26 10:39 AM, Gaurav Kohli wrote:
>>> On 1/27/2026 10:11 PM, Dmitry Baryshkov wrote:
>>>> On Tue, Jan 27, 2026 at 09:42:10PM +0530, Gaurav Kohli wrote:
>>>>> On 1/24/2026 12:33 AM, Dmitry Baryshkov wrote:
>>>>>> On Fri, Jan 23, 2026 at 07:23:39PM +0530, Gaurav Kohli wrote:
>>>>>>> On 1/8/2026 12:37 PM, Gaurav Kohli wrote:
>>>>>>>> On 1/3/2026 8:26 PM, Bjorn Andersson wrote:
>>>>>>>>> On Tue, Dec 23, 2025 at 06:02:21PM +0530, Gaurav Kohli wrote:
>>>>>>>>>> From: Casey Connolly <casey.connolly@linaro.org>
>>>>>>>>>>
>>>>>>>>>> Generalise the qcom,bam-dmux child node support by probing all
>>>>>>>>>> remoteproc children with of_platform_populate(). This will be used to
>>>>>>>>>> enable support for devices which are best represented as
>>>>>>>>>> subnodes of the
>>>>>>>>>> remoteproc, such as those representing QMI clients.
>>>>>>>>> Please flip this around, start with the description of the problem
>>>>>>>>> you're trying to solve.
>>>>>>>>>
>>>>>>>>>> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
>>>>>>>>> This must have your signed-off-by, where you certifies the origin of
>>>>>>>>> this patch.
>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>>      drivers/remoteproc/qcom_q6v5.c     | 4 ++++
>>>>>>>>>>      drivers/remoteproc/qcom_q6v5_mss.c | 8 --------
>>>>>>>>>>      2 files changed, 4 insertions(+), 8 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/remoteproc/qcom_q6v5.c
>>>>>>>>>> b/drivers/remoteproc/qcom_q6v5.c
>>>>>>>>>> index 58d5b85e58cd..a02839c7ed8c 100644
>>>>>>>>>> --- a/drivers/remoteproc/qcom_q6v5.c
>>>>>>>>>> +++ b/drivers/remoteproc/qcom_q6v5.c
>>>>>>>>>> @@ -6,6 +6,7 @@
>>>>>>>>>>       * Copyright (C) 2014 Sony Mobile Communications AB
>>>>>>>>>>       * Copyright (c) 2012-2013, The Linux Foundation. All rights
>>>>>>>>>> reserved.
>>>>>>>>>>       */
>>>>>>>>>> +#include <linux/of_platform.h>
>>>>>>>>>>      #include <linux/kernel.h>
>>>>>>>>>>      #include <linux/platform_device.h>
>>>>>>>>>>      #include <linux/interconnect.h>
>>>>>>>>>> @@ -351,6 +352,8 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5,
>>>>>>>>>> struct platform_device *pdev,
>>>>>>>>>>              return dev_err_probe(&pdev->dev, PTR_ERR(q6v5->path),
>>>>>>>>>>                           "failed to acquire interconnect path\n");
>>>>>>>>>>      +    of_platform_populate(q6v5->dev->of_node, NULL, NULL, q6v5->dev);
>>>>>>>>> There are other child nodes here, in particular the GLINK and SMD edges.
>>>>>>>>> Do we really want platform_devices registered for them?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Bjorn
>>>>>>>> thanks for pointing this, can you please suggest the right approach.
>>>>>>>>
>>>>>>>> This should not impact glink, as that is registering as rproc sub node,
>>>>>>>> And we need rproc cooling as child node
>>>>>>>>
>>>>>>>> of remote proc subsytem to create probe dependency only.
>>>>>>>>
>>>>>>>>
>>>>>>>> Can we do platform populate for specific child, would that be right
>>>>>>>> approach. or we should create rproc cooling as independent of parent ?
>>>>>>>>
>>>>>>> HI Bjorn,
>>>>>>>
>>>>>>> I’d like to highlight the impact and details of placement of remoteproc
>>>>>>> cooling dt node:
>>>>>>>
>>>>>>>
>>>>>>> ->As a child of the remote proc subsystem node:
>>>>>>>        In this configuration, the cooling device will only be probed once the
>>>>>>> corresponding remote proc subsystem itself is probed.
>>>>>>>
>>>>>>> ->Outside the remote proc subsystem, may be part of soc node:
>>>>>>>        In this setup, the cooling device will be probed independently. It will
>>>>>>> wait until the remoteproc subsystem is brought up
>>>>>>>        before completing cooling registration.
>>>>>>>        The drawback here is that if the parent remoteproc subsystem is
>>>>>>> disabled, the cooling device will still undergo an
>>>>>>>        unnecessary probe, even though it cannot be registered.
>>>>>> Bjorns question was different. It wasn't about pushing cooling device
>>>>>> outside of the remoteproc node. It is about not registering the devices.
>>>>>>
>>>>>> Can we follow the approach outlined by qcom_add_smd_subdev() /
>>>>>> qcom_add_glink_subdev()?
>>>>> Hi Dmitry,
>>>>>
>>>>> Thanks for the review. Since the remoteproc cooling is a QMI-based driver,
>>>>> it will receive the
>>>>> subsystem up notification directly. Therefore, there’s no need to make it a
>>>>> subdev node or
>>>>> tie it into the init/reset sequence of remoteproc subsytem.
>>>> But you've added a subnode for it (and we are discussing exactly
>>>> of_platform_populate()) call. So, you are tying it to the remoteproc
>>>> device lifecycle instead of the remoteproc subsys, which seems strange
>>>> to me. There is no cooling device if the DSP is not running.
>>>
>>> For the cooling feature, we don’t need to define it as a subnode. The cooling subsystem becomes relevant only
>>> after the remote subsystem is up, at which point it will receive add/delete notifications from the QMI server.
>>>
>>>
>>> If child nodes must be modeled as subnodes for rproc, we can move the CDSP TMD out of the remoteproc and add in soc.
>>> Is there currently a way for the remoteproc core layer to call of_platform_populate() without requiring a subnode?
>> I think the question is "why can't you register the remoteproc device
>> as a cooling_device, with perhaps #cooling-cells = <1>; instead of
>> any form of children?"
>>
>> Konrad
> 
> 
> thanks Konrad, for the review.
> 
> As each subsystem can expose multiple thermal mitigation devices via the remoteproc TMD service, so need to define child node.

I think you're stuck in an XY problem - you keep insisting that adding
a subnode is your end goal, while you really want to achieve being able
to register multiple cooling devices. Or at least that's how I read your
messages since you happen not to give any explanation as to why it's
actually necessary.

In my previous message, I forgot that cells for cooling devices actually
represent the minimum and maximum cooling state allowed. But since the
API is just part of the kernel, there's nothing preventing us from
evolving it.

Currently, we have:

Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml

properties:
  "#cooling-cells":
    description:
      Must be 2, in order to specify minimum and maximum cooling state used in
      the cooling-maps reference. The first cell is the minimum cooling state
      and the second cell is the maximum cooling state requested.
    const: 2

But I think it would be perfectly fine to suggest a change such that
if cells > 2, the last two cells keep the current behavior and the former
ones let you index into a cooling device exposed through a single OF node

e.g.

rproc_xyz: remoteproc {
	compatible = "qcom,rproc-xyz";

	...

	#cooling-device-cells = <3>;
};

...

thermal-zones {
	super-rproc-therm-a {
		thermal-sensors = <&rproc_xyz RPROC_XYZ_COOLING_A
				   THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;

		trips { ... } ;
	};

	super-rproc-therm-b {
		thermal-sensors = <&rproc_xyz RPROC_XYZ_COOLING_B
				   THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;

		trips { ... } ;
	};
};

This would be resolved by allowing drivers to register an .of_xlate-type
function which would take the RPROC_XYZ_COOLING_n argument and e.g. use
it as an index into struct thermal_cooling_device cdev[]; within the
driver struct.

Konrad

Re: [PATCH v1 2/8] remoteproc: qcom: probe all child devices

[Dmitry Baryshkov]

On Fri, Jan 30, 2026 at 10:13:06AM +0100, Konrad Dybcio wrote:
> On 1/30/26 8:03 AM, Gaurav Kohli wrote:
> > 
> > On 1/28/2026 3:15 PM, Konrad Dybcio wrote:
> >> On 1/28/26 10:39 AM, Gaurav Kohli wrote:
> >>> On 1/27/2026 10:11 PM, Dmitry Baryshkov wrote:
> >>>> On Tue, Jan 27, 2026 at 09:42:10PM +0530, Gaurav Kohli wrote:
> >>>>> On 1/24/2026 12:33 AM, Dmitry Baryshkov wrote:
> >>>>>> On Fri, Jan 23, 2026 at 07:23:39PM +0530, Gaurav Kohli wrote:
> >>>>>>> On 1/8/2026 12:37 PM, Gaurav Kohli wrote:
> >>>>>>>> On 1/3/2026 8:26 PM, Bjorn Andersson wrote:
> >>>>>>>>> On Tue, Dec 23, 2025 at 06:02:21PM +0530, Gaurav Kohli wrote:
> >>>>>>>>>> From: Casey Connolly <casey.connolly@linaro.org>
> >>>>>>>>>>
> >>>>>>>>>> Generalise the qcom,bam-dmux child node support by probing all
> >>>>>>>>>> remoteproc children with of_platform_populate(). This will be used to
> >>>>>>>>>> enable support for devices which are best represented as
> >>>>>>>>>> subnodes of the
> >>>>>>>>>> remoteproc, such as those representing QMI clients.
> >>>>>>>>> Please flip this around, start with the description of the problem
> >>>>>>>>> you're trying to solve.
> >>>>>>>>>
> >>>>>>>>>> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
> >>>>>>>>> This must have your signed-off-by, where you certifies the origin of
> >>>>>>>>> this patch.
> >>>>>>>>>
> >>>>>>>>>> ---
> >>>>>>>>>>      drivers/remoteproc/qcom_q6v5.c     | 4 ++++
> >>>>>>>>>>      drivers/remoteproc/qcom_q6v5_mss.c | 8 --------
> >>>>>>>>>>      2 files changed, 4 insertions(+), 8 deletions(-)
> >>>>>>>>>>
> >>>>>>>>>> diff --git a/drivers/remoteproc/qcom_q6v5.c
> >>>>>>>>>> b/drivers/remoteproc/qcom_q6v5.c
> >>>>>>>>>> index 58d5b85e58cd..a02839c7ed8c 100644
> >>>>>>>>>> --- a/drivers/remoteproc/qcom_q6v5.c
> >>>>>>>>>> +++ b/drivers/remoteproc/qcom_q6v5.c
> >>>>>>>>>> @@ -6,6 +6,7 @@
> >>>>>>>>>>       * Copyright (C) 2014 Sony Mobile Communications AB
> >>>>>>>>>>       * Copyright (c) 2012-2013, The Linux Foundation. All rights
> >>>>>>>>>> reserved.
> >>>>>>>>>>       */
> >>>>>>>>>> +#include <linux/of_platform.h>
> >>>>>>>>>>      #include <linux/kernel.h>
> >>>>>>>>>>      #include <linux/platform_device.h>
> >>>>>>>>>>      #include <linux/interconnect.h>
> >>>>>>>>>> @@ -351,6 +352,8 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5,
> >>>>>>>>>> struct platform_device *pdev,
> >>>>>>>>>>              return dev_err_probe(&pdev->dev, PTR_ERR(q6v5->path),
> >>>>>>>>>>                           "failed to acquire interconnect path\n");
> >>>>>>>>>>      +    of_platform_populate(q6v5->dev->of_node, NULL, NULL, q6v5->dev);
> >>>>>>>>> There are other child nodes here, in particular the GLINK and SMD edges.
> >>>>>>>>> Do we really want platform_devices registered for them?
> >>>>>>>>>
> >>>>>>>>> Regards,
> >>>>>>>>> Bjorn
> >>>>>>>> thanks for pointing this, can you please suggest the right approach.
> >>>>>>>>
> >>>>>>>> This should not impact glink, as that is registering as rproc sub node,
> >>>>>>>> And we need rproc cooling as child node
> >>>>>>>>
> >>>>>>>> of remote proc subsytem to create probe dependency only.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Can we do platform populate for specific child, would that be right
> >>>>>>>> approach. or we should create rproc cooling as independent of parent ?
> >>>>>>>>
> >>>>>>> HI Bjorn,
> >>>>>>>
> >>>>>>> I’d like to highlight the impact and details of placement of remoteproc
> >>>>>>> cooling dt node:
> >>>>>>>
> >>>>>>>
> >>>>>>> ->As a child of the remote proc subsystem node:
> >>>>>>>        In this configuration, the cooling device will only be probed once the
> >>>>>>> corresponding remote proc subsystem itself is probed.
> >>>>>>>
> >>>>>>> ->Outside the remote proc subsystem, may be part of soc node:
> >>>>>>>        In this setup, the cooling device will be probed independently. It will
> >>>>>>> wait until the remoteproc subsystem is brought up
> >>>>>>>        before completing cooling registration.
> >>>>>>>        The drawback here is that if the parent remoteproc subsystem is
> >>>>>>> disabled, the cooling device will still undergo an
> >>>>>>>        unnecessary probe, even though it cannot be registered.
> >>>>>> Bjorns question was different. It wasn't about pushing cooling device
> >>>>>> outside of the remoteproc node. It is about not registering the devices.
> >>>>>>
> >>>>>> Can we follow the approach outlined by qcom_add_smd_subdev() /
> >>>>>> qcom_add_glink_subdev()?
> >>>>> Hi Dmitry,
> >>>>>
> >>>>> Thanks for the review. Since the remoteproc cooling is a QMI-based driver,
> >>>>> it will receive the
> >>>>> subsystem up notification directly. Therefore, there’s no need to make it a
> >>>>> subdev node or
> >>>>> tie it into the init/reset sequence of remoteproc subsytem.
> >>>> But you've added a subnode for it (and we are discussing exactly
> >>>> of_platform_populate()) call. So, you are tying it to the remoteproc
> >>>> device lifecycle instead of the remoteproc subsys, which seems strange
> >>>> to me. There is no cooling device if the DSP is not running.
> >>>
> >>> For the cooling feature, we don’t need to define it as a subnode. The cooling subsystem becomes relevant only
> >>> after the remote subsystem is up, at which point it will receive add/delete notifications from the QMI server.
> >>>
> >>>
> >>> If child nodes must be modeled as subnodes for rproc, we can move the CDSP TMD out of the remoteproc and add in soc.
> >>> Is there currently a way for the remoteproc core layer to call of_platform_populate() without requiring a subnode?
> >> I think the question is "why can't you register the remoteproc device
> >> as a cooling_device, with perhaps #cooling-cells = <1>; instead of
> >> any form of children?"
> >>
> >> Konrad
> > 
> > 
> > thanks Konrad, for the review.
> > 
> > As each subsystem can expose multiple thermal mitigation devices via the remoteproc TMD service, so need to define child node.
> 
> I think you're stuck in an XY problem - you keep insisting that adding
> a subnode is your end goal, while you really want to achieve being able
> to register multiple cooling devices. Or at least that's how I read your
> messages since you happen not to give any explanation as to why it's
> actually necessary.
> 
> In my previous message, I forgot that cells for cooling devices actually
> represent the minimum and maximum cooling state allowed. But since the
> API is just part of the kernel, there's nothing preventing us from
> evolving it.
> 
> Currently, we have:
> 
> Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml
> 
> properties:
>   "#cooling-cells":
>     description:
>       Must be 2, in order to specify minimum and maximum cooling state used in
>       the cooling-maps reference. The first cell is the minimum cooling state
>       and the second cell is the maximum cooling state requested.
>     const: 2
> 
> But I think it would be perfectly fine to suggest a change such that
> if cells > 2, the last two cells keep the current behavior and the former
> ones let you index into a cooling device exposed through a single OF node

This might be a big change, which probably needs to be coordinated with
thermal and DT maintainers first.

> 
> e.g.
> 
> rproc_xyz: remoteproc {
> 	compatible = "qcom,rproc-xyz";
> 
> 	...
> 
> 	#cooling-device-cells = <3>;
> };

Which brings in another topic. In DT we have labels for different DT
children, which correspond to different handlers on the DSP side. For
the CDSP we see a "cdsp_sw" only. I think I've asked several times, but
didn't get an example of the device having more than one, just claims
that there might be more thane one TMD.

Do we need different cooling cells here? Or would it be enough to send
the same max state to all TMDs on the DSP side?

> 
> ...
> 
> thermal-zones {
> 	super-rproc-therm-a {
> 		thermal-sensors = <&rproc_xyz RPROC_XYZ_COOLING_A
> 				   THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> 
> 		trips { ... } ;
> 	};
> 
> 	super-rproc-therm-b {
> 		thermal-sensors = <&rproc_xyz RPROC_XYZ_COOLING_B
> 				   THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> 
> 		trips { ... } ;
> 	};
> };
> 
> This would be resolved by allowing drivers to register an .of_xlate-type
> function which would take the RPROC_XYZ_COOLING_n argument and e.g. use
> it as an index into struct thermal_cooling_device cdev[]; within the
> driver struct.



> 
> Konrad

-- 
With best wishes
Dmitry

Re: [PATCH v1 2/8] remoteproc: qcom: probe all child devices

[Gaurav Kohli]

On 1/31/2026 1:36 PM, Dmitry Baryshkov wrote:
> On Fri, Jan 30, 2026 at 10:13:06AM +0100, Konrad Dybcio wrote:
>> On 1/30/26 8:03 AM, Gaurav Kohli wrote:
>>>
>>> On 1/28/2026 3:15 PM, Konrad Dybcio wrote:
>>>> On 1/28/26 10:39 AM, Gaurav Kohli wrote:
>>>>> On 1/27/2026 10:11 PM, Dmitry Baryshkov wrote:
>>>>>> On Tue, Jan 27, 2026 at 09:42:10PM +0530, Gaurav Kohli wrote:
>>>>>>> On 1/24/2026 12:33 AM, Dmitry Baryshkov wrote:
>>>>>>>> On Fri, Jan 23, 2026 at 07:23:39PM +0530, Gaurav Kohli wrote:
>>>>>>>>> On 1/8/2026 12:37 PM, Gaurav Kohli wrote:
>>>>>>>>>> On 1/3/2026 8:26 PM, Bjorn Andersson wrote:
>>>>>>>>>>> On Tue, Dec 23, 2025 at 06:02:21PM +0530, Gaurav Kohli wrote:
>>>>>>>>>>>> From: Casey Connolly <casey.connolly@linaro.org>
>>>>>>>>>>>>
>>>>>>>>>>>> Generalise the qcom,bam-dmux child node support by probing all
>>>>>>>>>>>> remoteproc children with of_platform_populate(). This will be used to
>>>>>>>>>>>> enable support for devices which are best represented as
>>>>>>>>>>>> subnodes of the
>>>>>>>>>>>> remoteproc, such as those representing QMI clients.
>>>>>>>>>>> Please flip this around, start with the description of the problem
>>>>>>>>>>> you're trying to solve.
>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
>>>>>>>>>>> This must have your signed-off-by, where you certifies the origin of
>>>>>>>>>>> this patch.
>>>>>>>>>>>
>>>>>>>>>>>> ---
>>>>>>>>>>>>       drivers/remoteproc/qcom_q6v5.c     | 4 ++++
>>>>>>>>>>>>       drivers/remoteproc/qcom_q6v5_mss.c | 8 --------
>>>>>>>>>>>>       2 files changed, 4 insertions(+), 8 deletions(-)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/drivers/remoteproc/qcom_q6v5.c
>>>>>>>>>>>> b/drivers/remoteproc/qcom_q6v5.c
>>>>>>>>>>>> index 58d5b85e58cd..a02839c7ed8c 100644
>>>>>>>>>>>> --- a/drivers/remoteproc/qcom_q6v5.c
>>>>>>>>>>>> +++ b/drivers/remoteproc/qcom_q6v5.c
>>>>>>>>>>>> @@ -6,6 +6,7 @@
>>>>>>>>>>>>        * Copyright (C) 2014 Sony Mobile Communications AB
>>>>>>>>>>>>        * Copyright (c) 2012-2013, The Linux Foundation. All rights
>>>>>>>>>>>> reserved.
>>>>>>>>>>>>        */
>>>>>>>>>>>> +#include <linux/of_platform.h>
>>>>>>>>>>>>       #include <linux/kernel.h>
>>>>>>>>>>>>       #include <linux/platform_device.h>
>>>>>>>>>>>>       #include <linux/interconnect.h>
>>>>>>>>>>>> @@ -351,6 +352,8 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5,
>>>>>>>>>>>> struct platform_device *pdev,
>>>>>>>>>>>>               return dev_err_probe(&pdev->dev, PTR_ERR(q6v5->path),
>>>>>>>>>>>>                            "failed to acquire interconnect path\n");
>>>>>>>>>>>>       +    of_platform_populate(q6v5->dev->of_node, NULL, NULL, q6v5->dev);
>>>>>>>>>>> There are other child nodes here, in particular the GLINK and SMD edges.
>>>>>>>>>>> Do we really want platform_devices registered for them?
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Bjorn
>>>>>>>>>> thanks for pointing this, can you please suggest the right approach.
>>>>>>>>>>
>>>>>>>>>> This should not impact glink, as that is registering as rproc sub node,
>>>>>>>>>> And we need rproc cooling as child node
>>>>>>>>>>
>>>>>>>>>> of remote proc subsytem to create probe dependency only.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Can we do platform populate for specific child, would that be right
>>>>>>>>>> approach. or we should create rproc cooling as independent of parent ?
>>>>>>>>>>
>>>>>>>>> HI Bjorn,
>>>>>>>>>
>>>>>>>>> I’d like to highlight the impact and details of placement of remoteproc
>>>>>>>>> cooling dt node:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ->As a child of the remote proc subsystem node:
>>>>>>>>>         In this configuration, the cooling device will only be probed once the
>>>>>>>>> corresponding remote proc subsystem itself is probed.
>>>>>>>>>
>>>>>>>>> ->Outside the remote proc subsystem, may be part of soc node:
>>>>>>>>>         In this setup, the cooling device will be probed independently. It will
>>>>>>>>> wait until the remoteproc subsystem is brought up
>>>>>>>>>         before completing cooling registration.
>>>>>>>>>         The drawback here is that if the parent remoteproc subsystem is
>>>>>>>>> disabled, the cooling device will still undergo an
>>>>>>>>>         unnecessary probe, even though it cannot be registered.
>>>>>>>> Bjorns question was different. It wasn't about pushing cooling device
>>>>>>>> outside of the remoteproc node. It is about not registering the devices.
>>>>>>>>
>>>>>>>> Can we follow the approach outlined by qcom_add_smd_subdev() /
>>>>>>>> qcom_add_glink_subdev()?
>>>>>>> Hi Dmitry,
>>>>>>>
>>>>>>> Thanks for the review. Since the remoteproc cooling is a QMI-based driver,
>>>>>>> it will receive the
>>>>>>> subsystem up notification directly. Therefore, there’s no need to make it a
>>>>>>> subdev node or
>>>>>>> tie it into the init/reset sequence of remoteproc subsytem.
>>>>>> But you've added a subnode for it (and we are discussing exactly
>>>>>> of_platform_populate()) call. So, you are tying it to the remoteproc
>>>>>> device lifecycle instead of the remoteproc subsys, which seems strange
>>>>>> to me. There is no cooling device if the DSP is not running.
>>>>>
>>>>> For the cooling feature, we don’t need to define it as a subnode. The cooling subsystem becomes relevant only
>>>>> after the remote subsystem is up, at which point it will receive add/delete notifications from the QMI server.
>>>>>
>>>>>
>>>>> If child nodes must be modeled as subnodes for rproc, we can move the CDSP TMD out of the remoteproc and add in soc.
>>>>> Is there currently a way for the remoteproc core layer to call of_platform_populate() without requiring a subnode?
>>>> I think the question is "why can't you register the remoteproc device
>>>> as a cooling_device, with perhaps #cooling-cells = <1>; instead of
>>>> any form of children?"
>>>>
>>>> Konrad
>>>
>>>
>>> thanks Konrad, for the review.
>>>
>>> As each subsystem can expose multiple thermal mitigation devices via the remoteproc TMD service, so need to define child node.
>>
>> I think you're stuck in an XY problem - you keep insisting that adding
>> a subnode is your end goal, while you really want to achieve being able
>> to register multiple cooling devices. Or at least that's how I read your
>> messages since you happen not to give any explanation as to why it's
>> actually necessary.
>>
>> In my previous message, I forgot that cells for cooling devices actually
>> represent the minimum and maximum cooling state allowed. But since the
>> API is just part of the kernel, there's nothing preventing us from
>> evolving it.
>>
>> Currently, we have:
>>
>> Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml
>>
>> properties:
>>    "#cooling-cells":
>>      description:
>>        Must be 2, in order to specify minimum and maximum cooling state used in
>>        the cooling-maps reference. The first cell is the minimum cooling state
>>        and the second cell is the maximum cooling state requested.
>>      const: 2
>>
>> But I think it would be perfectly fine to suggest a change such that
>> if cells > 2, the last two cells keep the current behavior and the former
>> ones let you index into a cooling device exposed through a single OF node
> 
> This might be a big change, which probably needs to be coordinated with
> thermal and DT maintainers first.
> 
>>
>> e.g.
>>
>> rproc_xyz: remoteproc {
>> 	compatible = "qcom,rproc-xyz";
>>
>> 	...
>>
>> 	#cooling-device-cells = <3>;
>> };
> 
> Which brings in another topic. In DT we have labels for different DT
> children, which correspond to different handlers on the DSP side. For
> the CDSP we see a "cdsp_sw" only. I think I've asked several times, but
> didn't get an example of the device having more than one, just claims
> that there might be more thane one TMD.
> 
> Do we need different cooling cells here? Or would it be enough to send
> the same max state to all TMDs on the DSP side?
> 

For newer targets, Within the CDSP we have compute core(cdsp-sw),
npu(hmx-sw) core and both have independent dcvs and also dedicated
tsens on each core.

And For Modem also we have multiple mitigation devices based on
different modem tech, for e.g tech level side we have modem-lte,
modem-nr etc and mitigation at different power amplifier side like
modem-pa etc. We have not added modem node for current series target
as it does not support modem.

>>
>> ...
>>
>> thermal-zones {
>> 	super-rproc-therm-a {
>> 		thermal-sensors = <&rproc_xyz RPROC_XYZ_COOLING_A
>> 				   THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
>>
>> 		trips { ... } ;
>> 	};
>>
>> 	super-rproc-therm-b {
>> 		thermal-sensors = <&rproc_xyz RPROC_XYZ_COOLING_B
>> 				   THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
>>
>> 		trips { ... } ;
>> 	};
>> };
>>
>> This would be resolved by allowing drivers to register an .of_xlate-type
>> function which would take the RPROC_XYZ_COOLING_n argument and e.g. use
>> it as an index into struct thermal_cooling_device cdev[]; within the
>> driver struct.
> 
> 
> 
>>
>> Konrad
> 

Re: [PATCH v1 2/8] remoteproc: qcom: probe all child devices

[Dmitry Baryshkov]

On Sat, 31 Jan 2026 at 11:12, Gaurav Kohli
<gaurav.kohli@oss.qualcomm.com> wrote:
>
>
>
> On 1/31/2026 1:36 PM, Dmitry Baryshkov wrote:
> > On Fri, Jan 30, 2026 at 10:13:06AM +0100, Konrad Dybcio wrote:
> >> On 1/30/26 8:03 AM, Gaurav Kohli wrote:
> >>>
> >>> On 1/28/2026 3:15 PM, Konrad Dybcio wrote:
> >>>> On 1/28/26 10:39 AM, Gaurav Kohli wrote:
> >>>>> On 1/27/2026 10:11 PM, Dmitry Baryshkov wrote:
> >>>>>> On Tue, Jan 27, 2026 at 09:42:10PM +0530, Gaurav Kohli wrote:
> >>>>>>> On 1/24/2026 12:33 AM, Dmitry Baryshkov wrote:
> >>>>>>>> On Fri, Jan 23, 2026 at 07:23:39PM +0530, Gaurav Kohli wrote:
> >>>>>>>>> On 1/8/2026 12:37 PM, Gaurav Kohli wrote:
> >>>>>>>>>> On 1/3/2026 8:26 PM, Bjorn Andersson wrote:
> >>>>>>>>>>> On Tue, Dec 23, 2025 at 06:02:21PM +0530, Gaurav Kohli wrote:
> >>>>>>>>>>>> From: Casey Connolly <casey.connolly@linaro.org>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Generalise the qcom,bam-dmux child node support by probing all
> >>>>>>>>>>>> remoteproc children with of_platform_populate(). This will be used to
> >>>>>>>>>>>> enable support for devices which are best represented as
> >>>>>>>>>>>> subnodes of the
> >>>>>>>>>>>> remoteproc, such as those representing QMI clients.
> >>>>>>>>>>> Please flip this around, start with the description of the problem
> >>>>>>>>>>> you're trying to solve.
> >>>>>>>>>>>
> >>>>>>>>>>>> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
> >>>>>>>>>>> This must have your signed-off-by, where you certifies the origin of
> >>>>>>>>>>> this patch.
> >>>>>>>>>>>
> >>>>>>>>>>>> ---
> >>>>>>>>>>>>       drivers/remoteproc/qcom_q6v5.c     | 4 ++++
> >>>>>>>>>>>>       drivers/remoteproc/qcom_q6v5_mss.c | 8 --------
> >>>>>>>>>>>>       2 files changed, 4 insertions(+), 8 deletions(-)
> >>>>>>>>>>>>
> >>>>>>>>>>>> diff --git a/drivers/remoteproc/qcom_q6v5.c
> >>>>>>>>>>>> b/drivers/remoteproc/qcom_q6v5.c
> >>>>>>>>>>>> index 58d5b85e58cd..a02839c7ed8c 100644
> >>>>>>>>>>>> --- a/drivers/remoteproc/qcom_q6v5.c
> >>>>>>>>>>>> +++ b/drivers/remoteproc/qcom_q6v5.c
> >>>>>>>>>>>> @@ -6,6 +6,7 @@
> >>>>>>>>>>>>        * Copyright (C) 2014 Sony Mobile Communications AB
> >>>>>>>>>>>>        * Copyright (c) 2012-2013, The Linux Foundation. All rights
> >>>>>>>>>>>> reserved.
> >>>>>>>>>>>>        */
> >>>>>>>>>>>> +#include <linux/of_platform.h>
> >>>>>>>>>>>>       #include <linux/kernel.h>
> >>>>>>>>>>>>       #include <linux/platform_device.h>
> >>>>>>>>>>>>       #include <linux/interconnect.h>
> >>>>>>>>>>>> @@ -351,6 +352,8 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5,
> >>>>>>>>>>>> struct platform_device *pdev,
> >>>>>>>>>>>>               return dev_err_probe(&pdev->dev, PTR_ERR(q6v5->path),
> >>>>>>>>>>>>                            "failed to acquire interconnect path\n");
> >>>>>>>>>>>>       +    of_platform_populate(q6v5->dev->of_node, NULL, NULL, q6v5->dev);
> >>>>>>>>>>> There are other child nodes here, in particular the GLINK and SMD edges.
> >>>>>>>>>>> Do we really want platform_devices registered for them?
> >>>>>>>>>>>
> >>>>>>>>>>> Regards,
> >>>>>>>>>>> Bjorn
> >>>>>>>>>> thanks for pointing this, can you please suggest the right approach.
> >>>>>>>>>>
> >>>>>>>>>> This should not impact glink, as that is registering as rproc sub node,
> >>>>>>>>>> And we need rproc cooling as child node
> >>>>>>>>>>
> >>>>>>>>>> of remote proc subsytem to create probe dependency only.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Can we do platform populate for specific child, would that be right
> >>>>>>>>>> approach. or we should create rproc cooling as independent of parent ?
> >>>>>>>>>>
> >>>>>>>>> HI Bjorn,
> >>>>>>>>>
> >>>>>>>>> I’d like to highlight the impact and details of placement of remoteproc
> >>>>>>>>> cooling dt node:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> ->As a child of the remote proc subsystem node:
> >>>>>>>>>         In this configuration, the cooling device will only be probed once the
> >>>>>>>>> corresponding remote proc subsystem itself is probed.
> >>>>>>>>>
> >>>>>>>>> ->Outside the remote proc subsystem, may be part of soc node:
> >>>>>>>>>         In this setup, the cooling device will be probed independently. It will
> >>>>>>>>> wait until the remoteproc subsystem is brought up
> >>>>>>>>>         before completing cooling registration.
> >>>>>>>>>         The drawback here is that if the parent remoteproc subsystem is
> >>>>>>>>> disabled, the cooling device will still undergo an
> >>>>>>>>>         unnecessary probe, even though it cannot be registered.
> >>>>>>>> Bjorns question was different. It wasn't about pushing cooling device
> >>>>>>>> outside of the remoteproc node. It is about not registering the devices.
> >>>>>>>>
> >>>>>>>> Can we follow the approach outlined by qcom_add_smd_subdev() /
> >>>>>>>> qcom_add_glink_subdev()?
> >>>>>>> Hi Dmitry,
> >>>>>>>
> >>>>>>> Thanks for the review. Since the remoteproc cooling is a QMI-based driver,
> >>>>>>> it will receive the
> >>>>>>> subsystem up notification directly. Therefore, there’s no need to make it a
> >>>>>>> subdev node or
> >>>>>>> tie it into the init/reset sequence of remoteproc subsytem.
> >>>>>> But you've added a subnode for it (and we are discussing exactly
> >>>>>> of_platform_populate()) call. So, you are tying it to the remoteproc
> >>>>>> device lifecycle instead of the remoteproc subsys, which seems strange
> >>>>>> to me. There is no cooling device if the DSP is not running.
> >>>>>
> >>>>> For the cooling feature, we don’t need to define it as a subnode. The cooling subsystem becomes relevant only
> >>>>> after the remote subsystem is up, at which point it will receive add/delete notifications from the QMI server.
> >>>>>
> >>>>>
> >>>>> If child nodes must be modeled as subnodes for rproc, we can move the CDSP TMD out of the remoteproc and add in soc.
> >>>>> Is there currently a way for the remoteproc core layer to call of_platform_populate() without requiring a subnode?
> >>>> I think the question is "why can't you register the remoteproc device
> >>>> as a cooling_device, with perhaps #cooling-cells = <1>; instead of
> >>>> any form of children?"
> >>>>
> >>>> Konrad
> >>>
> >>>
> >>> thanks Konrad, for the review.
> >>>
> >>> As each subsystem can expose multiple thermal mitigation devices via the remoteproc TMD service, so need to define child node.
> >>
> >> I think you're stuck in an XY problem - you keep insisting that adding
> >> a subnode is your end goal, while you really want to achieve being able
> >> to register multiple cooling devices. Or at least that's how I read your
> >> messages since you happen not to give any explanation as to why it's
> >> actually necessary.
> >>
> >> In my previous message, I forgot that cells for cooling devices actually
> >> represent the minimum and maximum cooling state allowed. But since the
> >> API is just part of the kernel, there's nothing preventing us from
> >> evolving it.
> >>
> >> Currently, we have:
> >>
> >> Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml
> >>
> >> properties:
> >>    "#cooling-cells":
> >>      description:
> >>        Must be 2, in order to specify minimum and maximum cooling state used in
> >>        the cooling-maps reference. The first cell is the minimum cooling state
> >>        and the second cell is the maximum cooling state requested.
> >>      const: 2
> >>
> >> But I think it would be perfectly fine to suggest a change such that
> >> if cells > 2, the last two cells keep the current behavior and the former
> >> ones let you index into a cooling device exposed through a single OF node
> >
> > This might be a big change, which probably needs to be coordinated with
> > thermal and DT maintainers first.
> >
> >>
> >> e.g.
> >>
> >> rproc_xyz: remoteproc {
> >>      compatible = "qcom,rproc-xyz";
> >>
> >>      ...
> >>
> >>      #cooling-device-cells = <3>;
> >> };
> >
> > Which brings in another topic. In DT we have labels for different DT
> > children, which correspond to different handlers on the DSP side. For
> > the CDSP we see a "cdsp_sw" only. I think I've asked several times, but
> > didn't get an example of the device having more than one, just claims
> > that there might be more thane one TMD.
> >
> > Do we need different cooling cells here? Or would it be enough to send
> > the same max state to all TMDs on the DSP side?
> >
>
> For newer targets, Within the CDSP we have compute core(cdsp-sw),
> npu(hmx-sw) core and both have independent dcvs and also dedicated
> tsens on each core.

Okay, inside the DT bindings please provide this system as an example
rather than using the simplest one.

>
> And For Modem also we have multiple mitigation devices based on
> different modem tech, for e.g tech level side we have modem-lte,
> modem-nr etc and mitigation at different power amplifier side like
> modem-pa etc. We have not added modem node for current series target
> as it does not support modem.

I wrote it several times: there is no reason to limit yourself to
CDSP. Please also add support for ADSP, SLPI and modem.

>
> >>
> >> ...
> >>
> >> thermal-zones {
> >>      super-rproc-therm-a {
> >>              thermal-sensors = <&rproc_xyz RPROC_XYZ_COOLING_A
> >>                                 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> >>
> >>              trips { ... } ;
> >>      };
> >>
> >>      super-rproc-therm-b {
> >>              thermal-sensors = <&rproc_xyz RPROC_XYZ_COOLING_B
> >>                                 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> >>
> >>              trips { ... } ;
> >>      };
> >> };
> >>
> >> This would be resolved by allowing drivers to register an .of_xlate-type
> >> function which would take the RPROC_XYZ_COOLING_n argument and e.g. use
> >> it as an index into struct thermal_cooling_device cdev[]; within the
> >> driver struct.
> >
> >
> >
> >>
> >> Konrad
> >
>


-- 
With best wishes
Dmitry

Re: [PATCH v1 2/8] remoteproc: qcom: probe all child devices

[Gaurav Kohli]

On 1/31/2026 5:10 PM, Dmitry Baryshkov wrote:
> On Sat, 31 Jan 2026 at 11:12, Gaurav Kohli
> <gaurav.kohli@oss.qualcomm.com> wrote:
>>
>>
>>
>> On 1/31/2026 1:36 PM, Dmitry Baryshkov wrote:
>>> On Fri, Jan 30, 2026 at 10:13:06AM +0100, Konrad Dybcio wrote:
>>>> On 1/30/26 8:03 AM, Gaurav Kohli wrote:
>>>>>
>>>>> On 1/28/2026 3:15 PM, Konrad Dybcio wrote:
>>>>>> On 1/28/26 10:39 AM, Gaurav Kohli wrote:
>>>>>>> On 1/27/2026 10:11 PM, Dmitry Baryshkov wrote:
>>>>>>>> On Tue, Jan 27, 2026 at 09:42:10PM +0530, Gaurav Kohli wrote:
>>>>>>>>> On 1/24/2026 12:33 AM, Dmitry Baryshkov wrote:
>>>>>>>>>> On Fri, Jan 23, 2026 at 07:23:39PM +0530, Gaurav Kohli wrote:
>>>>>>>>>>> On 1/8/2026 12:37 PM, Gaurav Kohli wrote:
>>>>>>>>>>>> On 1/3/2026 8:26 PM, Bjorn Andersson wrote:
>>>>>>>>>>>>> On Tue, Dec 23, 2025 at 06:02:21PM +0530, Gaurav Kohli wrote:
>>>>>>>>>>>>>> From: Casey Connolly <casey.connolly@linaro.org>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Generalise the qcom,bam-dmux child node support by probing all
>>>>>>>>>>>>>> remoteproc children with of_platform_populate(). This will be used to
>>>>>>>>>>>>>> enable support for devices which are best represented as
>>>>>>>>>>>>>> subnodes of the
>>>>>>>>>>>>>> remoteproc, such as those representing QMI clients.
>>>>>>>>>>>>> Please flip this around, start with the description of the problem
>>>>>>>>>>>>> you're trying to solve.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
>>>>>>>>>>>>> This must have your signed-off-by, where you certifies the origin of
>>>>>>>>>>>>> this patch.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>        drivers/remoteproc/qcom_q6v5.c     | 4 ++++
>>>>>>>>>>>>>>        drivers/remoteproc/qcom_q6v5_mss.c | 8 --------
>>>>>>>>>>>>>>        2 files changed, 4 insertions(+), 8 deletions(-)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> diff --git a/drivers/remoteproc/qcom_q6v5.c
>>>>>>>>>>>>>> b/drivers/remoteproc/qcom_q6v5.c
>>>>>>>>>>>>>> index 58d5b85e58cd..a02839c7ed8c 100644
>>>>>>>>>>>>>> --- a/drivers/remoteproc/qcom_q6v5.c
>>>>>>>>>>>>>> +++ b/drivers/remoteproc/qcom_q6v5.c
>>>>>>>>>>>>>> @@ -6,6 +6,7 @@
>>>>>>>>>>>>>>         * Copyright (C) 2014 Sony Mobile Communications AB
>>>>>>>>>>>>>>         * Copyright (c) 2012-2013, The Linux Foundation. All rights
>>>>>>>>>>>>>> reserved.
>>>>>>>>>>>>>>         */
>>>>>>>>>>>>>> +#include <linux/of_platform.h>
>>>>>>>>>>>>>>        #include <linux/kernel.h>
>>>>>>>>>>>>>>        #include <linux/platform_device.h>
>>>>>>>>>>>>>>        #include <linux/interconnect.h>
>>>>>>>>>>>>>> @@ -351,6 +352,8 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5,
>>>>>>>>>>>>>> struct platform_device *pdev,
>>>>>>>>>>>>>>                return dev_err_probe(&pdev->dev, PTR_ERR(q6v5->path),
>>>>>>>>>>>>>>                             "failed to acquire interconnect path\n");
>>>>>>>>>>>>>>        +    of_platform_populate(q6v5->dev->of_node, NULL, NULL, q6v5->dev);
>>>>>>>>>>>>> There are other child nodes here, in particular the GLINK and SMD edges.
>>>>>>>>>>>>> Do we really want platform_devices registered for them?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Bjorn
>>>>>>>>>>>> thanks for pointing this, can you please suggest the right approach.
>>>>>>>>>>>>
>>>>>>>>>>>> This should not impact glink, as that is registering as rproc sub node,
>>>>>>>>>>>> And we need rproc cooling as child node
>>>>>>>>>>>>
>>>>>>>>>>>> of remote proc subsytem to create probe dependency only.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Can we do platform populate for specific child, would that be right
>>>>>>>>>>>> approach. or we should create rproc cooling as independent of parent ?
>>>>>>>>>>>>
>>>>>>>>>>> HI Bjorn,
>>>>>>>>>>>
>>>>>>>>>>> I’d like to highlight the impact and details of placement of remoteproc
>>>>>>>>>>> cooling dt node:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ->As a child of the remote proc subsystem node:
>>>>>>>>>>>          In this configuration, the cooling device will only be probed once the
>>>>>>>>>>> corresponding remote proc subsystem itself is probed.
>>>>>>>>>>>
>>>>>>>>>>> ->Outside the remote proc subsystem, may be part of soc node:
>>>>>>>>>>>          In this setup, the cooling device will be probed independently. It will
>>>>>>>>>>> wait until the remoteproc subsystem is brought up
>>>>>>>>>>>          before completing cooling registration.
>>>>>>>>>>>          The drawback here is that if the parent remoteproc subsystem is
>>>>>>>>>>> disabled, the cooling device will still undergo an
>>>>>>>>>>>          unnecessary probe, even though it cannot be registered.
>>>>>>>>>> Bjorns question was different. It wasn't about pushing cooling device
>>>>>>>>>> outside of the remoteproc node. It is about not registering the devices.
>>>>>>>>>>
>>>>>>>>>> Can we follow the approach outlined by qcom_add_smd_subdev() /
>>>>>>>>>> qcom_add_glink_subdev()?
>>>>>>>>> Hi Dmitry,
>>>>>>>>>
>>>>>>>>> Thanks for the review. Since the remoteproc cooling is a QMI-based driver,
>>>>>>>>> it will receive the
>>>>>>>>> subsystem up notification directly. Therefore, there’s no need to make it a
>>>>>>>>> subdev node or
>>>>>>>>> tie it into the init/reset sequence of remoteproc subsytem.
>>>>>>>> But you've added a subnode for it (and we are discussing exactly
>>>>>>>> of_platform_populate()) call. So, you are tying it to the remoteproc
>>>>>>>> device lifecycle instead of the remoteproc subsys, which seems strange
>>>>>>>> to me. There is no cooling device if the DSP is not running.
>>>>>>>
>>>>>>> For the cooling feature, we don’t need to define it as a subnode. The cooling subsystem becomes relevant only
>>>>>>> after the remote subsystem is up, at which point it will receive add/delete notifications from the QMI server.
>>>>>>>
>>>>>>>
>>>>>>> If child nodes must be modeled as subnodes for rproc, we can move the CDSP TMD out of the remoteproc and add in soc.
>>>>>>> Is there currently a way for the remoteproc core layer to call of_platform_populate() without requiring a subnode?
>>>>>> I think the question is "why can't you register the remoteproc device
>>>>>> as a cooling_device, with perhaps #cooling-cells = <1>; instead of
>>>>>> any form of children?"
>>>>>>
>>>>>> Konrad
>>>>>
>>>>>
>>>>> thanks Konrad, for the review.
>>>>>
>>>>> As each subsystem can expose multiple thermal mitigation devices via the remoteproc TMD service, so need to define child node.
>>>>
>>>> I think you're stuck in an XY problem - you keep insisting that adding
>>>> a subnode is your end goal, while you really want to achieve being able
>>>> to register multiple cooling devices. Or at least that's how I read your
>>>> messages since you happen not to give any explanation as to why it's
>>>> actually necessary.
>>>>
>>>> In my previous message, I forgot that cells for cooling devices actually
>>>> represent the minimum and maximum cooling state allowed. But since the
>>>> API is just part of the kernel, there's nothing preventing us from
>>>> evolving it.
>>>>
>>>> Currently, we have:
>>>>
>>>> Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml
>>>>
>>>> properties:
>>>>     "#cooling-cells":
>>>>       description:
>>>>         Must be 2, in order to specify minimum and maximum cooling state used in
>>>>         the cooling-maps reference. The first cell is the minimum cooling state
>>>>         and the second cell is the maximum cooling state requested.
>>>>       const: 2
>>>>
>>>> But I think it would be perfectly fine to suggest a change such that
>>>> if cells > 2, the last two cells keep the current behavior and the former
>>>> ones let you index into a cooling device exposed through a single OF node
>>>
>>> This might be a big change, which probably needs to be coordinated with
>>> thermal and DT maintainers first.
>>>
>>>>
>>>> e.g.
>>>>
>>>> rproc_xyz: remoteproc {
>>>>       compatible = "qcom,rproc-xyz";
>>>>
>>>>       ...
>>>>
>>>>       #cooling-device-cells = <3>;
>>>> };
>>>
>>> Which brings in another topic. In DT we have labels for different DT
>>> children, which correspond to different handlers on the DSP side. For
>>> the CDSP we see a "cdsp_sw" only. I think I've asked several times, but
>>> didn't get an example of the device having more than one, just claims
>>> that there might be more thane one TMD.
>>>
>>> Do we need different cooling cells here? Or would it be enough to send
>>> the same max state to all TMDs on the DSP side?
>>>
>>
>> For newer targets, Within the CDSP we have compute core(cdsp-sw),
>> npu(hmx-sw) core and both have independent dcvs and also dedicated
>> tsens on each core.
> 
> Okay, inside the DT bindings please provide this system as an example
> rather than using the simplest one.
> 
>>
>> And For Modem also we have multiple mitigation devices based on
>> different modem tech, for e.g tech level side we have modem-lte,
>> modem-nr etc and mitigation at different power amplifier side like
>> modem-pa etc. We have not added modem node for current series target
>> as it does not support modem.
> 
> I wrote it several times: there is no reason to limit yourself to
> CDSP. Please also add support for ADSP, SLPI and modem.
> 

Sure, will add.

>>
>>>>
>>>> ...
>>>>
>>>> thermal-zones {
>>>>       super-rproc-therm-a {
>>>>               thermal-sensors = <&rproc_xyz RPROC_XYZ_COOLING_A
>>>>                                  THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
>>>>
>>>>               trips { ... } ;
>>>>       };
>>>>
>>>>       super-rproc-therm-b {
>>>>               thermal-sensors = <&rproc_xyz RPROC_XYZ_COOLING_B
>>>>                                  THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
>>>>
>>>>               trips { ... } ;
>>>>       };
>>>> };
>>>>
>>>> This would be resolved by allowing drivers to register an .of_xlate-type
>>>> function which would take the RPROC_XYZ_COOLING_n argument and e.g. use
>>>> it as an index into struct thermal_cooling_device cdev[]; within the
>>>> driver struct.
>>>
>>>
>>>
>>>>
>>>> Konrad
>>>
>>
> 
> 

[PATCH v1 3/8] dt-bindings: thermal: Add qcom,qmi-cooling yaml bindings

[Gaurav Kohli]

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.

Add maintainer name also and update this binding for cdsp substem.

Co-developed-by: Casey Connolly <casey.connolly@linaro.org>
Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
---
 .../bindings/remoteproc/qcom,pas-common.yaml  |  6 ++
 .../bindings/thermal/qcom,qmi-cooling.yaml    | 99 +++++++++++++++++++
 2 files changed, 105 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 63a82e7a8bf8..bbc82253f76b 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
@@ -77,6 +77,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.
+    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..90b46712d241
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2023 (c), Linaro Limited
+
+%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:
+  - Caleb Connolly <caleb.connolly@linaro.org>
+  - 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.
+
+  Each subnode corresponds to a control interface for a single instance of the TMD
+  service running on a remote subsystem.
+
+definitions:
+  tmd:
+    type: object
+    description: |
+      A single Thermal Mitigation Device exposed by a remote subsystem.
+    properties:
+      label:
+        maxItems: 1
+      "#cooling-cells":
+        $ref: /schemas/thermal/thermal-cooling-devices.yaml#/properties/#cooling-cells
+      phandle: true
+
+    required:
+      - label
+      - "#cooling-cells"
+
+    additionalProperties: false
+
+properties:
+  compatible:
+    enum:
+      - qcom,qmi-cooling-modem
+      - qcom,qmi-cooling-cdsp
+
+  vdd:
+    $ref: "#/definitions/tmd"
+    description:
+      Modem processor temperature TMD
+    properties:
+      label:
+        const: modem
+
+required:
+  - compatible
+
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: qcom,qmi-cooling-cdsp
+    then:
+      properties:
+        cdsp_sw:
+          $ref: "#/definitions/tmd"
+          description:
+            CDSP software TMD
+          properties:
+            label:
+              const: cdsp_sw
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    remoteproc-cdsp {
+        cooling {
+            compatible = "qcom,qmi-cooling-cdsp";
+
+            cdsp_sw0: cdsp_sw {
+              label = "cdsp_sw";
+              #cooling-cells = <2>;
+            };
+        };
+    };
+
+    remoteproc-cdsp1 {
+        cooling {
+            compatible = "qcom,qmi-cooling-cdsp1";
+
+            cdsp_sw1: cdsp_sw {
+              label = "cdsp_sw";
+              #cooling-cells = <2>;
+            };
+        };
+    };
+...
-- 
2.34.1

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

[Rob Herring (Arm)]

On Tue, 23 Dec 2025 18:02:22 +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.
> 
> Add maintainer name also and update this binding for cdsp substem.
> 
> Co-developed-by: Casey Connolly <casey.connolly@linaro.org>
> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
> ---
>  .../bindings/remoteproc/qcom,pas-common.yaml  |  6 ++
>  .../bindings/thermal/qcom,qmi-cooling.yaml    | 99 +++++++++++++++++++
>  2 files changed, 105 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.example.dtb: /example-0/remoteproc-cdsp1/cooling: failed to match any schema with compatible: ['qcom,qmi-cooling-cdsp1']

doc reference errors (make refcheckdocs):

See https://patchwork.kernel.org/project/devicetree/patch/20251223123227.1317244-4-gaurav.kohli@oss.qualcomm.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.

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

[Gaurav Kohli]

On 12/23/2025 7:29 PM, Rob Herring (Arm) wrote:
> On Tue, 23 Dec 2025 18:02:22 +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.
>>
>> Add maintainer name also and update this binding for cdsp substem.
>>
>> Co-developed-by: Casey Connolly <casey.connolly@linaro.org>
>> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
>> ---
>>   .../bindings/remoteproc/qcom,pas-common.yaml  |  6 ++
>>   .../bindings/thermal/qcom,qmi-cooling.yaml    | 99 +++++++++++++++++++
>>   2 files changed, 105 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml
>>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.example.dtb: /example-0/remoteproc-cdsp1/cooling: failed to match any schema with compatible: ['qcom,qmi-cooling-cdsp1']
>
> doc reference errors (make refcheckdocs):
>
> See https://patchwork.kernel.org/project/devicetree/patch/20251223123227.1317244-4-gaurav.kohli@oss.qualcomm.com
>
> The base for the series is generally the latest rc1. A different dependency
> should be noted in *this* patch.
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
>
> pip3 install dtschema --upgrade
>
> Please check and re-submit after running the above command yourself. Note
> that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> your schema. However, it must be unset to test all examples with your schema.


thanks for review, missed to add one cdsp1 patch in this series, will 
update in next post.

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

[Dmitry Baryshkov]

On Tue, Dec 23, 2025 at 06:02:22PM +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.
> 
> Add maintainer name also and update this binding for cdsp substem.
> 
> Co-developed-by: Casey Connolly <casey.connolly@linaro.org>
> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
> ---
>  .../bindings/remoteproc/qcom,pas-common.yaml  |  6 ++
>  .../bindings/thermal/qcom,qmi-cooling.yaml    | 99 +++++++++++++++++++
>  2 files changed, 105 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 63a82e7a8bf8..bbc82253f76b 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
> @@ -77,6 +77,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.
> +    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..90b46712d241
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml
> @@ -0,0 +1,99 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2023 (c), Linaro Limited
> +
> +%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:
> +  - Caleb Connolly <caleb.connolly@linaro.org>

This wasn't updated.

> +  - 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.
> +
> +  Each subnode corresponds to a control interface for a single instance of the TMD
> +  service running on a remote subsystem.
> +
> +definitions:
> +  tmd:
> +    type: object
> +    description: |
> +      A single Thermal Mitigation Device exposed by a remote subsystem.
> +    properties:
> +      label:
> +        maxItems: 1
> +      "#cooling-cells":
> +        $ref: /schemas/thermal/thermal-cooling-devices.yaml#/properties/#cooling-cells
> +      phandle: true
> +
> +    required:
> +      - label
> +      - "#cooling-cells"
> +
> +    additionalProperties: false
> +
> +properties:
> +  compatible:
> +    enum:
> +      - qcom,qmi-cooling-modem
> +      - qcom,qmi-cooling-cdsp
> +
> +  vdd:
> +    $ref: "#/definitions/tmd"
> +    description:
> +      Modem processor temperature TMD
> +    properties:
> +      label:
> +        const: modem

Why it being called vdd?

Why do you define modem-specific node here, while the CDSP-specific is
defined under the if block?

> +
> +required:
> +  - compatible
> +
> +allOf:
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: qcom,qmi-cooling-cdsp
> +    then:
> +      properties:
> +        cdsp_sw:
> +          $ref: "#/definitions/tmd"
> +          description:
> +            CDSP software TMD
> +          properties:
> +            label:
> +              const: cdsp_sw

Why do we need a label in addition to the node name?

> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +    remoteproc-cdsp {
> +        cooling {
> +            compatible = "qcom,qmi-cooling-cdsp";
> +
> +            cdsp_sw0: cdsp_sw {

Is it allowed for device node names to have underscores?

> +              label = "cdsp_sw";
> +              #cooling-cells = <2>;
> +            };
> +        };
> +    };
> +
> +    remoteproc-cdsp1 {
> +        cooling {
> +            compatible = "qcom,qmi-cooling-cdsp1";
> +
> +            cdsp_sw1: cdsp_sw {
> +              label = "cdsp_sw";
> +              #cooling-cells = <2>;
> +            };
> +        };
> +    };

What's the point of having the second CDSP block? Could you demonstrate
modem instead?

> +...
> -- 
> 2.34.1
> 

-- 
With best wishes
Dmitry

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

[Gaurav Kohli]

On 12/24/2025 1:00 AM, Dmitry Baryshkov wrote:
> On Tue, Dec 23, 2025 at 06:02:22PM +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.
>>
>> Add maintainer name also and update this binding for cdsp substem.
>>
>> Co-developed-by: Casey Connolly <casey.connolly@linaro.org>
>> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
>> ---
>>   .../bindings/remoteproc/qcom,pas-common.yaml  |  6 ++
>>   .../bindings/thermal/qcom,qmi-cooling.yaml    | 99 +++++++++++++++++++
>>   2 files changed, 105 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 63a82e7a8bf8..bbc82253f76b 100644
>> --- a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
>> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
>> @@ -77,6 +77,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.
>> +    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..90b46712d241
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml
>> @@ -0,0 +1,99 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +# Copyright 2023 (c), Linaro Limited
>> +
>> +%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:
>> +  - Caleb Connolly <caleb.connolly@linaro.org>
> This wasn't updated.


will fix this.


>> +  - 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.
>> +
>> +  Each subnode corresponds to a control interface for a single instance of the TMD
>> +  service running on a remote subsystem.
>> +
>> +definitions:
>> +  tmd:
>> +    type: object
>> +    description: |
>> +      A single Thermal Mitigation Device exposed by a remote subsystem.
>> +    properties:
>> +      label:
>> +        maxItems: 1
>> +      "#cooling-cells":
>> +        $ref: /schemas/thermal/thermal-cooling-devices.yaml#/properties/#cooling-cells
>> +      phandle: true
>> +
>> +    required:
>> +      - label
>> +      - "#cooling-cells"
>> +
>> +    additionalProperties: false
>> +
>> +properties:
>> +  compatible:
>> +    enum:
>> +      - qcom,qmi-cooling-modem
>> +      - qcom,qmi-cooling-cdsp
>> +
>> +  vdd:
>> +    $ref: "#/definitions/tmd"
>> +    description:
>> +      Modem processor temperature TMD
>> +    properties:
>> +      label:
>> +        const: modem
> Why it being called vdd?
>
> Why do you define modem-specific node here, while the CDSP-specific is
> defined under the if block?


will remove modem in next post,  earlier we were developing for all 
subsystem.
right now wanted to post for cdsp subsystem first, will fix in next post.


>> +
>> +required:
>> +  - compatible
>> +
>> +allOf:
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            const: qcom,qmi-cooling-cdsp
>> +    then:
>> +      properties:
>> +        cdsp_sw:
>> +          $ref: "#/definitions/tmd"
>> +          description:
>> +            CDSP software TMD
>> +          properties:
>> +            label:
>> +              const: cdsp_sw
> Why do we need a label in addition to the node name?


was seeing label error for cdsp_sw without this, let me recheck and update.


>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> +  - |
>> +    remoteproc-cdsp {
>> +        cooling {
>> +            compatible = "qcom,qmi-cooling-cdsp";
>> +
>> +            cdsp_sw0: cdsp_sw {
> Is it allowed for device node names to have underscores?


will fix this, but not seeing any binding error with underscores.


>
>> +              label = "cdsp_sw";
>> +              #cooling-cells = <2>;
>> +            };
>> +        };
>> +    };
>> +
>> +    remoteproc-cdsp1 {
>> +        cooling {
>> +            compatible = "qcom,qmi-cooling-cdsp1";
>> +
>> +            cdsp_sw1: cdsp_sw {
>> +              label = "cdsp_sw";
>> +              #cooling-cells = <2>;
>> +            };
>> +        };
>> +    };
> What's the point of having the second CDSP block? Could you demonstrate
> modem instead?


Missed one cdsp1 block in this series, will add in next post. Leman's is 
using two cdsp subsystem for that we need cdsp1.


>> +...
>> -- 
>> 2.34.1
>>

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

[Dmitry Baryshkov]

On Wed, Dec 24, 2025 at 01:54:04PM +0530, Gaurav Kohli wrote:
> 
> On 12/24/2025 1:00 AM, Dmitry Baryshkov wrote:
> > On Tue, Dec 23, 2025 at 06:02:22PM +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.
> > > 
> > > Add maintainer name also and update this binding for cdsp substem.
> > > 
> > > Co-developed-by: Casey Connolly <casey.connolly@linaro.org>
> > > Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
> > > Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
> > > ---
> > >   .../bindings/remoteproc/qcom,pas-common.yaml  |  6 ++
> > >   .../bindings/thermal/qcom,qmi-cooling.yaml    | 99 +++++++++++++++++++
> > >   2 files changed, 105 insertions(+)
> > >   create mode 100644 Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml
> > > 
> > > +properties:
> > > +  compatible:
> > > +    enum:
> > > +      - qcom,qmi-cooling-modem
> > > +      - qcom,qmi-cooling-cdsp
> > > +
> > > +  vdd:
> > > +    $ref: "#/definitions/tmd"
> > > +    description:
> > > +      Modem processor temperature TMD
> > > +    properties:
> > > +      label:
> > > +        const: modem
> > Why it being called vdd?
> > 
> > Why do you define modem-specific node here, while the CDSP-specific is
> > defined under the if block?
> 
> will remove modem in next post,  earlier we were developing for all
> subsystem.
> right now wanted to post for cdsp subsystem first, will fix in next post.

Why? If there is no significant difference, merge support for all DSPs.
It would allow us to better understand the requirements for all DSP
kinds.


-- 
With best wishes
Dmitry

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

[Bjorn Andersson]

On Wed, Dec 24, 2025 at 01:54:04PM +0530, Gaurav Kohli wrote:
> On 12/24/2025 1:00 AM, Dmitry Baryshkov wrote:
> > On Tue, Dec 23, 2025 at 06:02:22PM +0530, Gaurav Kohli wrote:
> > > diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
[..]
> > > +  vdd:
> > > +    $ref: "#/definitions/tmd"
> > > +    description:
> > > +      Modem processor temperature TMD
> > > +    properties:
> > > +      label:
> > > +        const: modem
> > Why it being called vdd?
> > 
> > Why do you define modem-specific node here, while the CDSP-specific is
> > defined under the if block?
> 
> 
> will remove modem in next post,  earlier we were developing for all
> subsystem.
> right now wanted to post for cdsp subsystem first, will fix in next post.
> 

No, upstream the binding and driver for all known endpoints (and test to
the best of your ability), then enable the ones you have on your
platform.

[..]
> > 
> > > +              label = "cdsp_sw";
> > > +              #cooling-cells = <2>;
> > > +            };
> > > +        };
> > > +    };
> > > +
> > > +    remoteproc-cdsp1 {
> > > +        cooling {
> > > +            compatible = "qcom,qmi-cooling-cdsp1";
> > > +
> > > +            cdsp_sw1: cdsp_sw {
> > > +              label = "cdsp_sw";
> > > +              #cooling-cells = <2>;
> > > +            };
> > > +        };
> > > +    };
> > What's the point of having the second CDSP block? Could you demonstrate
> > modem instead?
> 
> 
> Missed one cdsp1 block in this series, will add in next post. Leman's is
> using two cdsp subsystem for that we need cdsp1.
> 

It's just an example, make it as informative as possible.

Regards,
Bjorn

> 
> > > +...
> > > -- 
> > > 2.34.1
> > > 

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

[Dmitry Baryshkov]

On Tue, Dec 23, 2025 at 06:02:22PM +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.
> 
> Add maintainer name also and update this binding for cdsp substem.
> 
> Co-developed-by: Casey Connolly <casey.connolly@linaro.org>
> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
> ---
>  .../bindings/remoteproc/qcom,pas-common.yaml  |  6 ++
>  .../bindings/thermal/qcom,qmi-cooling.yaml    | 99 +++++++++++++++++++
>  2 files changed, 105 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml
> 
> +
> +examples:
> +  - |
> +    remoteproc-cdsp {
> +        cooling {
> +            compatible = "qcom,qmi-cooling-cdsp";
> +
> +            cdsp_sw0: cdsp_sw {

After going through the driver and through the DT. How many cooling
handlers can be present on one DSP? If it's always only one, why do we
need subnodes at all?

> +              label = "cdsp_sw";
> +              #cooling-cells = <2>;
> +            };
> +        };
> +    };
> +
> +    remoteproc-cdsp1 {
> +        cooling {
> +            compatible = "qcom,qmi-cooling-cdsp1";
> +
> +            cdsp_sw1: cdsp_sw {
> +              label = "cdsp_sw";
> +              #cooling-cells = <2>;
> +            };
> +        };
> +    };
> +...
> -- 
> 2.34.1
> 

-- 
With best wishes
Dmitry

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

[Krzysztof Kozlowski]

On 23/12/2025 13:32, 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.
> 
> Add maintainer name also and update this binding for cdsp substem.
> 
> Co-developed-by: Casey Connolly <casey.connolly@linaro.org>
> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
> ---
>  .../bindings/remoteproc/qcom,pas-common.yaml  |  6 ++
>  .../bindings/thermal/qcom,qmi-cooling.yaml    | 99 +++++++++++++++++++
>  2 files changed, 105 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 63a82e7a8bf8..bbc82253f76b 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
> @@ -77,6 +77,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.
> +    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..90b46712d241
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml
> @@ -0,0 +1,99 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2023 (c), Linaro Limited
> +
> +%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:
> +  - Caleb Connolly <caleb.connolly@linaro.org>
> +  - 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.
> +
> +  Each subnode corresponds to a control interface for a single instance of the TMD
> +  service running on a remote subsystem.
> +
> +definitions:

defs, look at other code


> +  tmd:
> +    type: object
> +    description: |
> +      A single Thermal Mitigation Device exposed by a remote subsystem.

Missing proper formatting. Please do not send us code written by LLM.

> +    properties:
> +      label:
> +        maxItems: 1
> +      "#cooling-cells":
> +        $ref: /schemas/thermal/thermal-cooling-devices.yaml#/properties/#cooling-cells
> +      phandle: true

NAK, LLM generated junk. It is not acceptable to send such code.


Best regards,
Krzysztof

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

[Gaurav Kohli]

On 12/24/2025 2:27 PM, Krzysztof Kozlowski wrote:
> On 23/12/2025 13:32, 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.
>>
>> Add maintainer name also and update this binding for cdsp substem.
>>
>> Co-developed-by: Casey Connolly <casey.connolly@linaro.org>
>> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
>> ---
>>   .../bindings/remoteproc/qcom,pas-common.yaml  |  6 ++
>>   .../bindings/thermal/qcom,qmi-cooling.yaml    | 99 +++++++++++++++++++
>>   2 files changed, 105 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 63a82e7a8bf8..bbc82253f76b 100644
>> --- a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
>> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
>> @@ -77,6 +77,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.
>> +    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..90b46712d241
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml
>> @@ -0,0 +1,99 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +# Copyright 2023 (c), Linaro Limited
>> +
>> +%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:
>> +  - Caleb Connolly <caleb.connolly@linaro.org>
>> +  - 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.
>> +
>> +  Each subnode corresponds to a control interface for a single instance of the TMD
>> +  service running on a remote subsystem.
>> +
>> +definitions:
> defs, look at other code
>
>
>> +  tmd:
>> +    type: object
>> +    description: |
>> +      A single Thermal Mitigation Device exposed by a remote subsystem.
> Missing proper formatting. Please do not send us code written by LLM.


This patch is based on older series

https://lore.kernel.org/linux-devicetree/20230905-caleb-qmi_cooling-v1-0-5aa39d4164a7@linaro.org/, did some manual changes to remove unusable code.
let me fix the formatting. This is not generated code.


>
>> +    properties:
>> +      label:
>> +        maxItems: 1
>> +      "#cooling-cells":
>> +        $ref: /schemas/thermal/thermal-cooling-devices.yaml#/properties/#cooling-cells
>> +      phandle: true
> NAK, LLM generated junk. It is not acceptable to send such code.
>
>
> Best regards,
> Krzysztof

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

[Krzysztof Kozlowski]

On 24/12/2025 11:08, Gaurav Kohli wrote:
> 
> On 12/24/2025 2:27 PM, Krzysztof Kozlowski wrote:
>> On 23/12/2025 13:32, 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.
>>>
>>> Add maintainer name also and update this binding for cdsp substem.
>>>
>>> Co-developed-by: Casey Connolly <casey.connolly@linaro.org>
>>> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>>> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
>>> ---
>>>   .../bindings/remoteproc/qcom,pas-common.yaml  |  6 ++
>>>   .../bindings/thermal/qcom,qmi-cooling.yaml    | 99 +++++++++++++++++++
>>>   2 files changed, 105 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 63a82e7a8bf8..bbc82253f76b 100644
>>> --- a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
>>> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
>>> @@ -77,6 +77,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.
>>> +    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..90b46712d241
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml
>>> @@ -0,0 +1,99 @@
>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>> +# Copyright 2023 (c), Linaro Limited
>>> +
>>> +%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:
>>> +  - Caleb Connolly <caleb.connolly@linaro.org>
>>> +  - 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.
>>> +
>>> +  Each subnode corresponds to a control interface for a single instance of the TMD
>>> +  service running on a remote subsystem.
>>> +
>>> +definitions:
>> defs, look at other code
>>
>>
>>> +  tmd:
>>> +    type: object
>>> +    description: |
>>> +      A single Thermal Mitigation Device exposed by a remote subsystem.
>> Missing proper formatting. Please do not send us code written by LLM.
> 
> 
> This patch is based on older series
> 
> https://lore.kernel.org/linux-devicetree/20230905-caleb-qmi_cooling-v1-0-5aa39d4164a7@linaro.org/, did some manual changes to remove unusable code.

How? This is v1, not v2. How did you address other comments? Where did
you provide proper changelog? Why this is not correctly versioned/

> let me fix the formatting. This is not generated code.

I do not believe, because this:


>>> +      phandle: true

Does not exist. You cannot come with something like that, there is no
such code.

Only LLM when parsing DTB could invent something like this. Otherwise
explain me please the process leading to coming to such change.

Best regards,
Krzysztof

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

[Gaurav Kohli]

On 12/24/2025 3:54 PM, Krzysztof Kozlowski wrote:
> On 24/12/2025 11:08, Gaurav Kohli wrote:
>> On 12/24/2025 2:27 PM, Krzysztof Kozlowski wrote:
>>> On 23/12/2025 13:32, 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.
>>>>
>>>> Add maintainer name also and update this binding for cdsp substem.
>>>>
>>>> Co-developed-by: Casey Connolly <casey.connolly@linaro.org>
>>>> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>>>> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
>>>> ---
>>>>    .../bindings/remoteproc/qcom,pas-common.yaml  |  6 ++
>>>>    .../bindings/thermal/qcom,qmi-cooling.yaml    | 99 +++++++++++++++++++
>>>>    2 files changed, 105 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 63a82e7a8bf8..bbc82253f76b 100644
>>>> --- a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
>>>> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
>>>> @@ -77,6 +77,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.
>>>> +    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..90b46712d241
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml
>>>> @@ -0,0 +1,99 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>>> +# Copyright 2023 (c), Linaro Limited
>>>> +
>>>> +%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:
>>>> +  - Caleb Connolly <caleb.connolly@linaro.org>
>>>> +  - 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.
>>>> +
>>>> +  Each subnode corresponds to a control interface for a single instance of the TMD
>>>> +  service running on a remote subsystem.
>>>> +
>>>> +definitions:
>>> defs, look at other code
>>>
>>>
>>>> +  tmd:
>>>> +    type: object
>>>> +    description: |
>>>> +      A single Thermal Mitigation Device exposed by a remote subsystem.
>>> Missing proper formatting. Please do not send us code written by LLM.
>>
>> This patch is based on older series
>>
>> https://lore.kernel.org/linux-devicetree/20230905-caleb-qmi_cooling-v1-0-5aa39d4164a7@linaro.org/, did some manual changes to remove unusable code.
> How? This is v1, not v2. How did you address other comments? Where did
> you provide proper changelog? Why this is not correctly versioned/
>
>> let me fix the formatting. This is not generated code.
> I do not believe, because this:
>
>
>>>> +      phandle: true


As i have mentioned in earlier reply, we are including below series:

https://lore.kernel.org/linux-devicetree/20230905-caleb-qmi_cooling-v1-0-5aa39d4164a7@linaro.org/,) 
as this is client for remote proc cooling.
I was seeing this error while using older yam files.

('cdsp_sw' was unexpected)

from schema qcom,qmi-cooling.yaml

So to avoid that, i have added phandle to avoid this error. will fix 
this in proper way
by including another yaml file which will define the cdsp_sw,

Below is the dt node:
cooling {
+                compatible = "qcom,qmi-cooling-cdsp";
+                    cdsp_sw: cdsp_sw {
+                        label = "cdsp_sw";
+                        #cooling-cells = <2>;
+                    };
+            };


> Does not exist. You cannot come with something like that, there is no
> such code.
>
> Only LLM when parsing DTB could invent something like this. Otherwise
> explain me please the process leading to coming to such change.
>
> Best regards,
> Krzysztof

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

[Krzysztof Kozlowski]

On 31/12/2025 07:42, Gaurav Kohli wrote:
> 
> On 12/24/2025 3:54 PM, Krzysztof Kozlowski wrote:
>> On 24/12/2025 11:08, Gaurav Kohli wrote:
>>> On 12/24/2025 2:27 PM, Krzysztof Kozlowski wrote:
>>>> On 23/12/2025 13:32, 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.
>>>>>
>>>>> Add maintainer name also and update this binding for cdsp substem.
>>>>>
>>>>> Co-developed-by: Casey Connolly <casey.connolly@linaro.org>
>>>>> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>>>>> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
>>>>> ---
>>>>>    .../bindings/remoteproc/qcom,pas-common.yaml  |  6 ++
>>>>>    .../bindings/thermal/qcom,qmi-cooling.yaml    | 99 +++++++++++++++++++
>>>>>    2 files changed, 105 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 63a82e7a8bf8..bbc82253f76b 100644
>>>>> --- a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
>>>>> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
>>>>> @@ -77,6 +77,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.
>>>>> +    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..90b46712d241
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml
>>>>> @@ -0,0 +1,99 @@
>>>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>>>> +# Copyright 2023 (c), Linaro Limited
>>>>> +
>>>>> +%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:
>>>>> +  - Caleb Connolly <caleb.connolly@linaro.org>
>>>>> +  - 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.
>>>>> +
>>>>> +  Each subnode corresponds to a control interface for a single instance of the TMD
>>>>> +  service running on a remote subsystem.
>>>>> +
>>>>> +definitions:
>>>> defs, look at other code
>>>>
>>>>
>>>>> +  tmd:
>>>>> +    type: object
>>>>> +    description: |
>>>>> +      A single Thermal Mitigation Device exposed by a remote subsystem.
>>>> Missing proper formatting. Please do not send us code written by LLM.
>>>
>>> This patch is based on older series
>>>
>>> https://lore.kernel.org/linux-devicetree/20230905-caleb-qmi_cooling-v1-0-5aa39d4164a7@linaro.org/, did some manual changes to remove unusable code.
>> How? This is v1, not v2. How did you address other comments? Where did
>> you provide proper changelog? Why this is not correctly versioned/
>>
>>> let me fix the formatting. This is not generated code.
>> I do not believe, because this:
>>
>>
>>>>> +      phandle: true
> 
> 
> As i have mentioned in earlier reply, we are including below series:
> 
> https://lore.kernel.org/linux-devicetree/20230905-caleb-qmi_cooling-v1-0-5aa39d4164a7@linaro.org/,) 
> as this is client for remote proc cooling.
> I was seeing this error while using older yam files.
> 
> ('cdsp_sw' was unexpected)

cdsp_sw, not phandle.

> 
> from schema qcom,qmi-cooling.yaml
> 
> So to avoid that, i have added phandle to avoid this error. will fix 


Why? AGAIN: SUCH CODE DOES NOT EXIST. Why do you introduce code
completely different than everything else?


Best regards,
Krzysztof

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

[Dmitry Baryshkov]

On Wed, Dec 31, 2025 at 12:12:04PM +0530, Gaurav Kohli wrote:
> 
> On 12/24/2025 3:54 PM, Krzysztof Kozlowski wrote:
> > On 24/12/2025 11:08, Gaurav Kohli wrote:
> > > On 12/24/2025 2:27 PM, Krzysztof Kozlowski wrote:
> > > > On 23/12/2025 13:32, 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.
> > > > > 
> > > > > Add maintainer name also and update this binding for cdsp substem.
> > > > > 
> > > > > Co-developed-by: Casey Connolly <casey.connolly@linaro.org>
> > > > > Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
> > > > > Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
> > > > > ---
> > > > >    .../bindings/remoteproc/qcom,pas-common.yaml  |  6 ++
> > > > >    .../bindings/thermal/qcom,qmi-cooling.yaml    | 99 +++++++++++++++++++
> > > > >    2 files changed, 105 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 63a82e7a8bf8..bbc82253f76b 100644
> > > > > --- a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
> > > > > +++ b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
> > > > > @@ -77,6 +77,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.
> > > > > +    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..90b46712d241
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml
> > > > > @@ -0,0 +1,99 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > +# Copyright 2023 (c), Linaro Limited
> > > > > +
> > > > > +%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:
> > > > > +  - Caleb Connolly <caleb.connolly@linaro.org>
> > > > > +  - 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.
> > > > > +
> > > > > +  Each subnode corresponds to a control interface for a single instance of the TMD
> > > > > +  service running on a remote subsystem.
> > > > > +
> > > > > +definitions:
> > > > defs, look at other code
> > > > 
> > > > 
> > > > > +  tmd:
> > > > > +    type: object
> > > > > +    description: |
> > > > > +      A single Thermal Mitigation Device exposed by a remote subsystem.
> > > > Missing proper formatting. Please do not send us code written by LLM.
> > > 
> > > This patch is based on older series
> > > 
> > > https://lore.kernel.org/linux-devicetree/20230905-caleb-qmi_cooling-v1-0-5aa39d4164a7@linaro.org/, did some manual changes to remove unusable code.
> > How? This is v1, not v2. How did you address other comments? Where did
> > you provide proper changelog? Why this is not correctly versioned/
> > 
> > > let me fix the formatting. This is not generated code.
> > I do not believe, because this:
> > 
> > 
> > > > > +      phandle: true
> 
> 
> As i have mentioned in earlier reply, we are including below series:
> 
> https://lore.kernel.org/linux-devicetree/20230905-caleb-qmi_cooling-v1-0-5aa39d4164a7@linaro.org/,)
> as this is client for remote proc cooling.
> I was seeing this error while using older yam files.
> 
> ('cdsp_sw' was unexpected)
> 
> from schema qcom,qmi-cooling.yaml
> 
> So to avoid that, i have added phandle to avoid this error. will fix this in
> proper way
> by including another yaml file which will define the cdsp_sw,
> 
> Below is the dt node:
> cooling {
> +                compatible = "qcom,qmi-cooling-cdsp";
> +                    cdsp_sw: cdsp_sw {

You can't have a node called cdsp_sw. Underscores are not allowed in
node names.

> +                        label = "cdsp_sw";
> +                        #cooling-cells = <2>;
> +                    };
> +            };
> 
> 
> > Does not exist. You cannot come with something like that, there is no
> > such code.
> > 
> > Only LLM when parsing DTB could invent something like this. Otherwise
> > explain me please the process leading to coming to such change.
> > 
> > Best regards,
> > Krzysztof

-- 
With best wishes
Dmitry

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

[Gaurav Kohli]

On 12/31/2025 1:17 PM, Dmitry Baryshkov wrote:
> On Wed, Dec 31, 2025 at 12:12:04PM +0530, Gaurav Kohli wrote:
>> On 12/24/2025 3:54 PM, Krzysztof Kozlowski wrote:
>>> On 24/12/2025 11:08, Gaurav Kohli wrote:
>>>> On 12/24/2025 2:27 PM, Krzysztof Kozlowski wrote:
>>>>> On 23/12/2025 13:32, 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.
>>>>>>
>>>>>> Add maintainer name also and update this binding for cdsp substem.
>>>>>>
>>>>>> Co-developed-by: Casey Connolly <casey.connolly@linaro.org>
>>>>>> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>>>>>> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
>>>>>> ---
>>>>>>     .../bindings/remoteproc/qcom,pas-common.yaml  |  6 ++
>>>>>>     .../bindings/thermal/qcom,qmi-cooling.yaml    | 99 +++++++++++++++++++
>>>>>>     2 files changed, 105 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 63a82e7a8bf8..bbc82253f76b 100644
>>>>>> --- a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
>>>>>> @@ -77,6 +77,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.
>>>>>> +    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..90b46712d241
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml
>>>>>> @@ -0,0 +1,99 @@
>>>>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>>>>> +# Copyright 2023 (c), Linaro Limited
>>>>>> +
>>>>>> +%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:
>>>>>> +  - Caleb Connolly <caleb.connolly@linaro.org>
>>>>>> +  - 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.
>>>>>> +
>>>>>> +  Each subnode corresponds to a control interface for a single instance of the TMD
>>>>>> +  service running on a remote subsystem.
>>>>>> +
>>>>>> +definitions:
>>>>> defs, look at other code
>>>>>
>>>>>
>>>>>> +  tmd:
>>>>>> +    type: object
>>>>>> +    description: |
>>>>>> +      A single Thermal Mitigation Device exposed by a remote subsystem.
>>>>> Missing proper formatting. Please do not send us code written by LLM.
>>>> This patch is based on older series
>>>>
>>>> https://lore.kernel.org/linux-devicetree/20230905-caleb-qmi_cooling-v1-0-5aa39d4164a7@linaro.org/, did some manual changes to remove unusable code.
>>> How? This is v1, not v2. How did you address other comments? Where did
>>> you provide proper changelog? Why this is not correctly versioned/
>>>
>>>> let me fix the formatting. This is not generated code.
>>> I do not believe, because this:
>>>
>>>
>>>>>> +      phandle: true
>>
>> As i have mentioned in earlier reply, we are including below series:
>>
>> https://lore.kernel.org/linux-devicetree/20230905-caleb-qmi_cooling-v1-0-5aa39d4164a7@linaro.org/,)
>> as this is client for remote proc cooling.
>> I was seeing this error while using older yam files.
>>
>> ('cdsp_sw' was unexpected)
>>
>> from schema qcom,qmi-cooling.yaml
>>
>> So to avoid that, i have added phandle to avoid this error. will fix this in
>> proper way
>> by including another yaml file which will define the cdsp_sw,
>>
>> Below is the dt node:
>> cooling {
>> +                compatible = "qcom,qmi-cooling-cdsp";
>> +                    cdsp_sw: cdsp_sw {
> You can't have a node called cdsp_sw. Underscores are not allowed in
> node names.


Will change to cdsp-sw.

thanks

Gaurav


>> +                        label = "cdsp_sw";
>> +                        #cooling-cells = <2>;
>> +                    };
>> +            };
>>
>>
>>> Does not exist. You cannot come with something like that, there is no
>>> such code.
>>>
>>> Only LLM when parsing DTB could invent something like this. Otherwise
>>> explain me please the process leading to coming to such change.
>>>
>>> Best regards,
>>> Krzysztof

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

[Dmitry Baryshkov]

On 31/12/2025 09:52, Gaurav Kohli wrote:
> 
> On 12/31/2025 1:17 PM, Dmitry Baryshkov wrote:
>> On Wed, Dec 31, 2025 at 12:12:04PM +0530, Gaurav Kohli wrote:
>>> On 12/24/2025 3:54 PM, Krzysztof Kozlowski wrote:
>>>> On 24/12/2025 11:08, Gaurav Kohli wrote:
>>>>> On 12/24/2025 2:27 PM, Krzysztof Kozlowski wrote:
>>>>>> On 23/12/2025 13:32, 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.
>>>>>>>
>>>>>>> Add maintainer name also and update this binding for cdsp substem.
>>>>>>>
>>>>>>> Co-developed-by: Casey Connolly <casey.connolly@linaro.org>
>>>>>>> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>>>>>>> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
>>>>>>> ---
>>>>>>>     .../bindings/remoteproc/qcom,pas-common.yaml  |  6 ++
>>>>>>>     .../bindings/thermal/qcom,qmi-cooling.yaml    | 99 ++++++++++ 
>>>>>>> +++++++++
>>>>>>>     2 files changed, 105 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 63a82e7a8bf8..bbc82253f76b 100644
>>>>>>> --- a/Documentation/devicetree/bindings/remoteproc/qcom,pas- 
>>>>>>> common.yaml
>>>>>>> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,pas- 
>>>>>>> common.yaml
>>>>>>> @@ -77,6 +77,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.
>>>>>>> +    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..90b46712d241
>>>>>>> --- /dev/null
>>>>>>> +++ b/Documentation/devicetree/bindings/thermal/qcom,qmi- 
>>>>>>> cooling.yaml
>>>>>>> @@ -0,0 +1,99 @@
>>>>>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>>>>>> +# Copyright 2023 (c), Linaro Limited
>>>>>>> +
>>>>>>> +%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:
>>>>>>> +  - Caleb Connolly <caleb.connolly@linaro.org>
>>>>>>> +  - 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.
>>>>>>> +
>>>>>>> +  Each subnode corresponds to a control interface for a single 
>>>>>>> instance of the TMD
>>>>>>> +  service running on a remote subsystem.
>>>>>>> +
>>>>>>> +definitions:
>>>>>> defs, look at other code
>>>>>>
>>>>>>
>>>>>>> +  tmd:
>>>>>>> +    type: object
>>>>>>> +    description: |
>>>>>>> +      A single Thermal Mitigation Device exposed by a remote 
>>>>>>> subsystem.
>>>>>> Missing proper formatting. Please do not send us code written by LLM.
>>>>> This patch is based on older series
>>>>>
>>>>> https://lore.kernel.org/linux-devicetree/20230905-caleb- 
>>>>> qmi_cooling-v1-0-5aa39d4164a7@linaro.org/, did some manual changes 
>>>>> to remove unusable code.
>>>> How? This is v1, not v2. How did you address other comments? Where did
>>>> you provide proper changelog? Why this is not correctly versioned/
>>>>
>>>>> let me fix the formatting. This is not generated code.
>>>> I do not believe, because this:
>>>>
>>>>
>>>>>>> +      phandle: true
>>>
>>> As i have mentioned in earlier reply, we are including below series:
>>>
>>> https://lore.kernel.org/linux-devicetree/20230905-caleb-qmi_cooling- 
>>> v1-0-5aa39d4164a7@linaro.org/,)
>>> as this is client for remote proc cooling.
>>> I was seeing this error while using older yam files.
>>>
>>> ('cdsp_sw' was unexpected)
>>>
>>> from schema qcom,qmi-cooling.yaml
>>>
>>> So to avoid that, i have added phandle to avoid this error. will fix 
>>> this in
>>> proper way
>>> by including another yaml file which will define the cdsp_sw,
>>>
>>> Below is the dt node:
>>> cooling {
>>> +                compatible = "qcom,qmi-cooling-cdsp";
>>> +                    cdsp_sw: cdsp_sw {
>> You can't have a node called cdsp_sw. Underscores are not allowed in
>> node names.
> 
> 
> Will change to cdsp-sw.

Why do you need a subnode at all? Can there be multiple cooling 
"devices" for a DSP? Also, if you insist on having a subnode, could you 
please come up with a _generic_ enough name that would describe the 
node? cdsp-sw definitely isn't generic.

> 
> thanks
> 
> Gaurav
> 
> 
>>> +                        label = "cdsp_sw";
>>> +                        #cooling-cells = <2>;
>>> +                    };
>>> +            };
>>>
>>>
>>>> Does not exist. You cannot come with something like that, there is no
>>>> such code.
>>>>
>>>> Only LLM when parsing DTB could invent something like this. Otherwise
>>>> explain me please the process leading to coming to such change.
>>>>
>>>> Best regards,
>>>> Krzysztof


-- 
With best wishes
Dmitry

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

[Krzysztof Kozlowski]

On 23/12/2025 13:32, 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.
> 
> Add maintainer name also and update this binding for cdsp substem.
> 
> Co-developed-by: Casey Connolly <casey.connolly@linaro.org>
> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>

Messed DCO chain.

Best regards,
Krzysztof

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

[Konrad Dybcio]

On 12/23/25 1:32 PM, 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.
> 
> Add maintainer name also and update this binding for cdsp substem.
> 
> Co-developed-by: Casey Connolly <casey.connolly@linaro.org>
> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
> ---

[...]

> +    remoteproc-cdsp {
> +        cooling {
> +            compatible = "qcom,qmi-cooling-cdsp";
> +
> +            cdsp_sw0: cdsp_sw {

I'm curious about the meaning of the name - does "sw" here stand
for "software"?

If so, does this essentially mean "a software toggle for throttling the
CDSP"?

Would all such occurrences essentially always have a "sw" suffix?

Konrad

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

[Gaurav Kohli]

On 12/31/2025 5:29 PM, Konrad Dybcio wrote:
> On 12/23/25 1:32 PM, 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.
>>
>> Add maintainer name also and update this binding for cdsp substem.
>>
>> Co-developed-by: Casey Connolly <casey.connolly@linaro.org>
>> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
>> ---
> [...]
>
>> +    remoteproc-cdsp {
>> +        cooling {
>> +            compatible = "qcom,qmi-cooling-cdsp";
>> +
>> +            cdsp_sw0: cdsp_sw {
> I'm curious about the meaning of the name - does "sw" here stand
> for "software"?


This is same like cdsp DCVS capping from firmware instead of hlos.


>
> If so, does this essentially mean "a software toggle for throttling the
> CDSP"?
>
> Would all such occurrences essentially always have a "sw" suffix?
>
> Konrad

[PATCH v1 4/8] thermal: qcom: add qmi-cooling driver

[Gaurav Kohli]

From: Casey Connolly <casey.connolly@linaro.org>

The Thermal Mitigation Device (TMD) service exposes various platform
specific thermal mitigations available on remote subsystems (ie the
modem and cdsp). The service is exposed via the QMI messaging
interface, usually over the QRTR transport.

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.

Co-developed-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
---
 drivers/soc/qcom/Kconfig           |  13 +
 drivers/soc/qcom/Makefile          |   1 +
 drivers/soc/qcom/qmi-cooling.c     | 498 +++++++++++++++++++++++++++++
 drivers/soc/qcom/qmi-cooling.h     | 428 +++++++++++++++++++++++++
 drivers/thermal/qcom/qmi-cooling.h | 428 +++++++++++++++++++++++++
 5 files changed, 1368 insertions(+)
 create mode 100644 drivers/soc/qcom/qmi-cooling.c
 create mode 100644 drivers/soc/qcom/qmi-cooling.h
 create mode 100644 drivers/thermal/qcom/qmi-cooling.h

diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 2caadbbcf830..905a24b42fe6 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -124,6 +124,19 @@ config QCOM_PMIC_GLINK
 	  Say yes here to support USB-C and battery status on modern Qualcomm
 	  platforms.
 
+config QCOM_QMI_COOLING
+	tristate "Qualcomm QMI cooling drivers"
+	depends on QCOM_RPROC_COMMON
+	depends on ARCH_QCOM || COMPILE_TEST
+	select QCOM_QMI_HELPERS
+	help
+	   This enables the remote subsystem cooling devices. These cooling
+	   devices will be used by Qualcomm chipset to place various remote
+	   subsystem mitigations like remote processor passive mitigation,
+	   remote subsystem voltage restriction at low temperatures etc.
+	   The QMI cooling device will interface with remote subsystem
+	   using Qualcomm remoteproc interface.
+
 config QCOM_QMI_HELPERS
 	tristate
 	depends on NET
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index b7f1d2a57367..b6728f54944b 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_QCOM_PMIC_GLINK)	+= pmic_glink.o
 obj-$(CONFIG_QCOM_PMIC_GLINK)	+= pmic_glink_altmode.o
 obj-$(CONFIG_QCOM_PMIC_PDCHARGER_ULOG)	+= pmic_pdcharger_ulog.o
 CFLAGS_pmic_pdcharger_ulog.o	:=  -I$(src)
+obj-$(CONFIG_QCOM_QMI_COOLING) += qmi-cooling.o
 obj-$(CONFIG_QCOM_QMI_HELPERS)	+= qmi_helpers.o
 qmi_helpers-y	+= qmi_encdec.o qmi_interface.o
 obj-$(CONFIG_QCOM_RAMP_CTRL)	+= ramp_controller.o
diff --git a/drivers/soc/qcom/qmi-cooling.c b/drivers/soc/qcom/qmi-cooling.c
new file mode 100644
index 000000000000..1a6afcb96bf6
--- /dev/null
+++ b/drivers/soc/qcom/qmi-cooling.c
@@ -0,0 +1,498 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2017, The Linux Foundation
+ * Copyright (c) 2025, Linaro Limited
+ *
+ * QMI Thermal Mitigation Device (TMD) client driver.
+ * This driver provides an in-kernel client to handle hot and cold thermal
+ * mitigations for remote subsystems (modem and DSPs) running the TMD service.
+ * It doesn't implement any handling of reports from remote subsystems.
+ */
+
+#include <linux/cleanup.h>
+#include <linux/err.h>
+#include <linux/module.h>
+#include <linux/net.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/remoteproc/qcom_rproc.h>
+#include <linux/remoteproc_cooling.h>
+#include <linux/slab.h>
+#include <linux/soc/qcom/qmi.h>
+#include <linux/thermal.h>
+
+#include "qmi-cooling.h"
+
+#define MODEM0_INSTANCE_ID	0x0
+#define ADSP_INSTANCE_ID	0x1
+#define CDSP_INSTANCE_ID	0x43
+#define SLPI_INSTANCE_ID	0x53
+
+#define QMI_TMD_RESP_TIMEOUT msecs_to_jiffies(100)
+
+/**
+ * struct qmi_tmd_client - TMD client state
+ * @dev:	Device associated with this client
+ * @name:	Friendly name for the remote TMD service
+ * @handle:	QMI connection handle
+ * @mutex:	Lock to synchronise QMI communication
+ * @id:		The QMI TMD service instance ID
+ * @cdev_list:	The list of cooling devices (controls) enabled for this instance
+ * @svc_arrive_work: Work item for initialising the client when the TMD service
+ *		     starts.
+ * @connection_active: Whether or not we're connected to the QMI TMD service
+ */
+struct qmi_tmd_client {
+	struct device *dev;
+	const char *name;
+	struct qmi_handle handle;
+	struct mutex mutex;
+	u32 id;
+	struct list_head cdev_list;
+	struct work_struct svc_arrive_work;
+	bool connection_active;
+};
+
+/**
+ * struct qmi_tmd - A TMD cooling device
+ * @np:		OF node associated with this control
+ * @type:	The control type (exposed via sysfs)
+ * @qmi_name:	The common name of this control shared by the remote subsystem
+ * @rproc_cdev:	Remote processor cooling device handle
+ * @cur_state:	The current cooling/warming/mitigation state
+ * @max_state:	The maximum state
+ * @client:	The TMD client instance this control is associated with
+ */
+struct qmi_tmd {
+	struct device_node *np;
+	const char *type;
+	char qmi_name[QMI_TMD_MITIGATION_DEV_ID_LENGTH_MAX_V01 + 1];
+	struct list_head node;
+	struct remoteproc_cdev *rproc_cdev;
+	unsigned int cur_state;
+	unsigned int max_state;
+	struct qmi_tmd_client *client;
+};
+
+/**
+ * struct qmi_instance_id - QMI instance match data
+ * @id:		The QMI instance ID
+ * @name:	Friendly name for this instance
+ */
+struct qmi_instance_data {
+	u32 id;
+	const char *name;
+};
+
+/* Notify the remote subsystem of the requested cooling state */
+static int qmi_tmd_send_state_request(struct qmi_tmd *tmd)
+{
+	struct tmd_set_mitigation_level_resp_msg_v01 tmd_resp = { 0 };
+	struct tmd_set_mitigation_level_req_msg_v01 req = { 0 };
+	struct qmi_tmd_client *client;
+	struct qmi_txn txn;
+	int ret = 0;
+
+	client = tmd->client;
+
+	guard(mutex)(&client->mutex);
+
+	/*
+	 * This function is called by qmi_set_cur_state() which does not know if
+	 * the QMI service is actually online. If it isn't then we noop here.
+	 * The state is cached in tmd->cur_state and will be broadcast via
+	 * qmi_tmd_init_control() when the service comes up.
+	 */
+	if (!client->connection_active)
+		return 0;
+
+	strscpy(req.mitigation_dev_id.mitigation_dev_id, tmd->qmi_name,
+		QMI_TMD_MITIGATION_DEV_ID_LENGTH_MAX_V01 + 1);
+	req.mitigation_level = tmd->cur_state;
+
+	ret = qmi_txn_init(&client->handle, &txn,
+			   tmd_set_mitigation_level_resp_msg_v01_ei, &tmd_resp);
+	if (ret < 0) {
+		dev_err(client->dev, "qmi set state %d txn init failed for %s ret %d\n",
+			tmd->cur_state, tmd->type, ret);
+		return ret;
+	}
+
+	ret = qmi_send_request(&client->handle, NULL, &txn,
+			       QMI_TMD_SET_MITIGATION_LEVEL_REQ_V01,
+			       TMD_SET_MITIGATION_LEVEL_REQ_MSG_V01_MAX_MSG_LEN,
+			       tmd_set_mitigation_level_req_msg_v01_ei, &req);
+	if (ret < 0) {
+		dev_err(client->dev, "qmi set state %d txn send failed for %s ret %d\n",
+			tmd->cur_state, tmd->type, ret);
+		qmi_txn_cancel(&txn);
+		return ret;
+	}
+
+	ret = qmi_txn_wait(&txn, QMI_TMD_RESP_TIMEOUT);
+	if (ret < 0) {
+		dev_err(client->dev, "qmi set state %d txn wait failed for %s ret %d\n",
+			tmd->cur_state, tmd->type, ret);
+		return ret;
+	}
+
+	if (tmd_resp.resp.result != QMI_RESULT_SUCCESS_V01) {
+		ret = -tmd_resp.resp.result;
+		dev_err(client->dev, "qmi set state %d NOT success for %s ret %d\n",
+			tmd->cur_state, tmd->type, ret);
+		return ret;
+	}
+
+	dev_dbg(client->dev, "Requested state %d/%d for %s\n", tmd->cur_state,
+		tmd->max_state, tmd->type);
+
+	return 0;
+}
+
+static int qmi_get_max_level(void *devdata, unsigned long *level)
+{
+	struct qmi_tmd *tmd = devdata;
+
+	if (!tmd)
+		return -EINVAL;
+
+	*level = tmd->max_state;
+
+	return 0;
+}
+
+static int qmi_get_cur_level(void *devdata, unsigned long *level)
+{
+	struct qmi_tmd *tmd = devdata;
+
+	if (!tmd)
+		return -EINVAL;
+
+	*level = tmd->cur_state;
+
+	return 0;
+}
+
+static int qmi_set_cur_level(void *devdata, unsigned long level)
+{
+	struct qmi_tmd *tmd = devdata;
+
+	if (!tmd)
+		return -EINVAL;
+
+	if (level > tmd->max_state)
+		return -EINVAL;
+
+	if (tmd->cur_state == level)
+		return 0;
+
+	tmd->cur_state = level;
+
+	return qmi_tmd_send_state_request(tmd);
+}
+
+static const struct remoteproc_cooling_ops qmi_rproc_ops = {
+	.get_max_level = qmi_get_max_level,
+	.get_cur_level = qmi_get_cur_level,
+	.set_cur_level = qmi_set_cur_level,
+};
+
+static int qmi_register_cooling_device(struct qmi_tmd *tmd)
+{
+	struct remoteproc_cdev *rproc_cdev;
+
+	rproc_cdev = remoteproc_cooling_register(tmd->np,
+						 tmd->type,
+						 &qmi_rproc_ops,
+						 tmd);
+
+	if (IS_ERR(rproc_cdev))
+		return dev_err_probe(tmd->client->dev, PTR_ERR(rproc_cdev),
+				     "Failed to register cooling device %s\n",
+				     tmd->qmi_name);
+
+	tmd->rproc_cdev = rproc_cdev;
+	return 0;
+}
+
+/*
+ * Init a single TMD control by registering a cooling device for it, or
+ * synchronising state with the remote subsystem if recovering from a service
+ * restart. This is called when the TMD service starts up.
+ */
+static int qmi_tmd_init_control(struct qmi_tmd_client *client, const char *label,
+				u8 max_state)
+{
+	struct qmi_tmd *tmd = NULL;
+
+	list_for_each_entry(tmd, &client->cdev_list, node)
+		if (!strncasecmp(tmd->qmi_name, label,
+				 QMI_TMD_MITIGATION_DEV_ID_LENGTH_MAX_V01 + 1))
+			goto found;
+
+	dev_dbg(client->dev,
+		"TMD '%s' available in firmware but not specified in DT\n",
+		label);
+	return 0;
+
+found:
+	tmd->max_state = max_state;
+	/*
+	 * If the cooling device already exists then the QMI service went away and
+	 * came back. So just make sure the current cooling device state is
+	 * reflected on the remote side and then return.
+	 */
+	if (tmd->rproc_cdev)
+		return qmi_tmd_send_state_request(tmd);
+
+	return qmi_register_cooling_device(tmd);
+}
+
+/*
+ * When the QMI service starts up on a remote subsystem this function will fetch
+ * the list of TMDs on the subsystem, match it to the TMDs specified in devicetree
+ * and call qmi_tmd_init_control() for each
+ */
+static void qmi_tmd_svc_arrive(struct work_struct *work)
+{
+	struct qmi_tmd_client *client =
+		container_of(work, struct qmi_tmd_client, svc_arrive_work);
+
+	struct tmd_get_mitigation_device_list_req_msg_v01 req = { 0 };
+	struct tmd_get_mitigation_device_list_resp_msg_v01 *resp __free(kfree);
+	int ret = 0, i;
+	struct qmi_txn txn;
+
+	/* resp struct is 1.1kB, allocate it on the heap. */
+	resp = kzalloc(sizeof(*resp), GFP_KERNEL);
+	if (!resp)
+		return;
+
+	/* Get a list of TMDs supported by the remoteproc */
+	scoped_guard(mutex, &client->mutex) {
+		ret = qmi_txn_init(&client->handle, &txn,
+				tmd_get_mitigation_device_list_resp_msg_v01_ei, resp);
+		if (ret < 0) {
+			dev_err(client->dev,
+				"Transaction init error for instance_id: %#x ret %d\n",
+				client->id, ret);
+			return;
+		}
+
+		ret = qmi_send_request(&client->handle, NULL, &txn,
+				QMI_TMD_GET_MITIGATION_DEVICE_LIST_REQ_V01,
+				TMD_GET_MITIGATION_DEVICE_LIST_REQ_MSG_V01_MAX_MSG_LEN,
+				tmd_get_mitigation_device_list_req_msg_v01_ei, &req);
+		if (ret < 0) {
+			qmi_txn_cancel(&txn);
+			return;
+		}
+
+		ret = qmi_txn_wait(&txn, QMI_TMD_RESP_TIMEOUT);
+		if (ret < 0) {
+			dev_err(client->dev, "Transaction wait error for client %#x ret:%d\n",
+				client->id, ret);
+			return;
+		}
+		if (resp->resp.result != QMI_RESULT_SUCCESS_V01) {
+			ret = resp->resp.result;
+			dev_err(client->dev, "Failed to get device list for client %#x ret:%d\n",
+				client->id, ret);
+			return;
+		}
+
+		client->connection_active = true;
+	}
+
+	for (i = 0; i < resp->mitigation_device_list_len; i++) {
+		struct tmd_mitigation_dev_list_type_v01 *device =
+			&resp->mitigation_device_list[i];
+
+		ret = qmi_tmd_init_control(client,
+					   device->mitigation_dev_id.mitigation_dev_id,
+					   device->max_mitigation_level);
+		if (ret)
+			break;
+	}
+}
+
+static void thermal_qmi_net_reset(struct qmi_handle *qmi)
+{
+	struct qmi_tmd_client *client = container_of(qmi, struct qmi_tmd_client, handle);
+	struct qmi_tmd *tmd = NULL;
+
+	list_for_each_entry(tmd, &client->cdev_list, node) {
+		qmi_tmd_send_state_request(tmd);
+	}
+}
+
+static void thermal_qmi_del_server(struct qmi_handle *qmi, struct qmi_service *service)
+{
+	struct qmi_tmd_client *client = container_of(qmi, struct qmi_tmd_client, handle);
+
+	scoped_guard(mutex, &client->mutex)
+		client->connection_active = false;
+}
+
+static int thermal_qmi_new_server(struct qmi_handle *qmi, struct qmi_service *service)
+{
+	struct qmi_tmd_client *client = container_of(qmi, struct qmi_tmd_client, handle);
+	struct sockaddr_qrtr sq = { AF_QIPCRTR, service->node, service->port };
+
+	scoped_guard(mutex, &client->mutex)
+		kernel_connect(qmi->sock, (struct sockaddr_unsized *)&sq, sizeof(sq), 0);
+
+	queue_work(system_highpri_wq, &client->svc_arrive_work);
+
+	return 0;
+}
+
+static struct qmi_ops thermal_qmi_event_ops = {
+	.new_server = thermal_qmi_new_server,
+	.del_server = thermal_qmi_del_server,
+	.net_reset = thermal_qmi_net_reset,
+};
+
+static void qmi_tmd_cleanup(struct qmi_tmd_client *client)
+{
+	struct qmi_tmd *tmd, *c_next;
+
+	guard(mutex)(&client->mutex);
+
+	client->connection_active = false;
+
+	qmi_handle_release(&client->handle);
+	cancel_work(&client->svc_arrive_work);
+	list_for_each_entry_safe(tmd, c_next, &client->cdev_list, node) {
+		if (tmd->rproc_cdev)
+			remoteproc_cooling_unregister(tmd->rproc_cdev);
+
+		list_del(&tmd->node);
+	}
+}
+
+/* Parse the controls and allocate a qmi_tmd for each of them */
+static int qmi_tmd_alloc_cdevs(struct qmi_tmd_client *client)
+{
+	struct device *dev = client->dev;
+	struct qmi_tmd *tmd;
+	struct device_node *subnode, *node = dev->of_node;
+	int ret;
+
+	for_each_available_child_of_node(node, subnode) {
+		const char *name;
+
+		tmd = devm_kzalloc(dev, sizeof(*tmd), GFP_KERNEL);
+		if (!tmd)
+			return dev_err_probe(client->dev, -ENOMEM,
+					     "Couldn't allocate tmd\n");
+
+		tmd->type = devm_kasprintf(client->dev, GFP_KERNEL, "%s:%s",
+						client->name, subnode->name);
+		if (!tmd->type)
+			return dev_err_probe(dev, -ENOMEM,
+					     "Couldn't allocate cooling device name\n");
+
+		if (of_property_read_string(subnode, "label", &name)) {
+			return dev_err_probe(client->dev, -EINVAL,
+					     "Failed to parse dev name for %s\n",
+					     subnode->name);
+		}
+
+		ret = strscpy(tmd->qmi_name, name,
+			      QMI_TMD_MITIGATION_DEV_ID_LENGTH_MAX_V01 + 1);
+		if (ret == -E2BIG) {
+			return dev_err_probe(dev, -EINVAL, "TMD label %s is too long\n",
+					     name);
+		}
+
+		tmd->client = client;
+		tmd->np = subnode;
+		tmd->cur_state = 0;
+		list_add(&tmd->node, &client->cdev_list);
+	}
+
+	if (list_empty(&client->cdev_list))
+		return dev_err_probe(client->dev, -EINVAL,
+				     "No cooling devices specified for client %s (%#x)\n",
+				     client->name, client->id);
+
+	return 0;
+}
+
+static int qmi_tmd_client_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct qmi_tmd_client *client;
+	const struct qmi_instance_data *match;
+	int ret;
+	client = devm_kzalloc(dev, sizeof(*client), GFP_KERNEL);
+	if (!client)
+		return -ENOMEM;
+
+	client->dev = dev;
+
+	match = of_device_get_match_data(dev);
+	if (!match)
+		return dev_err_probe(dev, -EINVAL, "No match data\n");
+
+	client->id = match->id;
+	client->name = match->name;
+
+	mutex_init(&client->mutex);
+	INIT_LIST_HEAD(&client->cdev_list);
+	INIT_WORK(&client->svc_arrive_work, qmi_tmd_svc_arrive);
+
+	ret = qmi_tmd_alloc_cdevs(client);
+	if (ret)
+		return ret;
+
+	platform_set_drvdata(pdev, client);
+
+	ret = qmi_handle_init(&client->handle,
+			      TMD_GET_MITIGATION_DEVICE_LIST_RESP_MSG_V01_MAX_MSG_LEN,
+			      &thermal_qmi_event_ops, NULL);
+	if (ret < 0)
+		return dev_err_probe(client->dev, ret, "QMI handle init failed for client %#x\n",
+			      client->id);
+
+	ret = qmi_add_lookup(&client->handle, TMD_SERVICE_ID_V01, TMD_SERVICE_VERS_V01,
+			     client->id);
+	if (ret < 0) {
+		qmi_handle_release(&client->handle);
+		return dev_err_probe(client->dev, ret, "QMI register failed for client 0x%x\n",
+			      client->id);
+	}
+
+	return 0;
+}
+
+static void qmi_tmd_client_remove(struct platform_device *pdev)
+{
+	struct qmi_tmd_client *client = platform_get_drvdata(pdev);
+
+	qmi_tmd_cleanup(client);
+}
+
+static const struct of_device_id qmi_tmd_device_table[] = {
+	{
+		.compatible = "qcom,qmi-cooling-cdsp",
+		.data = &((struct qmi_instance_data) { CDSP_INSTANCE_ID, "cdsp" }),
+	},
+	{}
+};
+MODULE_DEVICE_TABLE(of, qmi_tmd_device_table);
+
+static struct platform_driver qmi_tmd_device_driver = {
+	.probe = qmi_tmd_client_probe,
+	.remove = qmi_tmd_client_remove,
+	.driver = {
+		.name = "qcom-qmi-cooling",
+		.of_match_table = qmi_tmd_device_table,
+	},
+};
+
+module_platform_driver(qmi_tmd_device_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Qualcomm QMI Thermal Mitigation Device driver");
diff --git a/drivers/soc/qcom/qmi-cooling.h b/drivers/soc/qcom/qmi-cooling.h
new file mode 100644
index 000000000000..f46b827b4ce6
--- /dev/null
+++ b/drivers/soc/qcom/qmi-cooling.h
@@ -0,0 +1,428 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2017, The Linux Foundation
+ * Copyright (c) 2023, Linaro Limited
+ */
+
+#ifndef __QCOM_COOLING_H__
+#define __QCOM_COOLING_H__
+
+#include <linux/soc/qcom/qmi.h>
+
+#define TMD_SERVICE_ID_V01 0x18
+#define TMD_SERVICE_VERS_V01 0x01
+
+#define QMI_TMD_GET_MITIGATION_DEVICE_LIST_RESP_V01 0x0020
+#define QMI_TMD_GET_MITIGATION_LEVEL_REQ_V01 0x0022
+#define QMI_TMD_GET_SUPPORTED_MSGS_REQ_V01 0x001E
+#define QMI_TMD_SET_MITIGATION_LEVEL_REQ_V01 0x0021
+#define QMI_TMD_REGISTER_NOTIFICATION_MITIGATION_LEVEL_RESP_V01 0x0023
+#define QMI_TMD_GET_SUPPORTED_MSGS_RESP_V01 0x001E
+#define QMI_TMD_SET_MITIGATION_LEVEL_RESP_V01 0x0021
+#define QMI_TMD_DEREGISTER_NOTIFICATION_MITIGATION_LEVEL_RESP_V01 0x0024
+#define QMI_TMD_MITIGATION_LEVEL_REPORT_IND_V01 0x0025
+#define QMI_TMD_GET_MITIGATION_LEVEL_RESP_V01 0x0022
+#define QMI_TMD_GET_SUPPORTED_FIELDS_REQ_V01 0x001F
+#define QMI_TMD_GET_MITIGATION_DEVICE_LIST_REQ_V01 0x0020
+#define QMI_TMD_REGISTER_NOTIFICATION_MITIGATION_LEVEL_REQ_V01 0x0023
+#define QMI_TMD_DEREGISTER_NOTIFICATION_MITIGATION_LEVEL_REQ_V01 0x0024
+#define QMI_TMD_GET_SUPPORTED_FIELDS_RESP_V01 0x001F
+
+#define QMI_TMD_MITIGATION_DEV_ID_LENGTH_MAX_V01 32
+#define QMI_TMD_MITIGATION_DEV_LIST_MAX_V01 32
+
+struct tmd_mitigation_dev_id_type_v01 {
+	char mitigation_dev_id[QMI_TMD_MITIGATION_DEV_ID_LENGTH_MAX_V01 + 1];
+};
+
+static const struct qmi_elem_info tmd_mitigation_dev_id_type_v01_ei[] = {
+	{
+		.data_type = QMI_STRING,
+		.elem_len = QMI_TMD_MITIGATION_DEV_ID_LENGTH_MAX_V01 + 1,
+		.elem_size = sizeof(char),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0,
+		.offset = offsetof(struct tmd_mitigation_dev_id_type_v01,
+				   mitigation_dev_id),
+	},
+	{
+		.data_type = QMI_EOTI,
+		.array_type = NO_ARRAY,
+		.tlv_type = QMI_COMMON_TLV_TYPE,
+	},
+};
+
+struct tmd_mitigation_dev_list_type_v01 {
+	struct tmd_mitigation_dev_id_type_v01 mitigation_dev_id;
+	uint8_t max_mitigation_level;
+};
+
+static const struct qmi_elem_info tmd_mitigation_dev_list_type_v01_ei[] = {
+	{
+		.data_type = QMI_STRUCT,
+		.elem_len = 1,
+		.elem_size = sizeof(struct tmd_mitigation_dev_id_type_v01),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0,
+		.offset = offsetof(struct tmd_mitigation_dev_list_type_v01,
+				   mitigation_dev_id),
+		.ei_array = tmd_mitigation_dev_id_type_v01_ei,
+	},
+	{
+		.data_type = QMI_UNSIGNED_1_BYTE,
+		.elem_len = 1,
+		.elem_size = sizeof(uint8_t),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0,
+		.offset = offsetof(struct tmd_mitigation_dev_list_type_v01,
+				   max_mitigation_level),
+	},
+	{
+		.data_type = QMI_EOTI,
+		.array_type = NO_ARRAY,
+		.tlv_type = QMI_COMMON_TLV_TYPE,
+	},
+};
+
+struct tmd_get_mitigation_device_list_req_msg_v01 {
+	char placeholder;
+};
+
+#define TMD_GET_MITIGATION_DEVICE_LIST_REQ_MSG_V01_MAX_MSG_LEN 0
+const struct qmi_elem_info tmd_get_mitigation_device_list_req_msg_v01_ei[] = {
+	{
+		.data_type = QMI_EOTI,
+		.array_type = NO_ARRAY,
+		.tlv_type = QMI_COMMON_TLV_TYPE,
+	},
+};
+
+struct tmd_get_mitigation_device_list_resp_msg_v01 {
+	struct qmi_response_type_v01 resp;
+	uint8_t mitigation_device_list_valid;
+	uint32_t mitigation_device_list_len;
+	struct tmd_mitigation_dev_list_type_v01
+		mitigation_device_list[QMI_TMD_MITIGATION_DEV_LIST_MAX_V01];
+};
+
+#define TMD_GET_MITIGATION_DEVICE_LIST_RESP_MSG_V01_MAX_MSG_LEN 1099
+static const struct qmi_elem_info tmd_get_mitigation_device_list_resp_msg_v01_ei[] = {
+	{
+		.data_type = QMI_STRUCT,
+		.elem_len = 1,
+		.elem_size = sizeof(struct qmi_response_type_v01),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0x02,
+		.offset = offsetof(struct tmd_get_mitigation_device_list_resp_msg_v01,
+				   resp),
+		.ei_array = qmi_response_type_v01_ei,
+	},
+	{
+		.data_type = QMI_OPT_FLAG,
+		.elem_len = 1,
+		.elem_size = sizeof(uint8_t),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0x10,
+		.offset = offsetof(struct tmd_get_mitigation_device_list_resp_msg_v01,
+				   mitigation_device_list_valid),
+	},
+	{
+		.data_type = QMI_DATA_LEN,
+		.elem_len = 1,
+		.elem_size = sizeof(uint8_t),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0x10,
+		.offset = offsetof(struct tmd_get_mitigation_device_list_resp_msg_v01,
+				   mitigation_device_list_len),
+	},
+	{
+		.data_type = QMI_STRUCT,
+		.elem_len = QMI_TMD_MITIGATION_DEV_LIST_MAX_V01,
+		.elem_size = sizeof(struct tmd_mitigation_dev_list_type_v01),
+		.array_type = VAR_LEN_ARRAY,
+		.tlv_type = 0x10,
+		.offset = offsetof(struct tmd_get_mitigation_device_list_resp_msg_v01,
+				   mitigation_device_list),
+		.ei_array = tmd_mitigation_dev_list_type_v01_ei,
+	},
+	{
+		.data_type = QMI_EOTI,
+		.array_type = NO_ARRAY,
+		.tlv_type = QMI_COMMON_TLV_TYPE,
+	},
+};
+
+struct tmd_set_mitigation_level_req_msg_v01 {
+	struct tmd_mitigation_dev_id_type_v01 mitigation_dev_id;
+	uint8_t mitigation_level;
+};
+
+#define TMD_SET_MITIGATION_LEVEL_REQ_MSG_V01_MAX_MSG_LEN 40
+static const struct qmi_elem_info tmd_set_mitigation_level_req_msg_v01_ei[] = {
+	{
+		.data_type = QMI_STRUCT,
+		.elem_len = 1,
+		.elem_size = sizeof(struct tmd_mitigation_dev_id_type_v01),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0x01,
+		.offset = offsetof(struct tmd_set_mitigation_level_req_msg_v01,
+				   mitigation_dev_id),
+		.ei_array = tmd_mitigation_dev_id_type_v01_ei,
+	},
+	{
+		.data_type = QMI_UNSIGNED_1_BYTE,
+		.elem_len = 1,
+		.elem_size = sizeof(uint8_t),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0x02,
+		.offset = offsetof(struct tmd_set_mitigation_level_req_msg_v01,
+				   mitigation_level),
+	},
+	{
+		.data_type = QMI_EOTI,
+		.array_type = NO_ARRAY,
+		.tlv_type = QMI_COMMON_TLV_TYPE,
+	},
+};
+
+struct tmd_set_mitigation_level_resp_msg_v01 {
+	struct qmi_response_type_v01 resp;
+};
+
+#define TMD_SET_MITIGATION_LEVEL_RESP_MSG_V01_MAX_MSG_LEN 7
+static const struct qmi_elem_info tmd_set_mitigation_level_resp_msg_v01_ei[] = {
+	{
+		.data_type = QMI_STRUCT,
+		.elem_len = 1,
+		.elem_size = sizeof(struct qmi_response_type_v01),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0x02,
+		.offset = offsetof(struct tmd_set_mitigation_level_resp_msg_v01, resp),
+		.ei_array = qmi_response_type_v01_ei,
+	},
+	{
+		.data_type = QMI_EOTI,
+		.array_type = NO_ARRAY,
+		.tlv_type = QMI_COMMON_TLV_TYPE,
+	},
+};
+
+struct tmd_get_mitigation_level_req_msg_v01 {
+	struct tmd_mitigation_dev_id_type_v01 mitigation_device;
+};
+#define TMD_GET_MITIGATION_LEVEL_REQ_MSG_V01_MAX_MSG_LEN 36
+
+static const struct qmi_elem_info tmd_get_mitigation_level_req_msg_v01_ei[] = {
+	{
+		.data_type = QMI_STRUCT,
+		.elem_len = 1,
+		.elem_size = sizeof(struct tmd_mitigation_dev_id_type_v01),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0x01,
+		.offset = offsetof(struct tmd_get_mitigation_level_req_msg_v01,
+				   mitigation_device),
+		.ei_array = tmd_mitigation_dev_id_type_v01_ei,
+	},
+	{
+		.data_type = QMI_EOTI,
+		.array_type = NO_ARRAY,
+		.tlv_type = QMI_COMMON_TLV_TYPE,
+	},
+};
+
+struct tmd_get_mitigation_level_resp_msg_v01 {
+	struct qmi_response_type_v01 resp;
+	uint8_t current_mitigation_level_valid;
+	uint8_t current_mitigation_level;
+	uint8_t requested_mitigation_level_valid;
+	uint8_t requested_mitigation_level;
+};
+
+#define TMD_GET_MITIGATION_LEVEL_RESP_MSG_V01_MAX_MSG_LEN 15
+static const struct qmi_elem_info tmd_get_mitigation_level_resp_msg_ei[] = {
+	{
+		.data_type = QMI_STRUCT,
+		.elem_len = 1,
+		.elem_size = sizeof(struct qmi_response_type_v01),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0x02,
+		.offset = offsetof(struct tmd_get_mitigation_level_resp_msg_v01, resp),
+		.ei_array = qmi_response_type_v01_ei,
+	},
+	{
+		.data_type = QMI_OPT_FLAG,
+		.elem_len = 1,
+		.elem_size = sizeof(uint8_t),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0x10,
+		.offset = offsetof(struct tmd_get_mitigation_level_resp_msg_v01,
+				   current_mitigation_level_valid),
+	},
+	{
+		.data_type = QMI_UNSIGNED_1_BYTE,
+		.elem_len = 1,
+		.elem_size = sizeof(uint8_t),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0x10,
+		.offset = offsetof(struct tmd_get_mitigation_level_resp_msg_v01,
+				   current_mitigation_level),
+	},
+	{
+		.data_type = QMI_OPT_FLAG,
+		.elem_len = 1,
+		.elem_size = sizeof(uint8_t),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0x11,
+		.offset = offsetof(struct tmd_get_mitigation_level_resp_msg_v01,
+				   requested_mitigation_level_valid),
+	},
+	{
+		.data_type = QMI_UNSIGNED_1_BYTE,
+		.elem_len = 1,
+		.elem_size = sizeof(uint8_t),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0x11,
+		.offset = offsetof(struct tmd_get_mitigation_level_resp_msg_v01,
+				   requested_mitigation_level),
+	},
+	{
+		.data_type = QMI_EOTI,
+		.array_type = NO_ARRAY,
+		.tlv_type = QMI_COMMON_TLV_TYPE,
+	},
+};
+
+struct tmd_register_notification_mitigation_level_req_msg_v01 {
+	struct tmd_mitigation_dev_id_type_v01 mitigation_device;
+};
+
+#define TMD_REGISTER_NOTIFICATION_MITIGATION_LEVEL_REQ_MSG_V01_MAX_MSG_LEN 36
+static const struct qmi_elem_info
+	tmd_register_notification_mitigation_level_req_msg_v01_ei[] = {
+		{
+			.data_type = QMI_STRUCT,
+			.elem_len = 1,
+			.elem_size = sizeof(struct tmd_mitigation_dev_id_type_v01),
+			.array_type = NO_ARRAY,
+			.tlv_type = 0x01,
+			.offset = offsetof(
+				struct tmd_register_notification_mitigation_level_req_msg_v01,
+				mitigation_device),
+			.ei_array = tmd_mitigation_dev_id_type_v01_ei,
+		},
+		{
+			.data_type = QMI_EOTI,
+			.array_type = NO_ARRAY,
+			.tlv_type = QMI_COMMON_TLV_TYPE,
+		},
+	};
+
+struct tmd_register_notification_mitigation_level_resp_msg_v01 {
+	struct qmi_response_type_v01 resp;
+};
+
+#define TMD_REGISTER_NOTIFICATION_MITIGATION_LEVEL_RESP_MSG_V01_MAX_MSG_LEN 7
+static const struct qmi_elem_info
+	tmd_register_notification_mitigation_level_resp_msg_v01_ei[] = {
+		{
+			.data_type = QMI_STRUCT,
+			.elem_len = 1,
+			.elem_size = sizeof(struct qmi_response_type_v01),
+			.array_type = NO_ARRAY,
+			.tlv_type = 0x02,
+			.offset = offsetof(
+				struct tmd_register_notification_mitigation_level_resp_msg_v01,
+				resp),
+			.ei_array = qmi_response_type_v01_ei,
+		},
+		{
+			.data_type = QMI_EOTI,
+			.array_type = NO_ARRAY,
+			.tlv_type = QMI_COMMON_TLV_TYPE,
+		},
+	};
+
+struct tmd_deregister_notification_mitigation_level_req_msg_v01 {
+	struct tmd_mitigation_dev_id_type_v01 mitigation_device;
+};
+
+#define TMD_DEREGISTER_NOTIFICATION_MITIGATION_LEVEL_REQ_MSG_V01_MAX_MSG_LEN 36
+static const struct qmi_elem_info
+	tmd_deregister_notification_mitigation_level_req_msg_v01_ei[] = {
+		{
+			.data_type = QMI_STRUCT,
+			.elem_len = 1,
+			.elem_size = sizeof(struct tmd_mitigation_dev_id_type_v01),
+			.array_type = NO_ARRAY,
+			.tlv_type = 0x01,
+			.offset = offsetof(
+				struct tmd_deregister_notification_mitigation_level_req_msg_v01,
+				mitigation_device),
+			.ei_array = tmd_mitigation_dev_id_type_v01_ei,
+		},
+		{
+			.data_type = QMI_EOTI,
+			.array_type = NO_ARRAY,
+			.tlv_type = QMI_COMMON_TLV_TYPE,
+		},
+	};
+
+struct tmd_deregister_notification_mitigation_level_resp_msg_v01 {
+	struct qmi_response_type_v01 resp;
+};
+
+#define TMD_DEREGISTER_NOTIFICATION_MITIGATION_LEVEL_RESP_MSG_V01_MAX_MSG_LEN 7
+static const struct qmi_elem_info
+	tmd_deregister_notification_mitigation_level_resp_msg_v01_ei[] = {
+		{
+			.data_type = QMI_STRUCT,
+			.elem_len = 1,
+			.elem_size = sizeof(struct qmi_response_type_v01),
+			.array_type = NO_ARRAY,
+			.tlv_type = 0x02,
+			.offset = offsetof(
+				struct tmd_deregister_notification_mitigation_level_resp_msg_v01,
+				resp),
+			.ei_array = qmi_response_type_v01_ei,
+		},
+		{
+			.data_type = QMI_EOTI,
+			.array_type = NO_ARRAY,
+			.tlv_type = QMI_COMMON_TLV_TYPE,
+		},
+	};
+
+struct tmd_mitigation_level_report_ind_msg_v01 {
+	struct tmd_mitigation_dev_id_type_v01 mitigation_device;
+	uint8_t current_mitigation_level;
+};
+
+#define TMD_MITIGATION_LEVEL_REPORT_IND_MSG_V01_MAX_MSG_LEN 40
+static const struct qmi_elem_info tmd_mitigation_level_report_ind_msg_v01_ei[] = {
+	{
+		.data_type = QMI_STRUCT,
+		.elem_len = 1,
+		.elem_size = sizeof(struct tmd_mitigation_dev_id_type_v01),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0x01,
+		.offset = offsetof(struct tmd_mitigation_level_report_ind_msg_v01,
+				   mitigation_device),
+		.ei_array = tmd_mitigation_dev_id_type_v01_ei,
+	},
+	{
+		.data_type = QMI_UNSIGNED_1_BYTE,
+		.elem_len = 1,
+		.elem_size = sizeof(uint8_t),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0x02,
+		.offset = offsetof(struct tmd_mitigation_level_report_ind_msg_v01,
+				   current_mitigation_level),
+	},
+	{
+		.data_type = QMI_EOTI,
+		.array_type = NO_ARRAY,
+		.tlv_type = QMI_COMMON_TLV_TYPE,
+	},
+};
+
+#endif /* __QMI_COOLING_INTERNAL_H__ */
diff --git a/drivers/thermal/qcom/qmi-cooling.h b/drivers/thermal/qcom/qmi-cooling.h
new file mode 100644
index 000000000000..f46b827b4ce6
--- /dev/null
+++ b/drivers/thermal/qcom/qmi-cooling.h
@@ -0,0 +1,428 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2017, The Linux Foundation
+ * Copyright (c) 2023, Linaro Limited
+ */
+
+#ifndef __QCOM_COOLING_H__
+#define __QCOM_COOLING_H__
+
+#include <linux/soc/qcom/qmi.h>
+
+#define TMD_SERVICE_ID_V01 0x18
+#define TMD_SERVICE_VERS_V01 0x01
+
+#define QMI_TMD_GET_MITIGATION_DEVICE_LIST_RESP_V01 0x0020
+#define QMI_TMD_GET_MITIGATION_LEVEL_REQ_V01 0x0022
+#define QMI_TMD_GET_SUPPORTED_MSGS_REQ_V01 0x001E
+#define QMI_TMD_SET_MITIGATION_LEVEL_REQ_V01 0x0021
+#define QMI_TMD_REGISTER_NOTIFICATION_MITIGATION_LEVEL_RESP_V01 0x0023
+#define QMI_TMD_GET_SUPPORTED_MSGS_RESP_V01 0x001E
+#define QMI_TMD_SET_MITIGATION_LEVEL_RESP_V01 0x0021
+#define QMI_TMD_DEREGISTER_NOTIFICATION_MITIGATION_LEVEL_RESP_V01 0x0024
+#define QMI_TMD_MITIGATION_LEVEL_REPORT_IND_V01 0x0025
+#define QMI_TMD_GET_MITIGATION_LEVEL_RESP_V01 0x0022
+#define QMI_TMD_GET_SUPPORTED_FIELDS_REQ_V01 0x001F
+#define QMI_TMD_GET_MITIGATION_DEVICE_LIST_REQ_V01 0x0020
+#define QMI_TMD_REGISTER_NOTIFICATION_MITIGATION_LEVEL_REQ_V01 0x0023
+#define QMI_TMD_DEREGISTER_NOTIFICATION_MITIGATION_LEVEL_REQ_V01 0x0024
+#define QMI_TMD_GET_SUPPORTED_FIELDS_RESP_V01 0x001F
+
+#define QMI_TMD_MITIGATION_DEV_ID_LENGTH_MAX_V01 32
+#define QMI_TMD_MITIGATION_DEV_LIST_MAX_V01 32
+
+struct tmd_mitigation_dev_id_type_v01 {
+	char mitigation_dev_id[QMI_TMD_MITIGATION_DEV_ID_LENGTH_MAX_V01 + 1];
+};
+
+static const struct qmi_elem_info tmd_mitigation_dev_id_type_v01_ei[] = {
+	{
+		.data_type = QMI_STRING,
+		.elem_len = QMI_TMD_MITIGATION_DEV_ID_LENGTH_MAX_V01 + 1,
+		.elem_size = sizeof(char),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0,
+		.offset = offsetof(struct tmd_mitigation_dev_id_type_v01,
+				   mitigation_dev_id),
+	},
+	{
+		.data_type = QMI_EOTI,
+		.array_type = NO_ARRAY,
+		.tlv_type = QMI_COMMON_TLV_TYPE,
+	},
+};
+
+struct tmd_mitigation_dev_list_type_v01 {
+	struct tmd_mitigation_dev_id_type_v01 mitigation_dev_id;
+	uint8_t max_mitigation_level;
+};
+
+static const struct qmi_elem_info tmd_mitigation_dev_list_type_v01_ei[] = {
+	{
+		.data_type = QMI_STRUCT,
+		.elem_len = 1,
+		.elem_size = sizeof(struct tmd_mitigation_dev_id_type_v01),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0,
+		.offset = offsetof(struct tmd_mitigation_dev_list_type_v01,
+				   mitigation_dev_id),
+		.ei_array = tmd_mitigation_dev_id_type_v01_ei,
+	},
+	{
+		.data_type = QMI_UNSIGNED_1_BYTE,
+		.elem_len = 1,
+		.elem_size = sizeof(uint8_t),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0,
+		.offset = offsetof(struct tmd_mitigation_dev_list_type_v01,
+				   max_mitigation_level),
+	},
+	{
+		.data_type = QMI_EOTI,
+		.array_type = NO_ARRAY,
+		.tlv_type = QMI_COMMON_TLV_TYPE,
+	},
+};
+
+struct tmd_get_mitigation_device_list_req_msg_v01 {
+	char placeholder;
+};
+
+#define TMD_GET_MITIGATION_DEVICE_LIST_REQ_MSG_V01_MAX_MSG_LEN 0
+const struct qmi_elem_info tmd_get_mitigation_device_list_req_msg_v01_ei[] = {
+	{
+		.data_type = QMI_EOTI,
+		.array_type = NO_ARRAY,
+		.tlv_type = QMI_COMMON_TLV_TYPE,
+	},
+};
+
+struct tmd_get_mitigation_device_list_resp_msg_v01 {
+	struct qmi_response_type_v01 resp;
+	uint8_t mitigation_device_list_valid;
+	uint32_t mitigation_device_list_len;
+	struct tmd_mitigation_dev_list_type_v01
+		mitigation_device_list[QMI_TMD_MITIGATION_DEV_LIST_MAX_V01];
+};
+
+#define TMD_GET_MITIGATION_DEVICE_LIST_RESP_MSG_V01_MAX_MSG_LEN 1099
+static const struct qmi_elem_info tmd_get_mitigation_device_list_resp_msg_v01_ei[] = {
+	{
+		.data_type = QMI_STRUCT,
+		.elem_len = 1,
+		.elem_size = sizeof(struct qmi_response_type_v01),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0x02,
+		.offset = offsetof(struct tmd_get_mitigation_device_list_resp_msg_v01,
+				   resp),
+		.ei_array = qmi_response_type_v01_ei,
+	},
+	{
+		.data_type = QMI_OPT_FLAG,
+		.elem_len = 1,
+		.elem_size = sizeof(uint8_t),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0x10,
+		.offset = offsetof(struct tmd_get_mitigation_device_list_resp_msg_v01,
+				   mitigation_device_list_valid),
+	},
+	{
+		.data_type = QMI_DATA_LEN,
+		.elem_len = 1,
+		.elem_size = sizeof(uint8_t),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0x10,
+		.offset = offsetof(struct tmd_get_mitigation_device_list_resp_msg_v01,
+				   mitigation_device_list_len),
+	},
+	{
+		.data_type = QMI_STRUCT,
+		.elem_len = QMI_TMD_MITIGATION_DEV_LIST_MAX_V01,
+		.elem_size = sizeof(struct tmd_mitigation_dev_list_type_v01),
+		.array_type = VAR_LEN_ARRAY,
+		.tlv_type = 0x10,
+		.offset = offsetof(struct tmd_get_mitigation_device_list_resp_msg_v01,
+				   mitigation_device_list),
+		.ei_array = tmd_mitigation_dev_list_type_v01_ei,
+	},
+	{
+		.data_type = QMI_EOTI,
+		.array_type = NO_ARRAY,
+		.tlv_type = QMI_COMMON_TLV_TYPE,
+	},
+};
+
+struct tmd_set_mitigation_level_req_msg_v01 {
+	struct tmd_mitigation_dev_id_type_v01 mitigation_dev_id;
+	uint8_t mitigation_level;
+};
+
+#define TMD_SET_MITIGATION_LEVEL_REQ_MSG_V01_MAX_MSG_LEN 40
+static const struct qmi_elem_info tmd_set_mitigation_level_req_msg_v01_ei[] = {
+	{
+		.data_type = QMI_STRUCT,
+		.elem_len = 1,
+		.elem_size = sizeof(struct tmd_mitigation_dev_id_type_v01),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0x01,
+		.offset = offsetof(struct tmd_set_mitigation_level_req_msg_v01,
+				   mitigation_dev_id),
+		.ei_array = tmd_mitigation_dev_id_type_v01_ei,
+	},
+	{
+		.data_type = QMI_UNSIGNED_1_BYTE,
+		.elem_len = 1,
+		.elem_size = sizeof(uint8_t),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0x02,
+		.offset = offsetof(struct tmd_set_mitigation_level_req_msg_v01,
+				   mitigation_level),
+	},
+	{
+		.data_type = QMI_EOTI,
+		.array_type = NO_ARRAY,
+		.tlv_type = QMI_COMMON_TLV_TYPE,
+	},
+};
+
+struct tmd_set_mitigation_level_resp_msg_v01 {
+	struct qmi_response_type_v01 resp;
+};
+
+#define TMD_SET_MITIGATION_LEVEL_RESP_MSG_V01_MAX_MSG_LEN 7
+static const struct qmi_elem_info tmd_set_mitigation_level_resp_msg_v01_ei[] = {
+	{
+		.data_type = QMI_STRUCT,
+		.elem_len = 1,
+		.elem_size = sizeof(struct qmi_response_type_v01),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0x02,
+		.offset = offsetof(struct tmd_set_mitigation_level_resp_msg_v01, resp),
+		.ei_array = qmi_response_type_v01_ei,
+	},
+	{
+		.data_type = QMI_EOTI,
+		.array_type = NO_ARRAY,
+		.tlv_type = QMI_COMMON_TLV_TYPE,
+	},
+};
+
+struct tmd_get_mitigation_level_req_msg_v01 {
+	struct tmd_mitigation_dev_id_type_v01 mitigation_device;
+};
+#define TMD_GET_MITIGATION_LEVEL_REQ_MSG_V01_MAX_MSG_LEN 36
+
+static const struct qmi_elem_info tmd_get_mitigation_level_req_msg_v01_ei[] = {
+	{
+		.data_type = QMI_STRUCT,
+		.elem_len = 1,
+		.elem_size = sizeof(struct tmd_mitigation_dev_id_type_v01),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0x01,
+		.offset = offsetof(struct tmd_get_mitigation_level_req_msg_v01,
+				   mitigation_device),
+		.ei_array = tmd_mitigation_dev_id_type_v01_ei,
+	},
+	{
+		.data_type = QMI_EOTI,
+		.array_type = NO_ARRAY,
+		.tlv_type = QMI_COMMON_TLV_TYPE,
+	},
+};
+
+struct tmd_get_mitigation_level_resp_msg_v01 {
+	struct qmi_response_type_v01 resp;
+	uint8_t current_mitigation_level_valid;
+	uint8_t current_mitigation_level;
+	uint8_t requested_mitigation_level_valid;
+	uint8_t requested_mitigation_level;
+};
+
+#define TMD_GET_MITIGATION_LEVEL_RESP_MSG_V01_MAX_MSG_LEN 15
+static const struct qmi_elem_info tmd_get_mitigation_level_resp_msg_ei[] = {
+	{
+		.data_type = QMI_STRUCT,
+		.elem_len = 1,
+		.elem_size = sizeof(struct qmi_response_type_v01),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0x02,
+		.offset = offsetof(struct tmd_get_mitigation_level_resp_msg_v01, resp),
+		.ei_array = qmi_response_type_v01_ei,
+	},
+	{
+		.data_type = QMI_OPT_FLAG,
+		.elem_len = 1,
+		.elem_size = sizeof(uint8_t),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0x10,
+		.offset = offsetof(struct tmd_get_mitigation_level_resp_msg_v01,
+				   current_mitigation_level_valid),
+	},
+	{
+		.data_type = QMI_UNSIGNED_1_BYTE,
+		.elem_len = 1,
+		.elem_size = sizeof(uint8_t),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0x10,
+		.offset = offsetof(struct tmd_get_mitigation_level_resp_msg_v01,
+				   current_mitigation_level),
+	},
+	{
+		.data_type = QMI_OPT_FLAG,
+		.elem_len = 1,
+		.elem_size = sizeof(uint8_t),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0x11,
+		.offset = offsetof(struct tmd_get_mitigation_level_resp_msg_v01,
+				   requested_mitigation_level_valid),
+	},
+	{
+		.data_type = QMI_UNSIGNED_1_BYTE,
+		.elem_len = 1,
+		.elem_size = sizeof(uint8_t),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0x11,
+		.offset = offsetof(struct tmd_get_mitigation_level_resp_msg_v01,
+				   requested_mitigation_level),
+	},
+	{
+		.data_type = QMI_EOTI,
+		.array_type = NO_ARRAY,
+		.tlv_type = QMI_COMMON_TLV_TYPE,
+	},
+};
+
+struct tmd_register_notification_mitigation_level_req_msg_v01 {
+	struct tmd_mitigation_dev_id_type_v01 mitigation_device;
+};
+
+#define TMD_REGISTER_NOTIFICATION_MITIGATION_LEVEL_REQ_MSG_V01_MAX_MSG_LEN 36
+static const struct qmi_elem_info
+	tmd_register_notification_mitigation_level_req_msg_v01_ei[] = {
+		{
+			.data_type = QMI_STRUCT,
+			.elem_len = 1,
+			.elem_size = sizeof(struct tmd_mitigation_dev_id_type_v01),
+			.array_type = NO_ARRAY,
+			.tlv_type = 0x01,
+			.offset = offsetof(
+				struct tmd_register_notification_mitigation_level_req_msg_v01,
+				mitigation_device),
+			.ei_array = tmd_mitigation_dev_id_type_v01_ei,
+		},
+		{
+			.data_type = QMI_EOTI,
+			.array_type = NO_ARRAY,
+			.tlv_type = QMI_COMMON_TLV_TYPE,
+		},
+	};
+
+struct tmd_register_notification_mitigation_level_resp_msg_v01 {
+	struct qmi_response_type_v01 resp;
+};
+
+#define TMD_REGISTER_NOTIFICATION_MITIGATION_LEVEL_RESP_MSG_V01_MAX_MSG_LEN 7
+static const struct qmi_elem_info
+	tmd_register_notification_mitigation_level_resp_msg_v01_ei[] = {
+		{
+			.data_type = QMI_STRUCT,
+			.elem_len = 1,
+			.elem_size = sizeof(struct qmi_response_type_v01),
+			.array_type = NO_ARRAY,
+			.tlv_type = 0x02,
+			.offset = offsetof(
+				struct tmd_register_notification_mitigation_level_resp_msg_v01,
+				resp),
+			.ei_array = qmi_response_type_v01_ei,
+		},
+		{
+			.data_type = QMI_EOTI,
+			.array_type = NO_ARRAY,
+			.tlv_type = QMI_COMMON_TLV_TYPE,
+		},
+	};
+
+struct tmd_deregister_notification_mitigation_level_req_msg_v01 {
+	struct tmd_mitigation_dev_id_type_v01 mitigation_device;
+};
+
+#define TMD_DEREGISTER_NOTIFICATION_MITIGATION_LEVEL_REQ_MSG_V01_MAX_MSG_LEN 36
+static const struct qmi_elem_info
+	tmd_deregister_notification_mitigation_level_req_msg_v01_ei[] = {
+		{
+			.data_type = QMI_STRUCT,
+			.elem_len = 1,
+			.elem_size = sizeof(struct tmd_mitigation_dev_id_type_v01),
+			.array_type = NO_ARRAY,
+			.tlv_type = 0x01,
+			.offset = offsetof(
+				struct tmd_deregister_notification_mitigation_level_req_msg_v01,
+				mitigation_device),
+			.ei_array = tmd_mitigation_dev_id_type_v01_ei,
+		},
+		{
+			.data_type = QMI_EOTI,
+			.array_type = NO_ARRAY,
+			.tlv_type = QMI_COMMON_TLV_TYPE,
+		},
+	};
+
+struct tmd_deregister_notification_mitigation_level_resp_msg_v01 {
+	struct qmi_response_type_v01 resp;
+};
+
+#define TMD_DEREGISTER_NOTIFICATION_MITIGATION_LEVEL_RESP_MSG_V01_MAX_MSG_LEN 7
+static const struct qmi_elem_info
+	tmd_deregister_notification_mitigation_level_resp_msg_v01_ei[] = {
+		{
+			.data_type = QMI_STRUCT,
+			.elem_len = 1,
+			.elem_size = sizeof(struct qmi_response_type_v01),
+			.array_type = NO_ARRAY,
+			.tlv_type = 0x02,
+			.offset = offsetof(
+				struct tmd_deregister_notification_mitigation_level_resp_msg_v01,
+				resp),
+			.ei_array = qmi_response_type_v01_ei,
+		},
+		{
+			.data_type = QMI_EOTI,
+			.array_type = NO_ARRAY,
+			.tlv_type = QMI_COMMON_TLV_TYPE,
+		},
+	};
+
+struct tmd_mitigation_level_report_ind_msg_v01 {
+	struct tmd_mitigation_dev_id_type_v01 mitigation_device;
+	uint8_t current_mitigation_level;
+};
+
+#define TMD_MITIGATION_LEVEL_REPORT_IND_MSG_V01_MAX_MSG_LEN 40
+static const struct qmi_elem_info tmd_mitigation_level_report_ind_msg_v01_ei[] = {
+	{
+		.data_type = QMI_STRUCT,
+		.elem_len = 1,
+		.elem_size = sizeof(struct tmd_mitigation_dev_id_type_v01),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0x01,
+		.offset = offsetof(struct tmd_mitigation_level_report_ind_msg_v01,
+				   mitigation_device),
+		.ei_array = tmd_mitigation_dev_id_type_v01_ei,
+	},
+	{
+		.data_type = QMI_UNSIGNED_1_BYTE,
+		.elem_len = 1,
+		.elem_size = sizeof(uint8_t),
+		.array_type = NO_ARRAY,
+		.tlv_type = 0x02,
+		.offset = offsetof(struct tmd_mitigation_level_report_ind_msg_v01,
+				   current_mitigation_level),
+	},
+	{
+		.data_type = QMI_EOTI,
+		.array_type = NO_ARRAY,
+		.tlv_type = QMI_COMMON_TLV_TYPE,
+	},
+};
+
+#endif /* __QMI_COOLING_INTERNAL_H__ */
-- 
2.34.1

Re: [PATCH v1 4/8] thermal: qcom: add qmi-cooling driver

[Dmitry Baryshkov]

On Tue, Dec 23, 2025 at 06:02:23PM +0530, Gaurav Kohli wrote:
> From: Casey Connolly <casey.connolly@linaro.org>
> 
> The Thermal Mitigation Device (TMD) service exposes various platform
> specific thermal mitigations available on remote subsystems (ie the
> modem and cdsp). The service is exposed via the QMI messaging
> interface, usually over the QRTR transport.
> 
> 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.
> 
> Co-developed-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
> ---
>  drivers/soc/qcom/Kconfig           |  13 +
>  drivers/soc/qcom/Makefile          |   1 +
>  drivers/soc/qcom/qmi-cooling.c     | 498 +++++++++++++++++++++++++++++
>  drivers/soc/qcom/qmi-cooling.h     | 428 +++++++++++++++++++++++++
>  drivers/thermal/qcom/qmi-cooling.h | 428 +++++++++++++++++++++++++
>  5 files changed, 1368 insertions(+)
>  create mode 100644 drivers/soc/qcom/qmi-cooling.c
>  create mode 100644 drivers/soc/qcom/qmi-cooling.h
>  create mode 100644 drivers/thermal/qcom/qmi-cooling.h
> 
> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> index 2caadbbcf830..905a24b42fe6 100644
> --- a/drivers/soc/qcom/Kconfig
> +++ b/drivers/soc/qcom/Kconfig
> @@ -124,6 +124,19 @@ config QCOM_PMIC_GLINK
>  	  Say yes here to support USB-C and battery status on modern Qualcomm
>  	  platforms.
>  
> +config QCOM_QMI_COOLING
> +	tristate "Qualcomm QMI cooling drivers"
> +	depends on QCOM_RPROC_COMMON
> +	depends on ARCH_QCOM || COMPILE_TEST
> +	select QCOM_QMI_HELPERS
> +	help
> +	   This enables the remote subsystem cooling devices. These cooling
> +	   devices will be used by Qualcomm chipset to place various remote
> +	   subsystem mitigations like remote processor passive mitigation,
> +	   remote subsystem voltage restriction at low temperatures etc.
> +	   The QMI cooling device will interface with remote subsystem
> +	   using Qualcomm remoteproc interface.
> +
>  config QCOM_QMI_HELPERS
>  	tristate
>  	depends on NET
> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
> index b7f1d2a57367..b6728f54944b 100644
> --- a/drivers/soc/qcom/Makefile
> +++ b/drivers/soc/qcom/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_QCOM_PMIC_GLINK)	+= pmic_glink.o
>  obj-$(CONFIG_QCOM_PMIC_GLINK)	+= pmic_glink_altmode.o
>  obj-$(CONFIG_QCOM_PMIC_PDCHARGER_ULOG)	+= pmic_pdcharger_ulog.o
>  CFLAGS_pmic_pdcharger_ulog.o	:=  -I$(src)
> +obj-$(CONFIG_QCOM_QMI_COOLING) += qmi-cooling.o
>  obj-$(CONFIG_QCOM_QMI_HELPERS)	+= qmi_helpers.o
>  qmi_helpers-y	+= qmi_encdec.o qmi_interface.o
>  obj-$(CONFIG_QCOM_RAMP_CTRL)	+= ramp_controller.o
> diff --git a/drivers/soc/qcom/qmi-cooling.c b/drivers/soc/qcom/qmi-cooling.c
> new file mode 100644
> index 000000000000..1a6afcb96bf6
> --- /dev/null
> +++ b/drivers/soc/qcom/qmi-cooling.c
> @@ -0,0 +1,498 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2017, The Linux Foundation
> + * Copyright (c) 2025, Linaro Limited
> + *
> + * QMI Thermal Mitigation Device (TMD) client driver.
> + * This driver provides an in-kernel client to handle hot and cold thermal
> + * mitigations for remote subsystems (modem and DSPs) running the TMD service.
> + * It doesn't implement any handling of reports from remote subsystems.
> + */
> +
> +#include <linux/cleanup.h>
> +#include <linux/err.h>
> +#include <linux/module.h>
> +#include <linux/net.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/remoteproc/qcom_rproc.h>
> +#include <linux/remoteproc_cooling.h>
> +#include <linux/slab.h>
> +#include <linux/soc/qcom/qmi.h>
> +#include <linux/thermal.h>
> +
> +#include "qmi-cooling.h"
> +
> +#define MODEM0_INSTANCE_ID	0x0
> +#define ADSP_INSTANCE_ID	0x1
> +#define CDSP_INSTANCE_ID	0x43

Will CDSP1 also use instance ID? What are instance IDs for GPDSP?

> +#define SLPI_INSTANCE_ID	0x53
> +
> +#define QMI_TMD_RESP_TIMEOUT msecs_to_jiffies(100)
> +
> +/**
> + * struct qmi_tmd_client - TMD client state
> + * @dev:	Device associated with this client
> + * @name:	Friendly name for the remote TMD service
> + * @handle:	QMI connection handle
> + * @mutex:	Lock to synchronise QMI communication
> + * @id:		The QMI TMD service instance ID
> + * @cdev_list:	The list of cooling devices (controls) enabled for this instance
> + * @svc_arrive_work: Work item for initialising the client when the TMD service
> + *		     starts.
> + * @connection_active: Whether or not we're connected to the QMI TMD service
> + */
> +struct qmi_tmd_client {
> +	struct device *dev;
> +	const char *name;
> +	struct qmi_handle handle;
> +	struct mutex mutex;
> +	u32 id;
> +	struct list_head cdev_list;
> +	struct work_struct svc_arrive_work;
> +	bool connection_active;
> +};
> +
> +/**
> + * struct qmi_tmd - A TMD cooling device
> + * @np:		OF node associated with this control
> + * @type:	The control type (exposed via sysfs)
> + * @qmi_name:	The common name of this control shared by the remote subsystem
> + * @rproc_cdev:	Remote processor cooling device handle
> + * @cur_state:	The current cooling/warming/mitigation state
> + * @max_state:	The maximum state
> + * @client:	The TMD client instance this control is associated with
> + */
> +struct qmi_tmd {
> +	struct device_node *np;
> +	const char *type;
> +	char qmi_name[QMI_TMD_MITIGATION_DEV_ID_LENGTH_MAX_V01 + 1];
> +	struct list_head node;
> +	struct remoteproc_cdev *rproc_cdev;
> +	unsigned int cur_state;
> +	unsigned int max_state;
> +	struct qmi_tmd_client *client;
> +};
> +
> +/**
> + * struct qmi_instance_id - QMI instance match data
> + * @id:		The QMI instance ID
> + * @name:	Friendly name for this instance
> + */
> +struct qmi_instance_data {
> +	u32 id;
> +	const char *name;
> +};
> +
> +/* Notify the remote subsystem of the requested cooling state */
> +static int qmi_tmd_send_state_request(struct qmi_tmd *tmd)
> +{
> +	struct tmd_set_mitigation_level_resp_msg_v01 tmd_resp = { 0 };
> +	struct tmd_set_mitigation_level_req_msg_v01 req = { 0 };
> +	struct qmi_tmd_client *client;
> +	struct qmi_txn txn;
> +	int ret = 0;
> +
> +	client = tmd->client;
> +
> +	guard(mutex)(&client->mutex);
> +
> +	/*
> +	 * This function is called by qmi_set_cur_state() which does not know if
> +	 * the QMI service is actually online. If it isn't then we noop here.
> +	 * The state is cached in tmd->cur_state and will be broadcast via
> +	 * qmi_tmd_init_control() when the service comes up.
> +	 */
> +	if (!client->connection_active)
> +		return 0;
> +
> +	strscpy(req.mitigation_dev_id.mitigation_dev_id, tmd->qmi_name,
> +		QMI_TMD_MITIGATION_DEV_ID_LENGTH_MAX_V01 + 1);
> +	req.mitigation_level = tmd->cur_state;
> +
> +	ret = qmi_txn_init(&client->handle, &txn,
> +			   tmd_set_mitigation_level_resp_msg_v01_ei, &tmd_resp);
> +	if (ret < 0) {
> +		dev_err(client->dev, "qmi set state %d txn init failed for %s ret %d\n",
> +			tmd->cur_state, tmd->type, ret);
> +		return ret;
> +	}
> +
> +	ret = qmi_send_request(&client->handle, NULL, &txn,
> +			       QMI_TMD_SET_MITIGATION_LEVEL_REQ_V01,
> +			       TMD_SET_MITIGATION_LEVEL_REQ_MSG_V01_MAX_MSG_LEN,
> +			       tmd_set_mitigation_level_req_msg_v01_ei, &req);
> +	if (ret < 0) {
> +		dev_err(client->dev, "qmi set state %d txn send failed for %s ret %d\n",
> +			tmd->cur_state, tmd->type, ret);
> +		qmi_txn_cancel(&txn);
> +		return ret;
> +	}
> +
> +	ret = qmi_txn_wait(&txn, QMI_TMD_RESP_TIMEOUT);
> +	if (ret < 0) {
> +		dev_err(client->dev, "qmi set state %d txn wait failed for %s ret %d\n",
> +			tmd->cur_state, tmd->type, ret);
> +		return ret;
> +	}
> +
> +	if (tmd_resp.resp.result != QMI_RESULT_SUCCESS_V01) {
> +		ret = -tmd_resp.resp.result;
> +		dev_err(client->dev, "qmi set state %d NOT success for %s ret %d\n",
> +			tmd->cur_state, tmd->type, ret);
> +		return ret;
> +	}
> +
> +	dev_dbg(client->dev, "Requested state %d/%d for %s\n", tmd->cur_state,
> +		tmd->max_state, tmd->type);
> +
> +	return 0;
> +}
> +
> +static int qmi_get_max_level(void *devdata, unsigned long *level)
> +{
> +	struct qmi_tmd *tmd = devdata;
> +
> +	if (!tmd)
> +		return -EINVAL;
> +
> +	*level = tmd->max_state;
> +
> +	return 0;
> +}
> +
> +static int qmi_get_cur_level(void *devdata, unsigned long *level)
> +{
> +	struct qmi_tmd *tmd = devdata;
> +
> +	if (!tmd)
> +		return -EINVAL;
> +
> +	*level = tmd->cur_state;
> +
> +	return 0;
> +}
> +
> +static int qmi_set_cur_level(void *devdata, unsigned long level)
> +{
> +	struct qmi_tmd *tmd = devdata;
> +
> +	if (!tmd)
> +		return -EINVAL;
> +
> +	if (level > tmd->max_state)
> +		return -EINVAL;
> +
> +	if (tmd->cur_state == level)
> +		return 0;
> +
> +	tmd->cur_state = level;
> +
> +	return qmi_tmd_send_state_request(tmd);
> +}
> +
> +static const struct remoteproc_cooling_ops qmi_rproc_ops = {
> +	.get_max_level = qmi_get_max_level,
> +	.get_cur_level = qmi_get_cur_level,
> +	.set_cur_level = qmi_set_cur_level,
> +};
> +
> +static int qmi_register_cooling_device(struct qmi_tmd *tmd)
> +{
> +	struct remoteproc_cdev *rproc_cdev;
> +
> +	rproc_cdev = remoteproc_cooling_register(tmd->np,
> +						 tmd->type,
> +						 &qmi_rproc_ops,
> +						 tmd);
> +
> +	if (IS_ERR(rproc_cdev))
> +		return dev_err_probe(tmd->client->dev, PTR_ERR(rproc_cdev),
> +				     "Failed to register cooling device %s\n",
> +				     tmd->qmi_name);

This is being executed outside of the probe() path. What is the point of
calling dev_err_probe() here?

> +
> +	tmd->rproc_cdev = rproc_cdev;
> +	return 0;
> +}
> +
> +/*
> + * Init a single TMD control by registering a cooling device for it, or
> + * synchronising state with the remote subsystem if recovering from a service
> + * restart. This is called when the TMD service starts up.
> + */
> +static int qmi_tmd_init_control(struct qmi_tmd_client *client, const char *label,
> +				u8 max_state)
> +{
> +	struct qmi_tmd *tmd = NULL;
> +
> +	list_for_each_entry(tmd, &client->cdev_list, node)
> +		if (!strncasecmp(tmd->qmi_name, label,
> +				 QMI_TMD_MITIGATION_DEV_ID_LENGTH_MAX_V01 + 1))
> +			goto found;
> +
> +	dev_dbg(client->dev,
> +		"TMD '%s' available in firmware but not specified in DT\n",
> +		label);
> +	return 0;
> +
> +found:
> +	tmd->max_state = max_state;
> +	/*
> +	 * If the cooling device already exists then the QMI service went away and
> +	 * came back. So just make sure the current cooling device state is
> +	 * reflected on the remote side and then return.
> +	 */
> +	if (tmd->rproc_cdev)
> +		return qmi_tmd_send_state_request(tmd);
> +
> +	return qmi_register_cooling_device(tmd);
> +}
> +
> +/*
> + * When the QMI service starts up on a remote subsystem this function will fetch
> + * the list of TMDs on the subsystem, match it to the TMDs specified in devicetree
> + * and call qmi_tmd_init_control() for each
> + */
> +static void qmi_tmd_svc_arrive(struct work_struct *work)
> +{
> +	struct qmi_tmd_client *client =
> +		container_of(work, struct qmi_tmd_client, svc_arrive_work);
> +
> +	struct tmd_get_mitigation_device_list_req_msg_v01 req = { 0 };
> +	struct tmd_get_mitigation_device_list_resp_msg_v01 *resp __free(kfree);
> +	int ret = 0, i;
> +	struct qmi_txn txn;
> +
> +	/* resp struct is 1.1kB, allocate it on the heap. */
> +	resp = kzalloc(sizeof(*resp), GFP_KERNEL);
> +	if (!resp)
> +		return;
> +
> +	/* Get a list of TMDs supported by the remoteproc */
> +	scoped_guard(mutex, &client->mutex) {
> +		ret = qmi_txn_init(&client->handle, &txn,
> +				tmd_get_mitigation_device_list_resp_msg_v01_ei, resp);
> +		if (ret < 0) {
> +			dev_err(client->dev,
> +				"Transaction init error for instance_id: %#x ret %d\n",
> +				client->id, ret);
> +			return;
> +		}
> +
> +		ret = qmi_send_request(&client->handle, NULL, &txn,
> +				QMI_TMD_GET_MITIGATION_DEVICE_LIST_REQ_V01,
> +				TMD_GET_MITIGATION_DEVICE_LIST_REQ_MSG_V01_MAX_MSG_LEN,
> +				tmd_get_mitigation_device_list_req_msg_v01_ei, &req);
> +		if (ret < 0) {
> +			qmi_txn_cancel(&txn);
> +			return;
> +		}
> +
> +		ret = qmi_txn_wait(&txn, QMI_TMD_RESP_TIMEOUT);

So, we are waiting with the mutex held. What if the remote proc crashes
and restarts _while_ we are waiting here?

> +		if (ret < 0) {
> +			dev_err(client->dev, "Transaction wait error for client %#x ret:%d\n",
> +				client->id, ret);
> +			return;
> +		}
> +		if (resp->resp.result != QMI_RESULT_SUCCESS_V01) {
> +			ret = resp->resp.result;
> +			dev_err(client->dev, "Failed to get device list for client %#x ret:%d\n",
> +				client->id, ret);
> +			return;
> +		}
> +
> +		client->connection_active = true;
> +	}
> +
> +	for (i = 0; i < resp->mitigation_device_list_len; i++) {
> +		struct tmd_mitigation_dev_list_type_v01 *device =
> +			&resp->mitigation_device_list[i];
> +
> +		ret = qmi_tmd_init_control(client,
> +					   device->mitigation_dev_id.mitigation_dev_id,
> +					   device->max_mitigation_level);
> +		if (ret)
> +			break;
> +	}
> +}
> +
> +static void thermal_qmi_net_reset(struct qmi_handle *qmi)
> +{
> +	struct qmi_tmd_client *client = container_of(qmi, struct qmi_tmd_client, handle);
> +	struct qmi_tmd *tmd = NULL;
> +
> +	list_for_each_entry(tmd, &client->cdev_list, node) {
> +		qmi_tmd_send_state_request(tmd);
> +	}

Useless braces, please drop.

> +}
> +
> +static void thermal_qmi_del_server(struct qmi_handle *qmi, struct qmi_service *service)
> +{
> +	struct qmi_tmd_client *client = container_of(qmi, struct qmi_tmd_client, handle);
> +
> +	scoped_guard(mutex, &client->mutex)
> +		client->connection_active = false;
> +}
> +
> +static int thermal_qmi_new_server(struct qmi_handle *qmi, struct qmi_service *service)
> +{
> +	struct qmi_tmd_client *client = container_of(qmi, struct qmi_tmd_client, handle);
> +	struct sockaddr_qrtr sq = { AF_QIPCRTR, service->node, service->port };

C99, please.

> +
> +	scoped_guard(mutex, &client->mutex)
> +		kernel_connect(qmi->sock, (struct sockaddr_unsized *)&sq, sizeof(sq), 0);
> +
> +	queue_work(system_highpri_wq, &client->svc_arrive_work);

Why?

> +
> +	return 0;
> +}
> +
> +static struct qmi_ops thermal_qmi_event_ops = {
> +	.new_server = thermal_qmi_new_server,
> +	.del_server = thermal_qmi_del_server,
> +	.net_reset = thermal_qmi_net_reset,
> +};
> +
> +static void qmi_tmd_cleanup(struct qmi_tmd_client *client)
> +{
> +	struct qmi_tmd *tmd, *c_next;
> +
> +	guard(mutex)(&client->mutex);
> +
> +	client->connection_active = false;
> +
> +	qmi_handle_release(&client->handle);
> +	cancel_work(&client->svc_arrive_work);
> +	list_for_each_entry_safe(tmd, c_next, &client->cdev_list, node) {
> +		if (tmd->rproc_cdev)
> +			remoteproc_cooling_unregister(tmd->rproc_cdev);
> +
> +		list_del(&tmd->node);
> +	}
> +}
> +
> +/* Parse the controls and allocate a qmi_tmd for each of them */
> +static int qmi_tmd_alloc_cdevs(struct qmi_tmd_client *client)
> +{
> +	struct device *dev = client->dev;
> +	struct qmi_tmd *tmd;
> +	struct device_node *subnode, *node = dev->of_node;
> +	int ret;
> +
> +	for_each_available_child_of_node(node, subnode) {

Hmm...

> +		const char *name;
> +
> +		tmd = devm_kzalloc(dev, sizeof(*tmd), GFP_KERNEL);
> +		if (!tmd)
> +			return dev_err_probe(client->dev, -ENOMEM,
> +					     "Couldn't allocate tmd\n");
> +
> +		tmd->type = devm_kasprintf(client->dev, GFP_KERNEL, "%s:%s",
> +						client->name, subnode->name);
> +		if (!tmd->type)
> +			return dev_err_probe(dev, -ENOMEM,
> +					     "Couldn't allocate cooling device name\n");
> +
> +		if (of_property_read_string(subnode, "label", &name)) {
> +			return dev_err_probe(client->dev, -EINVAL,
> +					     "Failed to parse dev name for %s\n",
> +					     subnode->name);
> +		}
> +
> +		ret = strscpy(tmd->qmi_name, name,
> +			      QMI_TMD_MITIGATION_DEV_ID_LENGTH_MAX_V01 + 1);
> +		if (ret == -E2BIG) {
> +			return dev_err_probe(dev, -EINVAL, "TMD label %s is too long\n",
> +					     name);
> +		}
> +
> +		tmd->client = client;
> +		tmd->np = subnode;
> +		tmd->cur_state = 0;
> +		list_add(&tmd->node, &client->cdev_list);
> +	}
> +
> +	if (list_empty(&client->cdev_list))
> +		return dev_err_probe(client->dev, -EINVAL,
> +				     "No cooling devices specified for client %s (%#x)\n",
> +				     client->name, client->id);
> +
> +	return 0;
> +}
> +
> +static int qmi_tmd_client_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct qmi_tmd_client *client;
> +	const struct qmi_instance_data *match;
> +	int ret;
> +	client = devm_kzalloc(dev, sizeof(*client), GFP_KERNEL);
> +	if (!client)
> +		return -ENOMEM;
> +
> +	client->dev = dev;
> +
> +	match = of_device_get_match_data(dev);
> +	if (!match)
> +		return dev_err_probe(dev, -EINVAL, "No match data\n");
> +
> +	client->id = match->id;
> +	client->name = match->name;
> +
> +	mutex_init(&client->mutex);
> +	INIT_LIST_HEAD(&client->cdev_list);
> +	INIT_WORK(&client->svc_arrive_work, qmi_tmd_svc_arrive);
> +
> +	ret = qmi_tmd_alloc_cdevs(client);
> +	if (ret)
> +		return ret;
> +
> +	platform_set_drvdata(pdev, client);
> +
> +	ret = qmi_handle_init(&client->handle,
> +			      TMD_GET_MITIGATION_DEVICE_LIST_RESP_MSG_V01_MAX_MSG_LEN,
> +			      &thermal_qmi_event_ops, NULL);
> +	if (ret < 0)
> +		return dev_err_probe(client->dev, ret, "QMI handle init failed for client %#x\n",
> +			      client->id);
> +
> +	ret = qmi_add_lookup(&client->handle, TMD_SERVICE_ID_V01, TMD_SERVICE_VERS_V01,
> +			     client->id);
> +	if (ret < 0) {
> +		qmi_handle_release(&client->handle);
> +		return dev_err_probe(client->dev, ret, "QMI register failed for client 0x%x\n",
> +			      client->id);
> +	}
> +
> +	return 0;
> +}
> +
> +static void qmi_tmd_client_remove(struct platform_device *pdev)
> +{
> +	struct qmi_tmd_client *client = platform_get_drvdata(pdev);
> +
> +	qmi_tmd_cleanup(client);
> +}
> +
> +static const struct of_device_id qmi_tmd_device_table[] = {
> +	{
> +		.compatible = "qcom,qmi-cooling-cdsp",

Where is support for modem cooling? ADSP? SLPI?

> +		.data = &((struct qmi_instance_data) { CDSP_INSTANCE_ID, "cdsp" }),

Define it outside and reference here. Use C99 initializers.

> +	},
> +	{}
> +};
> +MODULE_DEVICE_TABLE(of, qmi_tmd_device_table);
> +
> +static struct platform_driver qmi_tmd_device_driver = {
> +	.probe = qmi_tmd_client_probe,
> +	.remove = qmi_tmd_client_remove,
> +	.driver = {
> +		.name = "qcom-qmi-cooling",
> +		.of_match_table = qmi_tmd_device_table,
> +	},
> +};
> +
> +module_platform_driver(qmi_tmd_device_driver);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("Qualcomm QMI Thermal Mitigation Device driver");



> diff --git a/drivers/thermal/qcom/qmi-cooling.h b/drivers/thermal/qcom/qmi-cooling.h
> new file mode 100644
> index 000000000000..f46b827b4ce6
> --- /dev/null
> +++ b/drivers/thermal/qcom/qmi-cooling.h
> @@ -0,0 +1,428 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (c) 2017, The Linux Foundation
> + * Copyright (c) 2023, Linaro Limited
> + */
> +
> +#ifndef __QCOM_COOLING_H__
> +#define __QCOM_COOLING_H__
> +
> +#include <linux/soc/qcom/qmi.h>
> +
> +#define TMD_SERVICE_ID_V01 0x18
> +#define TMD_SERVICE_VERS_V01 0x01
> +
> +#define QMI_TMD_GET_MITIGATION_DEVICE_LIST_RESP_V01 0x0020
> +#define QMI_TMD_GET_MITIGATION_LEVEL_REQ_V01 0x0022
> +#define QMI_TMD_GET_SUPPORTED_MSGS_REQ_V01 0x001E
> +#define QMI_TMD_SET_MITIGATION_LEVEL_REQ_V01 0x0021
> +#define QMI_TMD_REGISTER_NOTIFICATION_MITIGATION_LEVEL_RESP_V01 0x0023
> +#define QMI_TMD_GET_SUPPORTED_MSGS_RESP_V01 0x001E
> +#define QMI_TMD_SET_MITIGATION_LEVEL_RESP_V01 0x0021
> +#define QMI_TMD_DEREGISTER_NOTIFICATION_MITIGATION_LEVEL_RESP_V01 0x0024
> +#define QMI_TMD_MITIGATION_LEVEL_REPORT_IND_V01 0x0025
> +#define QMI_TMD_GET_MITIGATION_LEVEL_RESP_V01 0x0022
> +#define QMI_TMD_GET_SUPPORTED_FIELDS_REQ_V01 0x001F
> +#define QMI_TMD_GET_MITIGATION_DEVICE_LIST_REQ_V01 0x0020
> +#define QMI_TMD_REGISTER_NOTIFICATION_MITIGATION_LEVEL_REQ_V01 0x0023
> +#define QMI_TMD_DEREGISTER_NOTIFICATION_MITIGATION_LEVEL_REQ_V01 0x0024
> +#define QMI_TMD_GET_SUPPORTED_FIELDS_RESP_V01 0x001F
> +
> +#define QMI_TMD_MITIGATION_DEV_ID_LENGTH_MAX_V01 32
> +#define QMI_TMD_MITIGATION_DEV_LIST_MAX_V01 32
> +
> +struct tmd_mitigation_dev_id_type_v01 {
> +	char mitigation_dev_id[QMI_TMD_MITIGATION_DEV_ID_LENGTH_MAX_V01 + 1];
> +};
> +
> +static const struct qmi_elem_info tmd_mitigation_dev_id_type_v01_ei[] = {

No data objects in the _header_ file.

> +	{
> +		.data_type = QMI_STRING,
> +		.elem_len = QMI_TMD_MITIGATION_DEV_ID_LENGTH_MAX_V01 + 1,
> +		.elem_size = sizeof(char),
> +		.array_type = NO_ARRAY,
> +		.tlv_type = 0,
> +		.offset = offsetof(struct tmd_mitigation_dev_id_type_v01,
> +				   mitigation_dev_id),
> +	},
> +	{
> +		.data_type = QMI_EOTI,
> +		.array_type = NO_ARRAY,
> +		.tlv_type = QMI_COMMON_TLV_TYPE,
> +	},
> +};
> +

-- 
With best wishes
Dmitry

Re: [PATCH v1 4/8] thermal: qcom: add qmi-cooling driver

[Gaurav Kohli]

On 12/24/2025 1:19 AM, Dmitry Baryshkov wrote:
> On Tue, Dec 23, 2025 at 06:02:23PM +0530, Gaurav Kohli wrote:
>> From: Casey Connolly <casey.connolly@linaro.org>
>>
>> The Thermal Mitigation Device (TMD) service exposes various platform
>> specific thermal mitigations available on remote subsystems (ie the
>> modem and cdsp). The service is exposed via the QMI messaging
>> interface, usually over the QRTR transport.
>>
>> 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.
>>
>> Co-developed-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
>> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>> ---
>>   drivers/soc/qcom/Kconfig           |  13 +
>>   drivers/soc/qcom/Makefile          |   1 +
>>   drivers/soc/qcom/qmi-cooling.c     | 498 +++++++++++++++++++++++++++++
>>   drivers/soc/qcom/qmi-cooling.h     | 428 +++++++++++++++++++++++++
>>   drivers/thermal/qcom/qmi-cooling.h | 428 +++++++++++++++++++++++++
>>   5 files changed, 1368 insertions(+)
>>   create mode 100644 drivers/soc/qcom/qmi-cooling.c
>>   create mode 100644 drivers/soc/qcom/qmi-cooling.h
>>   create mode 100644 drivers/thermal/qcom/qmi-cooling.h
>>
>> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
>> index 2caadbbcf830..905a24b42fe6 100644
>> --- a/drivers/soc/qcom/Kconfig
>> +++ b/drivers/soc/qcom/Kconfig
>> @@ -124,6 +124,19 @@ config QCOM_PMIC_GLINK
>>   	  Say yes here to support USB-C and battery status on modern Qualcomm
>>   	  platforms.
>>   
>> +config QCOM_QMI_COOLING
>> +	tristate "Qualcomm QMI cooling drivers"
>> +	depends on QCOM_RPROC_COMMON
>> +	depends on ARCH_QCOM || COMPILE_TEST
>> +	select QCOM_QMI_HELPERS
>> +	help
>> +	   This enables the remote subsystem cooling devices. These cooling
>> +	   devices will be used by Qualcomm chipset to place various remote
>> +	   subsystem mitigations like remote processor passive mitigation,
>> +	   remote subsystem voltage restriction at low temperatures etc.
>> +	   The QMI cooling device will interface with remote subsystem
>> +	   using Qualcomm remoteproc interface.
>> +
>>   config QCOM_QMI_HELPERS
>>   	tristate
>>   	depends on NET
>> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
>> index b7f1d2a57367..b6728f54944b 100644
>> --- a/drivers/soc/qcom/Makefile
>> +++ b/drivers/soc/qcom/Makefile
>> @@ -14,6 +14,7 @@ obj-$(CONFIG_QCOM_PMIC_GLINK)	+= pmic_glink.o
>>   obj-$(CONFIG_QCOM_PMIC_GLINK)	+= pmic_glink_altmode.o
>>   obj-$(CONFIG_QCOM_PMIC_PDCHARGER_ULOG)	+= pmic_pdcharger_ulog.o
>>   CFLAGS_pmic_pdcharger_ulog.o	:=  -I$(src)
>> +obj-$(CONFIG_QCOM_QMI_COOLING) += qmi-cooling.o
>>   obj-$(CONFIG_QCOM_QMI_HELPERS)	+= qmi_helpers.o
>>   qmi_helpers-y	+= qmi_encdec.o qmi_interface.o
>>   obj-$(CONFIG_QCOM_RAMP_CTRL)	+= ramp_controller.o
>> diff --git a/drivers/soc/qcom/qmi-cooling.c b/drivers/soc/qcom/qmi-cooling.c
>> new file mode 100644
>> index 000000000000..1a6afcb96bf6
>> --- /dev/null
>> +++ b/drivers/soc/qcom/qmi-cooling.c
>> @@ -0,0 +1,498 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (c) 2017, The Linux Foundation
>> + * Copyright (c) 2025, Linaro Limited
>> + *
>> + * QMI Thermal Mitigation Device (TMD) client driver.
>> + * This driver provides an in-kernel client to handle hot and cold thermal
>> + * mitigations for remote subsystems (modem and DSPs) running the TMD service.
>> + * It doesn't implement any handling of reports from remote subsystems.
>> + */
>> +
>> +#include <linux/cleanup.h>
>> +#include <linux/err.h>
>> +#include <linux/module.h>
>> +#include <linux/net.h>
>> +#include <linux/of.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/remoteproc/qcom_rproc.h>
>> +#include <linux/remoteproc_cooling.h>
>> +#include <linux/slab.h>
>> +#include <linux/soc/qcom/qmi.h>
>> +#include <linux/thermal.h>
>> +
>> +#include "qmi-cooling.h"
>> +
>> +#define MODEM0_INSTANCE_ID	0x0
>> +#define ADSP_INSTANCE_ID	0x1
>> +#define CDSP_INSTANCE_ID	0x43
> Will CDSP1 also use instance ID? What are instance IDs for GPDSP?


In Leman's there are two different cdsp subsytem, i will add new 
instance id for that also.

What is GPdsp, you mean gpu ?


>> +#define SLPI_INSTANCE_ID	0x53
>> +
>> +#define QMI_TMD_RESP_TIMEOUT msecs_to_jiffies(100)
>> +
>> +/**
>> + * struct qmi_tmd_client - TMD client state
>> + * @dev:	Device associated with this client
>> + * @name:	Friendly name for the remote TMD service
>> + * @handle:	QMI connection handle
>> + * @mutex:	Lock to synchronise QMI communication
>> + * @id:		The QMI TMD service instance ID
>> + * @cdev_list:	The list of cooling devices (controls) enabled for this instance
>> + * @svc_arrive_work: Work item for initialising the client when the TMD service
>> + *		     starts.
>> + * @connection_active: Whether or not we're connected to the QMI TMD service
>> + */
>> +struct qmi_tmd_client {
>> +	struct device *dev;
>> +	const char *name;
>> +	struct qmi_handle handle;
>> +	struct mutex mutex;
>> +	u32 id;
>> +	struct list_head cdev_list;
>> +	struct work_struct svc_arrive_work;
>> +	bool connection_active;
>> +};
>> +
>> +/**
>> + * struct qmi_tmd - A TMD cooling device
>> + * @np:		OF node associated with this control
>> + * @type:	The control type (exposed via sysfs)
>> + * @qmi_name:	The common name of this control shared by the remote subsystem
>> + * @rproc_cdev:	Remote processor cooling device handle
>> + * @cur_state:	The current cooling/warming/mitigation state
>> + * @max_state:	The maximum state
>> + * @client:	The TMD client instance this control is associated with
>> + */
>> +struct qmi_tmd {
>> +	struct device_node *np;
>> +	const char *type;
>> +	char qmi_name[QMI_TMD_MITIGATION_DEV_ID_LENGTH_MAX_V01 + 1];
>> +	struct list_head node;
>> +	struct remoteproc_cdev *rproc_cdev;
>> +	unsigned int cur_state;
>> +	unsigned int max_state;
>> +	struct qmi_tmd_client *client;
>> +};
>> +
>> +/**
>> + * struct qmi_instance_id - QMI instance match data
>> + * @id:		The QMI instance ID
>> + * @name:	Friendly name for this instance
>> + */
>> +struct qmi_instance_data {
>> +	u32 id;
>> +	const char *name;
>> +};
>> +
>> +/* Notify the remote subsystem of the requested cooling state */
>> +static int qmi_tmd_send_state_request(struct qmi_tmd *tmd)
>> +{
>> +	struct tmd_set_mitigation_level_resp_msg_v01 tmd_resp = { 0 };
>> +	struct tmd_set_mitigation_level_req_msg_v01 req = { 0 };
>> +	struct qmi_tmd_client *client;
>> +	struct qmi_txn txn;
>> +	int ret = 0;
>> +
>> +	client = tmd->client;
>> +
>> +	guard(mutex)(&client->mutex);
>> +
>> +	/*
>> +	 * This function is called by qmi_set_cur_state() which does not know if
>> +	 * the QMI service is actually online. If it isn't then we noop here.
>> +	 * The state is cached in tmd->cur_state and will be broadcast via
>> +	 * qmi_tmd_init_control() when the service comes up.
>> +	 */
>> +	if (!client->connection_active)
>> +		return 0;
>> +
>> +	strscpy(req.mitigation_dev_id.mitigation_dev_id, tmd->qmi_name,
>> +		QMI_TMD_MITIGATION_DEV_ID_LENGTH_MAX_V01 + 1);
>> +	req.mitigation_level = tmd->cur_state;
>> +
>> +	ret = qmi_txn_init(&client->handle, &txn,
>> +			   tmd_set_mitigation_level_resp_msg_v01_ei, &tmd_resp);
>> +	if (ret < 0) {
>> +		dev_err(client->dev, "qmi set state %d txn init failed for %s ret %d\n",
>> +			tmd->cur_state, tmd->type, ret);
>> +		return ret;
>> +	}
>> +
>> +	ret = qmi_send_request(&client->handle, NULL, &txn,
>> +			       QMI_TMD_SET_MITIGATION_LEVEL_REQ_V01,
>> +			       TMD_SET_MITIGATION_LEVEL_REQ_MSG_V01_MAX_MSG_LEN,
>> +			       tmd_set_mitigation_level_req_msg_v01_ei, &req);
>> +	if (ret < 0) {
>> +		dev_err(client->dev, "qmi set state %d txn send failed for %s ret %d\n",
>> +			tmd->cur_state, tmd->type, ret);
>> +		qmi_txn_cancel(&txn);
>> +		return ret;
>> +	}
>> +
>> +	ret = qmi_txn_wait(&txn, QMI_TMD_RESP_TIMEOUT);
>> +	if (ret < 0) {
>> +		dev_err(client->dev, "qmi set state %d txn wait failed for %s ret %d\n",
>> +			tmd->cur_state, tmd->type, ret);
>> +		return ret;
>> +	}
>> +
>> +	if (tmd_resp.resp.result != QMI_RESULT_SUCCESS_V01) {
>> +		ret = -tmd_resp.resp.result;
>> +		dev_err(client->dev, "qmi set state %d NOT success for %s ret %d\n",
>> +			tmd->cur_state, tmd->type, ret);
>> +		return ret;
>> +	}
>> +
>> +	dev_dbg(client->dev, "Requested state %d/%d for %s\n", tmd->cur_state,
>> +		tmd->max_state, tmd->type);
>> +
>> +	return 0;
>> +}
>> +
>> +static int qmi_get_max_level(void *devdata, unsigned long *level)
>> +{
>> +	struct qmi_tmd *tmd = devdata;
>> +
>> +	if (!tmd)
>> +		return -EINVAL;
>> +
>> +	*level = tmd->max_state;
>> +
>> +	return 0;
>> +}
>> +
>> +static int qmi_get_cur_level(void *devdata, unsigned long *level)
>> +{
>> +	struct qmi_tmd *tmd = devdata;
>> +
>> +	if (!tmd)
>> +		return -EINVAL;
>> +
>> +	*level = tmd->cur_state;
>> +
>> +	return 0;
>> +}
>> +
>> +static int qmi_set_cur_level(void *devdata, unsigned long level)
>> +{
>> +	struct qmi_tmd *tmd = devdata;
>> +
>> +	if (!tmd)
>> +		return -EINVAL;
>> +
>> +	if (level > tmd->max_state)
>> +		return -EINVAL;
>> +
>> +	if (tmd->cur_state == level)
>> +		return 0;
>> +
>> +	tmd->cur_state = level;
>> +
>> +	return qmi_tmd_send_state_request(tmd);
>> +}
>> +
>> +static const struct remoteproc_cooling_ops qmi_rproc_ops = {
>> +	.get_max_level = qmi_get_max_level,
>> +	.get_cur_level = qmi_get_cur_level,
>> +	.set_cur_level = qmi_set_cur_level,
>> +};
>> +
>> +static int qmi_register_cooling_device(struct qmi_tmd *tmd)
>> +{
>> +	struct remoteproc_cdev *rproc_cdev;
>> +
>> +	rproc_cdev = remoteproc_cooling_register(tmd->np,
>> +						 tmd->type,
>> +						 &qmi_rproc_ops,
>> +						 tmd);
>> +
>> +	if (IS_ERR(rproc_cdev))
>> +		return dev_err_probe(tmd->client->dev, PTR_ERR(rproc_cdev),
>> +				     "Failed to register cooling device %s\n",
>> +				     tmd->qmi_name);
> This is being executed outside of the probe() path. What is the point of
> calling dev_err_probe() here?
>
>> +
>> +	tmd->rproc_cdev = rproc_cdev;
>> +	return 0;
>> +}
>> +
>> +/*
>> + * Init a single TMD control by registering a cooling device for it, or
>> + * synchronising state with the remote subsystem if recovering from a service
>> + * restart. This is called when the TMD service starts up.
>> + */
>> +static int qmi_tmd_init_control(struct qmi_tmd_client *client, const char *label,
>> +				u8 max_state)
>> +{
>> +	struct qmi_tmd *tmd = NULL;
>> +
>> +	list_for_each_entry(tmd, &client->cdev_list, node)
>> +		if (!strncasecmp(tmd->qmi_name, label,
>> +				 QMI_TMD_MITIGATION_DEV_ID_LENGTH_MAX_V01 + 1))
>> +			goto found;
>> +
>> +	dev_dbg(client->dev,
>> +		"TMD '%s' available in firmware but not specified in DT\n",
>> +		label);
>> +	return 0;
>> +
>> +found:
>> +	tmd->max_state = max_state;
>> +	/*
>> +	 * If the cooling device already exists then the QMI service went away and
>> +	 * came back. So just make sure the current cooling device state is
>> +	 * reflected on the remote side and then return.
>> +	 */
>> +	if (tmd->rproc_cdev)
>> +		return qmi_tmd_send_state_request(tmd);
>> +
>> +	return qmi_register_cooling_device(tmd);
>> +}
>> +
>> +/*
>> + * When the QMI service starts up on a remote subsystem this function will fetch
>> + * the list of TMDs on the subsystem, match it to the TMDs specified in devicetree
>> + * and call qmi_tmd_init_control() for each
>> + */
>> +static void qmi_tmd_svc_arrive(struct work_struct *work)
>> +{
>> +	struct qmi_tmd_client *client =
>> +		container_of(work, struct qmi_tmd_client, svc_arrive_work);
>> +
>> +	struct tmd_get_mitigation_device_list_req_msg_v01 req = { 0 };
>> +	struct tmd_get_mitigation_device_list_resp_msg_v01 *resp __free(kfree);
>> +	int ret = 0, i;
>> +	struct qmi_txn txn;
>> +
>> +	/* resp struct is 1.1kB, allocate it on the heap. */
>> +	resp = kzalloc(sizeof(*resp), GFP_KERNEL);
>> +	if (!resp)
>> +		return;
>> +
>> +	/* Get a list of TMDs supported by the remoteproc */
>> +	scoped_guard(mutex, &client->mutex) {
>> +		ret = qmi_txn_init(&client->handle, &txn,
>> +				tmd_get_mitigation_device_list_resp_msg_v01_ei, resp);
>> +		if (ret < 0) {
>> +			dev_err(client->dev,
>> +				"Transaction init error for instance_id: %#x ret %d\n",
>> +				client->id, ret);
>> +			return;
>> +		}
>> +
>> +		ret = qmi_send_request(&client->handle, NULL, &txn,
>> +				QMI_TMD_GET_MITIGATION_DEVICE_LIST_REQ_V01,
>> +				TMD_GET_MITIGATION_DEVICE_LIST_REQ_MSG_V01_MAX_MSG_LEN,
>> +				tmd_get_mitigation_device_list_req_msg_v01_ei, &req);
>> +		if (ret < 0) {
>> +			qmi_txn_cancel(&txn);
>> +			return;
>> +		}
>> +
>> +		ret = qmi_txn_wait(&txn, QMI_TMD_RESP_TIMEOUT);
> So, we are waiting with the mutex held. What if the remote proc crashes
> and restarts _while_ we are waiting here?
>
>> +		if (ret < 0) {
>> +			dev_err(client->dev, "Transaction wait error for client %#x ret:%d\n",
>> +				client->id, ret);
>> +			return;
>> +		}
>> +		if (resp->resp.result != QMI_RESULT_SUCCESS_V01) {
>> +			ret = resp->resp.result;
>> +			dev_err(client->dev, "Failed to get device list for client %#x ret:%d\n",
>> +				client->id, ret);
>> +			return;
>> +		}
>> +
>> +		client->connection_active = true;
>> +	}
>> +
>> +	for (i = 0; i < resp->mitigation_device_list_len; i++) {
>> +		struct tmd_mitigation_dev_list_type_v01 *device =
>> +			&resp->mitigation_device_list[i];
>> +
>> +		ret = qmi_tmd_init_control(client,
>> +					   device->mitigation_dev_id.mitigation_dev_id,
>> +					   device->max_mitigation_level);
>> +		if (ret)
>> +			break;
>> +	}
>> +}
>> +
>> +static void thermal_qmi_net_reset(struct qmi_handle *qmi)
>> +{
>> +	struct qmi_tmd_client *client = container_of(qmi, struct qmi_tmd_client, handle);
>> +	struct qmi_tmd *tmd = NULL;
>> +
>> +	list_for_each_entry(tmd, &client->cdev_list, node) {
>> +		qmi_tmd_send_state_request(tmd);
>> +	}
> Useless braces, please drop.


sure, will fix this.


>
>> +}
>> +
>> +static void thermal_qmi_del_server(struct qmi_handle *qmi, struct qmi_service *service)
>> +{
>> +	struct qmi_tmd_client *client = container_of(qmi, struct qmi_tmd_client, handle);
>> +
>> +	scoped_guard(mutex, &client->mutex)
>> +		client->connection_active = false;
>> +}
>> +
>> +static int thermal_qmi_new_server(struct qmi_handle *qmi, struct qmi_service *service)
>> +{
>> +	struct qmi_tmd_client *client = container_of(qmi, struct qmi_tmd_client, handle);
>> +	struct sockaddr_qrtr sq = { AF_QIPCRTR, service->node, service->port };
> C99, please.
>
>> +
>> +	scoped_guard(mutex, &client->mutex)
>> +		kernel_connect(qmi->sock, (struct sockaddr_unsized *)&sq, sizeof(sq), 0);
>> +
>> +	queue_work(system_highpri_wq, &client->svc_arrive_work);
> Why?


this function indicates that qmi service is up, but post that there is 
lot of work like query available tmd devices in remote subsystem and 
then registration

  with cooling framework.


>
>> +
>> +	return 0;
>> +}
>> +
>> +static struct qmi_ops thermal_qmi_event_ops = {
>> +	.new_server = thermal_qmi_new_server,
>> +	.del_server = thermal_qmi_del_server,
>> +	.net_reset = thermal_qmi_net_reset,
>> +};
>> +
>> +static void qmi_tmd_cleanup(struct qmi_tmd_client *client)
>> +{
>> +	struct qmi_tmd *tmd, *c_next;
>> +
>> +	guard(mutex)(&client->mutex);
>> +
>> +	client->connection_active = false;
>> +
>> +	qmi_handle_release(&client->handle);
>> +	cancel_work(&client->svc_arrive_work);
>> +	list_for_each_entry_safe(tmd, c_next, &client->cdev_list, node) {
>> +		if (tmd->rproc_cdev)
>> +			remoteproc_cooling_unregister(tmd->rproc_cdev);
>> +
>> +		list_del(&tmd->node);
>> +	}
>> +}
>> +
>> +/* Parse the controls and allocate a qmi_tmd for each of them */
>> +static int qmi_tmd_alloc_cdevs(struct qmi_tmd_client *client)
>> +{
>> +	struct device *dev = client->dev;
>> +	struct qmi_tmd *tmd;
>> +	struct device_node *subnode, *node = dev->of_node;
>> +	int ret;
>> +
>> +	for_each_available_child_of_node(node, subnode) {
> Hmm...
>
>> +		const char *name;
>> +
>> +		tmd = devm_kzalloc(dev, sizeof(*tmd), GFP_KERNEL);
>> +		if (!tmd)
>> +			return dev_err_probe(client->dev, -ENOMEM,
>> +					     "Couldn't allocate tmd\n");
>> +
>> +		tmd->type = devm_kasprintf(client->dev, GFP_KERNEL, "%s:%s",
>> +						client->name, subnode->name);
>> +		if (!tmd->type)
>> +			return dev_err_probe(dev, -ENOMEM,
>> +					     "Couldn't allocate cooling device name\n");
>> +
>> +		if (of_property_read_string(subnode, "label", &name)) {
>> +			return dev_err_probe(client->dev, -EINVAL,
>> +					     "Failed to parse dev name for %s\n",
>> +					     subnode->name);
>> +		}
>> +
>> +		ret = strscpy(tmd->qmi_name, name,
>> +			      QMI_TMD_MITIGATION_DEV_ID_LENGTH_MAX_V01 + 1);
>> +		if (ret == -E2BIG) {
>> +			return dev_err_probe(dev, -EINVAL, "TMD label %s is too long\n",
>> +					     name);
>> +		}
>> +
>> +		tmd->client = client;
>> +		tmd->np = subnode;
>> +		tmd->cur_state = 0;
>> +		list_add(&tmd->node, &client->cdev_list);
>> +	}
>> +
>> +	if (list_empty(&client->cdev_list))
>> +		return dev_err_probe(client->dev, -EINVAL,
>> +				     "No cooling devices specified for client %s (%#x)\n",
>> +				     client->name, client->id);
>> +
>> +	return 0;
>> +}
>> +
>> +static int qmi_tmd_client_probe(struct platform_device *pdev)
>> +{
>> +	struct device *dev = &pdev->dev;
>> +	struct qmi_tmd_client *client;
>> +	const struct qmi_instance_data *match;
>> +	int ret;
>> +	client = devm_kzalloc(dev, sizeof(*client), GFP_KERNEL);
>> +	if (!client)
>> +		return -ENOMEM;
>> +
>> +	client->dev = dev;
>> +
>> +	match = of_device_get_match_data(dev);
>> +	if (!match)
>> +		return dev_err_probe(dev, -EINVAL, "No match data\n");
>> +
>> +	client->id = match->id;
>> +	client->name = match->name;
>> +
>> +	mutex_init(&client->mutex);
>> +	INIT_LIST_HEAD(&client->cdev_list);
>> +	INIT_WORK(&client->svc_arrive_work, qmi_tmd_svc_arrive);
>> +
>> +	ret = qmi_tmd_alloc_cdevs(client);
>> +	if (ret)
>> +		return ret;
>> +
>> +	platform_set_drvdata(pdev, client);
>> +
>> +	ret = qmi_handle_init(&client->handle,
>> +			      TMD_GET_MITIGATION_DEVICE_LIST_RESP_MSG_V01_MAX_MSG_LEN,
>> +			      &thermal_qmi_event_ops, NULL);
>> +	if (ret < 0)
>> +		return dev_err_probe(client->dev, ret, "QMI handle init failed for client %#x\n",
>> +			      client->id);
>> +
>> +	ret = qmi_add_lookup(&client->handle, TMD_SERVICE_ID_V01, TMD_SERVICE_VERS_V01,
>> +			     client->id);
>> +	if (ret < 0) {
>> +		qmi_handle_release(&client->handle);
>> +		return dev_err_probe(client->dev, ret, "QMI register failed for client 0x%x\n",
>> +			      client->id);
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +static void qmi_tmd_client_remove(struct platform_device *pdev)
>> +{
>> +	struct qmi_tmd_client *client = platform_get_drvdata(pdev);
>> +
>> +	qmi_tmd_cleanup(client);
>> +}
>> +
>> +static const struct of_device_id qmi_tmd_device_table[] = {
>> +	{
>> +		.compatible = "qcom,qmi-cooling-cdsp",
> Where is support for modem cooling? ADSP? SLPI?
>
>> +		.data = &((struct qmi_instance_data) { CDSP_INSTANCE_ID, "cdsp" }),
> Define it outside and reference here. Use C99 initializers.
>
>> +	},
>> +	{}
>> +};
>> +MODULE_DEVICE_TABLE(of, qmi_tmd_device_table);
>> +
>> +static struct platform_driver qmi_tmd_device_driver = {
>> +	.probe = qmi_tmd_client_probe,
>> +	.remove = qmi_tmd_client_remove,
>> +	.driver = {
>> +		.name = "qcom-qmi-cooling",
>> +		.of_match_table = qmi_tmd_device_table,
>> +	},
>> +};
>> +
>> +module_platform_driver(qmi_tmd_device_driver);
>> +
>> +MODULE_LICENSE("GPL");
>> +MODULE_DESCRIPTION("Qualcomm QMI Thermal Mitigation Device driver");
>
>
>> diff --git a/drivers/thermal/qcom/qmi-cooling.h b/drivers/thermal/qcom/qmi-cooling.h
>> new file mode 100644
>> index 000000000000..f46b827b4ce6
>> --- /dev/null
>> +++ b/drivers/thermal/qcom/qmi-cooling.h
>> @@ -0,0 +1,428 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * Copyright (c) 2017, The Linux Foundation
>> + * Copyright (c) 2023, Linaro Limited
>> + */
>> +
>> +#ifndef __QCOM_COOLING_H__
>> +#define __QCOM_COOLING_H__
>> +
>> +#include <linux/soc/qcom/qmi.h>
>> +
>> +#define TMD_SERVICE_ID_V01 0x18
>> +#define TMD_SERVICE_VERS_V01 0x01
>> +
>> +#define QMI_TMD_GET_MITIGATION_DEVICE_LIST_RESP_V01 0x0020
>> +#define QMI_TMD_GET_MITIGATION_LEVEL_REQ_V01 0x0022
>> +#define QMI_TMD_GET_SUPPORTED_MSGS_REQ_V01 0x001E
>> +#define QMI_TMD_SET_MITIGATION_LEVEL_REQ_V01 0x0021
>> +#define QMI_TMD_REGISTER_NOTIFICATION_MITIGATION_LEVEL_RESP_V01 0x0023
>> +#define QMI_TMD_GET_SUPPORTED_MSGS_RESP_V01 0x001E
>> +#define QMI_TMD_SET_MITIGATION_LEVEL_RESP_V01 0x0021
>> +#define QMI_TMD_DEREGISTER_NOTIFICATION_MITIGATION_LEVEL_RESP_V01 0x0024
>> +#define QMI_TMD_MITIGATION_LEVEL_REPORT_IND_V01 0x0025
>> +#define QMI_TMD_GET_MITIGATION_LEVEL_RESP_V01 0x0022
>> +#define QMI_TMD_GET_SUPPORTED_FIELDS_REQ_V01 0x001F
>> +#define QMI_TMD_GET_MITIGATION_DEVICE_LIST_REQ_V01 0x0020
>> +#define QMI_TMD_REGISTER_NOTIFICATION_MITIGATION_LEVEL_REQ_V01 0x0023
>> +#define QMI_TMD_DEREGISTER_NOTIFICATION_MITIGATION_LEVEL_REQ_V01 0x0024
>> +#define QMI_TMD_GET_SUPPORTED_FIELDS_RESP_V01 0x001F
>> +
>> +#define QMI_TMD_MITIGATION_DEV_ID_LENGTH_MAX_V01 32
>> +#define QMI_TMD_MITIGATION_DEV_LIST_MAX_V01 32
>> +
>> +struct tmd_mitigation_dev_id_type_v01 {
>> +	char mitigation_dev_id[QMI_TMD_MITIGATION_DEV_ID_LENGTH_MAX_V01 + 1];
>> +};
>> +
>> +static const struct qmi_elem_info tmd_mitigation_dev_id_type_v01_ei[] = {
> No data objects in the _header_ file.
>
>> +	{
>> +		.data_type = QMI_STRING,
>> +		.elem_len = QMI_TMD_MITIGATION_DEV_ID_LENGTH_MAX_V01 + 1,
>> +		.elem_size = sizeof(char),
>> +		.array_type = NO_ARRAY,
>> +		.tlv_type = 0,
>> +		.offset = offsetof(struct tmd_mitigation_dev_id_type_v01,
>> +				   mitigation_dev_id),
>> +	},
>> +	{
>> +		.data_type = QMI_EOTI,
>> +		.array_type = NO_ARRAY,
>> +		.tlv_type = QMI_COMMON_TLV_TYPE,
>> +	},
>> +};
>> +

Re: [PATCH v1 4/8] thermal: qcom: add qmi-cooling driver

[Dmitry Baryshkov]

On 31/12/2025 08:28, Gaurav Kohli wrote:
> 
> On 12/24/2025 1:19 AM, Dmitry Baryshkov wrote:
>> On Tue, Dec 23, 2025 at 06:02:23PM +0530, Gaurav Kohli wrote:
>>> From: Casey Connolly <casey.connolly@linaro.org>
>>>
>>> The Thermal Mitigation Device (TMD) service exposes various platform
>>> specific thermal mitigations available on remote subsystems (ie the
>>> modem and cdsp). The service is exposed via the QMI messaging
>>> interface, usually over the QRTR transport.
>>>
>>> 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.
>>>
>>> Co-developed-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>>> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
>>> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>>> ---
>>>   drivers/soc/qcom/Kconfig           |  13 +
>>>   drivers/soc/qcom/Makefile          |   1 +
>>>   drivers/soc/qcom/qmi-cooling.c     | 498 +++++++++++++++++++++++++++++
>>>   drivers/soc/qcom/qmi-cooling.h     | 428 +++++++++++++++++++++++++
>>>   drivers/thermal/qcom/qmi-cooling.h | 428 +++++++++++++++++++++++++
>>>   5 files changed, 1368 insertions(+)
>>>   create mode 100644 drivers/soc/qcom/qmi-cooling.c
>>>   create mode 100644 drivers/soc/qcom/qmi-cooling.h
>>>   create mode 100644 drivers/thermal/qcom/qmi-cooling.h
>>>
>>> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
>>> index 2caadbbcf830..905a24b42fe6 100644
>>> --- a/drivers/soc/qcom/Kconfig
>>> +++ b/drivers/soc/qcom/Kconfig
>>> @@ -124,6 +124,19 @@ config QCOM_PMIC_GLINK
>>>         Say yes here to support USB-C and battery status on modern 
>>> Qualcomm
>>>         platforms.
>>> +config QCOM_QMI_COOLING
>>> +    tristate "Qualcomm QMI cooling drivers"
>>> +    depends on QCOM_RPROC_COMMON
>>> +    depends on ARCH_QCOM || COMPILE_TEST
>>> +    select QCOM_QMI_HELPERS
>>> +    help
>>> +       This enables the remote subsystem cooling devices. These cooling
>>> +       devices will be used by Qualcomm chipset to place various remote
>>> +       subsystem mitigations like remote processor passive mitigation,
>>> +       remote subsystem voltage restriction at low temperatures etc.
>>> +       The QMI cooling device will interface with remote subsystem
>>> +       using Qualcomm remoteproc interface.
>>> +
>>>   config QCOM_QMI_HELPERS
>>>       tristate
>>>       depends on NET
>>> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
>>> index b7f1d2a57367..b6728f54944b 100644
>>> --- a/drivers/soc/qcom/Makefile
>>> +++ b/drivers/soc/qcom/Makefile
>>> @@ -14,6 +14,7 @@ obj-$(CONFIG_QCOM_PMIC_GLINK)    += pmic_glink.o
>>>   obj-$(CONFIG_QCOM_PMIC_GLINK)    += pmic_glink_altmode.o
>>>   obj-$(CONFIG_QCOM_PMIC_PDCHARGER_ULOG)    += pmic_pdcharger_ulog.o
>>>   CFLAGS_pmic_pdcharger_ulog.o    :=  -I$(src)
>>> +obj-$(CONFIG_QCOM_QMI_COOLING) += qmi-cooling.o
>>>   obj-$(CONFIG_QCOM_QMI_HELPERS)    += qmi_helpers.o
>>>   qmi_helpers-y    += qmi_encdec.o qmi_interface.o
>>>   obj-$(CONFIG_QCOM_RAMP_CTRL)    += ramp_controller.o
>>> diff --git a/drivers/soc/qcom/qmi-cooling.c b/drivers/soc/qcom/qmi- 
>>> cooling.c
>>> new file mode 100644
>>> index 000000000000..1a6afcb96bf6
>>> --- /dev/null
>>> +++ b/drivers/soc/qcom/qmi-cooling.c
>>> @@ -0,0 +1,498 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Copyright (c) 2017, The Linux Foundation
>>> + * Copyright (c) 2025, Linaro Limited
>>> + *
>>> + * QMI Thermal Mitigation Device (TMD) client driver.
>>> + * This driver provides an in-kernel client to handle hot and cold 
>>> thermal
>>> + * mitigations for remote subsystems (modem and DSPs) running the 
>>> TMD service.
>>> + * It doesn't implement any handling of reports from remote subsystems.
>>> + */
>>> +
>>> +#include <linux/cleanup.h>
>>> +#include <linux/err.h>
>>> +#include <linux/module.h>
>>> +#include <linux/net.h>
>>> +#include <linux/of.h>
>>> +#include <linux/platform_device.h>
>>> +#include <linux/remoteproc/qcom_rproc.h>
>>> +#include <linux/remoteproc_cooling.h>
>>> +#include <linux/slab.h>
>>> +#include <linux/soc/qcom/qmi.h>
>>> +#include <linux/thermal.h>
>>> +
>>> +#include "qmi-cooling.h"
>>> +
>>> +#define MODEM0_INSTANCE_ID    0x0
>>> +#define ADSP_INSTANCE_ID    0x1
>>> +#define CDSP_INSTANCE_ID    0x43
>> Will CDSP1 also use instance ID? What are instance IDs for GPDSP?
> 
> 
> In Leman's there are two different cdsp subsytem, i will add new 
> instance id for that also.
> 
> What is GPdsp, you mean gpu ?
> 

No, I mean general purpose DSP aka GPDSP aka GDSP.

-- 
With best wishes
Dmitry

Re: [PATCH v1 4/8] thermal: qcom: add qmi-cooling driver

[Krzysztof Kozlowski]

On 23/12/2025 13:32, Gaurav Kohli wrote:
> +static int thermal_qmi_new_server(struct qmi_handle *qmi, struct qmi_service *service)
> +{
> +	struct qmi_tmd_client *client = container_of(qmi, struct qmi_tmd_client, handle);
> +	struct sockaddr_qrtr sq = { AF_QIPCRTR, service->node, service->port };
> +
> +	scoped_guard(mutex, &client->mutex)
> +		kernel_connect(qmi->sock, (struct sockaddr_unsized *)&sq, sizeof(sq), 0);
> +
> +	queue_work(system_highpri_wq, &client->svc_arrive_work);
> +
> +	return 0;
> +}
> +
> +static struct qmi_ops thermal_qmi_event_ops = {

Why this is not const?

From where did you copy this code?

> +	.new_server = thermal_qmi_new_server,
> +	.del_server = thermal_qmi_del_server,
> +	.net_reset = thermal_qmi_net_reset,
> +};
> +
> +static void qmi_tmd_cleanup(struct qmi_tmd_client *client)
> +{
> +	struct qmi_tmd *tmd, *c_next;
> +
> +	guard(mutex)(&client->mutex);
> +
> +	client->connection_active = false;
> +
> +	qmi_handle_release(&client->handle);
> +	cancel_work(&client->svc_arrive_work);
> +	list_for_each_entry_safe(tmd, c_next, &client->cdev_list, node) {
> +		if (tmd->rproc_cdev)
> +			remoteproc_cooling_unregister(tmd->rproc_cdev);
> +
> +		list_del(&tmd->node);
> +	}
> +}
> +
> +/* Parse the controls and allocate a qmi_tmd for each of them */
> +static int qmi_tmd_alloc_cdevs(struct qmi_tmd_client *client)
> +{
> +	struct device *dev = client->dev;
> +	struct qmi_tmd *tmd;
> +	struct device_node *subnode, *node = dev->of_node;
> +	int ret;
> +
> +	for_each_available_child_of_node(node, subnode) {
> +		const char *name;
> +
> +		tmd = devm_kzalloc(dev, sizeof(*tmd), GFP_KERNEL);
> +		if (!tmd)
> +			return dev_err_probe(client->dev, -ENOMEM,
> +					     "Couldn't allocate tmd\n");

You leak nodes.

> +
> +		tmd->type = devm_kasprintf(client->dev, GFP_KERNEL, "%s:%s",
> +						client->name, subnode->name);
> +		if (!tmd->type)
> +			return dev_err_probe(dev, -ENOMEM,
> +					     "Couldn't allocate cooling device name\n");

Everywhere...

> +
> +		if (of_property_read_string(subnode, "label", &name)) {
> +			return dev_err_probe(client->dev, -EINVAL,
> +					     "Failed to parse dev name for %s\n",
> +					     subnode->name);
> +		}
> +
> +		ret = strscpy(tmd->qmi_name, name,
> +			      QMI_TMD_MITIGATION_DEV_ID_LENGTH_MAX_V01 + 1);
> +		if (ret == -E2BIG) {
> +			return dev_err_probe(dev, -EINVAL, "TMD label %s is too long\n",
> +					     name);
> +		}
> +
> +		tmd->client = client;
> +		tmd->np = subnode;
> +		tmd->cur_state = 0;
> +		list_add(&tmd->node, &client->cdev_list);
> +	}
> +
> +	if (list_empty(&client->cdev_list))
> +		return dev_err_probe(client->dev, -EINVAL,
> +				     "No cooling devices specified for client %s (%#x)\n",
> +				     client->name, client->id);
> +
> +	return 0;
> +}
> +
> +static int qmi_tmd_client_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct qmi_tmd_client *client;
> +	const struct qmi_instance_data *match;
> +	int ret;

Open any existing Linux driver. How does this part look like?

> +	client = devm_kzalloc(dev, sizeof(*client), GFP_KERNEL);
> +	if (!client)
> +		return -ENOMEM;
> +
> +	client->dev = dev;
> +
> +	match = of_device_get_match_data(dev);
> +	if (!match)
> +		return dev_err_probe(dev, -EINVAL, "No match data\n");
> +
> +	client->id = match->id;
> +	client->name = match->name;
> +
> +	mutex_init(&client->mutex);
> +	INIT_LIST_HEAD(&client->cdev_list);
> +	INIT_WORK(&client->svc_arrive_work, qmi_tmd_svc_arrive);
> +
> +	ret = qmi_tmd_alloc_cdevs(client);
> +	if (ret)
> +		return ret;
> +
> +	platform_set_drvdata(pdev, client);
> +
> +	ret = qmi_handle_init(&client->handle,
> +			      TMD_GET_MITIGATION_DEVICE_LIST_RESP_MSG_V01_MAX_MSG_LEN,
> +			      &thermal_qmi_event_ops, NULL);
> +	if (ret < 0)
> +		return dev_err_probe(client->dev, ret, "QMI handle init failed for client %#x\n",
> +			      client->id);
> +
> +	ret = qmi_add_lookup(&client->handle, TMD_SERVICE_ID_V01, TMD_SERVICE_VERS_V01,
> +			     client->id);
> +	if (ret < 0) {
> +		qmi_handle_release(&client->handle);
> +		return dev_err_probe(client->dev, ret, "QMI register failed for client 0x%x\n",
> +			      client->id);
> +	}
> +
> +	return 0;
> +}
> +
> +static void qmi_tmd_client_remove(struct platform_device *pdev)
> +{
> +	struct qmi_tmd_client *client = platform_get_drvdata(pdev);
> +
> +	qmi_tmd_cleanup(client);
> +}
> +
> +static const struct of_device_id qmi_tmd_device_table[] = {
> +	{
> +		.compatible = "qcom,qmi-cooling-cdsp",
> +		.data = &((struct qmi_instance_data) { CDSP_INSTANCE_ID, "cdsp" }),

Please use Linux coding style.

> +	},
> +	{}
> +};
> +MODULE_DEVICE_TABLE(of, qmi_tmd_device_table);
> +
> +static struct platform_driver qmi_tmd_device_driver = {
> +	.probe = qmi_tmd_client_probe,
> +	.remove = qmi_tmd_client_remove,
> +	.driver = {
> +		.name = "qcom-qmi-cooling",
> +		.of_match_table = qmi_tmd_device_table,
> +	},


Best regards,
Krzysztof

Re: [PATCH v1 4/8] thermal: qcom: add qmi-cooling driver

[Gaurav Kohli]

On 12/24/2025 2:31 PM, Krzysztof Kozlowski wrote:
> On 23/12/2025 13:32, Gaurav Kohli wrote:
>> +static int thermal_qmi_new_server(struct qmi_handle *qmi, struct qmi_service *service)
>> +{
>> +	struct qmi_tmd_client *client = container_of(qmi, struct qmi_tmd_client, handle);
>> +	struct sockaddr_qrtr sq = { AF_QIPCRTR, service->node, service->port };
>> +
>> +	scoped_guard(mutex, &client->mutex)
>> +		kernel_connect(qmi->sock, (struct sockaddr_unsized *)&sq, sizeof(sq), 0);
>> +
>> +	queue_work(system_highpri_wq, &client->svc_arrive_work);
>> +
>> +	return 0;
>> +}
>> +
>> +static struct qmi_ops thermal_qmi_event_ops = {
> Why this is not const?


Will fix this.


>
>  From where did you copy this code?


We are using Casey's patches also in current series.

https://lore.kernel.org/linux-devicetree/20250822042316.1762153-1-quic_gkohli@quicinc.com/

Will fix all the suggested comments.


>
>> +	.new_server = thermal_qmi_new_server,
>> +	.del_server = thermal_qmi_del_server,
>> +	.net_reset = thermal_qmi_net_reset,
>> +};
>> +
>> +static void qmi_tmd_cleanup(struct qmi_tmd_client *client)
>> +{
>> +	struct qmi_tmd *tmd, *c_next;
>> +
>> +	guard(mutex)(&client->mutex);
>> +
>> +	client->connection_active = false;
>> +
>> +	qmi_handle_release(&client->handle);
>> +	cancel_work(&client->svc_arrive_work);
>> +	list_for_each_entry_safe(tmd, c_next, &client->cdev_list, node) {
>> +		if (tmd->rproc_cdev)
>> +			remoteproc_cooling_unregister(tmd->rproc_cdev);
>> +
>> +		list_del(&tmd->node);
>> +	}
>> +}
>> +
>> +/* Parse the controls and allocate a qmi_tmd for each of them */
>> +static int qmi_tmd_alloc_cdevs(struct qmi_tmd_client *client)
>> +{
>> +	struct device *dev = client->dev;
>> +	struct qmi_tmd *tmd;
>> +	struct device_node *subnode, *node = dev->of_node;
>> +	int ret;
>> +
>> +	for_each_available_child_of_node(node, subnode) {
>> +		const char *name;
>> +
>> +		tmd = devm_kzalloc(dev, sizeof(*tmd), GFP_KERNEL);
>> +		if (!tmd)
>> +			return dev_err_probe(client->dev, -ENOMEM,
>> +					     "Couldn't allocate tmd\n");
> You leak nodes.
>
>> +
>> +		tmd->type = devm_kasprintf(client->dev, GFP_KERNEL, "%s:%s",
>> +						client->name, subnode->name);
>> +		if (!tmd->type)
>> +			return dev_err_probe(dev, -ENOMEM,
>> +					     "Couldn't allocate cooling device name\n");
> Everywhere...
>
>> +
>> +		if (of_property_read_string(subnode, "label", &name)) {
>> +			return dev_err_probe(client->dev, -EINVAL,
>> +					     "Failed to parse dev name for %s\n",
>> +					     subnode->name);
>> +		}
>> +
>> +		ret = strscpy(tmd->qmi_name, name,
>> +			      QMI_TMD_MITIGATION_DEV_ID_LENGTH_MAX_V01 + 1);
>> +		if (ret == -E2BIG) {
>> +			return dev_err_probe(dev, -EINVAL, "TMD label %s is too long\n",
>> +					     name);
>> +		}
>> +
>> +		tmd->client = client;
>> +		tmd->np = subnode;
>> +		tmd->cur_state = 0;
>> +		list_add(&tmd->node, &client->cdev_list);
>> +	}
>> +
>> +	if (list_empty(&client->cdev_list))
>> +		return dev_err_probe(client->dev, -EINVAL,
>> +				     "No cooling devices specified for client %s (%#x)\n",
>> +				     client->name, client->id);
>> +
>> +	return 0;
>> +}
>> +
>> +static int qmi_tmd_client_probe(struct platform_device *pdev)
>> +{
>> +	struct device *dev = &pdev->dev;
>> +	struct qmi_tmd_client *client;
>> +	const struct qmi_instance_data *match;
>> +	int ret;
> Open any existing Linux driver. How does this part look like?
>
>> +	client = devm_kzalloc(dev, sizeof(*client), GFP_KERNEL);
>> +	if (!client)
>> +		return -ENOMEM;
>> +
>> +	client->dev = dev;
>> +
>> +	match = of_device_get_match_data(dev);
>> +	if (!match)
>> +		return dev_err_probe(dev, -EINVAL, "No match data\n");
>> +
>> +	client->id = match->id;
>> +	client->name = match->name;
>> +
>> +	mutex_init(&client->mutex);
>> +	INIT_LIST_HEAD(&client->cdev_list);
>> +	INIT_WORK(&client->svc_arrive_work, qmi_tmd_svc_arrive);
>> +
>> +	ret = qmi_tmd_alloc_cdevs(client);
>> +	if (ret)
>> +		return ret;
>> +
>> +	platform_set_drvdata(pdev, client);
>> +
>> +	ret = qmi_handle_init(&client->handle,
>> +			      TMD_GET_MITIGATION_DEVICE_LIST_RESP_MSG_V01_MAX_MSG_LEN,
>> +			      &thermal_qmi_event_ops, NULL);
>> +	if (ret < 0)
>> +		return dev_err_probe(client->dev, ret, "QMI handle init failed for client %#x\n",
>> +			      client->id);
>> +
>> +	ret = qmi_add_lookup(&client->handle, TMD_SERVICE_ID_V01, TMD_SERVICE_VERS_V01,
>> +			     client->id);
>> +	if (ret < 0) {
>> +		qmi_handle_release(&client->handle);
>> +		return dev_err_probe(client->dev, ret, "QMI register failed for client 0x%x\n",
>> +			      client->id);
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +static void qmi_tmd_client_remove(struct platform_device *pdev)
>> +{
>> +	struct qmi_tmd_client *client = platform_get_drvdata(pdev);
>> +
>> +	qmi_tmd_cleanup(client);
>> +}
>> +
>> +static const struct of_device_id qmi_tmd_device_table[] = {
>> +	{
>> +		.compatible = "qcom,qmi-cooling-cdsp",
>> +		.data = &((struct qmi_instance_data) { CDSP_INSTANCE_ID, "cdsp" }),
> Please use Linux coding style.
>
>> +	},
>> +	{}
>> +};
>> +MODULE_DEVICE_TABLE(of, qmi_tmd_device_table);
>> +
>> +static struct platform_driver qmi_tmd_device_driver = {
>> +	.probe = qmi_tmd_client_probe,
>> +	.remove = qmi_tmd_client_remove,
>> +	.driver = {
>> +		.name = "qcom-qmi-cooling",
>> +		.of_match_table = qmi_tmd_device_table,
>> +	},
>
> Best regards,
> Krzysztof

[PATCH v1 5/8] arm64: dts: qcom: Enable cdsp qmi tmd devices for lemans

[Gaurav Kohli]

Enable cdsp cooling devices and thermal zone cooling map bindings for
both cdsp and cdsp1.

Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/lemans.dtsi | 138 ++++++++++++++++++++++++---
 1 file changed, 126 insertions(+), 12 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
index 0b154d57ba24..68cc4badaed5 100644
--- a/arch/arm64/boot/dts/qcom/lemans.dtsi
+++ b/arch/arm64/boot/dts/qcom/lemans.dtsi
@@ -21,6 +21,7 @@
 #include <dt-bindings/power/qcom-rpmpd.h>
 #include <dt-bindings/soc/qcom,gpr.h>
 #include <dt-bindings/soc/qcom,rpmh-rsc.h>
+#include <dt-bindings/thermal/thermal.h>
 
 / {
 	interrupt-parent = <&intc>;
@@ -7018,6 +7019,14 @@ compute-cb@11 {
 					};
 				};
 			};
+
+			cooling {
+				compatible = "qcom,qmi-cooling-cdsp";
+					cdsp_sw0: cdsp_sw {
+						label = "cdsp_sw";
+						#cooling-cells = <2>;
+					};
+			};
 		};
 
 		remoteproc_cdsp1: remoteproc@2a300000 {
@@ -7174,6 +7183,15 @@ compute-cb@13 {
 					};
 				};
 			};
+
+
+			cooling {
+				compatible = "qcom,qmi-cooling-cdsp";
+					cdsp_sw1: cdsp_sw {
+						label = "cdsp_sw";
+						#cooling-cells = <2>;
+					};
+			};
 		};
 
 		remoteproc_adsp: remoteproc@30000000 {
@@ -7856,7 +7874,7 @@ nsp-0-0-0-thermal {
 			thermal-sensors = <&tsens2 5>;
 
 			trips {
-				trip-point0 {
+				nsp_0_0_0_alert0: trip-point0 {
 					temperature = <105000>;
 					hysteresis = <5000>;
 					type = "passive";
@@ -7868,6 +7886,14 @@ trip-point1 {
 					type = "passive";
 				};
 			};
+
+			cooling-maps {
+				map0 {
+					trip = <&nsp_0_0_0_alert0>;
+					cooling-device = <&cdsp_sw0
+							THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
 		};
 
 		nsp-0-1-0-thermal {
@@ -7876,7 +7902,7 @@ nsp-0-1-0-thermal {
 			thermal-sensors = <&tsens2 6>;
 
 			trips {
-				trip-point0 {
+				nsp_0_1_0_alert0: trip-point0 {
 					temperature = <105000>;
 					hysteresis = <5000>;
 					type = "passive";
@@ -7888,6 +7914,14 @@ trip-point1 {
 					type = "passive";
 				};
 			};
+
+			cooling-maps {
+				map0 {
+					trip = <&nsp_0_1_0_alert0>;
+					cooling-device = <&cdsp_sw0
+							THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
 		};
 
 		nsp-0-2-0-thermal {
@@ -7896,7 +7930,7 @@ nsp-0-2-0-thermal {
 			thermal-sensors = <&tsens2 7>;
 
 			trips {
-				trip-point0 {
+				nsp_0_2_0_alert0: trip-point0 {
 					temperature = <105000>;
 					hysteresis = <5000>;
 					type = "passive";
@@ -7908,6 +7942,14 @@ trip-point1 {
 					type = "passive";
 				};
 			};
+
+			cooling-maps {
+				map0 {
+					trip = <&nsp_0_2_0_alert0>;
+					cooling-device = <&cdsp_sw0
+							THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
 		};
 
 		nsp-1-0-0-thermal {
@@ -7916,7 +7958,7 @@ nsp-1-0-0-thermal {
 			thermal-sensors = <&tsens2 8>;
 
 			trips {
-				trip-point0 {
+				nsp_1_0_0_alert0: trip-point0 {
 					temperature = <105000>;
 					hysteresis = <5000>;
 					type = "passive";
@@ -7928,6 +7970,14 @@ trip-point1 {
 					type = "passive";
 				};
 			};
+
+			cooling-maps {
+				map0 {
+					trip = <&nsp_1_0_0_alert0>;
+					cooling-device = <&cdsp_sw1
+							THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
 		};
 
 		nsp-1-1-0-thermal {
@@ -7936,7 +7986,7 @@ nsp-1-1-0-thermal {
 			thermal-sensors = <&tsens2 9>;
 
 			trips {
-				trip-point0 {
+				nsp_1_1_0_alert0: trip-point0 {
 					temperature = <105000>;
 					hysteresis = <5000>;
 					type = "passive";
@@ -7948,6 +7998,14 @@ trip-point1 {
 					type = "passive";
 				};
 			};
+
+			cooling-maps {
+				map0 {
+					trip = <&nsp_1_1_0_alert0>;
+					cooling-device = <&cdsp_sw1
+							THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
 		};
 
 		nsp-1-2-0-thermal {
@@ -7956,7 +8014,7 @@ nsp-1-2-0-thermal {
 			thermal-sensors = <&tsens2 10>;
 
 			trips {
-				trip-point0 {
+				nsp_1_2_0_alert0: trip-point0 {
 					temperature = <105000>;
 					hysteresis = <5000>;
 					type = "passive";
@@ -7968,6 +8026,14 @@ trip-point1 {
 					type = "passive";
 				};
 			};
+
+			cooling-maps {
+				map0 {
+					trip = <&nsp_1_2_0_alert0>;
+					cooling-device = <&cdsp_sw1
+							THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
 		};
 
 		ddrss-0-thermal {
@@ -8110,7 +8176,7 @@ nsp-0-0-1-thermal {
 			thermal-sensors = <&tsens3 5>;
 
 			trips {
-				trip-point0 {
+				nsp_0_0_1_alert0: trip-point0 {
 					temperature = <105000>;
 					hysteresis = <5000>;
 					type = "passive";
@@ -8122,6 +8188,14 @@ trip-point1 {
 					type = "passive";
 				};
 			};
+
+			cooling-maps {
+				map0 {
+					trip = <&nsp_0_0_1_alert0>;
+					cooling-device = <&cdsp_sw0
+							THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
 		};
 
 		nsp-0-1-1-thermal {
@@ -8130,7 +8204,7 @@ nsp-0-1-1-thermal {
 			thermal-sensors = <&tsens3 6>;
 
 			trips {
-				trip-point0 {
+				nsp_0_1_1_alert0: trip-point0 {
 					temperature = <105000>;
 					hysteresis = <5000>;
 					type = "passive";
@@ -8142,6 +8216,14 @@ trip-point1 {
 					type = "passive";
 				};
 			};
+
+			cooling-maps {
+				map0 {
+					trip = <&nsp_0_1_1_alert0>;
+					cooling-device = <&cdsp_sw0
+							THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
 		};
 
 		nsp-0-2-1-thermal {
@@ -8150,7 +8232,7 @@ nsp-0-2-1-thermal {
 			thermal-sensors = <&tsens3 7>;
 
 			trips {
-				trip-point0 {
+				nsp_0_2_1_alert0: trip-point0 {
 					temperature = <105000>;
 					hysteresis = <5000>;
 					type = "passive";
@@ -8162,6 +8244,14 @@ trip-point1 {
 					type = "passive";
 				};
 			};
+
+			cooling-maps {
+				map0 {
+					trip = <&nsp_0_2_1_alert0>;
+					cooling-device = <&cdsp_sw0
+							THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
 		};
 
 		nsp-1-0-1-thermal {
@@ -8170,7 +8260,7 @@ nsp-1-0-1-thermal {
 			thermal-sensors = <&tsens3 8>;
 
 			trips {
-				trip-point0 {
+				nsp_1_0_1_alert0: trip-point0 {
 					temperature = <105000>;
 					hysteresis = <5000>;
 					type = "passive";
@@ -8182,6 +8272,14 @@ trip-point1 {
 					type = "passive";
 				};
 			};
+
+			cooling-maps {
+				map0 {
+					trip = <&nsp_1_0_1_alert0>;
+					cooling-device = <&cdsp_sw1
+							THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
 		};
 
 		nsp-1-1-1-thermal {
@@ -8190,7 +8288,7 @@ nsp-1-1-1-thermal {
 			thermal-sensors = <&tsens3 9>;
 
 			trips {
-				trip-point0 {
+				nsp_1_1_1_alert0: trip-point0 {
 					temperature = <105000>;
 					hysteresis = <5000>;
 					type = "passive";
@@ -8202,6 +8300,14 @@ trip-point1 {
 					type = "passive";
 				};
 			};
+
+			cooling-maps {
+				map0 {
+					trip = <&nsp_1_1_1_alert0>;
+					cooling-device = <&cdsp_sw1
+							THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
 		};
 
 		nsp-1-2-1-thermal {
@@ -8210,7 +8316,7 @@ nsp-1-2-1-thermal {
 			thermal-sensors = <&tsens3 10>;
 
 			trips {
-				trip-point0 {
+				nsp_1_2_1_alert0: trip-point0 {
 					temperature = <105000>;
 					hysteresis = <5000>;
 					type = "passive";
@@ -8222,6 +8328,14 @@ trip-point1 {
 					type = "passive";
 				};
 			};
+
+			cooling-maps {
+				map0 {
+					trip = <&nsp_1_2_1_alert0>;
+					cooling-device = <&cdsp_sw1
+							THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
 		};
 
 		ddrss-1-thermal {
-- 
2.34.1

Re: [PATCH v1 5/8] arm64: dts: qcom: Enable cdsp qmi tmd devices for lemans

[Dmitry Baryshkov]

On Tue, Dec 23, 2025 at 06:02:24PM +0530, Gaurav Kohli wrote:
> Enable cdsp cooling devices and thermal zone cooling map bindings for
> both cdsp and cdsp1.
> 
> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/lemans.dtsi | 138 ++++++++++++++++++++++++---
>  1 file changed, 126 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
> index 0b154d57ba24..68cc4badaed5 100644
> --- a/arch/arm64/boot/dts/qcom/lemans.dtsi
> +++ b/arch/arm64/boot/dts/qcom/lemans.dtsi
> @@ -21,6 +21,7 @@
>  #include <dt-bindings/power/qcom-rpmpd.h>
>  #include <dt-bindings/soc/qcom,gpr.h>
>  #include <dt-bindings/soc/qcom,rpmh-rsc.h>
> +#include <dt-bindings/thermal/thermal.h>
>  
>  / {
>  	interrupt-parent = <&intc>;
> @@ -7018,6 +7019,14 @@ compute-cb@11 {
>  					};
>  				};
>  			};
> +
> +			cooling {
> +				compatible = "qcom,qmi-cooling-cdsp";
> +					cdsp_sw0: cdsp_sw {

Please fix DT formatting here.

> +						label = "cdsp_sw";
> +						#cooling-cells = <2>;
> +					};
> +			};
>  		};
>  
>  		remoteproc_cdsp1: remoteproc@2a300000 {

-- 
With best wishes
Dmitry

[PATCH v1 6/8] arm64: dts: qcom: Enable cdsp qmi tmd devices for talos

[Gaurav Kohli]

Enable cdsp cooling devices and thermal zone cooling map bindings
for cdsp.

Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/talos.dtsi | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/talos.dtsi b/arch/arm64/boot/dts/qcom/talos.dtsi
index 95d26e313622..61faea81c263 100644
--- a/arch/arm64/boot/dts/qcom/talos.dtsi
+++ b/arch/arm64/boot/dts/qcom/talos.dtsi
@@ -18,6 +18,7 @@
 #include <dt-bindings/power/qcom-rpmpd.h>
 #include <dt-bindings/power/qcom,rpmhpd.h>
 #include <dt-bindings/soc/qcom,rpmh-rsc.h>
+#include <dt-bindings/thermal/thermal.h>
 
 / {
 	interrupt-parent = <&intc>;
@@ -3550,6 +3551,14 @@ compute-cb@6 {
 					};
 				};
 			};
+
+			cooling {
+				compatible = "qcom,qmi-cooling-cdsp";
+					cdsp_sw: cdsp_sw {
+						label = "cdsp_sw";
+						#cooling-cells = <2>;
+					};
+			};
 		};
 
 		pmu@90b6300 {
@@ -4721,12 +4730,26 @@ q6-hvx-thermal {
 			thermal-sensors = <&tsens0 10>;
 
 			trips {
+				q6_hvx_alert0: trip-point0 {
+					temperature = <105000>;
+					hysteresis = <5000>;
+					type = "passive";
+				};
+
 				q6-hvx-critical {
 					temperature = <115000>;
 					hysteresis = <1000>;
 					type = "critical";
 				};
 			};
+
+			cooling-maps {
+				map0 {
+					trip = <&q6_hvx_alert0>;
+					cooling-device = <&cdsp_sw
+							THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
 		};
 
 		mdm-core-thermal {
-- 
2.34.1

Re: [PATCH v1 6/8] arm64: dts: qcom: Enable cdsp qmi tmd devices for talos

[Bjorn Andersson]

On Tue, Dec 23, 2025 at 06:02:25PM +0530, Gaurav Kohli wrote:
> Enable cdsp cooling devices and thermal zone cooling map bindings
> for cdsp.

This is the first time we're seeing this in a DeviceTree file, so I want
a proper problem description of what it is, why it is. As described in:
https://docs.kernel.org/process/submitting-patches.html#describe-your-changes

> 
> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/talos.dtsi | 23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/talos.dtsi b/arch/arm64/boot/dts/qcom/talos.dtsi
> index 95d26e313622..61faea81c263 100644
> --- a/arch/arm64/boot/dts/qcom/talos.dtsi
> +++ b/arch/arm64/boot/dts/qcom/talos.dtsi
> @@ -18,6 +18,7 @@
>  #include <dt-bindings/power/qcom-rpmpd.h>
>  #include <dt-bindings/power/qcom,rpmhpd.h>
>  #include <dt-bindings/soc/qcom,rpmh-rsc.h>
> +#include <dt-bindings/thermal/thermal.h>
>  
>  / {
>  	interrupt-parent = <&intc>;
> @@ -3550,6 +3551,14 @@ compute-cb@6 {
>  					};
>  				};
>  			};
> +
> +			cooling {
> +				compatible = "qcom,qmi-cooling-cdsp";
> +					cdsp_sw: cdsp_sw {
> +						label = "cdsp_sw";
> +						#cooling-cells = <2>;
> +					};
> +			};
>  		};
>  
>  		pmu@90b6300 {
> @@ -4721,12 +4730,26 @@ q6-hvx-thermal {
>  			thermal-sensors = <&tsens0 10>;
>  
>  			trips {
> +				q6_hvx_alert0: trip-point0 {
> +					temperature = <105000>;

Perhaps my coffee hasn't kicked in this morning, but doesn't this say
that we should start throttle at 105C? Isn't that quite a bit above the
point where the OSM/EPSS is starving the apps CPUs? Shouldn't it be the
other way around? What does this cooling device actually do?

Regards,
Bjorn

> +					hysteresis = <5000>;
> +					type = "passive";
> +				};
> +
>  				q6-hvx-critical {
>  					temperature = <115000>;
>  					hysteresis = <1000>;
>  					type = "critical";
>  				};
>  			};
> +
> +			cooling-maps {
> +				map0 {
> +					trip = <&q6_hvx_alert0>;
> +					cooling-device = <&cdsp_sw
> +							THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> +				};
> +			};
>  		};
>  
>  		mdm-core-thermal {
> -- 
> 2.34.1
> 

[PATCH v1 7/8] arm64: dts: qcom: Enable cdsp qmi tmd devices for kodiak

[Gaurav Kohli]

Enable cdsp cooling devices and cooling map bindings
for cdsp.

Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/kodiak.dtsi | 36 ++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
index c2ccbb67f800..03c1cef910a9 100644
--- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
+++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
@@ -4780,6 +4780,14 @@ compute-cb@14 {
 					};
 				};
 			};
+
+			cooling {
+				compatible = "qcom,qmi-cooling-cdsp";
+					cdsp_sw: cdsp_sw {
+						label = "cdsp_sw";
+						#cooling-cells = <2>;
+					};
+			};
 		};
 
 		usb_1: usb@a600000 {
@@ -7587,12 +7595,26 @@ nspss0_alert0: trip-point0 {
 					type = "hot";
 				};
 
+				nspss0_alert1: trip-point1 {
+					temperature = <100000>;
+					hysteresis = <5000>;
+					type = "passive";
+				};
+
 				nspss0_crit: nspss0-crit {
 					temperature = <110000>;
 					hysteresis = <0>;
 					type = "critical";
 				};
 			};
+
+			cooling-maps {
+				map0 {
+					trip = <&nspss0_alert1>;
+					cooling-device = <&cdsp_sw
+							THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
 		};
 
 		nspss1-thermal {
@@ -7605,12 +7627,26 @@ nspss1_alert0: trip-point0 {
 					type = "hot";
 				};
 
+				nspss1_alert1: trip-point1 {
+					temperature = <100000>;
+					hysteresis = <5000>;
+					type = "passive";
+				};
+
 				nspss1_crit: nspss1-crit {
 					temperature = <110000>;
 					hysteresis = <0>;
 					type = "critical";
 				};
 			};
+
+			cooling-maps {
+				map0 {
+					trip = <&nspss1_alert1>;
+					cooling-device = <&cdsp_sw
+							THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
 		};
 
 		video-thermal {
-- 
2.34.1

Re: [PATCH v1 7/8] arm64: dts: qcom: Enable cdsp qmi tmd devices for kodiak

[Bjorn Andersson]

On Tue, Dec 23, 2025 at 06:02:26PM +0530, Gaurav Kohli wrote:
> Enable cdsp cooling devices and cooling map bindings
> for cdsp.
> 
> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/kodiak.dtsi | 36 ++++++++++++++++++++++++++++
>  1 file changed, 36 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> index c2ccbb67f800..03c1cef910a9 100644
> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> @@ -4780,6 +4780,14 @@ compute-cb@14 {
>  					};
>  				};
>  			};
> +
> +			cooling {
> +				compatible = "qcom,qmi-cooling-cdsp";
> +					cdsp_sw: cdsp_sw {
> +						label = "cdsp_sw";
> +						#cooling-cells = <2>;
> +					};
> +			};
>  		};
>  
>  		usb_1: usb@a600000 {
> @@ -7587,12 +7595,26 @@ nspss0_alert0: trip-point0 {
>  					type = "hot";
>  				};
>  
> +				nspss0_alert1: trip-point1 {
> +					temperature = <100000>;

As with the previous patch, I want this number to be motivated in the
commit message.

Regards,
Bjorn

> +					hysteresis = <5000>;
> +					type = "passive";
> +				};
> +
>  				nspss0_crit: nspss0-crit {
>  					temperature = <110000>;
>  					hysteresis = <0>;
>  					type = "critical";
>  				};
>  			};
> +
> +			cooling-maps {
> +				map0 {
> +					trip = <&nspss0_alert1>;
> +					cooling-device = <&cdsp_sw
> +							THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> +				};
> +			};
>  		};
>  
>  		nspss1-thermal {
> @@ -7605,12 +7627,26 @@ nspss1_alert0: trip-point0 {
>  					type = "hot";
>  				};
>  
> +				nspss1_alert1: trip-point1 {
> +					temperature = <100000>;
> +					hysteresis = <5000>;
> +					type = "passive";
> +				};
> +
>  				nspss1_crit: nspss1-crit {
>  					temperature = <110000>;
>  					hysteresis = <0>;
>  					type = "critical";
>  				};
>  			};
> +
> +			cooling-maps {
> +				map0 {
> +					trip = <&nspss1_alert1>;
> +					cooling-device = <&cdsp_sw
> +							THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> +				};
> +			};
>  		};
>  
>  		video-thermal {
> -- 
> 2.34.1
> 

[PATCH v1 8/8] arm64: dts: qcom: Enable cdsp qmi tmd devices for monaco

[Gaurav Kohli]

Enable cdsp cooling devices and thermal zone cooling map bindings
for cdsp.

Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/monaco.dtsi | 92 ++++++++++++++++++++++++++++
 1 file changed, 92 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
index 985e37bf4876..1fe148ec5cf7 100644
--- a/arch/arm64/boot/dts/qcom/monaco.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
@@ -6217,6 +6217,14 @@ compute-cb@4 {
 					};
 				};
 			};
+
+			cooling {
+				compatible = "qcom,qmi-cooling-cdsp";
+					cdsp_sw: cdsp_sw {
+						label = "cdsp_sw";
+						#cooling-cells = <2>;
+					};
+			};
 		};
 
 		tsens2: thermal-sensor@c251000 {
@@ -6569,36 +6577,78 @@ nsp-0-0-0-thermal {
 			thermal-sensors = <&tsens2 5>;
 
 			trips {
+				nsp_0_0_0_alert0: trip-point0 {
+					temperature = <115000>;
+					hysteresis = <5000>;
+					type = "passive";
+				};
+
 				nsp-critical {
 					temperature = <125000>;
 					hysteresis = <1000>;
 					type = "critical";
 				};
 			};
+
+			cooling-maps {
+				map0 {
+					trip = <&nsp_0_0_0_alert0>;
+					cooling-device = <&cdsp_sw
+							THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
 		};
 
 		nsp-0-1-0-thermal {
 			thermal-sensors = <&tsens2 6>;
 
 			trips {
+				nsp_0_1_0_alert0: trip-point0 {
+					temperature = <115000>;
+					hysteresis = <5000>;
+					type = "passive";
+				};
+
 				nsp-critical {
 					temperature = <125000>;
 					hysteresis = <1000>;
 					type = "critical";
 				};
 			};
+
+			cooling-maps {
+				map0 {
+					trip = <&nsp_0_1_0_alert0>;
+					cooling-device = <&cdsp_sw
+							THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
 		};
 
 		nsp-0-2-0-thermal {
 			thermal-sensors = <&tsens2 7>;
 
 			trips {
+				nsp_0_2_0_alert0: trip-point0 {
+					temperature = <115000>;
+					hysteresis = <5000>;
+					type = "passive";
+				};
+
 				nsp-critical {
 					temperature = <125000>;
 					hysteresis = <1000>;
 					type = "critical";
 				};
 			};
+
+			cooling-maps {
+				map0 {
+					trip = <&nsp_0_2_0_alert0>;
+					cooling-device = <&cdsp_sw
+							THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
 		};
 
 		ddrss-0-thermal {
@@ -6689,36 +6739,78 @@ nsp-0-0-1-thermal {
 			thermal-sensors = <&tsens3 5>;
 
 			trips {
+				nsp_0_0_1_alert0: trip-point0 {
+					temperature = <115000>;
+					hysteresis = <5000>;
+					type = "passive";
+				};
+
 				nsp-critical {
 					temperature = <125000>;
 					hysteresis = <1000>;
 					type = "critical";
 				};
 			};
+
+			cooling-maps {
+				map0 {
+					trip = <&nsp_0_0_1_alert0>;
+					cooling-device = <&cdsp_sw
+							THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
 		};
 
 		nsp-0-1-1-thermal {
 			thermal-sensors = <&tsens3 6>;
 
 			trips {
+				nsp_0_1_1_alert0: trip-point0 {
+					temperature = <115000>;
+					hysteresis = <5000>;
+					type = "passive";
+				};
+
 				nsp-critical {
 					temperature = <125000>;
 					hysteresis = <1000>;
 					type = "critical";
 				};
 			};
+
+			cooling-maps {
+				map0 {
+					trip = <&nsp_0_1_1_alert0>;
+					cooling-device = <&cdsp_sw
+							THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
 		};
 
 		nsp-0-2-1-thermal {
 			thermal-sensors = <&tsens3 7>;
 
 			trips {
+				nsp_0_2_1_alert0: trip-point0 {
+					temperature = <115000>;
+					hysteresis = <5000>;
+					type = "passive";
+				};
+
 				nsp-critical {
 					temperature = <125000>;
 					hysteresis = <1000>;
 					type = "critical";
 				};
 			};
+
+			cooling-maps {
+				map0 {
+					trip = <&nsp_0_2_1_alert0>;
+					cooling-device = <&cdsp_sw
+							THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
 		};
 
 		ddrss-1-thermal {
-- 
2.34.1

Re: [PATCH v1 8/8] arm64: dts: qcom: Enable cdsp qmi tmd devices for monaco

[Krzysztof Kozlowski]

On 23/12/2025 13:32, Gaurav Kohli wrote:
> Enable cdsp cooling devices and thermal zone cooling map bindings
> for cdsp.
> 
> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/monaco.dtsi | 92 ++++++++++++++++++++++++++++
>  1 file changed, 92 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
> index 985e37bf4876..1fe148ec5cf7 100644
> --- a/arch/arm64/boot/dts/qcom/monaco.dtsi
> +++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
> @@ -6217,6 +6217,14 @@ compute-cb@4 {
>  					};
>  				};
>  			};
> +
> +			cooling {
> +				compatible = "qcom,qmi-cooling-cdsp";
> +					cdsp_sw: cdsp_sw {

Another LLM generated snippet or just mistake?

Best regards,
Krzysztof

Re: [PATCH v1 8/8] arm64: dts: qcom: Enable cdsp qmi tmd devices for monaco

[Gaurav Kohli]

On 12/24/2025 2:28 PM, Krzysztof Kozlowski wrote:
> On 23/12/2025 13:32, Gaurav Kohli wrote:
>> Enable cdsp cooling devices and thermal zone cooling map bindings
>> for cdsp.
>>
>> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>> ---
>>   arch/arm64/boot/dts/qcom/monaco.dtsi | 92 ++++++++++++++++++++++++++++
>>   1 file changed, 92 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
>> index 985e37bf4876..1fe148ec5cf7 100644
>> --- a/arch/arm64/boot/dts/qcom/monaco.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
>> @@ -6217,6 +6217,14 @@ compute-cb@4 {
>>   					};
>>   				};
>>   			};
>> +
>> +			cooling {
>> +				compatible = "qcom,qmi-cooling-cdsp";
>> +					cdsp_sw: cdsp_sw {
> Another LLM generated snippet or just mistake?


All this is manual code, will fix this.


>
> Best regards,
> Krzysztof

Re: [PATCH v1 0/8] Add RemoteProc cooling support

[Casey Connolly]

On 12/23/25 13:32, Gaurav Kohli wrote:
> This series introduces a generic remote proc cooling framework to control
> thermal sensors located on remote subsystem like modem, dsp etc.
> Communications with these subsystems occurs through various channels, for example,
> QMI interface for Qualcomm.
>   
> The Framework provides an abstraction layer between thermal subsytem and vendor
> specific remote subsystem. Vendor drivers are expected to implement callback
> and registration mechanisms with cooling framework to control cooling
> devices.
> 
> This patchset also revives earlier discussions of QMI based TMD cooling
> devices discussion posted on below series by Casey:
> https://lore.kernel.org/linux-devicetree/20230905-caleb-qmi_cooling-v1-0-5aa39d4164a7@linaro.org/
> 
> That series introduced Qualcomm QMI-based TMD cooling devices which 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 and registering with remoteproc
> cooling framework for cooling registration.
> 
> This patch series has a compilation/runtime dependency on another series [1].
> 
> [1] https://lore.kernel.org/linux-devicetree/20250822042316.1762153-1-quic_gkohli@quicinc.com/
> 
> Casey Connolly (2):
>    remoteproc: qcom: probe all child devices
>    thermal: qcom: add qmi-cooling driver

I'm glad this series is getting revived. It would be good if you could 
explain what changes you made to my patches somewhere.

I also remember one of my patches adding the DT parts for SDM845, would 
you be willing to pick that up for the next revision? I'd be happy to 
provide my Tested-by.

Kind regards,

> 
> Gaurav Kohli (6):
>    thermal: Add Remote Proc cooling driver
>    dt-bindings: thermal: Add qcom,qmi-cooling yaml bindings
>    arm64: dts: qcom: Enable cdsp qmi tmd devices for lemans
>    arm64: dts: qcom: Enable cdsp qmi tmd devices for talos
>    arm64: dts: qcom: Enable cdsp qmi tmd devices for kodiak
>    arm64: dts: qcom: Enable cdsp qmi tmd devices for monaco
> 
>   .../bindings/remoteproc/qcom,pas-common.yaml  |   6 +
>   .../bindings/thermal/qcom,qmi-cooling.yaml    |  99 ++++
>   MAINTAINERS                                   |   8 +
>   arch/arm64/boot/dts/qcom/kodiak.dtsi          |  36 ++
>   arch/arm64/boot/dts/qcom/lemans.dtsi          | 138 ++++-
>   arch/arm64/boot/dts/qcom/monaco.dtsi          |  92 ++++
>   arch/arm64/boot/dts/qcom/talos.dtsi           |  23 +
>   drivers/remoteproc/qcom_q6v5.c                |   4 +
>   drivers/remoteproc/qcom_q6v5_mss.c            |   8 -
>   drivers/soc/qcom/Kconfig                      |  13 +
>   drivers/soc/qcom/Makefile                     |   1 +
>   drivers/soc/qcom/qmi-cooling.c                | 498 ++++++++++++++++++
>   drivers/soc/qcom/qmi-cooling.h                | 428 +++++++++++++++
>   drivers/thermal/Kconfig                       |  11 +
>   drivers/thermal/Makefile                      |   2 +
>   drivers/thermal/qcom/qmi-cooling.h            | 428 +++++++++++++++
>   drivers/thermal/remoteproc_cooling.c          | 154 ++++++
>   include/linux/remoteproc_cooling.h            |  52 ++
>   18 files changed, 1981 insertions(+), 20 deletions(-)
>   create mode 100644 Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml
>   create mode 100644 drivers/soc/qcom/qmi-cooling.c
>   create mode 100644 drivers/soc/qcom/qmi-cooling.h
>   create mode 100644 drivers/thermal/qcom/qmi-cooling.h
>   create mode 100644 drivers/thermal/remoteproc_cooling.c
>   create mode 100644 include/linux/remoteproc_cooling.h
> 

Re: [PATCH v1 0/8] Add RemoteProc cooling support

[Gaurav Kohli]

On 1/10/2026 9:43 PM, Casey Connolly wrote:
>
>
> On 12/23/25 13:32, Gaurav Kohli wrote:
>> This series introduces a generic remote proc cooling framework to 
>> control
>> thermal sensors located on remote subsystem like modem, dsp etc.
>> Communications with these subsystems occurs through various channels, 
>> for example,
>> QMI interface for Qualcomm.
>>   The Framework provides an abstraction layer between thermal 
>> subsytem and vendor
>> specific remote subsystem. Vendor drivers are expected to implement 
>> callback
>> and registration mechanisms with cooling framework to control cooling
>> devices.
>>
>> This patchset also revives earlier discussions of QMI based TMD cooling
>> devices discussion posted on below series by Casey:
>> https://lore.kernel.org/linux-devicetree/20230905-caleb-qmi_cooling-v1-0-5aa39d4164a7@linaro.org/ 
>>
>>
>> That series introduced Qualcomm QMI-based TMD cooling devices which 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 and registering with remoteproc
>> cooling framework for cooling registration.
>>
>> This patch series has a compilation/runtime dependency on another 
>> series [1].
>>
>> [1] 
>> https://lore.kernel.org/linux-devicetree/20250822042316.1762153-1-quic_gkohli@quicinc.com/
>>
>> Casey Connolly (2):
>>    remoteproc: qcom: probe all child devices
>>    thermal: qcom: add qmi-cooling driver
>
> I'm glad this series is getting revived. It would be good if you could 
> explain what changes you made to my patches somewhere.
>
> I also remember one of my patches adding the DT parts for SDM845, 
> would you be willing to pick that up for the next revision? I'd be 
> happy to provide my Tested-by.
>
> Kind regards,
>
Hi Casey,

With this remoeproc cooling abstraction layer, we have integrated your 
patches for subsystem cooling. As lot of comments came for qmi-cooling 
driver, so need to send v2 with cleanup.

Will do clean up and send series again. Yes for other targets like 
sdm845 we will add once this is concluded.


>>
>> Gaurav Kohli (6):
>>    thermal: Add Remote Proc cooling driver
>>    dt-bindings: thermal: Add qcom,qmi-cooling yaml bindings
>>    arm64: dts: qcom: Enable cdsp qmi tmd devices for lemans
>>    arm64: dts: qcom: Enable cdsp qmi tmd devices for talos
>>    arm64: dts: qcom: Enable cdsp qmi tmd devices for kodiak
>>    arm64: dts: qcom: Enable cdsp qmi tmd devices for monaco
>>
>>   .../bindings/remoteproc/qcom,pas-common.yaml  |   6 +
>>   .../bindings/thermal/qcom,qmi-cooling.yaml    |  99 ++++
>>   MAINTAINERS                                   |   8 +
>>   arch/arm64/boot/dts/qcom/kodiak.dtsi          |  36 ++
>>   arch/arm64/boot/dts/qcom/lemans.dtsi          | 138 ++++-
>>   arch/arm64/boot/dts/qcom/monaco.dtsi          |  92 ++++
>>   arch/arm64/boot/dts/qcom/talos.dtsi           |  23 +
>>   drivers/remoteproc/qcom_q6v5.c                |   4 +
>>   drivers/remoteproc/qcom_q6v5_mss.c            |   8 -
>>   drivers/soc/qcom/Kconfig                      |  13 +
>>   drivers/soc/qcom/Makefile                     |   1 +
>>   drivers/soc/qcom/qmi-cooling.c                | 498 ++++++++++++++++++
>>   drivers/soc/qcom/qmi-cooling.h                | 428 +++++++++++++++
>>   drivers/thermal/Kconfig                       |  11 +
>>   drivers/thermal/Makefile                      |   2 +
>>   drivers/thermal/qcom/qmi-cooling.h            | 428 +++++++++++++++
>>   drivers/thermal/remoteproc_cooling.c          | 154 ++++++
>>   include/linux/remoteproc_cooling.h            |  52 ++
>>   18 files changed, 1981 insertions(+), 20 deletions(-)
>>   create mode 100644 
>> Documentation/devicetree/bindings/thermal/qcom,qmi-cooling.yaml
>>   create mode 100644 drivers/soc/qcom/qmi-cooling.c
>>   create mode 100644 drivers/soc/qcom/qmi-cooling.h
>>   create mode 100644 drivers/thermal/qcom/qmi-cooling.h
>>   create mode 100644 drivers/thermal/remoteproc_cooling.c
>>   create mode 100644 include/linux/remoteproc_cooling.h
>>
>

Re: [PATCH v1 0/8] Add RemoteProc cooling support

[Trilok Soni]

On 1/13/2026 1:33 AM, Gaurav Kohli wrote:
> 
> On 1/10/2026 9:43 PM, Casey Connolly wrote:
>>
>>
>> On 12/23/25 13:32, Gaurav Kohli wrote:
>>> This series introduces a generic remote proc cooling framework to control
>>> thermal sensors located on remote subsystem like modem, dsp etc.
>>> Communications with these subsystems occurs through various channels, for example,
>>> QMI interface for Qualcomm.
>>>   The Framework provides an abstraction layer between thermal subsytem and vendor
>>> specific remote subsystem. Vendor drivers are expected to implement callback
>>> and registration mechanisms with cooling framework to control cooling
>>> devices.
>>>
>>> This patchset also revives earlier discussions of QMI based TMD cooling
>>> devices discussion posted on below series by Casey:
>>> https://lore.kernel.org/linux-devicetree/20230905-caleb-qmi_cooling-v1-0-5aa39d4164a7@linaro.org/
>>>
>>> That series introduced Qualcomm QMI-based TMD cooling devices which 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 and registering with remoteproc
>>> cooling framework for cooling registration.
>>>
>>> This patch series has a compilation/runtime dependency on another series [1].
>>>
>>> [1] https://lore.kernel.org/linux-devicetree/20250822042316.1762153-1-quic_gkohli@quicinc.com/
>>>
>>> Casey Connolly (2):
>>>    remoteproc: qcom: probe all child devices
>>>    thermal: qcom: add qmi-cooling driver
>>
>> I'm glad this series is getting revived. It would be good if you could explain what changes you made to my patches somewhere.
>>
>> I also remember one of my patches adding the DT parts for SDM845, would you be willing to pick that up for the next revision? I'd be happy to provide my Tested-by.
>>
>> Kind regards,
>>
> Hi Casey,
> 
> With this remoeproc cooling abstraction layer, we have integrated your patches for subsystem cooling. As lot of comments came for qmi-cooling driver, so need to send v2 with cleanup.

Gaurav - the question somewhere in the series was that why you had marked your patch series 
to v1, when you had revived the original (v1?) series from Casey? Should we consider
current patch series as v2 then? I don't know if that comment was concluded. 

---Trilok Soni

Re: [PATCH v1 0/8] Add RemoteProc cooling support

[Konrad Dybcio]

On 2/1/26 9:20 PM, Trilok Soni wrote:
> On 1/13/2026 1:33 AM, Gaurav Kohli wrote:
>>
>> On 1/10/2026 9:43 PM, Casey Connolly wrote:
>>>
>>>
>>> On 12/23/25 13:32, Gaurav Kohli wrote:
>>>> This series introduces a generic remote proc cooling framework to control
>>>> thermal sensors located on remote subsystem like modem, dsp etc.
>>>> Communications with these subsystems occurs through various channels, for example,
>>>> QMI interface for Qualcomm.
>>>>   The Framework provides an abstraction layer between thermal subsytem and vendor
>>>> specific remote subsystem. Vendor drivers are expected to implement callback
>>>> and registration mechanisms with cooling framework to control cooling
>>>> devices.
>>>>
>>>> This patchset also revives earlier discussions of QMI based TMD cooling
>>>> devices discussion posted on below series by Casey:
>>>> https://lore.kernel.org/linux-devicetree/20230905-caleb-qmi_cooling-v1-0-5aa39d4164a7@linaro.org/
>>>>
>>>> That series introduced Qualcomm QMI-based TMD cooling devices which 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 and registering with remoteproc
>>>> cooling framework for cooling registration.
>>>>
>>>> This patch series has a compilation/runtime dependency on another series [1].
>>>>
>>>> [1] https://lore.kernel.org/linux-devicetree/20250822042316.1762153-1-quic_gkohli@quicinc.com/
>>>>
>>>> Casey Connolly (2):
>>>>    remoteproc: qcom: probe all child devices
>>>>    thermal: qcom: add qmi-cooling driver
>>>
>>> I'm glad this series is getting revived. It would be good if you could explain what changes you made to my patches somewhere.
>>>
>>> I also remember one of my patches adding the DT parts for SDM845, would you be willing to pick that up for the next revision? I'd be happy to provide my Tested-by.
>>>
>>> Kind regards,
>>>
>> Hi Casey,
>>
>> With this remoeproc cooling abstraction layer, we have integrated your patches for subsystem cooling. As lot of comments came for qmi-cooling driver, so need to send v2 with cleanup.
> 
> Gaurav - the question somewhere in the series was that why you had marked your patch series 
> to v1, when you had revived the original (v1?) series from Casey? Should we consider
> current patch series as v2 then? I don't know if that comment was concluded. 

Because we have effectively 2 'v1's, there's already a certain mess, but
the msgid is different between them so the tools won't be confused
(i.e. just go with v2 for the next revision)

The outstanding request is to include a high-level changelog of what is
different as compared to the original series (as well as picking up the
original 845 DT commit if still relevant)

Konrad

Re: [PATCH v1 0/8] Add RemoteProc cooling support

[Gaurav Kohli]

On 2/2/2026 3:23 PM, Konrad Dybcio wrote:
> On 2/1/26 9:20 PM, Trilok Soni wrote:
>> On 1/13/2026 1:33 AM, Gaurav Kohli wrote:
>>>
>>> On 1/10/2026 9:43 PM, Casey Connolly wrote:
>>>>
>>>>
>>>> On 12/23/25 13:32, Gaurav Kohli wrote:
>>>>> This series introduces a generic remote proc cooling framework to control
>>>>> thermal sensors located on remote subsystem like modem, dsp etc.
>>>>> Communications with these subsystems occurs through various channels, for example,
>>>>> QMI interface for Qualcomm.
>>>>>    The Framework provides an abstraction layer between thermal subsytem and vendor
>>>>> specific remote subsystem. Vendor drivers are expected to implement callback
>>>>> and registration mechanisms with cooling framework to control cooling
>>>>> devices.
>>>>>
>>>>> This patchset also revives earlier discussions of QMI based TMD cooling
>>>>> devices discussion posted on below series by Casey:
>>>>> https://lore.kernel.org/linux-devicetree/20230905-caleb-qmi_cooling-v1-0-5aa39d4164a7@linaro.org/
>>>>>
>>>>> That series introduced Qualcomm QMI-based TMD cooling devices which 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 and registering with remoteproc
>>>>> cooling framework for cooling registration.
>>>>>
>>>>> This patch series has a compilation/runtime dependency on another series [1].
>>>>>
>>>>> [1] https://lore.kernel.org/linux-devicetree/20250822042316.1762153-1-quic_gkohli@quicinc.com/
>>>>>
>>>>> Casey Connolly (2):
>>>>>     remoteproc: qcom: probe all child devices
>>>>>     thermal: qcom: add qmi-cooling driver
>>>>
>>>> I'm glad this series is getting revived. It would be good if you could explain what changes you made to my patches somewhere.
>>>>
>>>> I also remember one of my patches adding the DT parts for SDM845, would you be willing to pick that up for the next revision? I'd be happy to provide my Tested-by.
>>>>
>>>> Kind regards,
>>>>
>>> Hi Casey,
>>>
>>> With this remoeproc cooling abstraction layer, we have integrated your patches for subsystem cooling. As lot of comments came for qmi-cooling driver, so need to send v2 with cleanup.
>>
>> Gaurav - the question somewhere in the series was that why you had marked your patch series
>> to v1, when you had revived the original (v1?) series from Casey? Should we consider
>> current patch series as v2 then? I don't know if that comment was concluded.
> 
> Because we have effectively 2 'v1's, there's already a certain mess, but
> the msgid is different between them so the tools won't be confused
> (i.e. just go with v2 for the next revision)
> 
> The outstanding request is to include a high-level changelog of what is
> different as compared to the original series (as well as picking up the
> original 845 DT commit if still relevant)

thanks, sure will update changelog for the actual diff/design change in 
next version.

> 
> Konrad

Re: [PATCH v1 0/8] Add RemoteProc cooling support

[Gaurav Kohli]

On 2/2/2026 1:50 AM, Trilok Soni wrote:
> On 1/13/2026 1:33 AM, Gaurav Kohli wrote:
>>
>> On 1/10/2026 9:43 PM, Casey Connolly wrote:
>>>
>>>
>>> On 12/23/25 13:32, Gaurav Kohli wrote:
>>>> This series introduces a generic remote proc cooling framework to control
>>>> thermal sensors located on remote subsystem like modem, dsp etc.
>>>> Communications with these subsystems occurs through various channels, for example,
>>>> QMI interface for Qualcomm.
>>>>    The Framework provides an abstraction layer between thermal subsytem and vendor
>>>> specific remote subsystem. Vendor drivers are expected to implement callback
>>>> and registration mechanisms with cooling framework to control cooling
>>>> devices.
>>>>
>>>> This patchset also revives earlier discussions of QMI based TMD cooling
>>>> devices discussion posted on below series by Casey:
>>>> https://lore.kernel.org/linux-devicetree/20230905-caleb-qmi_cooling-v1-0-5aa39d4164a7@linaro.org/
>>>>
>>>> That series introduced Qualcomm QMI-based TMD cooling devices which 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 and registering with remoteproc
>>>> cooling framework for cooling registration.
>>>>
>>>> This patch series has a compilation/runtime dependency on another series [1].
>>>>
>>>> [1] https://lore.kernel.org/linux-devicetree/20250822042316.1762153-1-quic_gkohli@quicinc.com/
>>>>
>>>> Casey Connolly (2):
>>>>     remoteproc: qcom: probe all child devices
>>>>     thermal: qcom: add qmi-cooling driver
>>>
>>> I'm glad this series is getting revived. It would be good if you could explain what changes you made to my patches somewhere.
>>>
>>> I also remember one of my patches adding the DT parts for SDM845, would you be willing to pick that up for the next revision? I'd be happy to provide my Tested-by.
>>>
>>> Kind regards,
>>>
>> Hi Casey,
>>
>> With this remoeproc cooling abstraction layer, we have integrated your patches for subsystem cooling. As lot of comments came for qmi-cooling driver, so need to send v2 with cleanup.
> 
> Gaurav - the question somewhere in the series was that why you had marked your patch series
> to v1, when you had revived the original (v1?) series from Casey? Should we consider
> current patch series as v2 then? I don't know if that comment was concluded.

thanks Trilok for review, i have marked this qmi-cooling to v1, as using 
this as part of new remoteproc cooling series.

> 
> ---Trilok Soni