From: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
To: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Ian Campbell
<ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>,
Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
Mark Brown
<broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>,
Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
Tomasz Figa <tomasz.figa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: The future of DT binding maintainership
Date: Sun, 21 Jul 2013 20:49:40 +1000 [thread overview]
Message-ID: <20130721104940.GC22475@voom.fritz.box> (raw)
In-Reply-To: <20130720034647.2B7B43E14BF@localhost>
[-- Attachment #1.1: Type: text/plain, Size: 2991 bytes --]
On Sat, Jul 20, 2013 at 04:46:47AM +0100, Grant Likely wrote:
> A number of us had a face-to-face meeting in Dublin last week to talk
> about DT maintainership and the fact that it simply isn't working right
> now. Neither Rob nor I can keep up with the load and there are a lot of
> poorly designed bindings appearing in the tree.
>
> Device tree binding maintainership needs to be split off to a separate
> group, and we've started with a few people willing to help, Pawel Moll,
> Mark Rutland, Stephen Warren and Ian Campbell.
>
> (BTW, even though I've already sent a patch adding that group
> MAINTAINERS, this is not set in stone. Anyone else wanting to help
> maintain should volunteer)
Sounds good.
> Another thing discussed is that we need to start validating DT schema
> with an extension to dtc. Tomasz Figa has volunteered to do this work
> and has support from his employer to spend time on it. What I'm hoping
> to have is that the DT schema will get checked as part of the dts build
> process so that any DT file that doesn't match the documented schema
> will get flagged, and that the schema files will be human readable and
> will double as documentation.
Tomasz, please keep me in the loop on this. This sounds like exactly
what the "checks" infrastructure in dtc was designed for, but I never
had time to implement very much there. I'd definitely like to follow
progress here, though.
> There is not yet any process for binding maintainership. We talked about
> a few ideas, but they really need to be hashed out here on the mailing
> list. A couple of the questions:
>
> - How are bindings allowed to be merged? Through subsystem trees, or
> only through the bindings tree?
> - Through the bindings tree is more work but it will provide more
> control.
> - Through subsystem trees means drivers and bindings get merged
> together.
> - If we have a schema tool that reports errors on missing or
> unapproved schema, then spliting the driver from the binding won't
> matter that much.
> - Do we need to differentiate between 'staging' and 'stable' bindings?
> - What is the schedule for splitting the bindings and .dts files out of
> the kernel?
> - Ian Campbell is maintaining a DT bindings and .dts mirror tree which
> should eventually become the 'master' for merging DT bindings.
It seems to me that the kernel tree has become the informal repository
for board dts files is in itself a problem. It encourages people to
think the two are closely linked and that all that matters is that a
specific dts works with its corresponding kernel and vice versa,
rather than fdts being the general description they're supposed to be.
Not that I have much in the way of better ideas.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #1.2: Type: application/pgp-signature, Size: 198 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
WARNING: multiple messages have this Message-ID (diff)
From: David Gibson <david@gibson.dropbear.id.au>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Wolfram Sang <w.sang@pengutronix.de>,
Tomasz Figa <tomasz.figa@gmail.com>,
Mark Rutland <mark.rutland@arm.com>,
Stephen Warren <swarren@wwwdotorg.org>,
Ian Campbell <ian.campbell@citrix.com>,
Pawel Moll <pawel.moll@arm.com>,
devicetree@vger.kernel.org, devicetree-discuss@lists.ozlabs.org,
linux-kernel@vger.kernel.org,
Mark Brown <broonie@opensource.wolfsonmicro.com>,
Rob Herring <rob.herring@calxeda.com>
Subject: Re: The future of DT binding maintainership
Date: Sun, 21 Jul 2013 20:49:40 +1000 [thread overview]
Message-ID: <20130721104940.GC22475@voom.fritz.box> (raw)
In-Reply-To: <20130720034647.2B7B43E14BF@localhost>
[-- Attachment #1: Type: text/plain, Size: 2991 bytes --]
On Sat, Jul 20, 2013 at 04:46:47AM +0100, Grant Likely wrote:
> A number of us had a face-to-face meeting in Dublin last week to talk
> about DT maintainership and the fact that it simply isn't working right
> now. Neither Rob nor I can keep up with the load and there are a lot of
> poorly designed bindings appearing in the tree.
>
> Device tree binding maintainership needs to be split off to a separate
> group, and we've started with a few people willing to help, Pawel Moll,
> Mark Rutland, Stephen Warren and Ian Campbell.
>
> (BTW, even though I've already sent a patch adding that group
> MAINTAINERS, this is not set in stone. Anyone else wanting to help
> maintain should volunteer)
Sounds good.
> Another thing discussed is that we need to start validating DT schema
> with an extension to dtc. Tomasz Figa has volunteered to do this work
> and has support from his employer to spend time on it. What I'm hoping
> to have is that the DT schema will get checked as part of the dts build
> process so that any DT file that doesn't match the documented schema
> will get flagged, and that the schema files will be human readable and
> will double as documentation.
Tomasz, please keep me in the loop on this. This sounds like exactly
what the "checks" infrastructure in dtc was designed for, but I never
had time to implement very much there. I'd definitely like to follow
progress here, though.
> There is not yet any process for binding maintainership. We talked about
> a few ideas, but they really need to be hashed out here on the mailing
> list. A couple of the questions:
>
> - How are bindings allowed to be merged? Through subsystem trees, or
> only through the bindings tree?
> - Through the bindings tree is more work but it will provide more
> control.
> - Through subsystem trees means drivers and bindings get merged
> together.
> - If we have a schema tool that reports errors on missing or
> unapproved schema, then spliting the driver from the binding won't
> matter that much.
> - Do we need to differentiate between 'staging' and 'stable' bindings?
> - What is the schedule for splitting the bindings and .dts files out of
> the kernel?
> - Ian Campbell is maintaining a DT bindings and .dts mirror tree which
> should eventually become the 'master' for merging DT bindings.
It seems to me that the kernel tree has become the informal repository
for board dts files is in itself a problem. It encourages people to
think the two are closely linked and that all that matters is that a
specific dts works with its corresponding kernel and vice versa,
rather than fdts being the general description they're supposed to be.
Not that I have much in the way of better ideas.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2013-07-21 10:49 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CACxGe6vtJPbbqwpH8Th5S36Hx50f39j1P4OpLb-Um9xQie6Lng@mail.gmail.com>
2013-07-20 3:46 ` The future of DT binding maintainership Grant Likely
2013-07-20 13:49 ` Tomasz Figa
2013-07-22 19:59 ` Chaiken, Alison
2013-07-22 20:09 ` Tomasz Figa
2013-07-22 21:34 ` Jon Loeliger
2013-07-22 21:57 ` Tomasz Figa
2013-07-23 15:55 ` Stephen Warren
2013-07-24 20:28 ` Grant Likely
2013-07-24 20:26 ` Grant Likely
2013-07-23 15:52 ` Stephen Warren
2013-07-24 14:11 ` Grant Likely
2013-07-25 7:47 ` David Lang
2013-07-25 17:46 ` Stephen Warren
2013-07-21 10:49 ` David Gibson [this message]
2013-07-21 10:49 ` David Gibson
2013-07-25 20:17 ` Rob Herring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130721104940.GC22475@voom.fritz.box \
--to=david-xt8fgy+axnrb3ne2bgzf6laj5h9x9tb+@public.gmane.org \
--cc=broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org \
--cc=ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=pawel.moll-5wv7dgnIgG8@public.gmane.org \
--cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \
--cc=tomasz.figa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.