As discussed in the ARM kernel summit, people on the devicetree list
would no longer like to receive emails about all dts changes. Remove
from MAINTAINERS.
Signed-off-by: Doug Anderson <[email protected]>
---
MAINTAINERS | 2 --
1 file changed, 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index ebaf8bd..0166e8e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5987,7 +5987,6 @@ OMAP DEVICE TREE SUPPORT
M: Benoît Cousson <[email protected]>
M: Tony Lindgren <[email protected]>
L: [email protected]
-L: [email protected]
S: Maintained
F: arch/arm/boot/dts/*omap*
F: arch/arm/boot/dts/*am3*
@@ -6167,7 +6166,6 @@ M: Ian Campbell <[email protected]>
L: [email protected]
S: Maintained
F: Documentation/devicetree/
-F: arch/*/boot/dts/
F: include/dt-bindings/
OPENRISC ARCHITECTURE
--
1.8.4
On 10/23/2013 08:22 AM, Doug Anderson wrote:
> As discussed in the ARM kernel summit, people on the devicetree list
> would no longer like to receive emails about all dts changes. Remove
> from MAINTAINERS.
We need to make sure platform maintainers are copied though. That may be
hard since we don't have standard layout/naming of dts files.
We might also want to drop these:
K: of_get_property
K: of_match_table
They are at least on the wrong maintainer list now as they should be
associated with the binding maintainers and not DT core code if we do
keep them.
Also based on the discussion, we need to add
Documentation/devicetree/bindings/* to appropriate subsystem
maintainers, but that should probably wait until after Friday at least.
Rob
>
> Signed-off-by: Doug Anderson <[email protected]>
> ---
> MAINTAINERS | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ebaf8bd..0166e8e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5987,7 +5987,6 @@ OMAP DEVICE TREE SUPPORT
> M: Benoît Cousson <[email protected]>
> M: Tony Lindgren <[email protected]>
> L: [email protected]
> -L: [email protected]
> S: Maintained
> F: arch/arm/boot/dts/*omap*
> F: arch/arm/boot/dts/*am3*
> @@ -6167,7 +6166,6 @@ M: Ian Campbell <[email protected]>
> L: [email protected]
> S: Maintained
> F: Documentation/devicetree/
> -F: arch/*/boot/dts/
> F: include/dt-bindings/
>
> OPENRISC ARCHITECTURE
>
Em Wed, 23 Oct 2013 12:12:32 -0500
Rob Herring <[email protected]> escreveu:
> On 10/23/2013 08:22 AM, Doug Anderson wrote:
> > As discussed in the ARM kernel summit, people on the devicetree list
> > would no longer like to receive emails about all dts changes. Remove
> > from MAINTAINERS.
>
> We need to make sure platform maintainers are copied though. That may be
> hard since we don't have standard layout/naming of dts files.
>
> We might also want to drop these:
> K: of_get_property
> K: of_match_table
>
> They are at least on the wrong maintainer list now as they should be
> associated with the binding maintainers and not DT core code if we do
> keep them.
>
> Also based on the discussion, we need to add
> Documentation/devicetree/bindings/* to appropriate subsystem
> maintainers, but that should probably wait until after Friday at least.
/me is confused. What's the procedure for the DT patches for the devices
supported by the subsystem I maintain, e. g. patches for
/drivers/media/platform?
Should I just apply them, if I think that it is needed by the hardware?
Are there any criteria to be followed? If so, what criteria?
/me hopes that all those questions will be discussed/answered at KS on
Friday's discussions ;)
In any case, my suggestion is that this patch should be a way more verbose,
and should come together with a patch adding something at Documentation
(SubmittingPatches, or maybe SubmitingDTPatches) in order to be sure that
both developers and subsystem maintainers will do the right thing.
Thanks,
Mauro
>
> Rob
>
> >
> > Signed-off-by: Doug Anderson <[email protected]>
> > ---
> > MAINTAINERS | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index ebaf8bd..0166e8e 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -5987,7 +5987,6 @@ OMAP DEVICE TREE SUPPORT
> > M: Benoît Cousson <[email protected]>
> > M: Tony Lindgren <[email protected]>
> > L: [email protected]
> > -L: [email protected]
> > S: Maintained
> > F: arch/arm/boot/dts/*omap*
> > F: arch/arm/boot/dts/*am3*
> > @@ -6167,7 +6166,6 @@ M: Ian Campbell <[email protected]>
> > L: [email protected]
> > S: Maintained
> > F: Documentation/devicetree/
> > -F: arch/*/boot/dts/
> > F: include/dt-bindings/
> >
> > OPENRISC ARCHITECTURE
> >
>
--
Cheers,
Mauro
On Wed, Oct 23, 2013 at 5:54 PM, Mauro Carvalho Chehab
<[email protected]> wrote:
> Em Wed, 23 Oct 2013 12:12:32 -0500
> Rob Herring <[email protected]> escreveu:
>
>> On 10/23/2013 08:22 AM, Doug Anderson wrote:
>> > As discussed in the ARM kernel summit, people on the devicetree list
>> > would no longer like to receive emails about all dts changes. Remove
>> > from MAINTAINERS.
>>
>> We need to make sure platform maintainers are copied though. That may be
>> hard since we don't have standard layout/naming of dts files.
>>
>> We might also want to drop these:
>> K: of_get_property
>> K: of_match_table
>>
>> They are at least on the wrong maintainer list now as they should be
>> associated with the binding maintainers and not DT core code if we do
>> keep them.
>>
>> Also based on the discussion, we need to add
>> Documentation/devicetree/bindings/* to appropriate subsystem
>> maintainers, but that should probably wait until after Friday at least.
>
> /me is confused. What's the procedure for the DT patches for the devices
> supported by the subsystem I maintain, e. g. patches for
> /drivers/media/platform?
>
> Should I just apply them, if I think that it is needed by the hardware?
> Are there any criteria to be followed? If so, what criteria?
>
> /me hopes that all those questions will be discussed/answered at KS on
> Friday's discussions ;)
Yes, it should all become clear at the DT slot on Fri.
> In any case, my suggestion is that this patch should be a way more verbose,
> and should come together with a patch adding something at Documentation
> (SubmittingPatches, or maybe SubmitingDTPatches) in order to be sure that
> both developers and subsystem maintainers will do the right thing.
A binding howto/best practices doc is planned which should help in this area.
Rob