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

Chester Lin chester62515 at gmail.com
Fri Feb 23 23:56:12 PST 2024


On Sat, Feb 24, 2024 at 03:25:59PM +0800, Chester Lin wrote:
> Hi all,
> 
> Sorry for the late reply since I lost connection with upstream due to a
> health condition, which affected my eyesight 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 rushed 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

"My current employer". Sorry for my stupid typo.

Chester

> 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



More information about the linux-arm-kernel mailing list