lkml.org 
[lkml]   [2021]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 8/8] MAINTAINERS: Add an entry for NXP S32G2 boards
Date
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

\
 
 \ /
  Last update: 2021-08-12 17:55    [W:0.059 / U:0.640 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site