[RFC] Culling traffic volume on devicetree mailing list

[RFC] Culling traffic volume on devicetree mailing list

[Grant Likely]

Hi everyone,

Today on the devicetree conf call we (Rob, Ian and I) talked about
culling the volume of traffic on the devicetree list so that it would
be more useful to the DTC maintainers and non-Linux users like
freebsd. We'd like to propose creating the following two lists so that
those interested don't need to drink from the firehose:

devicetree-compiler: Specifically for discussing dt tooling topics
(parsing, schema validation, data format)

devicetree-spec: For discussing 'core' device tree bindings. ie.
anything that would be a candidate for putting into an ePAPR type
spec. Individual device bindings would continue to be posted to
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, but anything affecting subsystems or
generic patterns should be posted to this new list.

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

Re: [RFC] Culling traffic volume on devicetree mailing list

[Florian Fainelli]

Hi,

Le mardi 21 janvier 2014, 14:40:48 Grant Likely a écrit :
> Hi everyone,
> 
> Today on the devicetree conf call we (Rob, Ian and I) talked about
> culling the volume of traffic on the devicetree list so that it would
> be more useful to the DTC maintainers and non-Linux users like
> freebsd. We'd like to propose creating the following two lists so that
> those interested don't need to drink from the firehose:
> 
> devicetree-compiler: Specifically for discussing dt tooling topics
> (parsing, schema validation, data format)
> 
> devicetree-spec: For discussing 'core' device tree bindings. ie.
> anything that would be a candidate for putting into an ePAPR type
> spec. Individual device bindings would continue to be posted to
> devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, but anything affecting subsystems or
> generic patterns should be posted to this new list.
> 
> Thoughts?

I definitively support that idea. Any schedule on when you plan on creating 
those two mailing-lists?
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Culling traffic volume on devicetree mailing list

[Jason Cooper]

Grant,

On Tue, Jan 21, 2014 at 02:40:48PM +0000, Grant Likely wrote:
> Hi everyone,
> 
> Today on the devicetree conf call 

Sorry I couldn't make it, I had a last minute engagement yesterday AM.

> we (Rob, Ian and I) talked about culling the volume of traffic on the
> devicetree list so that it would be more useful to the DTC maintainers
> and non-Linux users like freebsd. We'd like to propose creating the
> following two lists so that those interested don't need to drink from
> the firehose:
> 
> devicetree-compiler: Specifically for discussing dt tooling topics
> (parsing, schema validation, data format)

Ack.

> devicetree-spec: For discussing 'core' device tree bindings. ie.
> anything that would be a candidate for putting into an ePAPR type
> spec. Individual device bindings would continue to be posted to
> devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, but anything affecting subsystems or
> generic patterns should be posted to this new list.
> 
> Thoughts?

How do patch series submitters easily determine when to send to -spec
vice the general list?  I'm thinking wrt get_maintainers.pl.

Perhaps it's worth considering organizing Doc.../bindings/ into
subsystem/ and ...'not'?  The "suitable for ePAPR" criteria would be a
good differentiator.

thx,

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

Re: [RFC] Culling traffic volume on devicetree mailing list

[Olof Johansson]

On Tue, Jan 21, 2014 at 6:40 AM, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
> Hi everyone,
>
> Today on the devicetree conf call we (Rob, Ian and I) talked about
> culling the volume of traffic on the devicetree list so that it would
> be more useful to the DTC maintainers and non-Linux users like
> freebsd. We'd like to propose creating the following two lists so that
> those interested don't need to drink from the firehose:
>
> devicetree-compiler: Specifically for discussing dt tooling topics
> (parsing, schema validation, data format)

This makes a lot of sense, and should help to decouple the bindings
and standards from the tool. Should have happened a long time ago. :)

> devicetree-spec: For discussing 'core' device tree bindings. ie.
> anything that would be a candidate for putting into an ePAPR type
> spec. Individual device bindings would continue to be posted to
> devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, but anything affecting subsystems or
> generic patterns should be posted to this new list.

I predict that it will be hard for someone posting a patch to tell if
they should send it to this list or some other list. It might be
convenient for you guys to ignore the high-volume list and just focus
on this one, but for the people who post patches it just makes it more
complicated. IMHO.


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

