On 12/02/2018 09:52, Viresh Kumar wrote: > On 12-02-18, 09:39, Daniel Lezcano wrote: >> On 12/02/2018 07:10, Viresh Kumar wrote: >>> On 09-02-18, 13:14, Daniel Lezcano wrote: >>>> 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/ ?? >> >> yes. >> >>>> 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. >> >> They don't define a cooling device in the DT ? > > Sorry but I am getting a bit confused on what you are suggesting. > Maybe you need to rephrase it once more for me, from the very > beginning :) Not sure it is worth to go further in the discussion. I realize the *-cells is widely used everywhere. I was wondering if cooling-cells still have a meaning if we remove the min|max-levels as it is always two. But so far it is used as a cooling property for the device in any case and removing it *is* inconsistent with the rest of the code. Just to clarify my comment above, I understood you were asking how to not use the cpu as a cooling device. As the binding between the cooling device and the thermal zone happens when the DT nodes are the same, when registering the cpufreq driver as a cooling device and when the cooling-device registers itself at the cooling-map parsing time, if we remove the cooling-device in the cooling-map, the binding never happens thus the cpu is never used as a cooling device. However, these are all required fields, so the only way to do that is to remove the entire thermal zone node, not sure it is what we want :) -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog -- 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
