diff mbox series

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

Message ID 20240221120123.1118552-2-ghennadi.procopciuc@oss.nxp.com (mailing list archive)
State Superseded
Headers show
Series MAINTAINERS: Add S32G SoC maintainer | expand

Commit Message

Ghennadi Procopciuc Feb. 21, 2024, 12:01 p.m. UTC
From: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>

Add myself as a maintainer of the NXP S32G DT files.

Signed-off-by: Ghennadi Procopciuc <ghennadi.procopciuc@oss.nxp.com>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

Comments

Krzysztof Kozlowski Feb. 21, 2024, 2:42 p.m. UTC | #1
On 21/02/2024 13:01, Ghennadi Procopciuc wrote:
> From: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
> 
> Add myself as a maintainer of the NXP S32G DT files.

No need for cover letters for single patches. OTOH, this commit msg is
empty...

Plus your patch looks corrupted (wrong encoding): F??rber

BTW, did you contribute anything to the upstream Linux kernel? Do you
know the process? Downstream does not really matter.


Best regards,
Krzysztof
Krzysztof Kozlowski Feb. 21, 2024, 2:45 p.m. UTC | #2
On 21/02/2024 15:42, Krzysztof Kozlowski wrote:
> On 21/02/2024 13:01, Ghennadi Procopciuc wrote:
>> From: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
>>
>> Add myself as a maintainer of the NXP S32G DT files.
> 
> No need for cover letters for single patches. OTOH, this commit msg is
> empty...
> 
> Plus your patch looks corrupted (wrong encoding): F??rber
> 
> BTW, did you contribute anything to the upstream Linux kernel? Do you
> know the process? Downstream does not really matter.

I found the answer:

From: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
Signed-off-by: Ghennadi Procopciuc <ghennadi.procopciuc@oss.nxp.com>

Does not look like. Please get some upstream work experience first.

https://lore.kernel.org/all/?q=f%3Aghennadi.procopciuc%40oss.nxp.com

Best regards,
Krzysztof
Ghennadi Procopciuc Feb. 21, 2024, 3:19 p.m. UTC | #3
On 2/21/24 16:45, Krzysztof Kozlowski wrote:
> On 21/02/2024 15:42, Krzysztof Kozlowski wrote:
>> On 21/02/2024 13:01, Ghennadi Procopciuc wrote:
>>> From: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
>>>
>>> Add myself as a maintainer of the NXP S32G DT files.
>>
>> No need for cover letters for single patches. OTOH, this commit msg is
>> empty...
Thank you, I can correct that.

>> Plus your patch looks corrupted (wrong encoding): F??rber

Indeed, it is due to 'Content-Type: text/plain; charset="us-ascii"'.
I can fix this as part of v2.

>> BTW, did you contribute anything to the upstream Linux kernel? Do you
>> know the process? Downstream does not really matter.
> 
> I found the answer:
> 
> From: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
> Signed-off-by: Ghennadi Procopciuc <ghennadi.procopciuc@oss.nxp.com>
> 
> Does not look like. Please get some upstream work experience first.
> 
> https://lore.kernel.org/all/?q=f%3Aghennadi.procopciuc%40oss.nxp.com

Although I am new to upstream communities and may make mistakes, I am
eager to learn and improve.

After leaving SuSe[0], the current maintainer of the NXP S32G DT files
became inactive[1]. As a result, this area is not currently being
maintained. This is the actual reason why I attempted to add myself as a
maintainer of that area. Although I acknowledge that I may not have
enough experience to become a maintainer, I am concerned that the NXP
S32G DT patch submission may be blocked for everyone due to the current
situation.

Should someone else from MAINTAINERS take over this area, or are there
other alternatives?

[0] https://lore.kernel.org/all/20231115234508.11510-1-clin@suse.com/
[1]
https://lore.kernel.org/all/a7a55dc6-c204-4aad-adff-9806d3302b6b@oss.nxp.com/


