diff mbox series

[8/8] MAINTAINERS: Add an entry for NXP S32G2 boards

Message ID 20210805065429.27485-9-clin@suse.com
State New
Headers show
Series arm64: dts: initial NXP S32G2 support | expand

Commit Message

Chester Lin Aug. 5, 2021, 6:54 a.m. UTC
Add a new entry for the maintenance of NXP S32G2 DT files.

Signed-off-by: Chester Lin <clin@suse.com>
---
 MAINTAINERS | 6 ++++++
 1 file changed, 6 insertions(+)

Comments

Shawn Guo Aug. 9, 2021, 8:03 a.m. UTC | #1
On Thu, Aug 05, 2021 at 09:49:51AM +0200, Krzysztof Kozlowski wrote:
> On 05/08/2021 08:54, Chester Lin wrote:

> > Add a new entry for the maintenance of NXP S32G2 DT files.

> > 

> > Signed-off-by: Chester Lin <clin@suse.com>

> > ---

> >  MAINTAINERS | 6 ++++++

> >  1 file changed, 6 insertions(+)

> > 

> > diff --git a/MAINTAINERS b/MAINTAINERS

> > index 36aee8517ab0..3c6ba6cefd8f 100644

> > --- a/MAINTAINERS

> > +++ b/MAINTAINERS

> > @@ -2281,6 +2281,12 @@ F:	arch/arm/boot/dts/nuvoton-wpcm450*

> >  F:	arch/arm/mach-npcm/wpcm450.c

> >  F:	drivers/*/*wpcm*

> >  

> > +ARM/NXP S32G2 ARCHITECTURE

> > +M:	Chester Lin <clin@suse.com>

> > +L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)

> > +S:	Maintained

> > +F:	arch/arm64/boot/dts/freescale/s32g2*

> 

> I support the idea of sub-sub-architecture maintainers but I think idea

> of in-file addresses was preferred:

> https://lore.kernel.org/lkml/20200830122922.3884-1-shawnguo@kernel.org/


Thanks for reminding that the patch didn't land.  I just resent it with
your Reviewed-by tag added.  Thanks!

Shawn
Andreas Färber Aug. 12, 2021, 3:30 p.m. UTC | #2
Hello Shawn and Krzysztof,

On 09.08.21 10:03, Shawn Guo wrote:
> On Thu, Aug 05, 2021 at 09:49:51AM +0200, Krzysztof Kozlowski wrote:

>> On 05/08/2021 08:54, Chester Lin wrote:

>>> Add a new entry for the maintenance of NXP S32G2 DT files.

>>>

>>> Signed-off-by: Chester Lin <clin@suse.com>

>>> ---

>>>  MAINTAINERS | 6 ++++++

>>>  1 file changed, 6 insertions(+)

>>>

>>> diff --git a/MAINTAINERS b/MAINTAINERS

>>> index 36aee8517ab0..3c6ba6cefd8f 100644

>>> --- a/MAINTAINERS

>>> +++ b/MAINTAINERS

>>> @@ -2281,6 +2281,12 @@ F:	arch/arm/boot/dts/nuvoton-wpcm450*

>>>  F:	arch/arm/mach-npcm/wpcm450.c

>>>  F:	drivers/*/*wpcm*

>>>  

>>> +ARM/NXP S32G2 ARCHITECTURE


Suggestion from NXP is to use the broader S32G name.

>>> +M:	Chester Lin <clin@suse.com>

>>> +L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)

>>> +S:	Maintained

>>> +F:	arch/arm64/boot/dts/freescale/s32g2*

>>

>> I support the idea of sub-sub-architecture maintainers but I think idea

>> of in-file addresses was preferred:

>> https://lore.kernel.org/lkml/20200830122922.3884-1-shawnguo@kernel.org/


I had specifically asked Chester to add a MAINTAINERS section.

Is your apparent suggestion of not accepting this MAINTAINERS patch
based on the assumption that we're dealing with only one email address
in three files? What do you see as the threshold to warrant a section?

From my point of view, above MAINTAINERS entry is incomplete, as we
should CC the full team working on S32G for patch review, not just
Chester himself.
So that would in my mind have been additional R: and L: entries in that
MAINTAINERS section.

> Thanks for reminding that the patch didn't land.  I just resent it with

> your Reviewed-by tag added.  Thanks!


Your above patch does not make clear to me what syntax we should use for
adding email addresses to .dts[i] files now:

https://lore.kernel.org/lkml/20210809081033.GQ30984@dragon/

Especially when not dealing with file authors.

I get the impression it is not a replacement for an F: wildcard used in
MAINTAINERS, but rather a complement?

Please understand that this is not about a single .dts file, as your
patch suggests, but about a complete SoC family consisting of s32g*.dts*
as well as in the future drivers specific to this platform. It seems way
easier to specify the list of maintainers/reviewers in MAINTAINERS once
with suitable wildcard paths, than copying them into each and every
.dtsi and .dts file and driver .c/.h and later needing to sync multiple
places. If a bot or user has fixes or cleanups for the S32G code, we
want to know about it, so that NXP can consider it for their BSP
branches and SUSE for our SLE branches, and obviously for follow-up
patch series that are already in the works and waiting on this one.

Once merged, I would expect Chester or someone from NXP to set up an
S32G tree on kernel.org that gets integrated into linux-next and sends
pull requests to the SoC tree maintainers without bothering i.MX and
Layerscape maintainers. Did you handle that differently for S32V?

Thanks,
Andreas

P.S. Have you checked or considered whether your script change might
start to CC non-existing email addresses, since we wouldn't be allowed
to remove them from copyright or authorship statements to prevent that?

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)
Krzysztof Kozlowski Aug. 12, 2021, 3:54 p.m. UTC | #3
On 12/08/2021 17:30, Andreas Färber wrote:
> Hello Shawn and Krzysztof,

> 

> On 09.08.21 10:03, Shawn Guo wrote:

>> On Thu, Aug 05, 2021 at 09:49:51AM +0200, Krzysztof Kozlowski wrote:

>>> On 05/08/2021 08:54, Chester Lin wrote:

>>>> Add a new entry for the maintenance of NXP S32G2 DT files.

>>>>

>>>> Signed-off-by: Chester Lin <clin@suse.com>

>>>> ---

>>>>  MAINTAINERS | 6 ++++++

>>>>  1 file changed, 6 insertions(+)

>>>>

>>>> diff --git a/MAINTAINERS b/MAINTAINERS

>>>> index 36aee8517ab0..3c6ba6cefd8f 100644

>>>> --- a/MAINTAINERS

>>>> +++ b/MAINTAINERS

>>>> @@ -2281,6 +2281,12 @@ F:	arch/arm/boot/dts/nuvoton-wpcm450*

>>>>  F:	arch/arm/mach-npcm/wpcm450.c

>>>>  F:	drivers/*/*wpcm*

>>>>  

>>>> +ARM/NXP S32G2 ARCHITECTURE

> 

> Suggestion from NXP is to use the broader S32G name.

> 

>>>> +M:	Chester Lin <clin@suse.com>

>>>> +L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)

>>>> +S:	Maintained

>>>> +F:	arch/arm64/boot/dts/freescale/s32g2*

>>>

>>> I support the idea of sub-sub-architecture maintainers but I think idea

>>> of in-file addresses was preferred:

>>> https://lore.kernel.org/lkml/20200830122922.3884-1-shawnguo@kernel.org/

> 

> I had specifically asked Chester to add a MAINTAINERS section.

> 

> Is your apparent suggestion of not accepting this MAINTAINERS patch

> based on the assumption that we're dealing with only one email address

> in three files? What do you see as the threshold to warrant a section?

> 

> From my point of view, above MAINTAINERS entry is incomplete, as we

> should CC the full team working on S32G for patch review, not just

> Chester himself.

> So that would in my mind have been additional R: and L: entries in that

> MAINTAINERS section.


I assumed this is a sub-sub-architecture (something coming from
Layerscape or i.MX) but it seems it's not, therefore I don't mind having
separate entry in MAINTAINERS. The idea of in-file maintainers was for
specific boards and SoCs belonging to existing sub-architectures.

I agree with your following reasons.

> 

>> Thanks for reminding that the patch didn't land.  I just resent it with

>> your Reviewed-by tag added.  Thanks!

> 

> Your above patch does not make clear to me what syntax we should use for

> adding email addresses to .dts[i] files now:

> 

> https://lore.kernel.org/lkml/20210809081033.GQ30984@dragon/

> 

> Especially when not dealing with file authors.

> 

> I get the impression it is not a replacement for an F: wildcard used in

> MAINTAINERS, but rather a complement?

> 

> Please understand that this is not about a single .dts file, as your

> patch suggests, but about a complete SoC family consisting of s32g*.dts*

> as well as in the future drivers specific to this platform. It seems way

> easier to specify the list of maintainers/reviewers in MAINTAINERS once

> with suitable wildcard paths, than copying them into each and every

> .dtsi and .dts file and driver .c/.h and later needing to sync multiple

> places. If a bot or user has fixes or cleanups for the S32G code, we

> want to know about it, so that NXP can consider it for their BSP

> branches and SUSE for our SLE branches, and obviously for follow-up

> patch series that are already in the works and waiting on this one.

> 

> Once merged, I would expect Chester or someone from NXP to set up an

> S32G tree on kernel.org that gets integrated into linux-next and sends

> pull requests to the SoC tree maintainers without bothering i.MX and

> Layerscape maintainers. Did you handle that differently for S32V?

> 

> Thanks,

> Andreas

> 

> P.S. Have you checked or considered whether your script change might

> start to CC non-existing email addresses, since we wouldn't be allowed

> to remove them from copyright or authorship statements to prevent that?


The same can happen for DT bindings maintainers.

Best regards,
Krzysztof
diff mbox series

Patch

diff --git a/MAINTAINERS b/MAINTAINERS
index 36aee8517ab0..3c6ba6cefd8f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2281,6 +2281,12 @@  F:	arch/arm/boot/dts/nuvoton-wpcm450*
 F:	arch/arm/mach-npcm/wpcm450.c
 F:	drivers/*/*wpcm*
 
+ARM/NXP S32G2 ARCHITECTURE
+M:	Chester Lin <clin@suse.com>
+L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S:	Maintained
+F:	arch/arm64/boot/dts/freescale/s32g2*
+
 ARM/OPENMOKO NEO FREERUNNER (GTA02) MACHINE SUPPORT
 L:	openmoko-kernel@lists.openmoko.org (subscribers-only)
 S:	Orphan