On 12/06/2026 15:52, Gaurav Kohli wrote: > > > On 6/11/2026 5:53 PM, Krzysztof Kozlowski wrote: >> On 11/06/2026 13:12, Gaurav Kohli wrote: >>>> Why? And where is this generic property defined? You cannot just >>>> sprinkle generic properties in random bindings. >>>> >>> >>> Ack, will add why part. >>> These names are matched with the thermal mitigation device identifiers >>> populated by remote firmware over QMI and define mitigation devices are >>> exposed as cooling devices. >> >> No, -names correspond to values passed via DT, not some remote firmware. >> The remote firmware should give you interface which is explicit and does >> not need such properties. > > thanks Krzysztof for review, We need tmd-names because of following reasons: > > Following Daniel's series [1], the thermal framework supports > mapping multiple cooling devices per remoteproc/device via indexed > cooling-cells. > > 1) The thermal framework's cooling-maps reference > cooling devices by index (for #cooling-cells = <3>). Without tmd-names, > there's no way to know which index corresponds to which TMD, as firmware > may return tmd-names in any order. > > below are the changes post new thermal mapping changes: > DT: tmd-names = "cdsp_sw", "xyz"; > Firmware: ["cdsp_sw", "xyz1", "xyz2",] > Driver registers: Only "cdsp_sw" (index 0) and "xyz" (index 1)
names property are not to instruct drivers to register or not to register something. I don't understand the problem and explanation in the binding is basically non-existing. Remember that all lists and indices ARE FIXED, so driver knows exactly which index means what. > > This allows cooling-maps like below: > cooling-device = <&remoteproc 0 ...> // "cdsp_sw" > cooling-device = <&remoteproc 1 ...> // "xyz" > > 2) Not all firmware-provided TMDs should be > exposed as cooling devices. The tmd-names property acts as a filter, > allowing board-specific DT to select only the relevant TMDs for that > platform. And driver filters, no need for DT property. Best regards, Krzysztof
