[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

On Wed, 23 Oct 2013 20:46:22 +0200, Maxime Bizon [off-list ref] wrote:

On Wed, 2013-10-23 at 19:45 +0200, Richard Cochran wrote:

quoted

Once I design my board, and it goes into production, the hardware is
fixed. It doesn't change, and neither should the description of the
hardware, also known as the DTB. If I have to research all of the
ways 

SOC support are never completely finished; subsystems are getting new
features.
 
It's possible to ship a product with a kernel version that does not
handle all the chip goodies, then want to upgrade the kernel later when
someone has written the driver for a previously unused hardware block.

the first iteration of your DTB would be incomplete, the bindings to
describe that hardware block would not exist inside it.

At this point if the hardware exists then it should be described in DTB,
even if it is merely compatible, reg, interrupts and maybe clocks
properties. In many cases that is all that is required. It /is/ okay to
amend a binding later and to use default values if the new properties
aren't present.

real life example with Marvell Kirkwood, hw crypto support was added 1
year after initial SOC support.

That said, enabling new hardware is a different problem from changing
the binding on working hardware. It is entirely reasonable to update the
hardware description when enabling previously unused peripherals, but it
is absolutely not friendly to change a binding/driver in a what that fails on
previously working DTB (with the caveat that if no one notices, it
isn't breakage).

g.