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@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. 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
