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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx>
>>> ---
>>>  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@xxxxxxxx>
>>> +L:	linux-arm-kernel@xxxxxxxxxxxxxxxxxxx (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@xxxxxxxxxx/

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)



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux