| Message ID | 20210328122621.2614283-1-gregkh@linuxfoundation.org |
|---|---|
| State | New |
| Headers | show |
| Series | [net-next] qrtr: move to staging | expand |
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
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
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
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
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
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
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
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 --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/
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%)