diff mbox series

MAINTAINERS: add PCI Endpoint NTB drivers to NTB files

Message ID 20220812194205.388967-1-jdmason@kudzu.us (mailing list archive)
State Accepted
Commit e4fe2a2fc423cb51bfd36c14f95f3ca1d279ca92
Headers show
Series MAINTAINERS: add PCI Endpoint NTB drivers to NTB files | expand

Commit Message

Jon Mason Aug. 12, 2022, 7:42 p.m. UTC
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>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

Comments

Bjorn Helgaas Aug. 12, 2022, 7:49 p.m. UTC | #1
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>

FWIW,

Acked-by: Bjorn Helgaas <bhelgaas@google.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
>
Manivannan Sadhasivam Aug. 18, 2022, 6:02 a.m. UTC | #2
+ 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 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].

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

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

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
>
Jon Mason Aug. 18, 2022, 1:52 p.m. UTC | #3
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.

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

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

Given the length of time and the public work on the series, how much
longer should I have waited for a nack?

> 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/

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
> > 
> 
> -- 
> மணிவண்ணன் சதாசிவம்
Manivannan Sadhasivam Aug. 18, 2022, 2:51 p.m. UTC | #4
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.
> 
> 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.

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
> > > 
> > 
> > -- 
> > மணிவண்ணன் சதாசிவம்
Kishon Vijay Abraham I Aug. 19, 2022, 6:57 a.m. UTC | #5
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
>>>>
>>>
>>> -- 
>>> மணிவண்ணன் சதாசிவம்
>
diff mbox series

Patch

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/