Granted, it's harder to standardize things well when the hardware being described is changing so rapidly, but by treating the device tree as a Linux implementation detail rather than an ABI, you take away the incentive to get it (reasonably close to) right the first time. You could still have a separate Linux-internal tree (we already do -- struct device and friends) that encodes Linux concepts and/or fixes quirks in the hardware tree, which is generated from the hardware tree plus quirk code in the kernel, and possibly some supplementary external data file which *is* a Linux implementation detail and not meant for sharing with other components. In extreme cases the "quirk and supplementary external data" could be an entire replacement tree, if the standard one is hopeless for anything other than identifying which replacement tree to use, but most cases should not be that bad.
Moving the hardware tree outside the kernel source would send a clear message that it is not a Linux implementation detail (and thus compatibility between the trees and OSes including but not limited to Linux needs to be considered), and that things which are need to go somewhere else.
Also note that the dts sometimes contains implementation details of the bootloader -- it may make assumptions about how the loader sets up the address map, or it may make assumptions about what things the loader will fill in before passing the tree to the kernel. Both of these are true on Freescale PPC. In those cases ideally the trees would be stored in the bootloader tree.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds