diff mbox series

[net-next] qrtr: move to staging

Message ID 20210328122621.2614283-1-gregkh@linuxfoundation.org
State New
Headers show
Series [net-next] qrtr: move to staging | expand

Commit Message

Greg KH March 28, 2021, 12:26 p.m. UTC
There does not seem to be any developers willing to maintain the
net/qrtr/ code, so move it to drivers/staging/ so that it can be removed
from the kernel tree entirely in a few kernel releases if no one steps
up to maintain it.

Reported-by: Matthew Wilcox <willy@infradead.org>
Cc: Du Cheng <ducheng2@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/staging/Kconfig                | 2 ++
 drivers/staging/Makefile               | 1 +
 {net => drivers/staging}/qrtr/Kconfig  | 1 +
 {net => drivers/staging}/qrtr/Makefile | 0
 {net => drivers/staging}/qrtr/mhi.c    | 0
 {net => drivers/staging}/qrtr/ns.c     | 0
 {net => drivers/staging}/qrtr/qrtr.c   | 0
 {net => drivers/staging}/qrtr/qrtr.h   | 0
 {net => drivers/staging}/qrtr/smd.c    | 0
 {net => drivers/staging}/qrtr/tun.c    | 0
 net/Kconfig                            | 1 -
 net/Makefile                           | 1 -
 12 files changed, 4 insertions(+), 2 deletions(-)
 rename {net => drivers/staging}/qrtr/Kconfig (98%)
 rename {net => drivers/staging}/qrtr/Makefile (100%)
 rename {net => drivers/staging}/qrtr/mhi.c (100%)
 rename {net => drivers/staging}/qrtr/ns.c (100%)
 rename {net => drivers/staging}/qrtr/qrtr.c (100%)
 rename {net => drivers/staging}/qrtr/qrtr.h (100%)
 rename {net => drivers/staging}/qrtr/smd.c (100%)
 rename {net => drivers/staging}/qrtr/tun.c (100%)

Comments

Leon Romanovsky March 29, 2021, 5:17 a.m. UTC | #1
On Sun, Mar 28, 2021 at 02:26:21PM +0200, Greg Kroah-Hartman wrote:
> There does not seem to be any developers willing to maintain the

> net/qrtr/ code, so move it to drivers/staging/ so that it can be removed

> from the kernel tree entirely in a few kernel releases if no one steps

> up to maintain it.

> 

> Reported-by: Matthew Wilcox <willy@infradead.org>

> Cc: Du Cheng <ducheng2@gmail.com>

> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

> ---


Greg,

Why don't you simply delete it like other code that is not maintained?

Thanks
Greg KH March 29, 2021, 5:30 a.m. UTC | #2
On Mon, Mar 29, 2021 at 08:17:06AM +0300, Leon Romanovsky wrote:
> On Sun, Mar 28, 2021 at 02:26:21PM +0200, Greg Kroah-Hartman wrote:

> > There does not seem to be any developers willing to maintain the

> > net/qrtr/ code, so move it to drivers/staging/ so that it can be removed

> > from the kernel tree entirely in a few kernel releases if no one steps

> > up to maintain it.

> > 

> > Reported-by: Matthew Wilcox <willy@infradead.org>

> > Cc: Du Cheng <ducheng2@gmail.com>

> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

> > ---

> 

> Greg,

> 

> Why don't you simply delete it like other code that is not maintained?


"normally" we have been giving code a chance by having it live in
drivers/staging/ for a bit before removing it to allow anyone that
actually cares about the codebase to notice it before removing it.

We've done this for many drivers and code-chunks over the years, wimax
was one recent example.

Just trying to be nice :)

thanks,

greg k-h
Leon Romanovsky March 29, 2021, 6:30 a.m. UTC | #3
On Mon, Mar 29, 2021 at 07:30:08AM +0200, Greg Kroah-Hartman wrote:
> On Mon, Mar 29, 2021 at 08:17:06AM +0300, Leon Romanovsky wrote:

> > On Sun, Mar 28, 2021 at 02:26:21PM +0200, Greg Kroah-Hartman wrote:

> > > There does not seem to be any developers willing to maintain the

> > > net/qrtr/ code, so move it to drivers/staging/ so that it can be removed

> > > from the kernel tree entirely in a few kernel releases if no one steps

> > > up to maintain it.

> > > 

> > > Reported-by: Matthew Wilcox <willy@infradead.org>

> > > Cc: Du Cheng <ducheng2@gmail.com>

> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

> > > ---

> > 

> > Greg,

> > 

> > Why don't you simply delete it like other code that is not maintained?

> 

> "normally" we have been giving code a chance by having it live in

> drivers/staging/ for a bit before removing it to allow anyone that

> actually cares about the codebase to notice it before removing it.


I don't know about netdev view on this, but for the RDMA code, the code
in staging means _not_exist_. We took this decision after/during Lustre
fiasco. 

Thanks
Greg KH March 29, 2021, 6:41 a.m. UTC | #4
On Mon, Mar 29, 2021 at 09:30:25AM +0300, Leon Romanovsky wrote:
> On Mon, Mar 29, 2021 at 07:30:08AM +0200, Greg Kroah-Hartman wrote:

> > On Mon, Mar 29, 2021 at 08:17:06AM +0300, Leon Romanovsky wrote:

> > > On Sun, Mar 28, 2021 at 02:26:21PM +0200, Greg Kroah-Hartman wrote:

> > > > There does not seem to be any developers willing to maintain the

> > > > net/qrtr/ code, so move it to drivers/staging/ so that it can be removed

> > > > from the kernel tree entirely in a few kernel releases if no one steps

> > > > up to maintain it.

> > > > 

> > > > Reported-by: Matthew Wilcox <willy@infradead.org>

> > > > Cc: Du Cheng <ducheng2@gmail.com>

> > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

> > > > ---

> > > 

> > > Greg,

> > > 

> > > Why don't you simply delete it like other code that is not maintained?

> > 

> > "normally" we have been giving code a chance by having it live in

> > drivers/staging/ for a bit before removing it to allow anyone that

> > actually cares about the codebase to notice it before removing it.

> 

> I don't know about netdev view on this, but for the RDMA code, the code

> in staging means _not_exist_. We took this decision after/during Lustre

> fiasco. 


That's fine, each subsystem can set it's own rules for staging code.
For networking stuff, the flow-out-through-staging has been happening
for some time now.

Lustre was a different beast, that was an attempt to get code into the
kernel, not out.

thanks,

greg k-h
Manivannan Sadhasivam March 29, 2021, 10:52 a.m. UTC | #5
Hi Greg,

On Mon, Mar 29, 2021 at 11:47:12AM +0200, Loic Poulain wrote:
> Hi Greg,

> 

> On Sun, 28 Mar 2021 at 14:28, Greg Kroah-Hartman <gregkh@linuxfoundation.org>

> wrote:

> 

> > There does not seem to be any developers willing to maintain the

> > net/qrtr/ code, so move it to drivers/staging/ so that it can be removed

> > from the kernel tree entirely in a few kernel releases if no one steps

> > up to maintain it.

> >

> > Reported-by: Matthew Wilcox <willy@infradead.org>

> > Cc: Du Cheng <ducheng2@gmail.com>

> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

> >

> 

> As far as I know, QRTR/IPCR is still commonly used with Qualcomm-based

> platforms for accessing various components of the SoC.

> CCing Bjorn and Mani, In case they are interested in taking maintenance of

> that.

> 


As Loic said, QRTR is an integral component used in various Qualcomm based
upstream supported products like ChromeOS, newer WLAN chipsets (QCA6390) etc...

It is unfortunate that no one stepped up so far to maintain it. After
having an internal discussion, I decided to pitch in as a maintainer. I'll
send the MAINTAINERS change to netdev list now.

Thanks,
Mani

> Regards,

> Loic
Greg KH March 29, 2021, 11:03 a.m. UTC | #6
On Mon, Mar 29, 2021 at 04:22:36PM +0530, Manivannan Sadhasivam wrote:
> Hi Greg,

> 

> On Mon, Mar 29, 2021 at 11:47:12AM +0200, Loic Poulain wrote:

> > Hi Greg,

> > 

> > On Sun, 28 Mar 2021 at 14:28, Greg Kroah-Hartman <gregkh@linuxfoundation.org>

> > wrote:

> > 

> > > There does not seem to be any developers willing to maintain the

> > > net/qrtr/ code, so move it to drivers/staging/ so that it can be removed

> > > from the kernel tree entirely in a few kernel releases if no one steps

> > > up to maintain it.

> > >

> > > Reported-by: Matthew Wilcox <willy@infradead.org>

> > > Cc: Du Cheng <ducheng2@gmail.com>

> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

> > >

> > 

> > As far as I know, QRTR/IPCR is still commonly used with Qualcomm-based

