Re: [RFC] cpufreq: Add "dvfs-method" binding to probe cpufreq drivers

[Sudeep Holla <sudeep.holla@arm.com>]

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

[1] http://lwn.net/Articles/572114/