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

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

On 28/11/14 06:31, Viresh Kumar wrote:
> On 27 November 2014 at 16:45, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> 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."
>>
>> 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)
>
> Okay, I was completely wrong. :)
>
>> 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.
>
> Now these are the options we have for existing platforms:
>
> - Update those platforms to check if DT has "compatible" string in CPU node.
> If yes, don't create a device as this will be created by cpufreq-dt.
>

This fixes how it will work with new DTs, how about old DTs ?
IMO we still need the blacklist kind of logic I sent before.
Do you see any issues with that ?

> - Just remove the device creation from those paths if the Maintainers of
> those platforms want to cleanup their code, accepting the loss of backward
> compatibility..
>

I don't think this is something acceptable, why will someone want to
lose a working feature with new kernel.

Regards,
Sudeep