On 27/11/14 10:22, Viresh Kumar wrote:
On 27 November 2014 at 15:24, Sudeep Holla <sudeep.holla@xxxxxxx> 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
[1] http://lwn.net/Articles/572114/
--
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
