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)
