[PATCH 2/3] MAINTAINERS: Change device tree mailing list

[PATCH 2/3] MAINTAINERS: Change device tree mailing list

[Grant Likely]

New list on vger.kernel.org. The old list was a pain to moderate.

Signed-off-by: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <rob.herring@calxeda.org>
Cc: devicetree-discuss@lists.ozlabs.org
Cc: devicetree@vger.kernel.org
---
 MAINTAINERS | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 844d7e8..bc286e4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5882,7 +5882,7 @@ OMAP DEVICE TREE SUPPORT
 M:	Benoît Cousson <b-cousson@ti.com>
 M:	Tony Lindgren <tony@atomide.com>
 L:	linux-omap@vger.kernel.org
-L:	devicetree-discuss@lists.ozlabs.org (moderated for non-subscribers)
+L:	devicetree@vger.kernel.org
 S:	Maintained
 F:	arch/arm/boot/dts/*omap*
 F:	arch/arm/boot/dts/*am3*
@@ -6046,7 +6046,7 @@ F:	drivers/i2c/busses/i2c-ocores.c
 OPEN FIRMWARE AND FLATTENED DEVICE TREE
 M:	Grant Likely <grant.likely@linaro.org>
 M:	Rob Herring <rob.herring@calxeda.com>
-L:	devicetree-discuss@lists.ozlabs.org (moderated for non-subscribers)
+L:	devicetree@vger.kernel.org
 W:	http://fdt.secretlab.ca
 T:	git git://git.secretlab.ca/git/linux-2.6.git
 S:	Maintained
-- 
1.8.1.2

[PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[Grant Likely]

Device tree bindings require a lot more attention than they used to.
We've got a group of volunteers willing to take over maintaining
bindings. This patch adds them to the MAINTAINERS file.

This group still needs to work out a process for maintainership and how
they are going to work together. I recommend that they set up a shared
tree on git.kernel.org that they each have commit access to similar to
the tip tree or the arm-soc tree, but it is up to them.

Signed-off-by: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Cc: Ian Campbell <ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
Cc: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
Cc: Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
 MAINTAINERS | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index bc286e4..12c95d5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6050,13 +6050,24 @@ L:	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
 W:	http://fdt.secretlab.ca
 T:	git git://git.secretlab.ca/git/linux-2.6.git
 S:	Maintained
-F:	Documentation/devicetree
 F:	drivers/of
 F:	include/linux/of*.h
 F:	scripts/dtc
 K:	of_get_property
 K:	of_match_table
 
+OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
+M:	Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
+M:	Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
+M:	Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
+M:	Ian Campbell <ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
+L:	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
+S:	Maintained
+F:	Documentation/devicetree
+F:	arch/*/boot/dts
+F:	arch/*/
+F:	include/dt-bindings
+
 OPENRISC ARCHITECTURE
 M:	Jonas Bonn <jonas-A9uVI2HLR7kOP4wsBPIw7w@public.gmane.org>
 W:	http://openrisc.net
-- 
1.8.1.2

Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[Linus Walleij]

On Sat, Jul 20, 2013 at 5:19 AM, Grant Likely <grant.likely@linaro.org> wrote:

> Device tree bindings require a lot more attention than they used to.
> We've got a group of volunteers willing to take over maintaining
> bindings. This patch adds them to the MAINTAINERS file.
>
> This group still needs to work out a process for maintainership and how
> they are going to work together. I recommend that they set up a shared
> tree on git.kernel.org that they each have commit access to similar to
> the tip tree or the arm-soc tree, but it is up to them.
>
> Signed-off-by: Grant Likely <grant.likely@linaro.org>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: devicetree-discuss@lists.ozlabs.org
> Cc: devicetree@vger.kernel.org

Excellent move.
Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[Jon Loeliger]

> On Sat, Jul 20, 2013 at 5:19 AM, Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote
> :
> 
> > Device tree bindings require a lot more attention than they used to.
> > We've got a group of volunteers willing to take over maintaining
> > bindings. This patch adds them to the MAINTAINERS file.
> >
> > This group still needs to work out a process for maintainership and how
> > they are going to work together. I recommend that they set up a shared
> > tree on git.kernel.org that they each have commit access to similar to
> > the tip tree or the arm-soc tree, but it is up to them.
> >
> > Signed-off-by: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> > Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> > Cc: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
> > Cc: Ian Campbell <ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
> > Cc: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
> > Cc: Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>
> > Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> > Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> 
> Excellent move.
> Acked-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

Perhaps it is time to also place the official repo
of the Device Tree Compiler on git,kernel.org as well?

Other opinions?

jdl

Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[Grant Likely]

On Sun, Jul 21, 2013 at 2:46 PM, Jon Loeliger <jdl-CYoMK+44s/E@public.gmane.org> wrote:
> Perhaps it is time to also place the official repo
> of the Device Tree Compiler on git,kernel.org as well?

I'm fine with that. I can't say I'm excited about options like github.

g.

Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 1917 bytes --]

On Sun, Jul 21, 2013 at 08:46:11AM -0500, Jon Loeliger wrote:
> > On Sat, Jul 20, 2013 at 5:19 AM, Grant Likely <grant.likely@linaro.org> wrote
> > :
> > 
> > > Device tree bindings require a lot more attention than they used to.
> > > We've got a group of volunteers willing to take over maintaining
> > > bindings. This patch adds them to the MAINTAINERS file.
> > >
> > > This group still needs to work out a process for maintainership and how
> > > they are going to work together. I recommend that they set up a shared
> > > tree on git.kernel.org that they each have commit access to similar to
> > > the tip tree or the arm-soc tree, but it is up to them.
> > >
> > > Signed-off-by: Grant Likely <grant.likely@linaro.org>
> > > Cc: Pawel Moll <pawel.moll@arm.com>
> > > Cc: Mark Rutland <mark.rutland@arm.com>
> > > Cc: Stephen Warren <swarren@wwwdotorg.org>
> > > Cc: Ian Campbell <ian.campbell@citrix.com>
> > > Cc: Rob Herring <rob.herring@calxeda.com>
> > > Cc: Olof Johansson <olof@lixom.net>
> > > Cc: devicetree-discuss@lists.ozlabs.org
> > > Cc: devicetree@vger.kernel.org
> > 
> > Excellent move.
> > Acked-by: Linus Walleij <linus.walleij@linaro.org>
> 
> Perhaps it is time to also place the official repo
> of the Device Tree Compiler on git,kernel.org as well?

Sounds good to me.

Now that I'm no longer at IBM, and don't have the associated
complications with their Legal department, I'd rather like to resume
having direct commit access to the master dtc tree.  So if we could
get Jon and myself, at least, push access to a tree on git.kernel.org,
that would be nice.

(Fwiw, I do have a personal dtc branch tree on github at
https://github.com/dgibson/dtc).

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

Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[Jon Loeliger]

> 
> > Perhaps it is time to also place the official repo
> > of the Device Tree Compiler on git,kernel.org as well?
> 
> Sounds good to me.
> 
> Now that I'm no longer at IBM, and don't have the associated
> complications with their Legal department, I'd rather like to resume
> having direct commit access to the master dtc tree.  So if we could
> get Jon and myself, at least, push access to a tree on git.kernel.org,
> that would be nice.

Agreed.  Let's do that.

jdl

Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[Olof Johansson]

On Fri, Jul 19, 2013 at 8:19 PM, Grant Likely <grant.likely@linaro.org> wrote:
> Device tree bindings require a lot more attention than they used to.
> We've got a group of volunteers willing to take over maintaining
> bindings. This patch adds them to the MAINTAINERS file.
>
> This group still needs to work out a process for maintainership and how
> they are going to work together. I recommend that they set up a shared
> tree on git.kernel.org that they each have commit access to similar to
> the tip tree or the arm-soc tree, but it is up to them.
>
> Signed-off-by: Grant Likely <grant.likely@linaro.org>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: devicetree-discuss@lists.ozlabs.org
> Cc: devicetree@vger.kernel.org
> ---
>  MAINTAINERS | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index bc286e4..12c95d5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6050,13 +6050,24 @@ L:      devicetree@vger.kernel.org
>  W:     http://fdt.secretlab.ca
>  T:     git git://git.secretlab.ca/git/linux-2.6.git
>  S:     Maintained
> -F:     Documentation/devicetree
>  F:     drivers/of
>  F:     include/linux/of*.h
>  F:     scripts/dtc
>  K:     of_get_property
>  K:     of_match_table
>
> +OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> +M:     Pawel Moll <pawel.moll@arm.com>
> +M:     Mark Rutland <mark.rutland@arm.com>
> +M:     Stephen Warren <swarren@wwwdotorg.org>
> +M:     Ian Campbell <ian.campbell@citrix.com>
> +L:     devicetree@vger.kernel.org
> +S:     Maintained
> +F:     Documentation/devicetree
> +F:     arch/*/boot/dts
> +F:     arch/*/

This seems a bit broad. Someone is going to get a whole lot of email
if this goes in, and it might confuse contributors on who is
maintainer of what under arch.


-Olof

Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[Joe Perches]

On Sat, 2013-07-20 at 17:17 -0700, Olof Johansson wrote:
> On Fri, Jul 19, 2013 at 8:19 PM, Grant Likely <grant.likely@linaro.org> wrote:
> > Device tree bindings require a lot more attention than they used to.
> > We've got a group of volunteers willing to take over maintaining
> > bindings. This patch adds them to the MAINTAINERS file.
[]
> > diff --git a/MAINTAINERS b/MAINTAINERS
[]
> > +OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
[]
> > +F:     arch/*/
[]
> This seems a bit broad.

