On 09/02/2018 07:42, Viresh Kumar wrote: > On 07-02-18, 11:45, Daniel Lezcano wrote: >> Yes, that is my understanding. cooling-min-level and cooling-max-level >> are not used in the thermal framework code today. > > Right. > >> So if they are defined, we should check the cooling-device max and min >> are in the boundaries (if they are different from no-limit). > > Hmm, I am not sure. We do compare those values (from maps) with the > max reported by the cooling driver, so there is some boundary check > happening. And I don't think it is worth comparing the min/max values > from DT cooling device's nodes. Why not just leave those for the > driver to return (which is already happening btw). > > I don't think it would be correct for the thermal core to go and look > at the min/max properties of the cooling device directly, as those are > more for the thermal driver's help. The thermal core should just call > the get_max_state() callback and that's it. > > Anyway, we can take decision on the binding itself after some time but > I will send some patches to get rid of this property from CPU nodes > for now. It doesn't make sense to have it there (anyway it is > optional), as the cpu cooling devices are kind of virtual cooling > devices which rely on OPP or freq-table currently. Maybe I will begin > by just updating one platform and once that is merged, update > everything else as well. What about the "cooling-cells" ? Its usage is unclear in the code and I'm not sure it is really needed. -- <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
