On Fri, Jul 26, 2013 at 9:41 AM, David Woodhouse [off-list ref] wrote:

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

quoted

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 {};.

Yeah, /chosen was given as an example of stuff that's almost
*exclusively* "configuration" stuff.

But there's plenty outside there that can reasonably change.

It's OK to change the data, and of *course* the base address reported in
the DT should actually match reality *today*, if it changes on the fly.

It's not OK to change the *schema*  in which those data are expressed.
That's the ABI we're talking about.

Yes, yes - that's why the schema should be written down and used as a
validation input to dtc. Then dtc can spit out errors for non-standard
items. There would be two versions - the standard one and a legacy one
that includes the standard one plus the hacks that can't be undone.

But more importantly it provides a framework for people creating new
node definitions. Now they can't work in a vacuum and come up with
random names and structure for everything.

Most of the problems express in the thread would go away if the schema
was written down and discussed. The rule going forward would be no new
nodes that aren't part of the standard schema.

--
dwmw2

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Jon Smirl
jonsmirl at gmail.com