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. -- 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
