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

From: Chester Lin
Date: Sat Feb 24 2024 - 02:26:11 EST


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@xxxxxxxxxx>
> > M: Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>
> > R: Pengutronix Kernel Team <kernel@xxxxxxxxxxxxxx>
> > R: Fabio Estevam <festevam@xxxxxxxxx>
> > R: NXP Linux Team <linux-imx@xxxxxxx>
> > L: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx (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@xxxxxxxxx>
> R: Andreas Färber <afaerber@xxxxxxx>
> R: Matthias Brugger <mbrugger@xxxxxxxx>
> R: NXP S32 Linux Team <s32@xxxxxxx>
> L: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx (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