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

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

[Linus Walleij]

On Sat, Jul 13, 2013 at 10:49 PM, Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org> 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?

Yours,
Linus Walleij

Re: [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-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org> 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

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

[Linus Walleij]

On Sun, Jul 14, 2013 at 8:13 PM, Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org> wrote:
> On Sun, Jul 14, 2013 at 01:46:45AM +0200, Linus Walleij wrote:>> 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 ?

Well this is what we need everyone to know so I guess this confirms the
need to bring it up at the kernel summit...

> 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.

> 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

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

[Guenter Roeck]

On Mon, Jul 15, 2013 at 08:29:15AM -0600, Jonathan Corbet wrote:
> On Mon, 15 Jul 2013 10:36:22 +0200
> Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> 
> > > 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...
> 
> 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

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

[Greg KH]

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-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org> 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

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

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 618 bytes --]

On Mon, Jul 15, 2013 at 09:56:20AM -0700, Greg KH wrote:

> 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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

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

[Greg KH]

On Mon, Jul 15, 2013 at 06:06:00PM +0100, Mark Brown wrote:
> On Mon, Jul 15, 2013 at 09:56:20AM -0700, Greg KH wrote:
> 
> > 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.

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

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

[David Woodhouse]

[-- Attachment #1.1: Type: text/plain, Size: 1038 bytes --]

On Mon, 2013-07-15 at 09:56 -0700, Greg KH wrote:
> 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.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org                              Intel Corporation




[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

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

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1394 bytes --]

On Mon, Jul 15, 2013 at 11:41:57AM -0700, Greg KH wrote:
> On Mon, Jul 15, 2013 at 06:06:00PM +0100, Mark Brown wrote:

> > 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?

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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

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

[Linus Walleij]

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

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

[Grant Likely]

On Mon, 15 Jul 2013 19:50:27 +0100, David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
> On Mon, 2013-07-15 at 09:56 -0700, Greg KH wrote:
> > 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.

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.

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

[Grant Likely]

On Mon, 15 Jul 2013 23:07:36 +0200, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> 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.

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.

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

[Linus Walleij]

On Mon, Jul 15, 2013 at 8:50 PM, David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:

> 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

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

[Guenter Roeck]

On Fri, Jul 19, 2013 at 05:40:05PM +0200, Wolfram Sang wrote:
> On Mon, Jul 15, 2013 at 11:07:36PM +0200, Linus Walleij wrote:
> > 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.
> 
In this context, can the devicetree experts`please have a look into the
proposed bindings for the thermal subsystem ?

Thanks,
Guenter

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

[Chaiken, Alison]

I commented:
>> Assuredly if in a kernel update a driver adds new features which are
>> enabled by new properties described in the device-tree, updating both
>> the kernel and the device-tree at the same time makes sense?

David Woodhouse [dwmw2@infradead.org] inquired:
> the old kernel's driver simply didn't *use* the
> feature which was already (optionally) present. The later kernel *does*
> use the feature, and thus it needs to be described properly?

Precisely.   This case cames up frequently, as a board often (in principle) supports some new standards for which there is yet no available test peripheral.   Without hardware to test, no one creates a driver.    When there is no driver, no one creates DTS bindings.

> If so, that means the initial device-tree binding was *WRONG*. It
> omitted the description of this hardware feature, purely because the
> Linux driver at the time didn't happen to use it. Violating the cardinal
> rule that the device-tree description of the hardware SHALL NOT be
> dependent on any OS-specifics.

I take your point.    Ideally, a set of include files for a new board should be feature-complete , with more or less one DT node for every connector  on the board, whether or not there exists anything to plug in. Then the top-level board file would simply indicate the values of abstract properties and set status "okay" for hardware in-use.

Linus Walleij agrees:
# Varying parameters is not as big a thing as altering
# bindings. I should have been clear on this - altering a device
# tree to fit a board is fine. But altering device tree *bindings*
# is a sin.

Tomasz Figa explains:
@ - bindings should enter staging state after being introduced,
@ - from time to time a binding review meeting should take place (on IRC
@possibly) and discuss which of introduced staging bindings are ready to
@enter stable state,
@ - in stable state such binding would be considered an ABI.

In other words, David. Linus and Tomasz are suggesting that once a set of bindings has entered the stable branch, they are carved in stone equivalent to the way the "Thou Shalt not Break Userspace" commandment underlies the kernel's sysfs ABI.    Ideally,a kernel and device-tree binary that are part of a product release will be part of the stable branch.

The concept of having arch-level DTSI files that are included only by ISA-level DTSI files that are included only by CPU-level DTSI files might help this process.    When all the DT source is moved to a new repo and the directories are refactored, these all these most fundamental files can be put into stable branch.    The directory hierarchy then will make it clearer which files and associated bindings are part of stable ABI and are harder to modify.   And Documentation can express the idea that the DTB is the device-tree ABI towards the kernel and should be stable.

David continues:
> The older driver which doesn't use the optional feature should still work � just without
> *using* that feature, of course.
> If you ever encounter a scenario where you can't just use the latest
> device-tree, and an older kernel requires that you ship a contemporary
> device-tree to match it, then something has gone *catastrophically*
> wrong.

What can go catastrophically wrong is that the full functionality of a new driver will require new flexibility in some parameter that earlier implementations had assumed was invariant.    The new driver will want to read the parameter from the DTB that earlier implementations set in a driver's private data, or in a local include file, or even by a fuse.  Admittedly this example illustrates a newer driver requiring a newer DTB, not an older kernel requiring an older DTB.   Hopefully having a hierarchy of files will mean that only board-level files tend to get stuck in staging while those at higher levels would be patched rarely.

David continues:
> I think it's definitely worth having a session on device-tree bindings,
> to ensure that this subject is properly understood.

I hope that we will have an open discussion in Edinburgh that attendees who are not part of Kernel Summit may attend.   Pantelis Antoniou had mentioned a possible ELCE BoF session.

-- Alison

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

[David Woodhouse]

[-- Attachment #1.1: Type: text/plain, Size: 1933 bytes --]

On Sun, 2013-07-21 at 08:05 +0000, Chaiken, Alison wrote:
> David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
> >> 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.
> 
> Assuredly if in a kernel update a driver adds new features which are
> enabled by new properties described in the device-tree, updating both
> the kernel and the device-tree at the same time makes sense? 

Let me check I understand you correctly...

In this scenario, the old kernel's driver simply didn't *use* the
feature which was already (optionally) present. The later kernel *does*
use the feature, and thus it needs to be described properly?

If so, that means the initial device-tree binding was *WRONG*. It
omitted the description of this hardware feature, purely because the
Linux driver at the time didn't happen to use it. Violating the cardinal
rule that the device-tree description of the hardware SHALL NOT be
dependent on any OS-specifics.

It should describe the hardware.

And it didn't.

And even in this scenario, although the initial author of the
device-tree binding should of course be whipped for the omission of the
feature in question, there should be no reason why we cannot simply use
the *newer* device-tree in all circumstances. The older driver which
doesn't use the optional feature should still work — just without
*using* that feature, of course.

If you ever encounter a scenario where you can't just use the latest
device-tree, and an older kernel requires that you ship a contemporary
device-tree to match it, then something has gone *catastrophically*
wrong.

I think it's definitely worth having a session on device-tree bindings,
to ensure that this subject is properly understood. I would be keen to
attend that.

-- 
dwmw2


[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

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

[Linus Walleij]

On Sun, Jul 21, 2013 at 10:05 AM, Chaiken, Alison
<Alison_Chaiken-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org> wrote:

> Linus Walleij (linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org) responds:

>>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.
>
> Are you objecting to the concept of a multicomponent image?
> Or the idea that the kernel and device-tree are always updated together?

Not really. I should have been clearer on this.

(There are other people who are against the multi-component images
for other reasons, but that is a side issue.)

I am worried that the concurrent versioning of the constituent parts
of such an image invites engineers to updates both sides - the
kernel code and the device tree - to fit a certain deployment deadline.

Because there is no policeing of the device trees out there, no
conformance test and no guarding entity, beyond the devicetree@vger
mailing list.

> If one board has a large amount of flash storage and another has
> a smaller amount, assuredly they will need different device-tree blobs?

Yes. Varying parameters is not as big a thing as altering
bindings. I should have been clear on this - altering a device
tree to fit a board is fine. But altering device tree *bindings*
is a sin.

The idea is however, that once that device tree with a board is
deployed, it is not to change. Ever. Like it's this contract.

i.e., while a device tree may fluctuate during development because
of new interesting hardware needing new bindings etc, there must
come a time when the product is deployed, and then that's it - no
more updating the DTS/DTB files. Especially not updates altering
existing bindings.

I am worried that with these composite images this is not what
is happening - you get a firmware-over-the-air update and then there
is a brand new device tree there, and the new kernel would not boot
without it, and the old kernel will not boot on it either.

This is especially a problem in enterprise settings where a new
kernel is deployed separately from any hardware descriptions and
cannot follow the embedded industry's idea to keep nuts and bolts
in sync.

Currently for ACPI or USB or any other standard there is a process
and procedure in place to take that final decision that this is it.
We are missing this from the DT world.

I bet things are not as elegant as they may look in theory,
someone will inevitably bring out an example of runtime-patched
DSDT ACPI tables and BIOS upgrades chaning system bindings,
but I think the pure *ambition* to have these things stable is
what we are missing right now.

>> Or to put it another way: I think this is caused by embedded
>> companies constantly having one finger pressing the fast-forward
>> button.
>
> Because companies have their fingers on the fast-forward button,
> I suspect that many simply have not thought the issues through.

We are in total agreement...

Yours,
Linus Walleij

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

[Chaiken, Alison]

David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
>> 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.

Assuredly if in a kernel update a driver adds new features which are enabled by new properties described in the device-tree, updating both the kernel and the device-tree at the same time makes sense?   Or when you're taking about keeping files in sync, are you referring to a different practice?    Companies may jump several kernel versions in an update.    No one disagrees that a 3.2 kernel and a 3.7 kernel are going to benefit from different DTs, if not require them.

Linus Walleij (linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org) responds:
>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.

Are you objecting to the concept of a multicomponent image?   Or the idea that the kernel and device-tree are always updated together?    Assuredly the problem of performing over-the-air updates for an expensive device that has safety-critical components in a failsafe way is complex, and a requirement to separately update device-tree blobs and kernel (and potentially firmware) would create a big headache.   I've heard from a member of the ChromeOS team that they package the DTB with the kernel so that the resulting archive can be cryptographically signed.    Providing a signing mechanism for DTBs might reduce manufacturer interest in composite images.

> 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.

If a company sells products with dozens of board variants, then assuredly each variant will need its own top-level DTS.  If the lifecycle of the product is many years, but future customers may want to add or subtract features from the hardware, then long-term maintenance of multiple compatible DTS with kernels will be necessary.    If one board has a large amount of flash storage and another has a smaller amount, assuredly they will need different device-tree blobs?

I'm quite interested in the questions discussed here, and have submitted at ELCE abstract to discuss them:

https://events.linuxfoundation.org/cfp/proposals/478/657

Whether or not my abstract is accepted, the topics are timely ss device-tree moves to its own repo and add new features like macro preprocessing, and potentially the include directories are refactored.

> Changing that way of thinking goes well outside the kernel community
> I'm afraid, one way would be if device trees had conformance tests

I was thinking about a test tool in reaction to the recent discussion about moving DTSI files to a new home.   Suppose ARM or PPC had a top-level set of include files to replace skeleton.dtsi.     Conforming DTSI for (for example) OMAP or i.MX processors would be required to include these.   Then conforming OMAP4's and i.MX6's DTSI would be required to include the OMAP and i.MX ones.    OMAP4430's DTSI would include OMAP4's, and i.MX6Q would include i.MX6's.   No conforming DTSI would modify these include/arch/{omap,imx}/common files and users who wanted changes should submit patches or accept non-conformance.   No binding defined in these basic files could be renamed without good reasons.    Conformance would mean that some commonality in naming between the OMAP and i.MX (and ARM and PPC)
  binding names could be enforced when they are designed.

Having a conformance tool would reduce Maintainer workload -- wouldn't it?   From the end user point of view, I'd like to be able to make sure that the kernel config and DTS are compatible.   In other words, a script to check that all features with "status=okay" also have CONFIG_BLAHBLAHBLAH={Y,M}.

This idea about minimally modifiable layered include files is what I mean by "inheritance" in my abstract.    i.MX6Q subclasses i.MX6 which subclasses i.MX.    Thinking about device-tree from this point of view may help to apply best practices from other areas.

> Or to put it another way: I think this is caused by embedded
> companies constantly having one finger pressing the fast-forward
> button.

Because companies have their fingers on the fast-forward button, I suspect that many simply have not thought the issues through.   

Sorry for long message,
Alison Chaiken
Mentor Embedded Software