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

[Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>]

On Wed, 23 Oct 2013 20:46:22 +0200, Maxime Bizon <mbizon-MmRyKUhfbQ9GWvitb5QawA@public.gmane.org> wrote:
> 
> On Wed, 2013-10-23 at 19:45 +0200, Richard Cochran wrote:
> > 
> > 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.

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html