Defining schemas for Device Tree

[Mark Brown]

On Wed, Jul 31, 2013 at 05:59:10PM +0100, Dave Martin wrote:

> There may often be a conflict between making _good_ bindings, and making
> bindings which are convenient for maintainers to edit in .dts syntax.

> I think good bindings (in the sense of good ABI) must take precedence:
> good bindings need to interoperate well over a long period of time, and
> should be robust against future evolution of hardware platforms OSes.  If
> they look nice in the .dts file, that's a bonus -- but I don't think it
> should be viewed as a requirement.

While I take your point that we need to have a sane ABI I think you're
understating the importance of the human factors here - the harder it is
to reliably understand and edit the device trees the more likely it is
that people will end up shipping mistakes which undermines the work on
defining stable ABIs.

> A pair of properties like dma-names/dmas may be a bit cumbersome, but
> it can be precise, unambiguous, and simple and easy to parse and check.
> The semantics can be extended in the future if necessary, by adding
> additional companion properties.  From my perspective, this can work as
> a template for good bindings.

I think this is fine for bindings but it's just not really legible for
humans once the lists start growing.  We need a human interaction format
which is suitable for humans to work with, it's not good when people
start finding that it's a set backwards in terms of their ability to
work with their systems.

> Someone trying to maintain a complex .dts can always make their own life
> easier with a bit of scripting.  After all, in a future of stable
> bindings, a DT really shouldn't be changing much once it is complete.
> I don't see a clear reason why these issues must be solved by dtc
> itself.

I don't think it's terribly important if they're solved in dtc itself so
long as it's part of the standard tooling that everyone has access to.
There's a reasonable number of new SoCs get made which tend to be the
things that suffer most.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130731/5edf5c3d/attachment.sig>