Yep, that's every file anywhere under arch.

Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[Grant Likely]

On Sun, Jul 21, 2013 at 1:29 AM, Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org> wrote:
> On Sat, 2013-07-20 at 17:17 -0700, Olof Johansson wrote:
>> On Fri, Jul 19, 2013 at 8:19 PM, Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> > Device tree bindings require a lot more attention than they used to.
>> > We've got a group of volunteers willing to take over maintaining
>> > bindings. This patch adds them to the MAINTAINERS file.
> []
>> > diff --git a/MAINTAINERS b/MAINTAINERS
> []
>> > +OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> []
>> > +F:     arch/*/
> []
>> This seems a bit broad.
>
> Yep, that's every file anywhere under arch.

yeah, that was a c/p mistake. I'll drop that line before committing.

g.

Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[Grant Likely]

On Sun, Jul 21, 2013 at 10:46 AM, Grant Likely <grant.likely@linaro.org> wrote:
> On Sun, Jul 21, 2013 at 1:29 AM, Joe Perches <joe@perches.com> wrote:
>> On Sat, 2013-07-20 at 17:17 -0700, Olof Johansson wrote:
>>> On Fri, Jul 19, 2013 at 8:19 PM, Grant Likely <grant.likely@linaro.org> wrote:
>>> > Device tree bindings require a lot more attention than they used to.
>>> > We've got a group of volunteers willing to take over maintaining
>>> > bindings. This patch adds them to the MAINTAINERS file.
>> []
>>> > diff --git a/MAINTAINERS b/MAINTAINERS
>> []
>>> > +OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
>> []
>>> > +F:     arch/*/
>> []
>>> This seems a bit broad.
>>
>> Yep, that's every file anywhere under arch.
>
> yeah, that was a c/p mistake. I'll drop that line before committing.

