On Fri, Jul 26, 2013 at 02:38:02PM +0100, Russell King - ARM Linux wrote:

On Fri, Jul 26, 2013 at 09:27:09AM -0400, Jason Cooper wrote:

quoted

On Fri, Jul 26, 2013 at 03:09:29PM +0200, Richard Cochran wrote:

quoted

Unless I totally misunderstood, the thread is talking about letting
established bindings change with each new kernel version.  I am
opposed to that.

Of course, a user may want to change the values of his MAC addresses,
if he needs to. But he should never have to change *how* he specifies
those addresses.

The other dynamic change that bears mentioning here is attributes which
have been configured by the bootloader.  For example, in mvebu, we have
the Schrodinger's Cat register.  It allows you to reconfigure the base
address of the registers from *within* that register range.  If the
bootloader does this, the DT needs to be updated to reflect the current
hardware configuration.  Otherwise, the kernel is stuck poking around at
memory addresses hoping to find something sane.

But this falls into the same category as you mentioned, but outside of
chosen {};.

No, this falls within the remit of "describing the hardware" and it is
certainly something that is free to change.

We agree, I was just highlighting that attributes outside of chosen can
and need to be rewritten by the bootloader.

What should not "change" once a kernel is the method by which hardware is
described in DT.  "change" there in the sense that how it was described by
kernel 3.X should still be accepted by 3.X+n, even if 3.X+n comes up with
a much better way to describe it.

The actual data associated with those descriptions is free to change in
whatever way is necessary if the hardware itself changes due to things
being programmed differently.

Think of it as the difference between the design of an interface, and the
interface being used.  We don't mandate that the write() syscall shall
always be called for fd=1 with length=5 and bytes "Hello" in the buffer.
We mandate that the write() syscall shall be passed an integer fd, a
buffer pointer, and a length and we don't change that ever.

Think of "a better way to describe it" as introducing the writev() syscall
to supplement write() so that applications can do writes from scattered
memory locations.  We don't get rid of the write() syscall - we add to
the ABI that's already there leaving the existing interfaces with exactly
the same semantics, so that all the existing stuff continues to work as-is.

Yes, the manner in which the bootloader writes the changes should adhere
to the binding.  In my example, it shouldn't replace the reg property
with reg-mod.  It should just change the addresses to reflect the
current state of the hardware the kernel will see.

thx,

Jason.