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

Greg KH greg at kroah.com
Mon Jul 15 16:56:20 UTC 2013


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.
> 
> There have been discussions on improving the situation recently,
> so maybe someone has a few words to add?

How about a hint for subsystem maintainers as to what exactly we should
be looking for with these bindings?  I for one have no idea what is
"right" vs. "wrong" with them, so a document explaining this would be
good to have.

Or if we already have it, a pointer to it perhaps?

thanks,

greg k-h


More information about the Ksummit-2013-discuss mailing list