Handling of devicetree bindings
A message that is not in the archive (sent off-list or not yet received): 20130713192647.GA3798@katana
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 9 lines · Guenter Roeck
Quoted 7 lines · Wolfram Sang
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.
Quoted 5 lines
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?
Yours,
Linus Walleij
A message that is not in the archive (sent off-list or not yet received): CACRpkdaJ5podVCrb7XuhhGF0Oco+eLrFH0EVGZM0MBbGP9m7WQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 30 lines · Linus Walleij
Quoted 9 lines · Guenter Roeck
Quoted 7 lines · Wolfram Sang
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.
Quoted 5 lines
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 :-/
Quoted 9 lines
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
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 9 lines · Guenter Roeck
On Sun, Jul 14, 2013 at 01:46:45AM +0200, Linus Walleij wrote:>> Maybe some just consider this "some documentation", think it has been
Quoted 3 lines
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 ?
Well this is what we need everyone to know so I guess this confirms the need to bring it up at the kernel summit...
Quoted 2 lines
My approach is to accept properties which would otherwise require platform data. Is that acceptable ?
In most cases yes, but there are some paradigms about it, and nothing linux-specific should be encoded in it, except for a few "linux-*" bindings.
Quoted 2 lines
How can I know if devicetree-discuss is mostly silent on such matters, as you point out ?
Right now it feels like everyone developing these drivers think it is very convenient that the Linux subsystem maintainers do all the reviewing and deciding, so they can then later take the blame for it if they merged something bad.
I feel just as ambivalent about it as you do :-/
Yours,
Linus Walleij
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 7 lines · Jonathan Corbet
Quoted 4 lines · On Mon, 15 Jul 2013 10:36:22 +0200 Linus Walleij…
Quoted 3 lines
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 ?
Quoted 9 lines
Quoted 2 lines
Well this is what we need everyone to know so I guess this confirms the need to bring it up at the kernel summit...
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? If it's the latter, I don't think a kernel summit session will help much.
For my part I lack education, and KS session won't help me as I won't be there, unless the results are written down in a way that lets me get that education.
Guenter
Quoted 4 lines · Jonathan Corbet
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
A message that is not in the archive (sent off-list or not yet received): CACRpkdaEswVPNqwQkMjsNWutCpOQxgMeGwsgemsF4SSZxXMocQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 9 lines · Linus Walleij
Quoted 4 lines · Jonathan Corbet
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.
I think that it would make more sense to be a topic at an ARM maintainers summit with the output being a *short* guidance statement for all maintainers stating who is responsible for approving and merging new bindings.
g.
A message that is not in the archive (sent off-list or not yet received): 20130719154004.GA3081@katana
Quoted 11 lines · Wolfram Sang
Quoted 9 lines · Linus Walleij
Quoted 4 lines · Jonathan Corbet
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.
In this context, can the devicetree experts`please have a look into the proposed bindings for the thermal subsystem ?
Thanks,
Guenter
Quoted 35 lines · Linus Walleij
Quoted 9 lines · Guenter Roeck
Quoted 7 lines · Wolfram Sang
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.
Quoted 5 lines
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?
Quoted 6 lines
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
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 6 lines · Greg KH
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?
At the minute it's about at the level of saying that if you're not sure or don't know you should get the devicetree-discuss mailing list to review it. Ideally someone would write that document, though I wouldn't hold my breath and there is a bunch of convention involved.
_______________________________________________
devicetree-discuss mailing list devicetree-discuss-uLR06cmDAlY/[email protected]
https://lists.ozlabs.org/listinfo/devicetree-discuss
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 7 lines · Mark Brown
Quoted 4 lines · Greg KH
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.
Quoted 6 lines
Quoted 1 line
Or if we already have it, a pointer to it perhaps?
At the minute it's about at the level of saying that if you're not sure or don't know you should get the devicetree-discuss mailing list to review it. Ideally someone would write that document, though I wouldn't hold my breath and there is a bunch of convention involved.
So, what should I, as a subsystem maintainer, do if I get a patch with a binding in it? Wait some random amount of time before I can just apply it because no one on the mailing list said anything about it? Trust the developer who wrote it? Or just reject them all?
What do you advise?
thanks,
greg k-h
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 7 lines · Greg KH
Quoted 4 lines · Mark Brown
At the minute it's about at the level of saying that if you're not sure or don't know you should get the devicetree-discuss mailing list to review it. Ideally someone would write that document, though I wouldn't hold my breath and there is a bunch of convention involved.
Quoted 6 lines
So, what should I, as a subsystem maintainer, do if I get a patch with a binding in it? Wait some random amount of time before I can just apply it because no one on the mailing list said anything about it? Trust the developer who wrote it? Or just reject them all?
What do you advise?
Right, this is the problem. Given that this is supposed to be about defining an ABI probably sit on it until someone with more DT experience turns up to help though obviously that isn't always constructive. Trying to figure things out enough to decide if it's sane is another option, as is helping the submitter make their binding easier to review by doing things like split out more complex elements into incremental additions or making sure they aren't deluging the DT list with lots of subsystem stuff other than bindings.
Ideally a lot of this stuff will be fairly standard for the subsystem so hopefully it'll very quickly become apparent what's unusual which will help a lot.
_______________________________________________
devicetree-discuss mailing list devicetree-discuss-uLR06cmDAlY/[email protected]
https://lists.ozlabs.org/listinfo/devicetree-discuss
Quoted 6 lines · Greg KH
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?
The biggest thing is that it should describe the *hardware*, in a fashion which is completely OS-agnostic.
The same device-tree binding should work for Solaris, *BSD, Windows, eCos, and everything else.
I've heard tales of people having to keep device-tree files for their board tightly in sync with the specific *version* of the Linux kernel that they were shipped with.
That makes me very sad, because it almost certainly means that someone has done it completely and utterly wrong.
Signature · 2 lines
David Woodhouse Open Source Technology Centre [email protected] Intel Corporation
_______________________________________________
devicetree-discuss mailing list devicetree-discuss-uLR06cmDAlY/[email protected]
https://lists.ozlabs.org/listinfo/devicetree-discuss
A message that is not in the archive (sent off-list or not yet received): 1373914227.2128.24.camel-Fexsq3y4057IgHVZqg5X0TlWvGAXklZc@public.gmane.org
Quoted 14 lines · David Woodhouse
Quoted 6 lines · Greg KH
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?
The biggest thing is that it should describe the *hardware*, in a fashion which is completely OS-agnostic.
The same device-tree binding should work for Solaris, *BSD, Windows, eCos, and everything else.
Quoted 6 lines
I've heard tales of people having to keep device-tree files for their board tightly in sync with the specific *version* of the Linux kernel that they were shipped with.
That makes me very sad, because it almost certainly means that someone has done it completely and utterly wrong.
It is wrong, but it has happened. At first it was getting up and running with DT in ARM which was a major shift, but now it is down to lack of process. There is a new team of maintainers for DT bindings that I've just sent and email about. The ultimate goal is to add schema checking to device tree bindings and get them out of the kernel entirely. That should resolve the tightly-coupled problem that we're currently dealing with.
g.
Quoted 6 lines · David Woodhouse
I've heard tales of people having to keep device-tree files for their board tightly in sync with the specific *version* of the Linux kernel that they were shipped with.
That makes me very sad, because it almost certainly means that someone has done it completely and utterly wrong.
This paradigm creep up in ideas like the FIT image at this years ELC:
http://events.linuxfoundation.org/images/stories/slides/elc2013_fernandes.pdf
Surely, most complex mobile systems (such as mobile handsets) are flashed with some custom-brew composite images, FIT seems to want to start to standardize that.
However the dangerous stuff is not this tool even, it happens on the build systems: multiple things are compiled together and stuffed into an image, the device tree and kernel is always recompiled at every image composition. Everything is versioned in sync.
This means that most embedded companies have a build system where it is possible for system integrators to alter kernel code and device trees at the same time.
I think their mental model is that of assembling a fridge or a car or something - you take this bolt and it fits with that nut, and it's OK if it only fits on just this one model of the end product.
Changing that way of thinking goes well outside the kernel community I'm afraid, one way would be if device trees had conformance tests such as is done for ACPI (or USB, or whatever) meaning it will at some point arrive at a final, definitive form, and you're not allowed to alter bindings etc at that point. And given all bindings are available this can be done early on in the hardware projects.
I think a group of volunteers are up to move in this direction.
Needless to say, doing it the slow way threatens to slow down the deployment phase and lead to Gantt-effects in projects. Which I guess is why these companies really like the idea of tying in the device tree with the kernel.
Or to put it another way: I think this is caused by embedded companies constantly having one finger pressing the fast-forward button.
Yours,
Linus Walleij