digging around in device trees, and i'm familiar with the processing
of .dtsi "include" files, where later entries (nodes, properties)
override earlier ones, at least based on what i've read. but i just
noticed something i want to be clear on.
in some cases, a generic .dtsi file will set a bunch of generic
nodes and properties, like this in arch/arm/boot/dts/am33xx.dtsi:
/ {
compatible = "ti,am33xx";
interrupt-parent = <&intc>;
... snip ...
so far, so good. but then along comes am335x-boneblack.dts, which
starts off thusly:
#include "am33xx.dtsi"
#include "am335x-bone-common.dtsi"
/ {
model = "TI AM335x BeagleBone Black";
compatible = "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx";
};
so this latter file includes the earlier one, but in the case of the
"compatible" node, the latter file must still list the compatible
property of "ti,am33xx", even though that's already listed in the
included file.
rather than simply overriding, the "compatible" node would seem to
be a good place to inherit/extend existing strings, wouldn't you
think? or maybe not if you wanted to include a .dtsi file and
explicitly *break* some compatibility.
so i'm assuming there's nothing magic about the "compatible" node in
that it doesn't automatically inherit values from any included files,
is that correct?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================