lkml.org 
[lkml]   [2022]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] MAINTAINERS: add PCI Endpoint NTB drivers to NTB files
From


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@kudzu.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
>>>>
>>>
>>> --
>>> மணிவண்ணன் சதாசிவம்
>

\
 
 \ /
  Last update: 2022-08-19 08:59    [W:0.077 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site