[PATCH 1/1] MAINTAINERS: Add maintainer for NXP S32G boards

[Chester Lin]

Hi all,

Sorry for the late reply since I lost connection with upstream due to a
health condition, which affected my eyesights for a while so I tried to use
my eyes as less as possible. Please accept my apologies anyway.

On Fri, Feb 23, 2024 at 10:42:58PM +0800, Shawn Guo wrote:
> On Fri, Feb 23, 2024 at 01:29:10PM +0100, Arnd Bergmann wrote:
> > On Fri, Feb 23, 2024, at 13:02, Matthias Brugger wrote:
> > > On 22/02/2024 12:13, Krzysztof Kozlowski wrote:
> > >> On 21/02/2024 18:00, Ghennadi Procopciuc wrote:
> > >> 
> > >> Andreas or Matthias,
> > >> Maybe you could change your R: into M: and take s32g patches?
> > >> 
> > >> If not, then I will ack this patch making Ghennadi the maintainer.
> > >> 
> > >
> > > Normal process would be that Arnd would contact Chester to see if he is 
> > > not able 
> > > to do the maintainer work any more. In that case maybe Arnd could take 
> > > over.
> > 
> > I was hoping to see a reply from Chester one way or another,
> > I see he has been on Cc for the entire thread but not
> > chimed in.
> > 

Before leaving SUSE I reached NXP to see if anyone could take over it but I
didn't get response unfortunately. Maybe it was too rush to find a right person
at the moment but I still wish that someone can take over this role based on the
following reasons:

- Since I have returned my S32G boards to SUSE, currently I do not have a platform
to verify S32G patches unless I could get a new one. I wish I could still help
out but hardware & doc resources will be the biggest challenge to me.

- My current employee may have competitive relationship with NXP in automotive
field, which means I may not be fit in this role unless nobody cares.

> > > I'm not saying that Ghennadi won't be able to defend this, if it ever occurs. 
> > > Basically because I don't have a good track record of him due to missing 
> > > upstream collaboration.
> > >
> > > I would prefer that Arnd (or Andreas) step up to take the maintainer role. I 
> > > already have one and it's difficult for me to find the time to do it in an 
> > > acceptable way.
> > 
> > It appears that we already cover the dts files in the IMX
> > entry, whether that is intentional or not:
> > 
> > ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
> > M:      Shawn Guo <shawnguo at kernel.org>
> > M:      Sascha Hauer <s.hauer at pengutronix.de>
> > R:      Pengutronix Kernel Team <kernel at pengutronix.de>
> > R:      Fabio Estevam <festevam at gmail.com>
> > R:      NXP Linux Team <linux-imx at nxp.com> 
> > L:      linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> > S:      Maintained
> > T:      git git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git
> > F:      arch/arm/boot/dts/nxp/imx/
> > F:      arch/arm/boot/dts/nxp/mxs/
> > F:      arch/arm64/boot/dts/freescale/
> > 
> > Added everyone there to Cc, having any s32 patches go through
> > the imx tree would be the easiest way as far as I'm concerned.
> > I've added the maintainers to Cc, let's see what they think.
> 
> It's unintentional that IMX entry covers s32 dts files, as they have a
> dedicated entry.
> 
> ARM/NXP S32G ARCHITECTURE
> M:      Chester Lin <chester62515 at gmail.com>
> R:      Andreas Färber <afaerber at suse.de>
> R:      Matthias Brugger <mbrugger at suse.com>
> R:      NXP S32 Linux Team <s32 at nxp.com>
> L:      linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> S:      Maintained
> F:      arch/arm64/boot/dts/freescale/s32g*.dts*
> 
> However I'm fine with collecting and sending patches through IMX tree,
> if S32G folks help review them.
> 
> Shawn
> 

This looks good to me as well.

Regards,
Chester