Re: [PATCH v17 3/3] bus: mhi: Add userspace client interface driver
Hello, Il giorno dom 13 dic 2020 alle ore 15:22 Manivannan Sadhasivam ha scritto: > > On Fri, Dec 11, 2020 at 08:08:16PM -0800, Jakub Kicinski wrote: > > On Fri, 11 Dec 2020 11:37:34 -0600 Dan Williams wrote: > > > Just to re-iterate: QMI ~= AT commands ~= MBIM (not quite, but same > > > level) > > > > > > We already do QMI-over-USB, or AT-over-CDC-ACM. This is QMI-over-MHI. > > > > Why do we need a different QMI-over-X for every X? If you say there > > are already chardev interfaces to configure WWAN why not provide one > > of those? > > > > Just because the underlying PHY is different and it offers more services than > just configuring the modem (downloading crash dump, firmware download etc...) > > The existing chardev nodes are closely tied to the physical interfaces. For > instance, /dev/cdc_wdm is used by the USB based WWAN devices. So we really > can't > reuse it for MHI/PCIe. > let me also add that the current MHI UCI approach makes sense because it makes the switch USB -> PCIe smooth, since all the current open-source userspace tools (e.g. libqmi and qmicli), according to my testing until now, properly works without any need for a change, behaving the UCI QMI char device like cdc-wdm. While a different solution (which one?) would maybe cause to re-think the userspace side for having the same high-level behavior. Thanks, Daniele > > > It's not networking data plane. It's WWAN device configuration. > > > > Ack. Not that network config doesn't fall under networking, but eh. > > I wonder - did DaveM ever ack this, or was it just out of his sight > > enough, behind the cdev, to never trigger a nack? > > > > > There are no current kernel APIs for this, and I really don't think we > > > want there to be. The API surface is *huge* and we definitely don't > > > want that in-kernel. > > > > It is what it is today for WWAN. I don't think anyone in the > > development community or among users is particularly happy about > > the situation. Which makes it rather self evident why there is > > so much apprehension about this patch set. It's going to be > > a user space channel for everything Qualcomm - AI accelerator etc. > > Widening the WWAN status quo to more device types. > > Well not everything Qualcomm but for just the subsystems where there is no > standardization right now. I think we went too far ahead for standardizing > the modems. > > Thanks, > Mani >
Re: [PATCH v17 3/3] bus: mhi: Add userspace client interface driver
On Fri, Dec 11, 2020 at 08:08:16PM -0800, Jakub Kicinski wrote: > On Fri, 11 Dec 2020 11:37:34 -0600 Dan Williams wrote: > > Just to re-iterate: QMI ~= AT commands ~= MBIM (not quite, but same > > level) > > > > We already do QMI-over-USB, or AT-over-CDC-ACM. This is QMI-over-MHI. > > Why do we need a different QMI-over-X for every X? If you say there > are already chardev interfaces to configure WWAN why not provide one > of those? > Just because the underlying PHY is different and it offers more services than just configuring the modem (downloading crash dump, firmware download etc...) The existing chardev nodes are closely tied to the physical interfaces. For instance, /dev/cdc_wdm is used by the USB based WWAN devices. So we really can't reuse it for MHI/PCIe. > > It's not networking data plane. It's WWAN device configuration. > > Ack. Not that network config doesn't fall under networking, but eh. > I wonder - did DaveM ever ack this, or was it just out of his sight > enough, behind the cdev, to never trigger a nack? > > > There are no current kernel APIs for this, and I really don't think we > > want there to be. The API surface is *huge* and we definitely don't > > want that in-kernel. > > It is what it is today for WWAN. I don't think anyone in the > development community or among users is particularly happy about > the situation. Which makes it rather self evident why there is > so much apprehension about this patch set. It's going to be > a user space channel for everything Qualcomm - AI accelerator etc. > Widening the WWAN status quo to more device types. Well not everything Qualcomm but for just the subsystems where there is no standardization right now. I think we went too far ahead for standardizing the modems. Thanks, Mani
Re: [PATCH v17 3/3] bus: mhi: Add userspace client interface driver
On Fri, 11 Dec 2020 11:37:34 -0600 Dan Williams wrote: > Just to re-iterate: QMI ~= AT commands ~= MBIM (not quite, but same > level) > > We already do QMI-over-USB, or AT-over-CDC-ACM. This is QMI-over-MHI. Why do we need a different QMI-over-X for every X? If you say there are already chardev interfaces to configure WWAN why not provide one of those? > It's not networking data plane. It's WWAN device configuration. Ack. Not that network config doesn't fall under networking, but eh. I wonder - did DaveM ever ack this, or was it just out of his sight enough, behind the cdev, to never trigger a nack? > There are no current kernel APIs for this, and I really don't think we > want there to be. The API surface is *huge* and we definitely don't > want that in-kernel. It is what it is today for WWAN. I don't think anyone in the development community or among users is particularly happy about the situation. Which makes it rather self evident why there is so much apprehension about this patch set. It's going to be a user space channel for everything Qualcomm - AI accelerator etc. Widening the WWAN status quo to more device types.
Re: [PATCH v17 3/3] bus: mhi: Add userspace client interface driver
On Fri, 2020-12-11 at 08:44 +0100, Greg KH wrote: > On Thu, Dec 10, 2020 at 11:04:11PM -0800, Hemant Kumar wrote: > > This MHI client driver allows userspace clients to transfer > > raw data between MHI device and host using standard file > > operations. > > Driver instantiates UCI device object which is associated to device > > file node. UCI device object instantiates UCI channel object when > > device > > file node is opened. UCI channel object is used to manage MHI > > channels > > by calling MHI core APIs for read and write operations. MHI > > channels > > are started as part of device open(). MHI channels remain in start > > state until last release() is called on UCI device file node. > > Device > > file node is created with format > > > > /dev/ > > > > Currently it supports QMI channel. libqmi is userspace MHI client > > which > > communicates to a QMI service using QMI channel. libqmi is a glib- > > based > > library for talking to WWAN modems and devices which speaks QMI > > protocol. > > For more information about libqmi please refer > > https://www.freedesktop.org/wiki/Software/libqmi/ > > This says _what_ this is doing, but not _why_. > > Why do you want to circumvent the normal user/kernel apis for this > type > of device and move the normal network handling logic out to > userspace? > What does that help with? What does the current in-kernel api lack > that > this userspace interface is going to solve, and why can't the in- > kernel > api solve it instead? > > You are pushing a common user/kernel api out of the kernel here, to > become very device-specific, with no apparent justification as to why > this is happening. > > Also, because you are going around the existing network api, I will > need > the networking maintainers to ack this type of patch. Just to re-iterate: QMI ~= AT commands ~= MBIM (not quite, but same level) We already do QMI-over-USB, or AT-over-CDC-ACM. This is QMI-over-MHI. It's not networking data plane. It's WWAN device configuration. There are no current kernel APIs for this, and I really don't think we want there to be. The API surface is *huge* and we definitely don't want that in-kernel. Dan
Re: [PATCH v17 3/3] bus: mhi: Add userspace client interface driver
Hi, Maybe it is a good idea to take QMI as example. QMI is QUALCOMM private protocol, maybe lots of people do not know what is QMI? MHI device can be WIFI device or WWAN device, if it is WIFI device, it is a pure network device, and maybe do not need this driver. But for WWAN devices, it support AT/NMEA/QMI/MBIM etc. protocol. And this driver is work for these functions. There are similar drivers in the kernel for WWAN devices base on USB interface. Like drivers/usb/class/cdc-wdm.c (for QMI & MBIM), and drivers/usb/serial/usb_wwan.c (for AT/NMEA) For USB WWAN devices, open source softwares libqmi/libmbim/ModemManager/LVFS want to commutate with WWAN devices via above 2 drivers. For MHI WWAN devices, these open source software also need such driver. On 11 Dec 2020 08:44:29, Greg KH wrote: > On Thu, Dec 10, 2020 at 11:04:11PM -0800, Hemant Kumar wrote: > > This MHI client driver allows userspace clients to transfer raw data > > between MHI device and host using standard file operations. > > Driver instantiates UCI device object which is associated to device > > file node. UCI device object instantiates UCI channel object when > > device file node is opened. UCI channel object is used to manage MHI > > channels by calling MHI core APIs for read and write operations. MHI > > channels are started as part of device open(). MHI channels remain in > > start state until last release() is called on UCI device file node. > > Device file node is created with format > > > > /dev/ > > > > Currently it supports QMI channel. libqmi is userspace MHI client > > which communicates to a QMI service using QMI channel. libqmi is a > > glib-based library for talking to WWAN modems and devices which speaks QMI > protocol. > > For more information about libqmi please refer > > https://www.freedesktop.org/wiki/Software/libqmi/ > > This says _what_ this is doing, but not _why_. > > Why do you want to circumvent the normal user/kernel apis for this type of > device and move the normal network handling logic out to userspace? > What does that help with? What does the current in-kernel api lack that this > userspace interface is going to solve, and why can't the in-kernel api solve > it > instead? > > You are pushing a common user/kernel api out of the kernel here, to become > very device-specific, with no apparent justification as to why this is > happening. > > Also, because you are going around the existing network api, I will need the > networking maintainers to ack this type of patch. > > thanks, > > greg k-h > > >
Re: [PATCH v17 3/3] bus: mhi: Add userspace client interface driver
On Fri, 11 Dec 2020 at 08:44, Greg KH wrote: > > On Thu, Dec 10, 2020 at 11:04:11PM -0800, Hemant Kumar wrote: > > This MHI client driver allows userspace clients to transfer > > raw data between MHI device and host using standard file operations. > > Driver instantiates UCI device object which is associated to device > > file node. UCI device object instantiates UCI channel object when device > > file node is opened. UCI channel object is used to manage MHI channels > > by calling MHI core APIs for read and write operations. MHI channels > > are started as part of device open(). MHI channels remain in start > > state until last release() is called on UCI device file node. Device > > file node is created with format > > > > /dev/ > > > > Currently it supports QMI channel. libqmi is userspace MHI client which > > communicates to a QMI service using QMI channel. libqmi is a glib-based > > library for talking to WWAN modems and devices which speaks QMI protocol. > > For more information about libqmi please refer > > https://www.freedesktop.org/wiki/Software/libqmi/ > > This says _what_ this is doing, but not _why_. > > Why do you want to circumvent the normal user/kernel apis for this type > of device and move the normal network handling logic out to userspace? > What does that help with? What does the current in-kernel api lack that > this userspace interface is going to solve, and why can't the in-kernel > api solve it instead? > > You are pushing a common user/kernel api out of the kernel here, to > become very device-specific, with no apparent justification as to why > this is happening. That would probably deserve re-wording indeed. This interface offers access to the modem control channel(s), which can be QMI (added in this patch), MBIM, or the old known AT protocol. Because there is no WWAN subsystem, these control pipes are directly exposed to userspace and accessed by tools like libqmi, ModemManager, minicom (for AT) etc... However, the data path, transporting the network payload (IP) is well routed to the Linux network via the mhi-net driver. > > Also, because you are going around the existing network api, I will need > the networking maintainers to ack this type of patch.
Re: [PATCH v17 3/3] bus: mhi: Add userspace client interface driver
Hi Greg, On Fri, Dec 11, 2020 at 08:44:29AM +0100, Greg KH wrote: > On Thu, Dec 10, 2020 at 11:04:11PM -0800, Hemant Kumar wrote: > > This MHI client driver allows userspace clients to transfer > > raw data between MHI device and host using standard file operations. > > Driver instantiates UCI device object which is associated to device > > file node. UCI device object instantiates UCI channel object when device > > file node is opened. UCI channel object is used to manage MHI channels > > by calling MHI core APIs for read and write operations. MHI channels > > are started as part of device open(). MHI channels remain in start > > state until last release() is called on UCI device file node. Device > > file node is created with format > > > > /dev/ > > > > Currently it supports QMI channel. libqmi is userspace MHI client which > > communicates to a QMI service using QMI channel. libqmi is a glib-based > > library for talking to WWAN modems and devices which speaks QMI protocol. > > For more information about libqmi please refer > > https://www.freedesktop.org/wiki/Software/libqmi/ > > This says _what_ this is doing, but not _why_. > > Why do you want to circumvent the normal user/kernel apis for this type > of device and move the normal network handling logic out to userspace? > What does that help with? What does the current in-kernel api lack that > this userspace interface is going to solve, and why can't the in-kernel > api solve it instead? > Well, this driver is not moving the network handling logic out. Instead this driver just exposes a channel which can be used to configure the modem using the existing userspace library like libqmi. Then the networking logic is handled by a separate in kernel driver called mhi-net which is queued for v5.11. This is same for most of the Qualcomm USB modems as well. They expose a chardev node like /dev/cdc_wdm0 for configuration and once configured the networking logic is handled by usual network interface wwan0. The difference here is that the underlying physical layer is PCIe and there is this MHI bus which sits on top of it. > You are pushing a common user/kernel api out of the kernel here, to > become very device-specific, with no apparent justification as to why > this is happening. > > Also, because you are going around the existing network api, I will need > the networking maintainers to ack this type of patch. > No, this driver is not at all touching the networking part. As said, the networking logic is all handled by mhi-net driver. Thanks, Mani > thanks, > > greg k-h
Re: [PATCH v17 3/3] bus: mhi: Add userspace client interface driver
On Thu, Dec 10, 2020 at 11:04:11PM -0800, Hemant Kumar wrote: > This MHI client driver allows userspace clients to transfer > raw data between MHI device and host using standard file operations. > Driver instantiates UCI device object which is associated to device > file node. UCI device object instantiates UCI channel object when device > file node is opened. UCI channel object is used to manage MHI channels > by calling MHI core APIs for read and write operations. MHI channels > are started as part of device open(). MHI channels remain in start > state until last release() is called on UCI device file node. Device > file node is created with format > > /dev/ > > Currently it supports QMI channel. libqmi is userspace MHI client which > communicates to a QMI service using QMI channel. libqmi is a glib-based > library for talking to WWAN modems and devices which speaks QMI protocol. > For more information about libqmi please refer > https://www.freedesktop.org/wiki/Software/libqmi/ This says _what_ this is doing, but not _why_. Why do you want to circumvent the normal user/kernel apis for this type of device and move the normal network handling logic out to userspace? What does that help with? What does the current in-kernel api lack that this userspace interface is going to solve, and why can't the in-kernel api solve it instead? You are pushing a common user/kernel api out of the kernel here, to become very device-specific, with no apparent justification as to why this is happening. Also, because you are going around the existing network api, I will need the networking maintainers to ack this type of patch. thanks, greg k-h