> 
> Best regards,
> Krzysztof
> Regards,
Ghennadi
Krzysztof Kozlowski Feb. 21, 2024, 3:43 p.m. UTC | #4
On 21/02/2024 16:19, Ghennadi Procopciuc wrote:
> On 2/21/24 16:45, Krzysztof Kozlowski wrote:
>> On 21/02/2024 15:42, Krzysztof Kozlowski wrote:
>>> On 21/02/2024 13:01, Ghennadi Procopciuc wrote:
>>>> From: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
>>>>
>>>> Add myself as a maintainer of the NXP S32G DT files.
>>>
>>> No need for cover letters for single patches. OTOH, this commit msg is
>>> empty...
> Thank you, I can correct that.
> 
>>> Plus your patch looks corrupted (wrong encoding): F??rber
> 
> Indeed, it is due to 'Content-Type: text/plain; charset="us-ascii"'.
> I can fix this as part of v2.
> 
>>> BTW, did you contribute anything to the upstream Linux kernel? Do you
>>> know the process? Downstream does not really matter.
>>
>> I found the answer:
>>
>> From: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
>> Signed-off-by: Ghennadi Procopciuc <ghennadi.procopciuc@oss.nxp.com>
>>
>> Does not look like. Please get some upstream work experience first.
>>
>> https://lore.kernel.org/all/?q=f%3Aghennadi.procopciuc%40oss.nxp.com
> 
> Although I am new to upstream communities and may make mistakes, I am
> eager to learn and improve.
> 
> After leaving SuSe[0], the current maintainer of the NXP S32G DT files
> became inactive[1]. As a result, this area is not currently being
> maintained. This is the actual reason why I attempted to add myself as a
> maintainer of that area. Although I acknowledge that I may not have
> enough experience to become a maintainer, I am concerned that the NXP
> S32G DT patch submission may be blocked for everyone due to the current
> situation.

I would be just happy to see first actual contributions or any sort of
activity, like reviewing, before taking over something.

You do not need to become maintainer to provide reviews. By reviewing
patches you already reduce burden/work from the maintainers.

Best regards,
Krzysztof
Ghennadi Procopciuc Feb. 21, 2024, 5 p.m. UTC | #5
On 2/21/24 17:43, Krzysztof Kozlowski wrote:
> On 21/02/2024 16:19, Ghennadi Procopciuc wrote:
>> On 2/21/24 16:45, Krzysztof Kozlowski wrote:
>>> On 21/02/2024 15:42, Krzysztof Kozlowski wrote:
>>>> On 21/02/2024 13:01, Ghennadi Procopciuc wrote:
>>>>> From: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
>>>>>
>>>>> Add myself as a maintainer of the NXP S32G DT files.
>>>>
>>>> No need for cover letters for single patches. OTOH, this commit msg is
>>>> empty...
>> Thank you, I can correct that.
>>
>>>> Plus your patch looks corrupted (wrong encoding): F??rber
>>
>> Indeed, it is due to 'Content-Type: text/plain; charset="us-ascii"'.
>> I can fix this as part of v2.
>>
>>>> BTW, did you contribute anything to the upstream Linux kernel? Do you
>>>> know the process? Downstream does not really matter.
>>>
>>> I found the answer:
>>>
>>> From: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
>>> Signed-off-by: Ghennadi Procopciuc <ghennadi.procopciuc@oss.nxp.com>
>>>
>>> Does not look like. Please get some upstream work experience first.
>>>
>>> https://lore.kernel.org/all/?q=f%3Aghennadi.procopciuc%40oss.nxp.com
>>
>> Although I am new to upstream communities and may make mistakes, I am
>> eager to learn and improve.
>>
>> After leaving SuSe[0], the current maintainer of the NXP S32G DT files
>> became inactive[1]. As a result, this area is not currently being
>> maintained. This is the actual reason why I attempted to add myself as a
>> maintainer of that area. Although I acknowledge that I may not have
>> enough experience to become a maintainer, I am concerned that the NXP
>> S32G DT patch submission may be blocked for everyone due to the current
>> situation.
> 
> I would be just happy to see first actual contributions or any sort of
> activity, like reviewing, before taking over something.
> 
> You do not need to become maintainer to provide reviews. By reviewing
> patches you already reduce burden/work from the maintainers.
> 
> Best regards,
> Krzysztof
> 

I fully understand and agree with your perspective on this matter and
accept the fact that I will not be a maintainer as initially intended.
Furthermore, I am very willing to participate in any reviews related to
S32G SoCs.

Patches, including those I have created ([0], [1]), will likely be
submitted for this area. This is because each enabled driver for S32G
SoCs is expected to have at least one node in the device tree. These
patches will undergo review and receive feedback. However, the upstream
process will come to a halt at this point since there are no maintainers
to apply and integrate them. 

I do not know how this situation should be handled, given my lack of
experience in upstreaming maintenance. The documentation for the Linux
kernel is insufficient in providing guidance [2] on how to handle
inactive maintainers and it is unclear who should take over their
responsibilities. This is likely not the first time this has happened in
the kernel's history.

Could you please guide me on how these patches should be integrated into
a maintainer's  tree and by whom?

[0]
https://lore.kernel.org/all/94742ebd-bc3a-4726-9ba7-5954203e4da1@suse.com/
[1]
https://lore.kernel.org/all/372ed255-85b7-4f18-a28e-82e18171f7e3@suse.com/
[2]
https://docs.kernel.org/maintainer/feature-and-driver-maintainers.html#non-compliance

Best regards,
Ghennadi
Krzysztof Kozlowski Feb. 22, 2024, 11:13 a.m. UTC | #6
On 21/02/2024 18:00, Ghennadi Procopciuc wrote:
> On 2/21/24 17:43, Krzysztof Kozlowski wrote:
>> On 21/02/2024 16:19, Ghennadi Procopciuc wrote:
>>> On 2/21/24 16:45, Krzysztof Kozlowski wrote:
>>>> On 21/02/2024 15:42, Krzysztof Kozlowski wrote:
>>>>> On 21/02/2024 13:01, Ghennadi Procopciuc wrote:
>>>>>> From: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
>>>>>>
>>>>>> Add myself as a maintainer of the NXP S32G DT files.
>>>>>
>>>>> No need for cover letters for single patches. OTOH, this commit msg is
>>>>> empty...
>>> Thank you, I can correct that.
>>>
>>>>> Plus your patch looks corrupted (wrong encoding): F??rber
>>>
>>> Indeed, it is due to 'Content-Type: text/plain; charset="us-ascii"'.
>>> I can fix this as part of v2.
>>>
>>>>> BTW, did you contribute anything to the upstream Linux kernel? Do you
>>>>> know the process? Downstream does not really matter.
>>>>
>>>> I found the answer:
>>>>
>>>> From: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
>>>> Signed-off-by: Ghennadi Procopciuc <ghennadi.procopciuc@oss.nxp.com>
>>>>
>>>> Does not look like. Please get some upstream work experience first.
>>>>
>>>> https://lore.kernel.org/all/?q=f%3Aghennadi.procopciuc%40oss.nxp.com
>>>
>>> Although I am new to upstream communities and may make mistakes, I am
>>> eager to learn and improve.
>>>
>>> After leaving SuSe[0], the current maintainer of the NXP S32G DT files
>>> became inactive[1]. As a result, this area is not currently being
>>> maintained. This is the actual reason why I attempted to add myself as a
>>> maintainer of that area. Although I acknowledge that I may not have
>>> enough experience to become a maintainer, I am concerned that the NXP
>>> S32G DT patch submission may be blocked for everyone due to the current
>>> situation.
>>
>> I would be just happy to see first actual contributions or any sort of
>> activity, like reviewing, before taking over something.
>>
>> You do not need to become maintainer to provide reviews. By reviewing
>> patches you already reduce burden/work from the maintainers.
>>
>> Best regards,
>> Krzysztof
>>
> 
> I fully understand and agree with your perspective on this matter and
> accept the fact that I will not be a maintainer as initially intended.
> Furthermore, I am very willing to participate in any reviews related to
> S32G SoCs.

Just give it some time...

> 
> Patches, including those I have created ([0], [1]), will likely be
> submitted for this area. This is because each enabled driver for S32G
> SoCs is expected to have at least one node in the device tree. These
> patches will undergo review and receive feedback. However, the upstream
> process will come to a halt at this point since there are no maintainers
> to apply and integrate them. 

Indeed that's a problem.

> 
> I do not know how this situation should be handled, given my lack of
> experience in upstreaming maintenance. The documentation for the Linux
> kernel is insufficient in providing guidance [2] on how to handle
> inactive maintainers and it is unclear who should take over their
> responsibilities. This is likely not the first time this has happened in
> the kernel's history.
> 
> Could you please guide me on how these patches should be integrated into
> a maintainer's  tree and by whom?

Chester left Suse, so maybe this also means less interest in maintaining
it? Stepping up in such case, so your proposal, is reasonable, so in
general I agree and thank you for trying to do something here.

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.

