From: Kishon Vijay Abraham I <kishon@ti.com>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
Jon Mason <jdmason@kudzu.us>
Cc: <ntb@lists.linux.dev>, Bjorn Helgaas <helgaas@kernel.org>,
<Frank.Li@nxp.com>, <linux-pci@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] MAINTAINERS: add PCI Endpoint NTB drivers to NTB files
Date: Fri, 19 Aug 2022 12:27:57 +0530 [thread overview]
Message-ID: <06015c8a-2dbe-bc5f-4b8e-2ee87ee5910c@ti.com> (raw)
In-Reply-To: <20220818145115.GA111116@thinkpad>
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
>>>>
>>>
>>> --
>>> மணிவண்ணன் சதாசிவம்
>
prev parent reply other threads:[~2022-08-19 8:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-12 19:42 [PATCH] MAINTAINERS: add PCI Endpoint NTB drivers to NTB files Jon Mason
2022-08-12 19:49 ` Bjorn Helgaas
2022-08-18 6:02 ` Manivannan Sadhasivam
2022-08-18 13:52 ` Jon Mason
2022-08-18 14:51 ` Manivannan Sadhasivam
2022-08-19 6:57 ` Kishon Vijay Abraham I [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=06015c8a-2dbe-bc5f-4b8e-2ee87ee5910c@ti.com \
--to=kishon@ti.com \
--cc=Frank.Li@nxp.com \
--cc=helgaas@kernel.org \
--cc=jdmason@kudzu.us \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=ntb@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).