On 09-02-18, 13:14, Daniel Lezcano wrote: > Right. The semantic is unclear. The expected cooling-cells value is > always 2 (the code ignore values greater than two and yell if it is less > than 2). And the cooling-device binding tells there are two states. They are fixed to 2 as we don't need to use it differently for now. But that's more about how Linux is using this stuff. The binding still needs to provide a way to have more cells than just 2. > So the question is why do we need a cooling-cells as the information is > pointless here (always 2) ? To show that the device is a "cooling-device" and I see that consistent with everything else in DT, for example: interrupt-cells, gpio-cells, clock-cells, reset-cells, dma-cells. The "*-cells" properties is used widely to tell what the device can behave as, i.e. a cooling-device in our case. Now we always use 2 parameters exactly is a different thing all together :) > I see this field is artificially used to tell the cpufreq driver "please > register me as a cooling device". This is inconsistent from my pov. But that's how its used for every other controller, what's different here ? > Furthermore, the thermal-zone with the cooling device binds with the CPU > phandle, not the cooling-cells. Yeah, because that's the device really. > Putting apart the device binding changes discussion for the moment. Why > not register the cpufreq driver in all the cases and then drop s/cpufreq driver/cpufreq cooling driver/ ?? > cooling-cells ? So when the opps are present, its registers in the > cpufreq->ready callback. How will someone tell if they don't need the cooling infrastructure ? Specially for multiplatform thing. -- viresh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