> > platforms for accessing various components of the SoC.

> > CCing Bjorn and Mani, In case they are interested in taking maintenance of

> > that.

> > 

> 

> As Loic said, QRTR is an integral component used in various Qualcomm based

> upstream supported products like ChromeOS, newer WLAN chipsets (QCA6390) etc...

> 

> It is unfortunate that no one stepped up so far to maintain it. After

> having an internal discussion, I decided to pitch in as a maintainer. I'll

> send the MAINTAINERS change to netdev list now.


Great, can you also fix up the reported problems with the codebase that
resulted in this "ask for removal"?

thanks,

greg k-h
Manivannan Sadhasivam March 29, 2021, 11:07 a.m. UTC | #7
On Mon, Mar 29, 2021 at 01:03:24PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Mar 29, 2021 at 04:22:36PM +0530, Manivannan Sadhasivam wrote:

> > Hi Greg,

> > 

> > On Mon, Mar 29, 2021 at 11:47:12AM +0200, Loic Poulain wrote:

> > > Hi Greg,

> > > 

> > > On Sun, 28 Mar 2021 at 14:28, Greg Kroah-Hartman <gregkh@linuxfoundation.org>

> > > wrote:

> > > 

> > > > There does not seem to be any developers willing to maintain the

> > > > net/qrtr/ code, so move it to drivers/staging/ so that it can be removed

> > > > from the kernel tree entirely in a few kernel releases if no one steps

> > > > up to maintain it.

> > > >

> > > > Reported-by: Matthew Wilcox <willy@infradead.org>

> > > > Cc: Du Cheng <ducheng2@gmail.com>

> > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

> > > >

> > > 

> > > As far as I know, QRTR/IPCR is still commonly used with Qualcomm-based

> > > platforms for accessing various components of the SoC.

> > > CCing Bjorn and Mani, In case they are interested in taking maintenance of

> > > that.

> > > 

> > 

> > As Loic said, QRTR is an integral component used in various Qualcomm based

> > upstream supported products like ChromeOS, newer WLAN chipsets (QCA6390) etc...

> > 

> > It is unfortunate that no one stepped up so far to maintain it. After

> > having an internal discussion, I decided to pitch in as a maintainer. I'll

> > send the MAINTAINERS change to netdev list now.

> 

> Great, can you also fix up the reported problems with the codebase that

> resulted in this "ask for removal"?

> 


Yes, ofc. I do see couple of Syzbot bug reports now... I will look into them.
It turned out I fixed one of them earlier but should've handled all :)

Thanks,
Mani

> thanks,

> 

> greg k-h
Matthew Wilcox March 29, 2021, 11:30 a.m. UTC | #8
On Mon, Mar 29, 2021 at 04:37:41PM +0530, Manivannan Sadhasivam wrote:
> On Mon, Mar 29, 2021 at 01:03:24PM +0200, Greg Kroah-Hartman wrote:

> > On Mon, Mar 29, 2021 at 04:22:36PM +0530, Manivannan Sadhasivam wrote:

> > > Hi Greg,

> > > 

> > > On Mon, Mar 29, 2021 at 11:47:12AM +0200, Loic Poulain wrote:

> > > > Hi Greg,

> > > > 

> > > > On Sun, 28 Mar 2021 at 14:28, Greg Kroah-Hartman <gregkh@linuxfoundation.org>

> > > > wrote:

> > > > 

> > > > > There does not seem to be any developers willing to maintain the

> > > > > net/qrtr/ code, so move it to drivers/staging/ so that it can be removed

> > > > > from the kernel tree entirely in a few kernel releases if no one steps

> > > > > up to maintain it.

> > > > >

> > > > > Reported-by: Matthew Wilcox <willy@infradead.org>

> > > > > Cc: Du Cheng <ducheng2@gmail.com>

> > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

> > > > >

> > > > 

> > > > As far as I know, QRTR/IPCR is still commonly used with Qualcomm-based

> > > > platforms for accessing various components of the SoC.

> > > > CCing Bjorn and Mani, In case they are interested in taking maintenance of

> > > > that.

> > > > 

> > > 

> > > As Loic said, QRTR is an integral component used in various Qualcomm based

> > > upstream supported products like ChromeOS, newer WLAN chipsets (QCA6390) etc...

> > > 

> > > It is unfortunate that no one stepped up so far to maintain it. After

> > > having an internal discussion, I decided to pitch in as a maintainer. I'll

> > > send the MAINTAINERS change to netdev list now.

> > 

> > Great, can you also fix up the reported problems with the codebase that

> > resulted in this "ask for removal"?

> > 

> 

> Yes, ofc. I do see couple of Syzbot bug reports now... I will look into them.

> It turned out I fixed one of them earlier but should've handled all :)


From my point of view, the important patch to get applied is this one:

https://lore.kernel.org/netdev/20200605120037.17427-1-willy@infradead.org/
diff mbox series

Patch

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 6e798229fe25..43ab47e7861c 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -112,4 +112,6 @@  source "drivers/staging/wfx/Kconfig"
 
 source "drivers/staging/hikey9xx/Kconfig"
 
+source "drivers/staging/qrtr/Kconfig"
+
 endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 8d4d9812ecdf..0b7ae2a72954 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -45,4 +45,5 @@  obj-$(CONFIG_KPC2000)		+= kpc2000/
 obj-$(CONFIG_QLGE)		+= qlge/
 obj-$(CONFIG_WIMAX)		+= wimax/
 obj-$(CONFIG_WFX)		+= wfx/
+obj-$(CONFIG_QRTR)		+= qrtr/
 obj-y				+= hikey9xx/
diff --git a/net/qrtr/Kconfig b/drivers/staging/qrtr/Kconfig
similarity index 98%
rename from net/qrtr/Kconfig
rename to drivers/staging/qrtr/Kconfig
index b4020b84760f..e91825f01307 100644
--- a/net/qrtr/Kconfig
+++ b/drivers/staging/qrtr/Kconfig
@@ -4,6 +4,7 @@ 
 
 config QRTR
 	tristate "Qualcomm IPC Router support"
+	depends on NET
 	help
 	  Say Y if you intend to use Qualcomm IPC router protocol.  The
 	  protocol is used to communicate with services provided by other
diff --git a/net/qrtr/Makefile b/drivers/staging/qrtr/Makefile
similarity index 100%
rename from net/qrtr/Makefile
rename to drivers/staging/qrtr/Makefile
diff --git a/net/qrtr/mhi.c b/drivers/staging/qrtr/mhi.c
similarity index 100%
rename from net/qrtr/mhi.c
rename to drivers/staging/qrtr/mhi.c
diff --git a/net/qrtr/ns.c b/drivers/staging/qrtr/ns.c
similarity index 100%
rename from net/qrtr/ns.c
rename to drivers/staging/qrtr/ns.c
diff --git a/net/qrtr/qrtr.c b/drivers/staging/qrtr/qrtr.c
similarity index 100%
rename from net/qrtr/qrtr.c
rename to drivers/staging/qrtr/qrtr.c
diff --git a/net/qrtr/qrtr.h b/drivers/staging/qrtr/qrtr.h
similarity index 100%
rename from net/qrtr/qrtr.h
rename to drivers/staging/qrtr/qrtr.h
diff --git a/net/qrtr/smd.c b/drivers/staging/qrtr/smd.c
similarity index 100%
rename from net/qrtr/smd.c
rename to drivers/staging/qrtr/smd.c
diff --git a/net/qrtr/tun.c b/drivers/staging/qrtr/tun.c
similarity index 100%
rename from net/qrtr/tun.c
rename to drivers/staging/qrtr/tun.c
diff --git a/net/Kconfig b/net/Kconfig
index 9c456acc379e..09f14caf3f45 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -242,7 +242,6 @@  source "net/nsh/Kconfig"
 source "net/hsr/Kconfig"
 source "net/switchdev/Kconfig"
 source "net/l3mdev/Kconfig"
-source "net/qrtr/Kconfig"
 source "net/ncsi/Kconfig"
 
 config PCPU_DEV_REFCNT
diff --git a/net/Makefile b/net/Makefile
index 9ca9572188fe..5d57e972a33b 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -74,7 +74,6 @@  obj-$(CONFIG_NET_NSH)		+= nsh/
 obj-$(CONFIG_HSR)		+= hsr/
 obj-$(CONFIG_NET_SWITCHDEV)	+= switchdev/
 obj-$(CONFIG_NET_L3_MASTER_DEV)	+= l3mdev/
-obj-$(CONFIG_QRTR)		+= qrtr/
 obj-$(CONFIG_NET_NCSI)		+= ncsi/
 obj-$(CONFIG_XDP_SOCKETS)	+= xdp/
 obj-$(CONFIG_MPTCP)		+= mptcp/