| Message ID | 20200213091427.13435-1-manivannan.sadhasivam@linaro.org |
|---|---|
| Headers | show |
| Series | Migrate QRTR Nameservice to Kernel | expand |
On Thu, 2020-02-13 at 14:44 +0530, Manivannan Sadhasivam wrote: > Hello, > > This patchset migrates the Qualcomm IPC Router (QRTR) Nameservice > from userspace > to kernel under net/qrtr. > > The userspace implementation of it can be found here: > https://github.com/andersson/qrtr/blob/master/src/ns.c > > This change is required for enabling the WiFi functionality of some > Qualcomm > WLAN devices using ATH11K without any dependency on a userspace > daemon. Just out of curiousity, what's the motivation for not requiring a userspace daemon? What are the downsides of the current userspace daemon implementation? Dan > The original userspace code is published under BSD3 license. For > migrating it > to Linux kernel, I have adapted Dual BSD/GPL license. > > This patchset has been verified on Dragonboard410c and Intel NUC with > QCA6390 > WLAN device. > > Thanks, > Mani > > Manivannan Sadhasivam (2): > net: qrtr: Migrate nameservice to kernel from userspace > net: qrtr: Fix the local node ID as 1 > > net/qrtr/Makefile | 2 +- > net/qrtr/ns.c | 730 > ++++++++++++++++++++++++++++++++++++++++++++++ > net/qrtr/qrtr.c | 51 +--- > net/qrtr/qrtr.h | 4 + > 4 files changed, 746 insertions(+), 41 deletions(-) > create mode 100644 net/qrtr/ns.c >
Hi Dan, On Thu, Feb 13, 2020 at 09:22:39AM -0600, Dan Williams wrote: > On Thu, 2020-02-13 at 14:44 +0530, Manivannan Sadhasivam wrote: > > Hello, > > > > This patchset migrates the Qualcomm IPC Router (QRTR) Nameservice > > from userspace > > to kernel under net/qrtr. > > > > The userspace implementation of it can be found here: > > https://github.com/andersson/qrtr/blob/master/src/ns.c > > > > This change is required for enabling the WiFi functionality of some > > Qualcomm > > WLAN devices using ATH11K without any dependency on a userspace > > daemon. > > Just out of curiousity, what's the motivation for not requiring a > userspace daemon? What are the downsides of the current userspace > daemon implementation? > The primary motivation is to eliminate the need for installing and starting a userspace tool for the basic WiFi usage. This will be critical for the Qualcomm WLAN devices deployed in x86 laptops. Also, there are some plans to implement QRTR link negotiation based on this in future. Thanks, Mani > Dan > > > The original userspace code is published under BSD3 license. For > > migrating it > > to Linux kernel, I have adapted Dual BSD/GPL license. > > > > This patchset has been verified on Dragonboard410c and Intel NUC with > > QCA6390 > > WLAN device. > > > > Thanks, > > Mani > > > > Manivannan Sadhasivam (2): > > net: qrtr: Migrate nameservice to kernel from userspace > > net: qrtr: Fix the local node ID as 1 > > > > net/qrtr/Makefile | 2 +- > > net/qrtr/ns.c | 730 > > ++++++++++++++++++++++++++++++++++++++++++++++ > > net/qrtr/qrtr.c | 51 +--- > > net/qrtr/qrtr.h | 4 + > > 4 files changed, 746 insertions(+), 41 deletions(-) > > create mode 100644 net/qrtr/ns.c > > >
From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Date: Thu, 13 Feb 2020 21:00:08 +0530 > The primary motivation is to eliminate the need for installing and starting > a userspace tool for the basic WiFi usage. This will be critical for the > Qualcomm WLAN devices deployed in x86 laptops. I can't even remember it ever being the case that wifi would come up without the help of a userspace component of some sort to initiate the scan and choose and AP to associate with. And from that perspective your argument doesn't seem valid at all.
+ Kalle Valo On Thu, Feb 13, 2020 at 07:47:55AM -0800, David Miller wrote: > From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > Date: Thu, 13 Feb 2020 21:00:08 +0530 > > > The primary motivation is to eliminate the need for installing and starting > > a userspace tool for the basic WiFi usage. This will be critical for the > > Qualcomm WLAN devices deployed in x86 laptops. > > I can't even remember it ever being the case that wifi would come up without > the help of a userspace component of some sort to initiate the scan and choose > and AP to associate with. > > And from that perspective your argument doesn't seem valid at all. Kalle has some information to share. Thanks, Mani
Hi Dave, On Thu, Feb 13, 2020 at 07:47:55AM -0800, David Miller wrote: > From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > Date: Thu, 13 Feb 2020 21:00:08 +0530 > > > The primary motivation is to eliminate the need for installing and starting > > a userspace tool for the basic WiFi usage. This will be critical for the > > Qualcomm WLAN devices deployed in x86 laptops. > > I can't even remember it ever being the case that wifi would come up without > the help of a userspace component of some sort to initiate the scan and choose > and AP to associate with. > > And from that perspective your argument doesn't seem valid at all. For the WiFi yes, but I should have added that this QRTR nameservice is being used by modems, DSPs and some other co-processors for some offloading tasks. So currently, they all depend on userspace ns tool for working. So migrating it to kernel can benefit them all. Sorry that I should've made it clear in the commit message. Thanks, Mani
+ linux-wireless Hi Dave & Dan, Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> writes: > On Thu, Feb 13, 2020 at 07:47:55AM -0800, David Miller wrote: >> From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> >> Date: Thu, 13 Feb 2020 21:00:08 +0530 >> >> > The primary motivation is to eliminate the need for installing and starting >> > a userspace tool for the basic WiFi usage. This will be critical for the >> > Qualcomm WLAN devices deployed in x86 laptops. >> >> I can't even remember it ever being the case that wifi would come up without >> the help of a userspace component of some sort to initiate the scan and choose >> and AP to associate with. >> >> And from that perspective your argument doesn't seem valid at all. > > For the WiFi yes, but I should have added that this QRTR nameservice is being > used by modems, DSPs and some other co-processors for some offloading tasks. > So currently, they all depend on userspace ns tool for working. So migrating > it to kernel can benefit them all. So the background of this is to get QCA6390[1] (a Qualcomm Wi-Fi 6 PCI device) supported in ath11k without additional dependencies to user space. Currently Bjorn's QRTR user space daemon[2] needs to be running for ath11k to even be able to boot the firmware on the device. In my opinion a wireless driver should be "self contained", meaning that it should be enough just to update the kernel and install the firmware images to /lib/firmware and nothing else should be needed. But without Mani's patches a user with QCA6390 on her laptop would need to fetch and install the QRTR daemon (as I doubt distros have it pre-installed) before getting Wi-Fi working on the laptop. But without Wi-Fi trying to fetch anything from the internet is annoying, so not a very smooth user experience. I assume Dave above refers to iw, wpasupplicant and hostapd but I consider them very different from QRTR. iw, wpasupplicant and hostapd are generic wireless user space components using the generic nl80211/wext interfaces and they work with _all_ upstream drivers. They are also pre-installed by distros so it's basically plug and go for the user to get Wi-Fi running. Also from high level design point of view I don't like the idea that wireless drivers would start to having vendor specific user components, like Qualcomm, Marvell, Intel and other vendors having their own daemons running in addition of generic wireless components (iw/wpas/hostapd). That would be a quite mess trying to handle backwards compatibility and all other stable kernel/user space interface requirements. So to have a smooth out of box experience for ath11k users, I consider that we need QRTR in the kernel and that's why need Mani's patches[3]. [1] https://www.qualcomm.com/products/fastconnect-6800 [2] https://github.com/andersson/qrtr/ [3] https://patchwork.ozlabs.org/cover/1237353/ https://patchwork.ozlabs.org/patch/1237355/ https://patchwork.ozlabs.org/patch/1237354/