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