From: Krzysztof Kozlowski <krzk@kernel.org>
To: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
Cc: andersson@kernel.org, mathieu.poirier@linaro.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
rui.zhang@intel.com, lukasz.luba@arm.com, konradybcio@kernel.org,
mani@kernel.org, casey.connolly@linaro.org,
amit.kucheria@oss.qualcomm.com, linux-arm-msm@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org, manaf.pallikunhi@oss.qualcomm.com
Subject: Re: [PATCH v2 2/8] dt-bindings: thermal: Add qcom,qmi-cooling yaml bindings
Date: Tue, 24 Feb 2026 13:17:22 +0100 [thread overview]
Message-ID: <95142608-b5b1-43a4-b8b6-38e658275f30@kernel.org> (raw)
In-Reply-To: <4f815a0f-a815-4b77-a4cf-a4b18e776eab@oss.qualcomm.com>
On 24/02/2026 13:09, Gaurav Kohli wrote:
>>>>>>>>> + cooling:
>>>>>>>>> + $ref: /schemas/thermal/qcom,qmi-cooling.yaml#
>>>>>>>>> + description:
>>>>>>>>> + Cooling subnode which represents the cooling devices exposed by the Modem.
>>>>>>>> I do not see the reason why you need 3 (!!!) children here. Everything
>>>>>>>> should be folded here.
>>>>>>>
>>>>>>>
>>>>>>> Thanks Krzysztof for review.
>>>>>>>
>>>>>>> Each subsystem may support multiple thermal mitigation devices through
>>>>>>> remote TMD service.
>>>>>>>
>>>>>>> Because of this multiplicity, introduced separate binding file.
>>>>>>
>>>>>> This explains nothing. Subsystem does not matter for the binding. My
>>>>>> comment stays.
>>>>>>
>>>>>
>>>>> thanks for this suggestion, we will use qcom,pas-common.yaml to define
>>>>> bindings and avoid creating new file.
>>>>
>>>> I asked not to create any children nodes.
>>>>
>>>
>>> We have multiple cores within a subsystem(cdsp) and each core has its
>>> own independent DCVS. And also we have dedicated TSENS sensor placed on
>>> each core within the subsystem.
>>
>> Your own example in this patch had only one device, so how do you
>> imagine to convince us with incomplete or half baked code?
>>
>
> Target of this series supports one tmd per remoteproc, due to which we
> have not posted examples of multiple tmd. Can i use dt binding example
> sections to describe all tmd's per remoteproc?
I don't know but you sent a patch with such rationale. If you post
incomplete patch as rationale, why would we review it in your favor? If
you cannot post complete patch, then what is missing or wrong?
>
>>> As a result, each core requires its own cooling device, which must be
>>> linked to its TSENS thermal zone. Because of this, we introduced
>>> multiple child nodes—one for each cooling device.
>>
>> So you have one device with cooling cells=1+2, no?
>>
>
> This will be a bigger framework change which is not supported, i can see
I don't think that changing open source frameworks is "not supported". I
am pretty sure that changing is not only supported, but actually desired.
> other drivers are also using something like this multiple cooling device
> under device node, below are few examples :
>
> ->Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml
> In this multiple fan child nodes are present.
So you have a fan there?
>
> -> Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.yaml
> In this multiple child nodes are present, like heavy and light.
This is absolute antipattern, just look at the properties there. Don't
bring ever old legacy, junk as argument that you can do the same junk.
No, you can't. Just like past bugs are not valid reason to add similar
bugs in the future.
Standard writing binding rules apply here - do you have resources there?
No. Then you cannot have children. You should fold the nodes into the
parent and use cooling-cells=3 (or whatever other number makes sense).
Best regards,
Krzysztof
next prev parent reply other threads:[~2026-02-24 12:17 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-27 15:57 [PATCH v2 0/8] Add RemoteProc cooling support Gaurav Kohli
2026-01-27 15:57 ` [PATCH v2 1/8] thermal: Add Remote Proc cooling driver Gaurav Kohli
2026-01-28 11:32 ` Krzysztof Kozlowski
2026-01-30 6:39 ` Gaurav Kohli
2026-02-08 10:08 ` Krzysztof Kozlowski
2026-01-28 11:36 ` Krzysztof Kozlowski
2026-01-30 6:42 ` Gaurav Kohli
2026-01-30 5:39 ` kernel test robot
2026-01-30 6:47 ` kernel test robot
2026-03-06 9:19 ` Daniel Lezcano
2026-03-06 9:27 ` Lukasz Luba
2026-03-09 6:34 ` Gaurav Kohli
2026-01-27 15:57 ` [PATCH v2 2/8] dt-bindings: thermal: Add qcom,qmi-cooling yaml bindings Gaurav Kohli
2026-01-28 11:27 ` Krzysztof Kozlowski
2026-01-29 12:06 ` Gaurav Kohli
2026-02-08 10:06 ` Krzysztof Kozlowski
2026-02-11 7:37 ` Gaurav Kohli
2026-02-11 8:13 ` Krzysztof Kozlowski
2026-02-20 7:29 ` Gaurav Kohli
2026-02-20 7:44 ` Krzysztof Kozlowski
2026-02-24 12:09 ` Gaurav Kohli
2026-02-24 12:17 ` Krzysztof Kozlowski [this message]
2026-03-16 19:57 ` Daniel Lezcano
2026-03-18 10:17 ` Gaurav Kohli
2026-03-19 9:51 ` Konrad Dybcio
2026-03-21 9:00 ` Daniel Lezcano
2026-03-23 12:29 ` Konrad Dybcio
2026-03-23 14:19 ` Daniel Lezcano
2026-03-23 14:25 ` Gaurav Kohli
2026-02-24 12:52 ` Dmitry Baryshkov
2026-01-28 11:28 ` Krzysztof Kozlowski
2026-01-29 12:12 ` Gaurav Kohli
2026-01-29 0:45 ` Dmitry Baryshkov
2026-01-30 7:08 ` Gaurav Kohli
2026-01-30 9:02 ` Dmitry Baryshkov
2026-01-27 15:57 ` [PATCH v2 3/8] remoteproc: qcom: probe all child devices Gaurav Kohli
2026-01-27 16:50 ` Dmitry Baryshkov
2026-01-27 15:57 ` [PATCH v2 4/8] thermal: qcom: add qmi-cooling driver Gaurav Kohli
2026-01-30 9:05 ` kernel test robot
2026-03-06 9:31 ` Daniel Lezcano
2026-03-16 10:19 ` Gaurav Kohli
2026-03-13 14:15 ` Daniel Lezcano
2026-03-17 7:25 ` Gaurav Kohli
2026-01-27 15:57 ` [PATCH v2 5/8] arm64: dts: qcom: lemans: Enable CDSP cooling Gaurav Kohli
2026-01-29 0:43 ` Dmitry Baryshkov
2026-01-29 12:10 ` Gaurav Kohli
2026-01-29 12:29 ` Dmitry Baryshkov
2026-01-29 13:40 ` Gaurav Kohli
2026-01-30 1:20 ` Dmitry Baryshkov
2026-01-27 15:57 ` [PATCH v2 6/8] arm64: dts: qcom: talos: " Gaurav Kohli
2026-01-27 15:57 ` [PATCH v2 7/8] arm64: dts: qcom: kodiak: " Gaurav Kohli
2026-01-27 15:57 ` [PATCH v2 8/8] arm64: dts: qcom: monaco: " Gaurav Kohli
2026-03-06 9:09 ` [PATCH v2 0/8] Add RemoteProc cooling support Daniel Lezcano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=95142608-b5b1-43a4-b8b6-38e658275f30@kernel.org \
--to=krzk@kernel.org \
--cc=amit.kucheria@oss.qualcomm.com \
--cc=andersson@kernel.org \
--cc=casey.connolly@linaro.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gaurav.kohli@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=manaf.pallikunhi@oss.qualcomm.com \
--cc=mani@kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=robh@kernel.org \
--cc=rui.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox