Message-ID: <06015c8a-2dbe-bc5f-4b8e-2ee87ee5910c@ti.com>
Date:   Fri, 19 Aug 2022 12:27:57 +0530
From:   Kishon Vijay Abraham I <kishon@...com>
To:     Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
        Jon Mason <jdmason@...zu.us>
CC:     <ntb@...ts.linux.dev>, Bjorn Helgaas <helgaas@...nel.org>,
        <Frank.Li@....com>, <linux-pci@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] MAINTAINERS: add PCI Endpoint NTB drivers to NTB files



On 18/08/22 20:21, Manivannan Sadhasivam wrote:
> On Thu, Aug 18, 2022 at 09:52:03AM -0400, Jon Mason wrote:
>> On Thu, Aug 18, 2022 at 11:32:30AM +0530, Manivannan Sadhasivam wrote:
>>> + Kishon (PCI EP Maintainer)
>>>
>>> On Fri, Aug 12, 2022 at 03:42:05PM -0400, Jon Mason wrote:
>>>> The PCI Endpoint NTB drivers are under the NTB umbrella.  Add an entry
>>>> there to allow for notification of changes for it.
>>>>
>>>> Signed-off-by: Jon Mason <jdmason@...zu.us>
>>>
>>> Hi Jason,
>>
>> I assume you mean me.  Odd that you got my name wrong 2 lines below it
>> being properly written out.
>>
> 
> Terribly sorry about that! I was reading another thread just before this
> and misspelled your name.
> 
>>> I know that this patch is already in Linus's tree but I think this PCI Endpoint
>>> VNTB driver is not going in a correct path. First, Kishon is not convinced with
>>> the way the PCI Endpoint VNTB function driver is written currently. He prefers
>>> the VirtIO approach over the current one [1].
>>
>> To your point, this is already in Linus' tree.  If it is not the way
>> people want it, patches accepted.
>>
>> Kishon (in the thread) recommended doing it one way, and Frank
>> responded he liked doing it another.  Kishon didn't respond to that
>> last email.  To me, this is an acceptable technical disagreement that
>> can be addressed in the future and no need to prevent working patches
>> from being accepted.
>>
> 
> Kishon being the maintainer proposed an entirely different way of representing
> the driver. I agree that the patch is working but maintainer's view matters and
> if you don't hear from the maintainer for some time, you'll ping them (Frank
> did ping but there is something called RESEND).
> 
> I'm not sure that merging the patches without an ACK from the relevant subsystem
> maintainer is the right thing to do.
> 
>>> But while the conversation was still going on, the series got merged via NTB
>>> tree without any ACKs from the PCI/PCI_EP maintainers. Also, note that there
>>> was a patch touching the PCI Controller driver as well and that was also not
>>> ACKed [2].
>>
>> I put the series in my ntb-next branch, which was pulled into linux-next
>> for roughly 3 months, and he did not object then (though likely he did
>> not notice).  Multiple patches were submitted to the relevant mailing
>> lists to address minor issues in the series (from being in linux-next)
>> and most/all of those hit the PCI mailing list.  Bjorn responded to
>> all of them saying they needed to go through the ntb tree (because of
>> the dependency on Frank Li's original series).  So while not an
>> explicit ack, it was implicit to me in that he was aware of the
>> series.
Definitely take the blame for not registering my objection though I felt
I might be the odd one out for proposing a different way and rest are in
alignment to get it merged.

>>
>> Given the length of time and the public work on the series, how much
>> longer should I have waited for a nack?
>>
> 
> I'd argue that you should've waited for the ACK first. I've seen and
> experienced patch series hanging there for multiple releases. I'm not in favour
> of not responding to the patches, maintainers do have their own work to do but
> merging the patches touching the different subsystem without an ACK doesn't
> sound good to me.
> 
> I don't know why he didn't object when the series got merged in this manner :/
> 
>>> If this trend is going to continue in the coming days, then I'm afraid that NTB
>>> might end up being a backdoor for PCI/PCI_EP patches :(
>>
>> Completely unfounded, per Bjorn's comment on
>> https://lore.kernel.org/all/20220815183920.GA1960006@bhelgaas/
>>
> 

> It's now fine that NTB related PCI patches can be merged through NTB tree but
> please wait for an ACK for patches touching the non-NTB drivers. If you ask me
> how long you should wait, then I don't have an answer, but atleast give a
> notice before doing so that it can catch the proper eyes.

+1

Thanks,
Kishon

> 
> Thanks,
> Mani
> 
>> Thanks,
>> Jon
>>
>>>
>>> Thanks,
>>> Mani
>>>
>>> [1] https://lore.kernel.org/all/20220222162355.32369-4-Frank.Li@nxp.com
>>> [2] https://lore.kernel.org/all/20220222162355.32369-2-Frank.Li@nxp.com
>>>
>>>> ---
>>>>  MAINTAINERS | 1 +
>>>>  1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>> index 64379c699903..47e9f86bd712 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -14254,6 +14254,7 @@ W:	https://github.com/jonmason/ntb/wiki
>>>>  T:	git git://github.com/jonmason/ntb.git
>>>>  F:	drivers/net/ntb_netdev.c
>>>>  F:	drivers/ntb/
>>>> +F:	drivers/pci/endpoint/functions/pci-epf-*ntb.c
>>>>  F:	include/linux/ntb.h
>>>>  F:	include/linux/ntb_transport.h
>>>>  F:	tools/testing/selftests/ntb/
>>>> -- 
>>>> 2.30.2
>>>>
>>>
>>> -- 
>>> மணிவண்ணன் சதாசிவம்
> 

Powered by blists - more mailing lists