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

[Guenter Roeck]

On Sun, Jul 14, 2013 at 01:46:45AM +0200, Linus Walleij wrote:
> On Sat, Jul 13, 2013 at 10:49 PM, Guenter Roeck <linux at roeck-us.net> wrote:
> > On Sat, Jul 13, 2013 at 08:26:47PM +0100, Wolfram Sang wrote:
> 
> >> I think the KS would be a good opportunity to present the status quo,
> >> show some rules of thumb and finally discuss if we can improve the
> >> process even further. E.g., should first the bindings be accepted, then
> >> the driver? What could be the process if the need for a generic binding
> >> arises? And spreading the word, so at least the basic issues are
> >> understood by most maintainers.
> >>
> > Sounds like a good idea, but I think you'll need some deadline. When reviewing
> > hwmon drivers I usually wait for a couple of weeks if there is any feedback
> > from devicetree-discuss before I accept bindings, but what should I do
> > if there is no feedback ? Holding the driver hostage doesn't seem like a good
> > idea either.
> 
> Nobody rarely say anything on devicetree-discuss. And if something is
> said it will usually be about syntax rather than semantics. And if it's
> semantics, it's usually a subsystem or arch maintainer saying it.
> 
> I've been ranting a bit about this recently, and one of the problems with
> device tree now being driven by the Linux community (basically - it used
> to be a IEEE thing at one point in the past) is that as the bindings are
> merged by the subsystem maintainers, they alone get to decide when
> they are finished.
> 
> They are all in Documentation/devicetree/bindings/* so theoretically
> we could have a dedicated maintainer for it, but that requires someone
> to step up :-/
> 
> I wonder if some subsystem maintainers who are more used to things
> like ACPI or PCI where someone else has already done the thinking
> and written a large (non-perfect, mind you) specification even think that
> reviewing hardware descriptions is their problem at all?
> 
> Maybe some just consider this "some documentation", think it has been
> defined by someone who thought it over and merge it without looking
> closely.
> 
For my part I do have a close look, but I don't really know if my understanding
of acceptable properties matches the understanding of the devicetree community.
Devicetree is supposed to describe the hardware, but in many cases there is
an overlap between hardware description and configuration and/or use. Where is
the boundary ?

My approach is to accept properties which would otherwise require platform data.
Is that acceptable ? How can I know if devicetree-discuss is mostly silent on
such matters, as you point out ?

Guenter