Re: [Ksummit-2013-discuss] [ATTEND] Handling of devicetree bindings

[Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]

On Mon, Jul 15, 2013 at 4:29 PM, Jonathan Corbet <corbet-T1hC0tSOHrs@public.gmane.org> wrote:

> Do we need a kernel summit discussion, or do we just need a good
> document?  Or, to phrase the question another way, are we lacking a
> consensus among the clueful regarding how device tree bindings should be
> designed, or are we simply lacking education?

I think both. I fear some maintainers do not know enough about
the subject to know if a binding should be rejected.

We have for example:
Documentation/devicetree/usage-model.txt

But this does not at all qualify anyone to judge (dredd) the
validity of some new $binding. It's not kerneldoc, where
everything is pretty easy to understand, it is way more
complex.

It looks simple to begin with: registers, IRQs, compatible
strings ... then all of a sudden: how many #foo-cells should
this have?  0, 1 or 4? foo: bar@12345 {} what naming
convention should be used here? What is an alias? Basically
you have to know it all to properly review that.

The recent discussions about clock bindings is a good
example. Or the fact that we do not have common
pin control binings because it was simply too hard
to get people to agree: I got the committe work dumped
in my knee and I did a bad job at it too. :-(

Part of the problem with both major hardware description
languages (ACPI and devicetree) is that the developers using
either variant appear to be clueless of the other. What makes
devicetree more dangerous than ACPI is that the kernel
maintainers define it, it is not being given from the outside.

Yours,
Linus Walleij