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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html