Re: [RFC] Culling traffic volume on devicetree mailing list

[Ian Campbell]

On Wed, 2014-01-22 at 10:35 -0800, Olof Johansson wrote:
> > devicetree-spec: For discussing 'core' device tree bindings. ie.
> > anything that would be a candidate for putting into an ePAPR type
> > spec. Individual device bindings would continue to be posted to
> > devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, but anything affecting subsystems or
> > generic patterns should be posted to this new list.
> 
> I predict that it will be hard for someone posting a patch to tell if
> they should send it to this list or some other list. It might be
> convenient for you guys to ignore the high-volume list and just focus
> on this one, but for the people who post patches it just makes it more
> complicated. IMHO.

The issue with the current list is that it is too much of a firehose of
Linux patches for other non-Linux consumers of DTB e.g. BSD folks, me
with my Xen hat, see [0] for the intersection of those two which
prompted me to mention this on the call.

The firehose means that these people don't subscribe and therefore lack
visibility into what is going on with the core bindings (e.g. BSD seems
to have a different binding for gic interrupts, mentioned in the linked
thread).

I don't think the intention of the split was/should be that "core"
Linux/DTB people should only subscribe to -spec@, rather that it be a
more targeted list which non-Linux/DTB folks can be involved with to
discuss core binding issues and standardisation etc.

It seems like devicetree@ would be the right default destination for any
patch and so should be what is listed in MAINTAINERS etc.

Anyone who is doing actual core/spec work appropriate to -spec@ is
either going to be involved enough to know this themselves or can be
asked to CC the other list too as part of the first round of review. The
number of patches which would need to go to -spec should be a pretty
small fraction.

Ian.

[0] http://thread.gmane.org/gmane.os.freebsd.xen/1976

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

Re: [RFC] Culling traffic volume on devicetree mailing list

[Rob Herring]

On Thu, Jan 23, 2014 at 5:03 AM, Ian Campbell <Ian.Campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org> wrote:
> On Wed, 2014-01-22 at 10:35 -0800, Olof Johansson wrote:
>> > devicetree-spec: For discussing 'core' device tree bindings. ie.
>> > anything that would be a candidate for putting into an ePAPR type
>> > spec. Individual device bindings would continue to be posted to
>> > devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, but anything affecting subsystems or
>> > generic patterns should be posted to this new list.
>>
>> I predict that it will be hard for someone posting a patch to tell if
>> they should send it to this list or some other list. It might be
>> convenient for you guys to ignore the high-volume list and just focus
>> on this one, but for the people who post patches it just makes it more
>> complicated. IMHO.
>
> The issue with the current list is that it is too much of a firehose of
> Linux patches for other non-Linux consumers of DTB e.g. BSD folks, me
> with my Xen hat, see [0] for the intersection of those two which
> prompted me to mention this on the call.
>
> The firehose means that these people don't subscribe and therefore lack
> visibility into what is going on with the core bindings (e.g. BSD seems
> to have a different binding for gic interrupts, mentioned in the linked
> thread).
>
> I don't think the intention of the split was/should be that "core"
> Linux/DTB people should only subscribe to -spec@, rather that it be a
> more targeted list which non-Linux/DTB folks can be involved with to
> discuss core binding issues and standardisation etc.
>
> It seems like devicetree@ would be the right default destination for any
> patch and so should be what is listed in MAINTAINERS etc.
>
> Anyone who is doing actual core/spec work appropriate to -spec@ is
> either going to be involved enough to know this themselves or can be
> asked to CC the other list too as part of the first round of review. The
> number of patches which would need to go to -spec should be a pretty
> small fraction.
>

One approach would be to just try to reduce the firehose a bit.

The list gets lots of patches which are not new bindings because we
trigger on any dts change and any patch with of_get_property or
of_match_table. I'm guessing the latter was mainly to catch missing
documentation, but it is clear that we are failing at that as we are
at about 50% documented compatible strings in a new kernel (hopefully
my checkpatch addition will improve that).

