On 27/11/14 10:22, Viresh Kumar wrote:
On 27 November 2014 at 15:24, Sudeep Holla sudeep.holla@arm.com wrote:
No that won't suffice. You can't modify the DTs of the platforms using cpufreq-dt.c as of today. They should continue to work, so either you retain all the existing platform device creation in platform code as is or do something like below with the blacklist for those platforms.
Is the meaning of "backward compatibility" for DTs mentioned somewhere? I am not sure if we have to *always* follow the compatibility you are talking about.
It's the general understanding, I am not sure if it's specified anywhere in the kernel Documentation, but I could find the below excerpts from [1]:
"The compatibility rules say that new kernels must work with older device trees. If changes are required, they should be put into new properties; the old ones can then be deprecated but not removed. New properties should be optional, so that device trees lacking those properties continue to work. The device tree developers will provide a set of guidelines for the creation of future-proof bindings."
Probably we want new DTs to continue supporting older version of kernels. Not that older DTs should work with new kernel changes.
It's *exactly opposite* as DTs are considered as part of firmware that gets shipped with the boards and any kernel should work with that DT if it is compliance with the DT bindings(even old, as the DT bindings should never get changed only gets extended)
So, even with another field in cpuX node, we wouldn't break older kernels as they will anyway get the device from platform code.
Yes, but that's not what we want.
OK, in this way you still continue to work on existing platforms with *old DT*.
Probably not.
No, you *must* :). That's backward compatibility. Just consider a simple case where the bootloader is generating DT and we don't want to upgrade it.
Regards, Sudeep