In fact, if things go well with the schema tool, it would be possible
to leave out the .dts files entirely as far as binding review goes.
The binding would be the important part and the .dts files would be
checked against that. That's something for the future though.

g.

Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[Olof Johansson]

On Sun, Jul 21, 2013 at 2:46 AM, Grant Likely <grant.likely@linaro.org> wrote:
> On Sun, Jul 21, 2013 at 1:29 AM, Joe Perches <joe@perches.com> wrote:
>> On Sat, 2013-07-20 at 17:17 -0700, Olof Johansson wrote:
>>> On Fri, Jul 19, 2013 at 8:19 PM, Grant Likely <grant.likely@linaro.org> wrote:
>>> > Device tree bindings require a lot more attention than they used to.
>>> > We've got a group of volunteers willing to take over maintaining
>>> > bindings. This patch adds them to the MAINTAINERS file.
>> []
>>> > diff --git a/MAINTAINERS b/MAINTAINERS
>> []
>>> > +OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
>> []
>>> > +F:     arch/*/
>> []
>>> This seems a bit broad.
>>
>> Yep, that's every file anywhere under arch.
>
> yeah, that was a c/p mistake. I'll drop that line before committing.

Ok, with that:

Acked-by: Olof Johansson <olof@lixom.net>


-Olof

Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[Rob Herring]

On 07/19/2013 10:19 PM, Grant Likely wrote:
> Device tree bindings require a lot more attention than they used to.
> We've got a group of volunteers willing to take over maintaining
> bindings. This patch adds them to the MAINTAINERS file.
> 
> This group still needs to work out a process for maintainership and how
> they are going to work together. I recommend that they set up a shared
> tree on git.kernel.org that they each have commit access to similar to
> the tip tree or the arm-soc tree, but it is up to them.
> 
> Signed-off-by: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> Cc: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
> Cc: Ian Campbell <ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
> Cc: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
> Cc: Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>
> Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> ---
>  MAINTAINERS | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index bc286e4..12c95d5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6050,13 +6050,24 @@ L:	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>  W:	http://fdt.secretlab.ca
>  T:	git git://git.secretlab.ca/git/linux-2.6.git
>  S:	Maintained
> -F:	Documentation/devicetree
>  F:	drivers/of
>  F:	include/linux/of*.h
>  F:	scripts/dtc
>  K:	of_get_property
>  K:	of_match_table
>  
> +OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> +M:	Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> +M:	Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> +M:	Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
> +M:	Ian Campbell <ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>

You can add me. I was not intending to step down.

What about creating an email alias for the group instead?

Rob

> +L:	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> +S:	Maintained
> +F:	Documentation/devicetree
> +F:	arch/*/boot/dts
> +F:	arch/*/
> +F:	include/dt-bindings
> +
>  OPENRISC ARCHITECTURE
>  M:	Jonas Bonn <jonas-A9uVI2HLR7kOP4wsBPIw7w@public.gmane.org>
>  W:	http://openrisc.net
> 

Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[Grant Likely]

On Sun, Jul 21, 2013 at 7:56 PM, Rob Herring <robherring2@gmail.com> wrote:
> On 07/19/2013 10:19 PM, Grant Likely wrote:
>> +OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
>> +M:   Pawel Moll <pawel.moll@arm.com>
>> +M:   Mark Rutland <mark.rutland@arm.com>
>> +M:   Stephen Warren <swarren@wwwdotorg.org>
>> +M:   Ian Campbell <ian.campbell@citrix.com>
>
> You can add me. I was not intending to step down.

Done.

> What about creating an email alias for the group instead?

Would that be any different from the mailing list address?

g.

Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[Rob Herring]

On 07/21/2013 07:35 PM, Grant Likely wrote:
> On Sun, Jul 21, 2013 at 7:56 PM, Rob Herring <robherring2@gmail.com> wrote:
>> On 07/19/2013 10:19 PM, Grant Likely wrote:
>>> +OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
>>> +M:   Pawel Moll <pawel.moll@arm.com>
>>> +M:   Mark Rutland <mark.rutland@arm.com>
>>> +M:   Stephen Warren <swarren@wwwdotorg.org>
>>> +M:   Ian Campbell <ian.campbell@citrix.com>
>>
>> You can add me. I was not intending to step down.
> 
> Done.
> 
>> What about creating an email alias for the group instead?
> 
> Would that be any different from the mailing list address?

My own selfish desire is to easily separate emails for DT bindings and
DT core code. I suppose I could do that with a suffix on my email address.

It seems to work well for arm-soc where you have a group of maintainers
and don't necessarily know who is actively maintaining things. Not sure
if we want to timeshare like that, but it would give us the flexibility.

Rob

Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[Jon Loeliger]

> 
> My own selfish desire is to easily separate emails for DT bindings and
> DT core code. I suppose I could do that with a suffix on my email address.

And I've had the reverse problem:  Sorting out the DTC
and libfdt patches from the noise. :-)

jdl

Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[Rob Herring]

On Mon, Jul 22, 2013 at 4:36 PM, Jon Loeliger <jdl@jdl.com> wrote:
>>
>> My own selfish desire is to easily separate emails for DT bindings and
>> DT core code. I suppose I could do that with a suffix on my email address.
>
> And I've had the reverse problem:  Sorting out the DTC
> and libfdt patches from the noise. :-)

Noise to you is rock-n-roll to me. ;) It's only going to get harder if
lots of email to devicetree-discuss was getting dropped waiting for
moderator approval.

Yours is the harder problem since there is not really a way to use
kernel MAINTAINERS for dtc. Perhaps the kernel maintainer for dtc
could be "Send Your Patch Upstream <nobody@nowhere.com>".

Rob

Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[Pawel Moll]

On Sat, 2013-07-20 at 04:19 +0100, Grant Likely wrote:
> +F:	include/dt-bindings

One thing we didn't finish talking about was the question if this
directory is supposed to contain *.dtsi files as well? The obvious
problem I have is a vexpress motherboard being (well, actually not bein
right now) shared between arch/arm/boot/dts and arch/arm64/boot/dts.

Pawel

Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[Rob Herring]

On 07/22/2013 11:50 AM, Pawel Moll wrote:
> On Sat, 2013-07-20 at 04:19 +0100, Grant Likely wrote:
>> +F:	include/dt-bindings
> 
> One thing we didn't finish talking about was the question if this
> directory is supposed to contain *.dtsi files as well? The obvious
> problem I have is a vexpress motherboard being (well, actually not bein
> right now) shared between arch/arm/boot/dts and arch/arm64/boot/dts.

Please no. When we move dts files out of the kernel, we will still need
to copy dt-bindings into the kernel. Also, I think we should move all
dts files out of arch subdirs and arrange by vendor or soc family. I'm
sure there are some cases that structure doesn't fit well, but there is
very little in a dts tied to a cpu architecture.

Rob

> Pawel
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[Pawel Moll]

On Mon, 2013-07-22 at 21:03 +0100, Rob Herring wrote:
> On 07/22/2013 11:50 AM, Pawel Moll wrote:
> > On Sat, 2013-07-20 at 04:19 +0100, Grant Likely wrote:
> >> +F:	include/dt-bindings
> > 
> > One thing we didn't finish talking about was the question if this
> > directory is supposed to contain *.dtsi files as well? The obvious
> > problem I have is a vexpress motherboard being (well, actually not bein
> > right now) shared between arch/arm/boot/dts and arch/arm64/boot/dts.
> 
> Please no. 

No as in: no don't put *.dtsi files into include/dt-bindings; or: no, do
not duplicate the motherboard file?

It you meant the latter, this is exactly what I wanted to say: I don't
want to do that, but there's no way of avoiding it right now.

> When we move dts files out of the kernel, 

And when would this happen? Don't get me wrong, I'm in favour of doing
this as well (I really don't want to push all 15-or-so DTSes for all the
different models and SMMs I have into the kernel)

> we will still need
> to copy dt-bindings into the kernel. Also, I think we should move all
> dts files out of arch subdirs and arrange by vendor or soc family. I'm
> sure there are some cases that structure doesn't fit well, but there is
> very little in a dts tied to a cpu architecture.

I couldn't agree more. So:

<root>/include/dt-bindings/vendor/*?
<root>/dts/vendor/*?
<root>/of/vendor/*?
<root>/dt/vendor/*?
<root>/drivers/of/vendor/*?

Paweł

Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[Stephen Warren]

On 07/23/2013 10:14 AM, Pawel Moll wrote:
> On Mon, 2013-07-22 at 21:03 +0100, Rob Herring wrote:
>> On 07/22/2013 11:50 AM, Pawel Moll wrote:
>>> On Sat, 2013-07-20 at 04:19 +0100, Grant Likely wrote:
>>>> +F:	include/dt-bindings
>>>
>>> One thing we didn't finish talking about was the question if this
>>> directory is supposed to contain *.dtsi files as well? The obvious
>>> problem I have is a vexpress motherboard being (well, actually not bein
>>> right now) shared between arch/arm/boot/dts and arch/arm64/boot/dts.
>>
>> Please no. 
> 
> No as in: no don't put *.dtsi files into include/dt-bindings; or: no, do
> not duplicate the motherboard file?

Don't put *.dtsi into include/dt-bindings, I believe.

> It you meant the latter, this is exactly what I wanted to say: I don't
> want to do that, but there's no way of avoiding it right now.

I think the solution is to introduce some new shared/common location for
shared/common *.dtsi files, into the kernel tree, in the interim.

When *.dts move out of the kernel, this common location can simply be
consumed as part of the DT tree re-organization.

Or perhaps, we could move *.dts around in the kernel to match the
proposed DT tree structure before that point in time?

>> we will still need
>> to copy dt-bindings into the kernel. Also, I think we should move all
>> dts files out of arch subdirs and arrange by vendor or soc family. I'm
>> sure there are some cases that structure doesn't fit well, but there is
>> very little in a dts tied to a cpu architecture.
> 
> I couldn't agree more. So:
> 
> <root>/include/dt-bindings/vendor/*?

> <root>/dts/vendor/*?

I would tend to prefer that option, ...

> <root>/of/vendor/*?
> <root>/dt/vendor/*?

or perhaps that one.

> <root>/drivers/of/vendor/*?

Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[Ian Campbell]

On Tue, 2013-07-23 at 10:59 -0700, Stephen Warren wrote:

> I think the solution is to introduce some new shared/common location for
> shared/common *.dtsi files, into the kernel tree, in the interim.
> 
> When *.dts move out of the kernel, this common location can simply be
> consumed as part of the DT tree re-organization.
> 
> Or perhaps, we could move *.dts around in the kernel to match the
> proposed DT tree structure before that point in time?

FWIW I can easily handle any transformation as part of the automated
extraction into the device-tree.git. If it can expressed as a sed script
then so much the better, e.g. the current rules are
http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git;a=blob;f=scripts/rewrite-paths.sed;h=f7a157d1b486bac058f50e42cf7bedc8630e54ff;hb=HEAD.
If it gets too complicated for sed I can always switch to something
else.

I'm already pending a complete rebuild of the export to add in the
Documentation/devicetree/bindings sub tree but since it takes an age to
run I was waiting for the output of this conversation before kicking
that off.

Ian.

Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[Rob Herring]

On 07/23/2013 01:09 PM, Ian Campbell wrote:
> On Tue, 2013-07-23 at 10:59 -0700, Stephen Warren wrote:
> 
>> I think the solution is to introduce some new shared/common location for
>> shared/common *.dtsi files, into the kernel tree, in the interim.
>>
>> When *.dts move out of the kernel, this common location can simply be
>> consumed as part of the DT tree re-organization.
>>
>> Or perhaps, we could move *.dts around in the kernel to match the
>> proposed DT tree structure before that point in time?
> 
> FWIW I can easily handle any transformation as part of the automated
> extraction into the device-tree.git. If it can expressed as a sed script
> then so much the better, e.g. the current rules are
> http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git;a=blob;f=scripts/rewrite-paths.sed;h=f7a157d1b486bac058f50e42cf7bedc8630e54ff;hb=HEAD.
> If it gets too complicated for sed I can always switch to something
> else.
> 
> I'm already pending a complete rebuild of the export to add in the
> Documentation/devicetree/bindings sub tree but since it takes an age to
> run I was waiting for the output of this conversation before kicking
> that off.

I'd doubt we could completely script this with a generic rule without a
bunch of manual transformations. So I think either restructuring in the
kernel or when we move them out of the kernel makes more sense. We know
the problem is coming, but it is not yet a major, pressing issue.

OTOH, you could see how far you get by putting dts files in directories
by their board level compatible string vendor and put any include files
where ever they are included from. Of course, that is just my proposed
layout. I haven't heard any opinions on that layout.

Rob

Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[Ian Campbell]

On Tue, 2013-07-23 at 13:44 -0500, Rob Herring wrote:
> On 07/23/2013 01:09 PM, Ian Campbell wrote:
> > On Tue, 2013-07-23 at 10:59 -0700, Stephen Warren wrote:
> > 
> >> I think the solution is to introduce some new shared/common location for
> >> shared/common *.dtsi files, into the kernel tree, in the interim.
> >>
> >> When *.dts move out of the kernel, this common location can simply be
> >> consumed as part of the DT tree re-organization.
> >>
> >> Or perhaps, we could move *.dts around in the kernel to match the
> >> proposed DT tree structure before that point in time?
> > 
> > FWIW I can easily handle any transformation as part of the automated
> > extraction into the device-tree.git. If it can expressed as a sed script
> > then so much the better, e.g. the current rules are
> > http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git;a=blob;f=scripts/rewrite-paths.sed;h=f7a157d1b486bac058f50e42cf7bedc8630e54ff;hb=HEAD.
> > If it gets too complicated for sed I can always switch to something
> > else.
> > 
> > I'm already pending a complete rebuild of the export to add in the
> > Documentation/devicetree/bindings sub tree but since it takes an age to
> > run I was waiting for the output of this conversation before kicking
> > that off.
> 
> I'd doubt we could completely script this with a generic rule without a
> bunch of manual transformations.

Right. The advantage of scripting, even if that script is just a big
long list of manual rules, is that we can preserve the history from
linux.git in device-tree.git, so git annotate etc say something useful.

But if I'm going to write a big long list of such rules I'd like to only
do the bulk of the work once, so we need to decide on the layout first.

>  So I think either restructuring in the
> kernel or when we move them out of the kernel makes more sense. We know
> the problem is coming, but it is not yet a major, pressing issue.
> 
> OTOH, you could see how far you get by putting dts files in directories
> by their board level compatible string vendor and put any include files
> where ever they are included from. Of course, that is just my proposed
> layout. I haven't heard any opinions on that layout.

I don't really have a strong opinion on the layout myself, I'm happy to
implement whatever works for people.

The board level compatible string vendor is the top-level compatible,
right? e.g.:
        / {
                model = "Calxeda Highbank";
                compatible = "calxeda,highbank";
"calxeda,highbank" in this case. So you propose s|,|/| on that so the
file ends up in calxeda/highbank.dts?

For the included ecx-common.dtsi I think you are proposing to find all
the files which include it and then find the
deepest-common-subdirectory? In this case the other include is
ecx-2000.dts which is compatible calxeda,ecx-2000
(->calxeda/ecx2000.dts) so the common subdir is calxeda and dtsi would
become calxeda/ecs-2000.dtsi. That works, I should probably have picked
an example which didn't rely on files you are so involved with in case
there is a selection bias at work ;-)

Ian.

Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[Rob Herring]

On 07/23/2013 01:55 PM, Ian Campbell wrote:
> On Tue, 2013-07-23 at 13:44 -0500, Rob Herring wrote:
>> On 07/23/2013 01:09 PM, Ian Campbell wrote:
>>> On Tue, 2013-07-23 at 10:59 -0700, Stephen Warren wrote:
>>>
>>>> I think the solution is to introduce some new shared/common location for
>>>> shared/common *.dtsi files, into the kernel tree, in the interim.
>>>>
>>>> When *.dts move out of the kernel, this common location can simply be
>>>> consumed as part of the DT tree re-organization.
>>>>
>>>> Or perhaps, we could move *.dts around in the kernel to match the
>>>> proposed DT tree structure before that point in time?
>>>
>>> FWIW I can easily handle any transformation as part of the automated
>>> extraction into the device-tree.git. If it can expressed as a sed script
>>> then so much the better, e.g. the current rules are
>>> http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git;a=blob;f=scripts/rewrite-paths.sed;h=f7a157d1b486bac058f50e42cf7bedc8630e54ff;hb=HEAD.
>>> If it gets too complicated for sed I can always switch to something
>>> else.
>>>
>>> I'm already pending a complete rebuild of the export to add in the
>>> Documentation/devicetree/bindings sub tree but since it takes an age to
>>> run I was waiting for the output of this conversation before kicking
>>> that off.
>>
>> I'd doubt we could completely script this with a generic rule without a
>> bunch of manual transformations.
> 
> Right. The advantage of scripting, even if that script is just a big
> long list of manual rules, is that we can preserve the history from
> linux.git in device-tree.git, so git annotate etc say something useful.
> 
> But if I'm going to write a big long list of such rules I'd like to only
> do the bulk of the work once, so we need to decide on the layout first.
> 
>>  So I think either restructuring in the
>> kernel or when we move them out of the kernel makes more sense. We know
>> the problem is coming, but it is not yet a major, pressing issue.
>>
>> OTOH, you could see how far you get by putting dts files in directories
>> by their board level compatible string vendor and put any include files
>> where ever they are included from. Of course, that is just my proposed
>> layout. I haven't heard any opinions on that layout.
> 
> I don't really have a strong opinion on the layout myself, I'm happy to
> implement whatever works for people.
> 
> The board level compatible string vendor is the top-level compatible,
> right? e.g.:
>         / {
>                 model = "Calxeda Highbank";
>                 compatible = "calxeda,highbank";
> "calxeda,highbank" in this case. So you propose s|,|/| on that so the
> file ends up in calxeda/highbank.dts?

Well, I was thinking just taking the vendor name and keep the existing
filename, but getting some consistency in filenames would probably be
good as well.

> For the included ecx-common.dtsi I think you are proposing to find all
> the files which include it and then find the
> deepest-common-subdirectory? In this case the other include is
> ecx-2000.dts which is compatible calxeda,ecx-2000
> (->calxeda/ecx2000.dts) so the common subdir is calxeda and dtsi would
> become calxeda/ecs-2000.dtsi. That works, I should probably have picked
> an example which didn't rely on files you are so involved with in case
> there is a selection bias at work ;-)

Yes, Calxeda stuff is obviously a simple example, but I don't think we
have any/many examples of includes across SOC vendors. Where things
breakdown are 3rd party boards. Do those go in the board or SOC vendor
directory? I'd vote for SOC vendor dir to keep the include structure
simple. That may still have issue if there are includes for
daughterboards which support multiple vendors' SOCs.

Rob

Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[Stephen Warren]

On 07/23/2013 11:55 AM, Ian Campbell wrote:
> On Tue, 2013-07-23 at 13:44 -0500, Rob Herring wrote:
>> On 07/23/2013 01:09 PM, Ian Campbell wrote:
>>> On Tue, 2013-07-23 at 10:59 -0700, Stephen Warren wrote:
>>>
>>>> I think the solution is to introduce some new shared/common location for
>>>> shared/common *.dtsi files, into the kernel tree, in the interim.
>>>>
>>>> When *.dts move out of the kernel, this common location can simply be
>>>> consumed as part of the DT tree re-organization.
>>>>
>>>> Or perhaps, we could move *.dts around in the kernel to match the
>>>> proposed DT tree structure before that point in time?
>>>
>>> FWIW I can easily handle any transformation as part of the automated
>>> extraction into the device-tree.git. If it can expressed as a sed script
>>> then so much the better, e.g. the current rules are
>>> http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git;a=blob;f=scripts/rewrite-paths.sed;h=f7a157d1b486bac058f50e42cf7bedc8630e54ff;hb=HEAD.
>>> If it gets too complicated for sed I can always switch to something
>>> else.
>>>
>>> I'm already pending a complete rebuild of the export to add in the
>>> Documentation/devicetree/bindings sub tree but since it takes an age to
>>> run I was waiting for the output of this conversation before kicking
>>> that off.
>>
>> I'd doubt we could completely script this with a generic rule without a
>> bunch of manual transformations.
> 
> Right. The advantage of scripting, even if that script is just a big
> long list of manual rules, is that we can preserve the history from
> linux.git in device-tree.git, so git annotate etc say something useful.
> 
> But if I'm going to write a big long list of such rules I'd like to only
> do the bulk of the work once, so we need to decide on the layout first.
> 
>>  So I think either restructuring in the
>> kernel or when we move them out of the kernel makes more sense. We know
>> the problem is coming, but it is not yet a major, pressing issue.
>>
>> OTOH, you could see how far you get by putting dts files in directories
>> by their board level compatible string vendor and put any include files
>> where ever they are included from. Of course, that is just my proposed
>> layout. I haven't heard any opinions on that layout.
> 
> I don't really have a strong opinion on the layout myself, I'm happy to
> implement whatever works for people.
> 
> The board level compatible string vendor is the top-level compatible,
> right? e.g.:
>         / {
>                 model = "Calxeda Highbank";
>                 compatible = "calxeda,highbank";
> "calxeda,highbank" in this case. So you propose s|,|/| on that so the
> file ends up in calxeda/highbank.dts?
> 
> For the included ecx-common.dtsi I think you are proposing to find all
> the files which include it and then find the
> deepest-common-subdirectory? In this case the other include is
> ecx-2000.dts which is compatible calxeda,ecx-2000
> (->calxeda/ecx2000.dts) so the common subdir is calxeda and dtsi would
> become calxeda/ecs-2000.dtsi. That works, I should probably have picked
> an example which didn't rely on files you are so involved with in case
> there is a selection bias at work ;-)

That layout sounds pretty reasonable. Are all those patches underneath
dt/ or is calxeda/ a top-level directory?

I guess that means that common files like skeleton.dtsi will simply end
up at the top-level (or in "top-level" dt/). That's probably fine.

I'd like the filenames to stay the same; to some degree I consider that
part of the DT ABI. At least for Tegra, and I think most/many other SoCs
follow this scheme..., we have named the files ${soc}-${board}.dts, and
made sure that the ${soc} and ${board} values match U-Boot's values, so
U-Boot can just "load mmc 0:1 ${soc}-${board}.dts" and hence use the
exact same U-Boot script for all Tegra boards (and potentially for any
board that defines ${soc} and ${board}, and doing that is easy).

Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[Ian Campbell]

On Tue, 2013-07-23 at 13:44 -0500, Rob Herring wrote:
> On 07/23/2013 01:09 PM, Ian Campbell wrote:
> > On Tue, 2013-07-23 at 10:59 -0700, Stephen Warren wrote:
> > 
> >> I think the solution is to introduce some new shared/common location for
> >> shared/common *.dtsi files, into the kernel tree, in the interim.
> >>
> >> When *.dts move out of the kernel, this common location can simply be
> >> consumed as part of the DT tree re-organization.
> >>
> >> Or perhaps, we could move *.dts around in the kernel to match the
> >> proposed DT tree structure before that point in time?
> > 
> > FWIW I can easily handle any transformation as part of the automated
> > extraction into the device-tree.git. If it can expressed as a sed script
> > then so much the better, e.g. the current rules are
> > http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git;a=blob;f=scripts/rewrite-paths.sed;h=f7a157d1b486bac058f50e42cf7bedc8630e54ff;hb=HEAD.
> > If it gets too complicated for sed I can always switch to something
> > else.
> > 
> > I'm already pending a complete rebuild of the export to add in the
> > Documentation/devicetree/bindings sub tree but since it takes an age to
> > run I was waiting for the output of this conversation before kicking
> > that off.
> 
> I'd doubt we could completely script this with a generic rule without a
> bunch of manual transformations. So I think either restructuring in the
> kernel or when we move them out of the kernel makes more sense. We know
> the problem is coming, but it is not yet a major, pressing issue.

So in the end I rebuilt with the existing transformation plus rewirting
Documentation/devicetree/bindings/ onto Bindings. I've pushed the new
branches to
        
        http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git
        git://xenbits.xen.org/people/ianc/device-tree-rebasing.git

In keeping with the name this means that the master and upstream/dts
branches have been rebased and so updates will be non-fastforwarding (as
has the internal filter-state branch). As you would expect the tags have
all changed as well.

> OTOH, you could see how far you get by putting dts files in directories
> by their board level compatible string vendor and put any include files
> where ever they are included from. Of course, that is just my proposed
> layout. I haven't heard any opinions on that layout.

These sorts of more complicated transformation aren't really feasible to
implement in the current automatic conversion process. It tries to
retain full history for the affected files (so git annotate/log/etc are
useful) which is OK for rewriting based solely on the path but once you
have to inspect the actual contents it gets more complicated and
significantly slower (since git rewrite-branch has to checkout every
tree, even without this it takes 2 days or so to convert).

These conversions would be better off done either as a second, probably
also automated, shuffling after (perhaps immediately after) we cut over
to using device-tree.git as the primary home.

If we end up doing some restructuring while these files are still in the
kernel I think I can still cope with that.

Ian.

Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[Nicolas Pitre]

On Tue, 23 Jul 2013, Stephen Warren wrote:

> Or perhaps, we could move *.dts around in the kernel to match the
> proposed DT tree structure before that point in time?
> 
> >> we will still need
> >> to copy dt-bindings into the kernel. Also, I think we should move all
> >> dts files out of arch subdirs and arrange by vendor or soc family. I'm
> >> sure there are some cases that structure doesn't fit well, but there is
> >> very little in a dts tied to a cpu architecture.
> > 
> > I couldn't agree more. So:
> > 
> > <root>/include/dt-bindings/vendor/*?
> 
> > <root>/dts/vendor/*?
> 
> I would tend to prefer that option, ...

Please make a generic top-level directory for DT and move the dtc code 
in there as well.  Something like:

<root>/devicetree/dtc/*
<root>/devicetree/dts/*


Nicolas