On 28/11/14 06:31, Viresh Kumar wrote:
On 27 November 2014 at 16:45, Sudeep Holla <sudeep.holla@xxxxxxx> 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
--
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