I think dts files are pretty well reviewed by platform maintainers and
lots of changes are just new boards using existing bindings. There
should be little for DT maintainers to review there. This was
discussed and agreed to at the ARM summit.

So something like this:

diff --git a/MAINTAINERS b/MAINTAINERS
index 6c20792..4e485c0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6267,8 +6267,6 @@ S:        Maintained
 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:     Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
@@ -6279,7 +6277,6 @@ M:        Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
 L:     devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
 S:     Maintained
 F:     Documentation/devicetree/
-F:     arch/*/boot/dts/
 F:     include/dt-bindings/

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

Re: [RFC] Culling traffic volume on devicetree mailing list

[Grant Likely]

On Wed, 22 Jan 2014 08:05:20 -0800, Florian Fainelli <f.fainelli@gmail.com> wrote:
> Hi,
> 
> Le mardi 21 janvier 2014, 14:40:48 Grant Likely a écrit :
> > Hi everyone,
> > 
> > Today on the devicetree conf call we (Rob, Ian and I) talked about
> > culling the volume of traffic on the devicetree list so that it would
> > be more useful to the DTC maintainers and non-Linux users like
> > freebsd. We'd like to propose creating the following two lists so that
> > those interested don't need to drink from the firehose:
> > 
> > devicetree-compiler: Specifically for discussing dt tooling topics
> > (parsing, schema validation, data format)
> > 
> > devicetree-spec: For discussing 'core' device tree bindings. ie.
> > anything that would be a candidate for putting into an ePAPR type
> > spec. Individual device bindings would continue to be posted to
> > devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, but anything affecting subsystems or
> > generic patterns should be posted to this new list.
> > 
> > Thoughts?
> 
> I definitively support that idea. Any schedule on when you plan on creating 
> those two mailing-lists?

Next week.

g.

> -- 
> Florian

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

Re: [RFC] Culling traffic volume on devicetree mailing list

[Grant Likely]

On Wed, 22 Jan 2014 12:22:43 -0500, Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org> wrote:
> Grant,
> 
> On Tue, Jan 21, 2014 at 02:40:48PM +0000, Grant Likely wrote:
> > Hi everyone,
> > 
> > Today on the devicetree conf call 
> 
> Sorry I couldn't make it, I had a last minute engagement yesterday AM.
> 
> > we (Rob, Ian and I) talked about culling the volume of traffic on the
> > devicetree list so that it would be more useful to the DTC maintainers
> > and non-Linux users like freebsd. We'd like to propose creating the
> > following two lists so that those interested don't need to drink from
> > the firehose:
> > 
> > devicetree-compiler: Specifically for discussing dt tooling topics
> > (parsing, schema validation, data format)
> 
> Ack.
> 
> > devicetree-spec: For discussing 'core' device tree bindings. ie.
> > anything that would be a candidate for putting into an ePAPR type
> > spec. Individual device bindings would continue to be posted to
> > devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, but anything affecting subsystems or
> > generic patterns should be posted to this new list.
> > 
> > Thoughts?
> 
> How do patch series submitters easily determine when to send to -spec
> vice the general list?  I'm thinking wrt get_maintainers.pl.

Driver patch authors wouldn't need to worry about it over much.
get_maintainer.pl currently does what is needed. Only when developers
start venturing into core bindings would they need to worry about the
spec list. I'm inclined to believe that the traffic will be small enough
that we can simply tell people, "hey, this looks pretty generic, you
should probably post it to the spec list."

Maybe devicetree-core would be a better list name though.

> 
> Perhaps it's worth considering organizing Doc.../bindings/ into
> subsystem/ and ...'not'?  The "suitable for ePAPR" criteria would be a
> good differentiator.

I'm not opposed to that. Having someone curate that directory would be
helpful. Want to volunteer? :-)

g.

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

Re: [RFC] Culling traffic volume on devicetree mailing list

[Grant Likely]

On Wed, 22 Jan 2014 10:35:58 -0800, Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org> wrote:
> On Tue, Jan 21, 2014 at 6:40 AM, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
> > Hi everyone,
> >
> > Today on the devicetree conf call we (Rob, Ian and I) talked about
> > culling the volume of traffic on the devicetree list so that it would
> > be more useful to the DTC maintainers and non-Linux users like
> > freebsd. We'd like to propose creating the following two lists so that
> > those interested don't need to drink from the firehose:
> >
> > devicetree-compiler: Specifically for discussing dt tooling topics
> > (parsing, schema validation, data format)
> 
> This makes a lot of sense, and should help to decouple the bindings
> and standards from the tool. Should have happened a long time ago. :)
> 
> > devicetree-spec: For discussing 'core' device tree bindings. ie.
> > anything that would be a candidate for putting into an ePAPR type
> > spec. Individual device bindings would continue to be posted to
> > devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, but anything affecting subsystems or
> > generic patterns should be posted to this new list.
> 
> I predict that it will be hard for someone posting a patch to tell if
> they should send it to this list or some other list. It might be
> convenient for you guys to ignore the high-volume list and just focus
> on this one, but for the people who post patches it just makes it more
> complicated. IMHO.

I'm inclined to stick with the default of post to the original
devicetree list via get_maintainer.pl, and then direct people to the
core list on a case by case basis when they start doing something
generic.

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

Re: [RFC] Culling traffic volume on devicetree mailing list

[Grant Likely]

On Thu, 23 Jan 2014 08:53:34 -0600, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Jan 23, 2014 at 5:03 AM, Ian Campbell <Ian.Campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org> wrote:
> > On Wed, 2014-01-22 at 10:35 -0800, Olof Johansson wrote:
> >> > devicetree-spec: For discussing 'core' device tree bindings. ie.
> >> > anything that would be a candidate for putting into an ePAPR type
> >> > spec. Individual device bindings would continue to be posted to
> >> > devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, but anything affecting subsystems or
> >> > generic patterns should be posted to this new list.
> >>
> >> I predict that it will be hard for someone posting a patch to tell if
> >> they should send it to this list or some other list. It might be
> >> convenient for you guys to ignore the high-volume list and just focus
> >> on this one, but for the people who post patches it just makes it more
> >> complicated. IMHO.
> >
> > The issue with the current list is that it is too much of a firehose of
> > Linux patches for other non-Linux consumers of DTB e.g. BSD folks, me
> > with my Xen hat, see [0] for the intersection of those two which
> > prompted me to mention this on the call.
> >
> > The firehose means that these people don't subscribe and therefore lack
> > visibility into what is going on with the core bindings (e.g. BSD seems
> > to have a different binding for gic interrupts, mentioned in the linked
> > thread).
> >
> > I don't think the intention of the split was/should be that "core"
> > Linux/DTB people should only subscribe to -spec@, rather that it be a
> > more targeted list which non-Linux/DTB folks can be involved with to
> > discuss core binding issues and standardisation etc.
> >
> > It seems like devicetree@ would be the right default destination for any
> > patch and so should be what is listed in MAINTAINERS etc.
> >
> > Anyone who is doing actual core/spec work appropriate to -spec@ is
> > either going to be involved enough to know this themselves or can be
> > asked to CC the other list too as part of the first round of review. The
> > number of patches which would need to go to -spec should be a pretty
> > small fraction.
> >
> 
> One approach would be to just try to reduce the firehose a bit.
> 
> The list gets lots of patches which are not new bindings because we
> trigger on any dts change and any patch with of_get_property or
> of_match_table. I'm guessing the latter was mainly to catch missing
> documentation, but it is clear that we are failing at that as we are
> at about 50% documented compatible strings in a new kernel (hopefully
> my checkpatch addition will improve that).
> 
> I think dts files are pretty well reviewed by platform maintainers and
> lots of changes are just new boards using existing bindings. There
> should be little for DT maintainers to review there. This was
> discussed and agreed to at the ARM summit.
> 
> So something like this:

Acked-by: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

g.

> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6c20792..4e485c0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6267,8 +6267,6 @@ S:        Maintained
>  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:     Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> @@ -6279,7 +6277,6 @@ M:        Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>  L:     devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>  S:     Maintained
>  F:     Documentation/devicetree/
> -F:     arch/*/boot/dts/
>  F:     include/dt-bindings/
> 
>  OPENRISC ARCHITECTURE

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