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 --]
prev parent reply other threads:[~2013-07-21 12:34 UTC|newest]
Thread overview: 14+ 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]
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@gibson.dropbear.id.au \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=devicetree@vger.kernel.org \
--cc=grant.likely@secretlab.ca \
--cc=ian.campbell@citrix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=rob.herring@calxeda.com \
--cc=swarren@wwwdotorg.org \
--cc=tomasz.figa@gmail.com \
--cc=w.sang@pengutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox