linux-kernel - Re: [PATCH v2 6/6] cdx: MAINTAINERS: Explicitly mention Greg who handles patches

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <77143d25-e0ca-4dbd-9c36-ad8e4c71795e@linaro.org>
Date: Fri, 2 May 2025 09:52:18 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: "Gupta, Nipun" <nipun.gupta@....com>,
 Nikhil Agarwal <nikhil.agarwal@....com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 6/6] cdx: MAINTAINERS: Explicitly mention Greg who
 handles patches

On 02/05/2025 09:17, Greg Kroah-Hartman wrote:
> On Fri, May 02, 2025 at 08:57:12AM +0200, Krzysztof Kozlowski wrote:
>> On 02/05/2025 08:52, Gupta, Nipun wrote:
>>>
>>>
>>> On 02-05-2025 11:57, Krzysztof Kozlowski wrote:
>>>> On 01/05/2025 18:06, Krzysztof Kozlowski wrote:
>>>>> On 01/05/2025 17:59, Greg Kroah-Hartman wrote:
>>>>>> On Wed, Apr 30, 2025 at 08:41:34PM +0200, Krzysztof Kozlowski wrote:
>>>>>>> Patches for CDX bus drivers are applied by Greg Kroah-Hartman, so list
>>>>>>> him in the maintainers entry because otherwise contributors would be
>>>>>>> surprised their patches got lost.
>>>>>>>
>>>>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
>>>>>>> ---
>>>>>>>   MAINTAINERS | 1 +
>>>>>>>   1 file changed, 1 insertion(+)
>>>>>>>
>>>>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>>>>> index b2c3be5f6131432647dd01f22bbf4bf1c8bde9e6..505d7d45ad7d1c007e89a555264ff8cbeaf6e1f4 100644
>>>>>>> --- a/MAINTAINERS
>>>>>>> +++ b/MAINTAINERS
>>>>>>> @@ -1008,6 +1008,7 @@ F:	Documentation/devicetree/bindings/w1/amd,axi-1wire-host.yaml
>>>>>>>   F:	drivers/w1/masters/amd_axi_w1.c
>>>>>>>   
>>>>>>>   AMD CDX BUS DRIVER
>>>>>>> +M:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
>>>>>>
>>>>>> Sorry, but no, I'm not the maintainer of this driver.  It's up to the
>>>>>> maintainer(s) of it to send me the patches on to be merged, it is not up
>>>>>> to me to maintain the code at all.
>>>>>>
>>>>> Sure, I understand. I  will send a v3 without maintainers patch and I
>>>>> assume the maintainers will pick them up (unless drivers are orphaned).
>>>>
>>>>
>>>> And now I found this:
>>>> https://lore.kernel.org/lkml/929198a2-6b3b-0f1b-3f36-cd8955ca6f19@amd.com/
>>>>
>>>> "We do not maintain a tree and  patches go via Greg's tree."
>>>>
>>>> which means that patches won't be picked up. Your email does not pop up
>>>> on b4/get_maintainers. Overall this means cdx driver might be abandoned,
>>>> from contributors point of view.
>>>
>>> We usually copy Greg once the patches are reviewed/acked from our side 
>>> if he is not already on the list. Do you suggest any alternate approach 
>>> in maintaining the drivers like cdx which do not have their own tree?
>>
>>
>> Either you have the tree or person having the tree appears on
>> maintainers output. There is no other option.
> 
> What?  No, we do this for many subsystems already.  Look at the entry
> for "USB TYPEC BUS FOR ALTERNATE MODES" as one simple example.  The
> patches go to the list, Heikki reviews them and if he says "ack" or
> "signed-off-by" then I pick them up and add them to my tree and away the
> patch goes.

You are CC-ed on these Typec alternate modes, as the subsystem
maintainer or patches-picking-up-maintainer:

*  1 Heikki Krogerus <heikki.krogerus@...ux.intel.com>
     maintainer:USB TYPEC BUS FOR ALTERNATE MODES
*  2 Greg Kroah-Hartman <gregkh@...uxfoundation.org>
     maintainer:USB SUBSYSTEM

Here, you are not Cced at all. That's why this is different.

> 
> That last bit is NOT explicitly documented in MAINTAINERS as it does not
> need to be (otherwise you will have too many lines in that file).  This
> is just one more subsystem that does it this way, not a big deal.

It is basically the only one subsystem doing that way.

Basically this looks like incomplete subsystem or a driver without
subsystem. With the different that we have many per-driver entries but
they are part of some subsystem maintainer's scope.

> 
>> If you refuse to take the patches and handle them, I claim this is
>> orphaned from the kernel point of view, even if occasionally Greg takes
>> these. I believe Greg was already pointing this issue more than once.
> 
> They are "handling" them in that they are reviewing them when they get
> the chance and then I need to then pick them up.  Again, totally normal.

I agree they are handling them. I disagree this is totally normal that
get_maintainers.pl does not point out the actual subsystem/maintainer
handling the patches.

If I remember correctly, it was Linus who said he uses
`get_maintainer.pl -f FILE/PATH`, so with his workflow he would not get
the maintainer's address (yours). One would have to go through git
history to look for SoB, but that's not normal process.

That's an exception.


Best regards,
Krzysztof