On Thu, 11 Feb 2016, David Daney wrote:

quoted

quoted

The vast majority of people that see it will not be able to change their
firmware.  So it will be forever cluttering up their boot logs.

Until they switch to use APPENDED_DTB. :-)

I am philosophically opposed to making the DTB an internal kernel
implementation detail.

For OCTEON boards, it is an ABI between the boot firmware and the kernel, and
is impractical to change.

One could argue that many years ago, when the decision was made (by me), that
we should have opted to carry in the kernel source code tree the DTS files for
all OCTEON boards ever made, but we did not do that.  Due to the
non-reversibility of time, the decision is hard to reverse.

 I concur, a very good decision as far as I'm concerned!

 I had the misfortune to work with some Freescale Power boards which used 
in-kernel DTS files in a hope to match the respective board's firmware 
(U-boot).  Needless to say, that didn't quite work.  The mapping of board 
resources was reportedly changed in some version of the firmware to give 
more flexibility and the DTS files bundled with Linux updated accordingly, 
however no version of the old files was kept around and maintained.  So a 
kernel upgrade, which turned out inevitable at one point, became a 
challenging task to update the DTS files so as to match the version of the 
firmware the boards had.

 With some pain I was eventually able to sort this out through patching 
the old DTS files to match the ever-changing DTS syntax and get them 
accepted for a DTB build and work to an acceptable extent with the then 
current version of Linux.  However some board resources were lost, for 
example the IDE interface was no longer accessible; fortunately I didn't 
need it, so I just left it like that and didn't figure out what else I'd 
have to do to regain access.

 So no, no standalone DTS/DTBs please, thank you very much.

  Maciej