Best regards,
Krzysztof
Matthias Brugger Feb. 23, 2024, 12:02 p.m. UTC | #7
On 22/02/2024 12:13, Krzysztof Kozlowski wrote:
> On 21/02/2024 18:00, Ghennadi Procopciuc wrote:
>> On 2/21/24 17:43, Krzysztof Kozlowski wrote:
>>> On 21/02/2024 16:19, Ghennadi Procopciuc wrote:
>>>> On 2/21/24 16:45, Krzysztof Kozlowski wrote:
>>>>> On 21/02/2024 15:42, Krzysztof Kozlowski wrote:
>>>>>> On 21/02/2024 13:01, Ghennadi Procopciuc wrote:
>>>>>>> From: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
>>>>>>>
>>>>>>> Add myself as a maintainer of the NXP S32G DT files.
>>>>>>
>>>>>> No need for cover letters for single patches. OTOH, this commit msg is
>>>>>> empty...
>>>> Thank you, I can correct that.
>>>>
>>>>>> Plus your patch looks corrupted (wrong encoding): F??rber
>>>>
>>>> Indeed, it is due to 'Content-Type: text/plain; charset="us-ascii"'.
>>>> I can fix this as part of v2.
>>>>
>>>>>> BTW, did you contribute anything to the upstream Linux kernel? Do you
>>>>>> know the process? Downstream does not really matter.
>>>>>
>>>>> I found the answer:
>>>>>
>>>>> From: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
>>>>> Signed-off-by: Ghennadi Procopciuc <ghennadi.procopciuc@oss.nxp.com>
>>>>>
>>>>> Does not look like. Please get some upstream work experience first.
>>>>>
>>>>> https://lore.kernel.org/all/?q=f%3Aghennadi.procopciuc%40oss.nxp.com
>>>>
>>>> Although I am new to upstream communities and may make mistakes, I am
>>>> eager to learn and improve.
>>>>
>>>> After leaving SuSe[0], the current maintainer of the NXP S32G DT files
>>>> became inactive[1]. As a result, this area is not currently being
>>>> maintained. This is the actual reason why I attempted to add myself as a
>>>> maintainer of that area. Although I acknowledge that I may not have
>>>> enough experience to become a maintainer, I am concerned that the NXP
>>>> S32G DT patch submission may be blocked for everyone due to the current
>>>> situation.
>>>
>>> I would be just happy to see first actual contributions or any sort of
>>> activity, like reviewing, before taking over something.
>>>
>>> You do not need to become maintainer to provide reviews. By reviewing
>>> patches you already reduce burden/work from the maintainers.
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>
>> I fully understand and agree with your perspective on this matter and
>> accept the fact that I will not be a maintainer as initially intended.
>> Furthermore, I am very willing to participate in any reviews related to
>> S32G SoCs.
> 
> Just give it some time...
> 
>>
>> Patches, including those I have created ([0], [1]), will likely be
>> submitted for this area. This is because each enabled driver for S32G
>> SoCs is expected to have at least one node in the device tree. These
>> patches will undergo review and receive feedback. However, the upstream
>> process will come to a halt at this point since there are no maintainers
>> to apply and integrate them.
> 
> Indeed that's a problem.
> 
>>
>> I do not know how this situation should be handled, given my lack of
>> experience in upstreaming maintenance. The documentation for the Linux
>> kernel is insufficient in providing guidance [2] on how to handle
>> inactive maintainers and it is unclear who should take over their
>> responsibilities. This is likely not the first time this has happened in
>> the kernel's history.
>>
>> Could you please guide me on how these patches should be integrated into
>> a maintainer's  tree and by whom?
> 
> Chester left Suse, so maybe this also means less interest in maintaining
> it? Stepping up in such case, so your proposal, is reasonable, so in
> general I agree and thank you for trying to do something here.
> 
> 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 agree with you that some one should get maintainer for a SoC because he is 
involved in the Linux kernel community and not because he is working on 
downstream patches for the same silicon. Especially being paid by the company 
that produces the silicon can quickly get you into dificult situation. Think for 
example that NXP, which pays you, wants something to be added in the upstream 
kernel, but the code is not in a shape to be part of Linux kernel. That can 
generate conflict and for the upstream community it is important that the only 
criteria to accept something upstream is the fact that it is in a good shape for 
that, not any comercial roadmap by a company.

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.

Regards,
Matthias
Arnd Bergmann Feb. 23, 2024, 12:29 p.m. UTC | #8
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.

> 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@kernel.org>
M:      Sascha Hauer <s.hauer@pengutronix.de>
R:      Pengutronix Kernel Team <kernel@pengutronix.de>
R:      Fabio Estevam <festevam@gmail.com>
R:      NXP Linux Team <linux-imx@nxp.com> 
L:      linux-arm-kernel@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.

I also noticed that the pinctrl driver entry still has Chester's
old email address listed as the only maintainer, so we should
probably fix that as well:

PIN CONTROLLER - NXP S32
M:      Chester Lin <clin@suse.com>
R:      NXP S32 Linux Team <s32@nxp.com>
L:      linux-gpio@vger.kernel.org
S:      Maintained
F:      Documentation/devicetree/bindings/pinctrl/nxp,s32*
F:      drivers/pinctrl/nxp/

       Arnd
Shawn Guo Feb. 23, 2024, 2:42 p.m. UTC | #9
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.
> 
> > 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@kernel.org>
> M:      Sascha Hauer <s.hauer@pengutronix.de>
> R:      Pengutronix Kernel Team <kernel@pengutronix.de>
> R:      Fabio Estevam <festevam@gmail.com>
> R:      NXP Linux Team <linux-imx@nxp.com> 
> L:      linux-arm-kernel@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@gmail.com>
R:      Andreas Färber <afaerber@suse.de>
R:      Matthias Brugger <mbrugger@suse.com>
R:      NXP S32 Linux Team <s32@nxp.com>
L:      linux-arm-kernel@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
Chester Lin Feb. 24, 2024, 7:25 a.m. UTC | #10
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@kernel.org>
> > M:      Sascha Hauer <s.hauer@pengutronix.de>
> > R:      Pengutronix Kernel Team <kernel@pengutronix.de>
> > R:      Fabio Estevam <festevam@gmail.com>
> > R:      NXP Linux Team <linux-imx@nxp.com> 
> > L:      linux-arm-kernel@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@gmail.com>
> R:      Andreas Färber <afaerber@suse.de>
> R:      Matthias Brugger <mbrugger@suse.com>
> R:      NXP S32 Linux Team <s32@nxp.com>
> L:      linux-arm-kernel@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
Chester Lin Feb. 24, 2024, 7:56 a.m. UTC | #11
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@kernel.org>
> > > M:      Sascha Hauer <s.hauer@pengutronix.de>
> > > R:      Pengutronix Kernel Team <kernel@pengutronix.de>
> > > R:      Fabio Estevam <festevam@gmail.com>
> > > R:      NXP Linux Team <linux-imx@nxp.com> 
> > > L:      linux-arm-kernel@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@gmail.com>
> > R:      Andreas Färber <afaerber@suse.de>
> > R:      Matthias Brugger <mbrugger@suse.com>
> > R:      NXP S32 Linux Team <s32@nxp.com>
> > L:      linux-arm-kernel@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
Arnd Bergmann Feb. 24, 2024, 11:42 a.m. UTC | #12
On Sat, Feb 24, 2024, at 08:25, Chester Lin wrote:
> 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.

No worries, and thanks for the clarifications.

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

In general, there no problem to just retire from a maintainer
position or mark it as 'Odd fixes' instead of 'Maintained' when
you are no longer planning to actively maintain it.

>> > 
>> > 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@gmail.com>
>> R:      Andreas Färber <afaerber@suse.de>
>> R:      Matthias Brugger <mbrugger@suse.com>
>> R:      NXP S32 Linux Team <s32@nxp.com>
>> L:      linux-arm-kernel@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.
>> 
>
> This looks good to me as well.

Ok, in this case I would suggest we change this section to
only have 'R:' entries and no 'M:' for the moment.

Between the four of you (Chester, Andreas, Matthias, Ghennadi),
I think we can choose to keep everyone or drop those that are
unlikely to actually review patches. Please let us know you
would like to be included as a reviewer or not.

For the pinctrl driver, I would add the files to the "freescale"
pinctrl entry in a similar way and end up with

diff --git a/MAINTAINERS b/MAINTAINERS
index efeaeb51f183..c1924c0053bc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2555,13 +2555,14 @@ F:      drivers/*/*/*wpcm*
 F:     drivers/*/*wpcm*
 
 ARM/NXP S32G ARCHITECTURE
-M:     Chester Lin <chester62515@gmail.com>
+R:     Chester Lin <chester62515@gmail.com>
 R:     Andreas Färber <afaerber@suse.de>
 R:     Matthias Brugger <mbrugger@suse.com>
 R:     NXP S32 Linux Team <s32@nxp.com>
 L:     linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
 S:     Maintained
 F:     arch/arm64/boot/dts/freescale/s32g*.dts*
+F:     drivers/pinctrl/nxp/
 
 ARM/Orion SoC/Technologic Systems TS-78xx platform support
 M:     Alexander Clouter <alex@digriz.org.uk>
@@ -17415,7 +17416,9 @@ R:      Pengutronix Kernel Team <kernel@pengutronix.de>
 L:     linux-gpio@vger.kernel.org
 S:     Maintained
 F:     Documentation/devicetree/bindings/pinctrl/fsl,*
+F:     Documentation/devicetree/bindings/pinctrl/nxp,s32*
 F:     drivers/pinctrl/freescale/
+F:     drivers/pinctrl/nxp/
 
 PIN CONTROLLER - INTEL
 M:     Mika Westerberg <mika.westerberg@linux.intel.com>
@@ -17469,14 +17472,6 @@ S:     Supported
 F:     drivers/gpio/gpio-sama5d2-piobu.c
 F:     drivers/pinctrl/pinctrl-at91*
 
-PIN CONTROLLER - NXP S32
-M:     Chester Lin <clin@suse.com>
-R:     NXP S32 Linux Team <s32@nxp.com>
-L:     linux-gpio@vger.kernel.org
-S:     Maintained
-F:     Documentation/devicetree/bindings/pinctrl/nxp,s32*
-F:     drivers/pinctrl/nxp/
-
 PIN CONTROLLER - QUALCOMM
 M:     Bjorn Andersson <andersson@kernel.org>
 L:     linux-arm-msm@vger.kernel.org
Ghennadi Procopciuc Feb. 26, 2024, 7:33 a.m. UTC | #13
On 2/24/24 13:42, Arnd Bergmann wrote:
> On Sat, Feb 24, 2024, at 08:25, Chester Lin wrote:
>> 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.
> 
> No worries, and thanks for the clarifications.
> 
>> 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:
>>
>> 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.
> 
> In general, there no problem to just retire from a maintainer
> position or mark it as 'Odd fixes' instead of 'Maintained' when
> you are no longer planning to actively maintain it.
> 
>>>>
>>>> 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@gmail.com>
>>> R:      Andreas Färber <afaerber@suse.de>
>>> R:      Matthias Brugger <mbrugger@suse.com>
>>> R:      NXP S32 Linux Team <s32@nxp.com>
>>> L:      linux-arm-kernel@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.
>>>
>>
>> This looks good to me as well.

I agree, this looks good to me too.

> 
> Ok, in this case I would suggest we change this section to
> only have 'R:' entries and no 'M:' for the moment.
> 
> Between the four of you (Chester, Andreas, Matthias, Ghennadi),
> I think we can choose to keep everyone or drop those that are
> unlikely to actually review patches. Please let us know you
> would like to be included as a reviewer or not.

I would like to be included as reviewer.
Can we add Shawn as the maintainer since Chester agreed to pass on the
responsibility to him?

> 
> For the pinctrl driver, I would add the files to the "freescale"
> pinctrl entry in a similar way and end up with
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index efeaeb51f183..c1924c0053bc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2555,13 +2555,14 @@ F:      drivers/*/*/*wpcm*
>  F:     drivers/*/*wpcm*
>  
>  ARM/NXP S32G ARCHITECTURE
> -M:     Chester Lin <chester62515@gmail.com>
> +R:     Chester Lin <chester62515@gmail.com>
>  R:     Andreas Färber <afaerber@suse.de>
>  R:     Matthias Brugger <mbrugger@suse.com>
>  R:     NXP S32 Linux Team <s32@nxp.com>
>  L:     linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
>  S:     Maintained
>  F:     arch/arm64/boot/dts/freescale/s32g*.dts*
> +F:     drivers/pinctrl/nxp/
>  
>  ARM/Orion SoC/Technologic Systems TS-78xx platform support
>  M:     Alexander Clouter <alex@digriz.org.uk>
> @@ -17415,7 +17416,9 @@ R:      Pengutronix Kernel Team <kernel@pengutronix.de>
>  L:     linux-gpio@vger.kernel.org
>  S:     Maintained
>  F:     Documentation/devicetree/bindings/pinctrl/fsl,*
> +F:     Documentation/devicetree/bindings/pinctrl/nxp,s32*
>  F:     drivers/pinctrl/freescale/
> +F:     drivers/pinctrl/nxp/

Could you please add 'L: NXP S32 Linux Team <s32@nxp.com>', given that
this list is relevant for S32 patches ?

>  PIN CONTROLLER - INTEL
>  M:     Mika Westerberg <mika.westerberg@linux.intel.com>
> @@ -17469,14 +17472,6 @@ S:     Supported
>  F:     drivers/gpio/gpio-sama5d2-piobu.c
>  F:     drivers/pinctrl/pinctrl-at91*
>  
> -PIN CONTROLLER - NXP S32
> -M:     Chester Lin <clin@suse.com>
> -R:     NXP S32 Linux Team <s32@nxp.com>
> -L:     linux-gpio@vger.kernel.org
> -S:     Maintained
> -F:     Documentation/devicetree/bindings/pinctrl/nxp,s32*
> -F:     drivers/pinctrl/nxp/
> -
>  PIN CONTROLLER - QUALCOMM
>  M:     Bjorn Andersson <andersson@kernel.org>
>  L:     linux-arm-msm@vger.kernel.org

Best regards,
Ghennadi
Matthias Brugger Feb. 26, 2024, 9:55 a.m. UTC | #14
On 24/02/2024 12:42, Arnd Bergmann wrote:
[...]
>>> ARM/NXP S32G ARCHITECTURE
>>> M:      Chester Lin <chester62515@gmail.com>
>>> R:      Andreas Färber <afaerber@suse.de>
>>> R:      Matthias Brugger <mbrugger@suse.com>
>>> R:      NXP S32 Linux Team <s32@nxp.com>
>>> L:      linux-arm-kernel@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.
>>>
>>
>> This looks good to me as well.
> 
> Ok, in this case I would suggest we change this section to
> only have 'R:' entries and no 'M:' for the moment.
> 
> Between the four of you (Chester, Andreas, Matthias, Ghennadi),
> I think we can choose to keep everyone or drop those that are
> unlikely to actually review patches. Please let us know you
> would like to be included as a reviewer or not.
> 

Please include me as reviewer :)

Regards,
Matthias
Matthias Brugger Feb. 28, 2024, 3:19 p.m. UTC | #15
On 26/02/2024 10:55, Matthias Brugger wrote:
> 
> 
> On 24/02/2024 12:42, Arnd Bergmann wrote:
> [...]
>>>> ARM/NXP S32G ARCHITECTURE
>>>> M:      Chester Lin <chester62515@gmail.com>
>>>> R:      Andreas Färber <afaerber@suse.de>
>>>> R:      Matthias Brugger <mbrugger@suse.com>
>>>> R:      NXP S32 Linux Team <s32@nxp.com>
>>>> L:      linux-arm-kernel@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.
>>>>
>>>
>>> This looks good to me as well.
>>
>> Ok, in this case I would suggest we change this section to
>> only have 'R:' entries and no 'M:' for the moment.
>>
>> Between the four of you (Chester, Andreas, Matthias, Ghennadi),

I talked with Andreas today and he prefers to be dropped from the list.

Regards,
Matthias


>> I think we can choose to keep everyone or drop those that are
>> unlikely to actually review patches. Please let us know you
>> would like to be included as a reviewer or not.
>>
> 
> Please include me as reviewer :)
> 
> Regards,
> Matthias
>
diff mbox series

Patch

diff --git a/MAINTAINERS b/MAINTAINERS
index 9ed4d3868539..09d7a0489952 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2543,6 +2543,7 @@  F:	drivers/*/*wpcm*
 
 ARM/NXP S32G ARCHITECTURE
 M:	Chester Lin <chester62515@gmail.com>
+M:	Ghennadi Procopciuc <ghennadi.procopciuc@oss.nxp.com>
 R:	Andreas F??rber <afaerber@suse.de>
 R:	Matthias Brugger <mbrugger@suse.com>
 R:	NXP S32 Linux Team <s32@nxp.com>