| Message ID | 1609958656-15064-1-git-send-email-hemantk@codeaurora.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | userspace MHI client interface driver | expand |
Hi Greg, On Wed, Jan 06, 2021 at 10:44:13AM -0800, Hemant Kumar wrote: > This patch series adds support for UCI driver. UCI driver enables userspace > clients to communicate to external MHI devices like modem. UCI driver probe > creates standard character device file nodes for userspace clients to > perform open, read, write, poll and release file operations. These file > operations call MHI core layer APIs to perform data transfer using MHI bus > to communicate with MHI device. > > This interface allows exposing modem control channel(s) such as QMI, MBIM, > or AT commands to userspace which can be used to configure the modem using > tools such as libqmi, ModemManager, minicom (for AT), etc over MHI. This is > required as there are no kernel APIs to access modem control path for device > configuration. Data path transporting the network payload (IP), however, is > routed to the Linux network via the mhi-net driver. Currently driver supports > QMI channel. libqmi is userspace MHI client which communicates to a QMI > service using QMI channel. Please refer to > https://www.freedesktop.org/wiki/Software/libqmi/ for additional information > on libqmi. > > Patch is tested using arm64 and x86 based platform. > This series looks good to me and I'd like to merge it into mhi-next. You shared your reviews on the previous revisions, so I'd like to get your opinion first. Thanks, Mani > V18: > - Updated commit text for UCI to clarify why this driver is required for QMI > over MHI. Also updated cover letter with same information. > > v17: > - Updated commit text for UCI driver by mentioning about libqmi open-source > userspace program that will be talking to this UCI kernel driver. > - UCI driver depends upon patch "bus: mhi: core: Add helper API to return number > of free TREs". > > v16: > - Removed reference of WLAN as an external MHI device in documentation and > cover letter. > > v15: > - Updated documentation related to poll and release operations. > > V14: > - Fixed device file node format to /dev/<mhi_dev_name> instead of > /dev/mhi_<mhi_dev_name> because "mhi" is already part of mhi device name. > For example old format: /dev/mhi_mhi0_QMI new format: /dev/mhi0_QMI. > - Updated MHI documentation to reflect index mhi controller name in > QMI usage example. > > V13: > - Removed LOOPBACK channel from mhi_device_id table from this patch series. > Pushing a new patch series to add support for LOOPBACK channel and the user > space test application. Also removed the description from kernel documentation. > - Added QMI channel to mhi_device_id table. QMI channel has existing libqmi > support from user space. > - Updated kernel Documentation for QMI channel and provided external reference > for libqmi. > - Updated device file node name by appending mhi device name only, which already > includes mhi controller device name. > > V12: > - Added loopback test driver under selftest/drivers/mhi. Updated kernel > documentation for the usage of the loopback test application. > - Addressed review comments for renaming variable names, updated inline > comments and removed two redundant dev_dbg. > > V11: > - Fixed review comments for UCI documentation by expanding TLAs and rewording > some sentences. > > V10: > - Replaced mutex_lock with mutex_lock_interruptible in read() and write() file > ops call back. > > V9: > - Renamed dl_lock to dl_pending _lock and pending list to dl_pending for > clarity. > - Used read lock to protect cur_buf. > - Change transfer status check logic and only consider 0 and -EOVERFLOW as > only success. > - Added __int to module init function. > - Print channel name instead of minor number upon successful probe. > > V8: > - Fixed kernel test robot compilation error by changing %lu to %zu for > size_t. > - Replaced uci with UCI in Kconfig, commit text, and comments in driver > code. > - Fixed minor style related comments. > > V7: > - Decoupled uci device and uci channel objects. uci device is > associated with device file node. uci channel is associated > with MHI channels. uci device refers to uci channel to perform > MHI channel operations for device file operations like read() > and write(). uci device increments its reference count for > every open(). uci device calls mhi_uci_dev_start_chan() to start > the MHI channel. uci channel object is tracking number of times > MHI channel is referred. This allows to keep the MHI channel in > start state until last release() is called. After that uci channel > reference count goes to 0 and uci channel clean up is performed > which stops the MHI channel. After the last call to release() if > driver is removed uci reference count becomes 0 and uci object is > cleaned up. > - Use separate uci channel read and write lock to fine grain locking > between reader and writer. > - Use uci device lock to synchronize open, release and driver remove. > - Optimize for downlink only or uplink only UCI device. > > V6: > - Moved uci.c to mhi directory. > - Updated Kconfig to add module information. > - Updated Makefile to rename uci object file name as mhi_uci > - Removed kref for open count > > V5: > - Removed mhi_uci_drv structure. > - Used idr instead of creating global list of uci devices. > - Used kref instead of local ref counting for uci device and > open count. > - Removed unlikely macro. > > V4: > - Fix locking to protect proper struct members. > - Updated documentation describing uci client driver use cases. > - Fixed uci ref counting in mhi_uci_open for error case. > - Addressed style related review comments. > > V3: Added documentation for MHI UCI driver. > > V2: > - Added mutex lock to prevent multiple readers to access same > - mhi buffer which can result into use after free. > > Hemant Kumar (3): > bus: mhi: core: Move MHI_MAX_MTU to external header file > docs: Add documentation for userspace client interface > bus: mhi: Add userspace client interface driver > > Documentation/mhi/index.rst | 1 + > Documentation/mhi/uci.rst | 95 ++++++ > drivers/bus/mhi/Kconfig | 13 + > drivers/bus/mhi/Makefile | 3 + > drivers/bus/mhi/core/internal.h | 1 - > drivers/bus/mhi/uci.c | 664 ++++++++++++++++++++++++++++++++++++++++ > include/linux/mhi.h | 3 + > 7 files changed, 779 insertions(+), 1 deletion(-) > create mode 100644 Documentation/mhi/uci.rst > create mode 100644 drivers/bus/mhi/uci.c > > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project >
Hi Greg, On Wed, Jan 13, 2021 at 08:56:25PM +0530, Manivannan Sadhasivam wrote: > Hi Greg, > > On Wed, Jan 06, 2021 at 10:44:13AM -0800, Hemant Kumar wrote: > > This patch series adds support for UCI driver. UCI driver enables userspace > > clients to communicate to external MHI devices like modem. UCI driver probe > > creates standard character device file nodes for userspace clients to > > perform open, read, write, poll and release file operations. These file > > operations call MHI core layer APIs to perform data transfer using MHI bus > > to communicate with MHI device. > > > > This interface allows exposing modem control channel(s) such as QMI, MBIM, > > or AT commands to userspace which can be used to configure the modem using > > tools such as libqmi, ModemManager, minicom (for AT), etc over MHI. This is > > required as there are no kernel APIs to access modem control path for device > > configuration. Data path transporting the network payload (IP), however, is > > routed to the Linux network via the mhi-net driver. Currently driver supports > > QMI channel. libqmi is userspace MHI client which communicates to a QMI > > service using QMI channel. Please refer to > > https://www.freedesktop.org/wiki/Software/libqmi/ for additional information > > on libqmi. > > > > Patch is tested using arm64 and x86 based platform. > > > > This series looks good to me and I'd like to merge it into mhi-next. You > shared your reviews on the previous revisions, so I'd like to get your > opinion first. > Ping! Thanks, Mani > Thanks, > Mani > > > V18: > > - Updated commit text for UCI to clarify why this driver is required for QMI > > over MHI. Also updated cover letter with same information. > > > > v17: > > - Updated commit text for UCI driver by mentioning about libqmi open-source > > userspace program that will be talking to this UCI kernel driver. > > - UCI driver depends upon patch "bus: mhi: core: Add helper API to return number > > of free TREs". > > > > v16: > > - Removed reference of WLAN as an external MHI device in documentation and > > cover letter. > > > > v15: > > - Updated documentation related to poll and release operations. > > > > V14: > > - Fixed device file node format to /dev/<mhi_dev_name> instead of > > /dev/mhi_<mhi_dev_name> because "mhi" is already part of mhi device name. > > For example old format: /dev/mhi_mhi0_QMI new format: /dev/mhi0_QMI. > > - Updated MHI documentation to reflect index mhi controller name in > > QMI usage example. > > > > V13: > > - Removed LOOPBACK channel from mhi_device_id table from this patch series. > > Pushing a new patch series to add support for LOOPBACK channel and the user > > space test application. Also removed the description from kernel documentation. > > - Added QMI channel to mhi_device_id table. QMI channel has existing libqmi > > support from user space. > > - Updated kernel Documentation for QMI channel and provided external reference > > for libqmi. > > - Updated device file node name by appending mhi device name only, which already > > includes mhi controller device name. > > > > V12: > > - Added loopback test driver under selftest/drivers/mhi. Updated kernel > > documentation for the usage of the loopback test application. > > - Addressed review comments for renaming variable names, updated inline > > comments and removed two redundant dev_dbg. > > > > V11: > > - Fixed review comments for UCI documentation by expanding TLAs and rewording > > some sentences. > > > > V10: > > - Replaced mutex_lock with mutex_lock_interruptible in read() and write() file > > ops call back. > > > > V9: > > - Renamed dl_lock to dl_pending _lock and pending list to dl_pending for > > clarity. > > - Used read lock to protect cur_buf. > > - Change transfer status check logic and only consider 0 and -EOVERFLOW as > > only success. > > - Added __int to module init function. > > - Print channel name instead of minor number upon successful probe. > > > > V8: > > - Fixed kernel test robot compilation error by changing %lu to %zu for > > size_t. > > - Replaced uci with UCI in Kconfig, commit text, and comments in driver > > code. > > - Fixed minor style related comments. > > > > V7: > > - Decoupled uci device and uci channel objects. uci device is > > associated with device file node. uci channel is associated > > with MHI channels. uci device refers to uci channel to perform > > MHI channel operations for device file operations like read() > > and write(). uci device increments its reference count for > > every open(). uci device calls mhi_uci_dev_start_chan() to start > > the MHI channel. uci channel object is tracking number of times > > MHI channel is referred. This allows to keep the MHI channel in > > start state until last release() is called. After that uci channel > > reference count goes to 0 and uci channel clean up is performed > > which stops the MHI channel. After the last call to release() if > > driver is removed uci reference count becomes 0 and uci object is > > cleaned up. > > - Use separate uci channel read and write lock to fine grain locking > > between reader and writer. > > - Use uci device lock to synchronize open, release and driver remove. > > - Optimize for downlink only or uplink only UCI device. > > > > V6: > > - Moved uci.c to mhi directory. > > - Updated Kconfig to add module information. > > - Updated Makefile to rename uci object file name as mhi_uci > > - Removed kref for open count > > > > V5: > > - Removed mhi_uci_drv structure. > > - Used idr instead of creating global list of uci devices. > > - Used kref instead of local ref counting for uci device and > > open count. > > - Removed unlikely macro. > > > > V4: > > - Fix locking to protect proper struct members. > > - Updated documentation describing uci client driver use cases. > > - Fixed uci ref counting in mhi_uci_open for error case. > > - Addressed style related review comments. > > > > V3: Added documentation for MHI UCI driver. > > > > V2: > > - Added mutex lock to prevent multiple readers to access same > > - mhi buffer which can result into use after free. > > > > Hemant Kumar (3): > > bus: mhi: core: Move MHI_MAX_MTU to external header file > > docs: Add documentation for userspace client interface > > bus: mhi: Add userspace client interface driver > > > > Documentation/mhi/index.rst | 1 + > > Documentation/mhi/uci.rst | 95 ++++++ > > drivers/bus/mhi/Kconfig | 13 + > > drivers/bus/mhi/Makefile | 3 + > > drivers/bus/mhi/core/internal.h | 1 - > > drivers/bus/mhi/uci.c | 664 ++++++++++++++++++++++++++++++++++++++++ > > include/linux/mhi.h | 3 + > > 7 files changed, 779 insertions(+), 1 deletion(-) > > create mode 100644 Documentation/mhi/uci.rst > > create mode 100644 drivers/bus/mhi/uci.c > > > > -- > > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > > a Linux Foundation Collaborative Project > >
On Tue, Jan 19, 2021 at 03:12:50PM +0530, Manivannan Sadhasivam wrote: > Hi Greg, > > On Wed, Jan 13, 2021 at 08:56:25PM +0530, Manivannan Sadhasivam wrote: > > Hi Greg, > > > > On Wed, Jan 06, 2021 at 10:44:13AM -0800, Hemant Kumar wrote: > > > This patch series adds support for UCI driver. UCI driver enables userspace > > > clients to communicate to external MHI devices like modem. UCI driver probe > > > creates standard character device file nodes for userspace clients to > > > perform open, read, write, poll and release file operations. These file > > > operations call MHI core layer APIs to perform data transfer using MHI bus > > > to communicate with MHI device. > > > > > > This interface allows exposing modem control channel(s) such as QMI, MBIM, > > > or AT commands to userspace which can be used to configure the modem using > > > tools such as libqmi, ModemManager, minicom (for AT), etc over MHI. This is > > > required as there are no kernel APIs to access modem control path for device > > > configuration. Data path transporting the network payload (IP), however, is > > > routed to the Linux network via the mhi-net driver. Currently driver supports > > > QMI channel. libqmi is userspace MHI client which communicates to a QMI > > > service using QMI channel. Please refer to > > > https://www.freedesktop.org/wiki/Software/libqmi/ for additional information > > > on libqmi. > > > > > > Patch is tested using arm64 and x86 based platform. > > > > > > > This series looks good to me and I'd like to merge it into mhi-next. You > > shared your reviews on the previous revisions, so I'd like to get your > > opinion first. > > > > Ping! Sorry, it's in my to-review queue, buried with other stuff at the moment, but it's not lost... greg k-h
On Wed, Jan 13, 2021 at 08:56:25PM +0530, Manivannan Sadhasivam wrote: > Hi Greg, > > On Wed, Jan 06, 2021 at 10:44:13AM -0800, Hemant Kumar wrote: > > This patch series adds support for UCI driver. UCI driver enables userspace > > clients to communicate to external MHI devices like modem. UCI driver probe > > creates standard character device file nodes for userspace clients to > > perform open, read, write, poll and release file operations. These file > > operations call MHI core layer APIs to perform data transfer using MHI bus > > to communicate with MHI device. > > > > This interface allows exposing modem control channel(s) such as QMI, MBIM, > > or AT commands to userspace which can be used to configure the modem using > > tools such as libqmi, ModemManager, minicom (for AT), etc over MHI. This is > > required as there are no kernel APIs to access modem control path for device > > configuration. Data path transporting the network payload (IP), however, is > > routed to the Linux network via the mhi-net driver. Currently driver supports > > QMI channel. libqmi is userspace MHI client which communicates to a QMI > > service using QMI channel. Please refer to > > https://www.freedesktop.org/wiki/Software/libqmi/ for additional information > > on libqmi. > > > > Patch is tested using arm64 and x86 based platform. > > > > This series looks good to me and I'd like to merge it into mhi-next. You > shared your reviews on the previous revisions, so I'd like to get your > opinion first. If you get the networking people to give you an ack on this, it's fine with me. thanks, greg k-h
On Wed 27 Jan 09:15 CST 2021, Greg KH wrote: > On Wed, Jan 13, 2021 at 08:56:25PM +0530, Manivannan Sadhasivam wrote: > > Hi Greg, > > > > On Wed, Jan 06, 2021 at 10:44:13AM -0800, Hemant Kumar wrote: > > > This patch series adds support for UCI driver. UCI driver enables userspace > > > clients to communicate to external MHI devices like modem. UCI driver probe > > > creates standard character device file nodes for userspace clients to > > > perform open, read, write, poll and release file operations. These file > > > operations call MHI core layer APIs to perform data transfer using MHI bus > > > to communicate with MHI device. > > > > > > This interface allows exposing modem control channel(s) such as QMI, MBIM, > > > or AT commands to userspace which can be used to configure the modem using > > > tools such as libqmi, ModemManager, minicom (for AT), etc over MHI. This is > > > required as there are no kernel APIs to access modem control path for device > > > configuration. Data path transporting the network payload (IP), however, is > > > routed to the Linux network via the mhi-net driver. Currently driver supports > > > QMI channel. libqmi is userspace MHI client which communicates to a QMI > > > service using QMI channel. Please refer to > > > https://www.freedesktop.org/wiki/Software/libqmi/ for additional information > > > on libqmi. > > > > > > Patch is tested using arm64 and x86 based platform. > > > > > > > This series looks good to me and I'd like to merge it into mhi-next. You > > shared your reviews on the previous revisions, so I'd like to get your > > opinion first. > > If you get the networking people to give you an ack on this, it's fine > with me. > Why? As concluded in previous iterations of this series this does not relate to networking. Regards, Bjorn
Hi Greg, On Wed, Jan 27, 2021 at 04:15:42PM +0100, Greg KH wrote: > On Wed, Jan 13, 2021 at 08:56:25PM +0530, Manivannan Sadhasivam wrote: > > Hi Greg, > > > > On Wed, Jan 06, 2021 at 10:44:13AM -0800, Hemant Kumar wrote: > > > This patch series adds support for UCI driver. UCI driver enables userspace > > > clients to communicate to external MHI devices like modem. UCI driver probe > > > creates standard character device file nodes for userspace clients to > > > perform open, read, write, poll and release file operations. These file > > > operations call MHI core layer APIs to perform data transfer using MHI bus > > > to communicate with MHI device. > > > > > > This interface allows exposing modem control channel(s) such as QMI, MBIM, > > > or AT commands to userspace which can be used to configure the modem using > > > tools such as libqmi, ModemManager, minicom (for AT), etc over MHI. This is > > > required as there are no kernel APIs to access modem control path for device > > > configuration. Data path transporting the network payload (IP), however, is > > > routed to the Linux network via the mhi-net driver. Currently driver supports > > > QMI channel. libqmi is userspace MHI client which communicates to a QMI > > > service using QMI channel. Please refer to > > > https://www.freedesktop.org/wiki/Software/libqmi/ for additional information > > > on libqmi. > > > > > > Patch is tested using arm64 and x86 based platform. > > > > > > > This series looks good to me and I'd like to merge it into mhi-next. You > > shared your reviews on the previous revisions, so I'd like to get your > > opinion first. > > If you get the networking people to give you an ack on this, it's fine > with me. > As discussed in previous iteration, this series is not belonging to networking subsystem. The functionality provided by this series allows us to configure the modem over MHI bus and the rest of the networking stuff happens over the networking subsystem as usual. This holds the same with USB and serial modems which we are having over decades in mainline. Thanks, Mani > thanks, > > greg k-h
On Mon, Feb 01, 2021 at 04:25:49PM +0530, Manivannan Sadhasivam wrote: > Hi Greg, > > On Wed, Jan 27, 2021 at 04:15:42PM +0100, Greg KH wrote: > > On Wed, Jan 13, 2021 at 08:56:25PM +0530, Manivannan Sadhasivam wrote: > > > Hi Greg, > > > > > > On Wed, Jan 06, 2021 at 10:44:13AM -0800, Hemant Kumar wrote: > > > > This patch series adds support for UCI driver. UCI driver enables userspace > > > > clients to communicate to external MHI devices like modem. UCI driver probe > > > > creates standard character device file nodes for userspace clients to > > > > perform open, read, write, poll and release file operations. These file > > > > operations call MHI core layer APIs to perform data transfer using MHI bus > > > > to communicate with MHI device. > > > > > > > > This interface allows exposing modem control channel(s) such as QMI, MBIM, > > > > or AT commands to userspace which can be used to configure the modem using > > > > tools such as libqmi, ModemManager, minicom (for AT), etc over MHI. This is > > > > required as there are no kernel APIs to access modem control path for device > > > > configuration. Data path transporting the network payload (IP), however, is > > > > routed to the Linux network via the mhi-net driver. Currently driver supports > > > > QMI channel. libqmi is userspace MHI client which communicates to a QMI > > > > service using QMI channel. Please refer to > > > > https://www.freedesktop.org/wiki/Software/libqmi/ for additional information > > > > on libqmi. > > > > > > > > Patch is tested using arm64 and x86 based platform. > > > > > > > > > > This series looks good to me and I'd like to merge it into mhi-next. You > > > shared your reviews on the previous revisions, so I'd like to get your > > > opinion first. > > > > If you get the networking people to give you an ack on this, it's fine > > with me. > > > > As discussed in previous iteration, this series is not belonging to networking > subsystem. The functionality provided by this series allows us to configure the > modem over MHI bus and the rest of the networking stuff happens over the > networking subsystem as usual. Great, then it should be easy to get their acceptance :) > This holds the same with USB and serial modems which we are having over decades > in mainline. I don't see the connection here, sorry. thanks, greg k-h
On Mon, Feb 01, 2021 at 12:15:51PM +0100, Greg KH wrote: > On Mon, Feb 01, 2021 at 04:25:49PM +0530, Manivannan Sadhasivam wrote: > > Hi Greg, > > > > On Wed, Jan 27, 2021 at 04:15:42PM +0100, Greg KH wrote: > > > On Wed, Jan 13, 2021 at 08:56:25PM +0530, Manivannan Sadhasivam wrote: > > > > Hi Greg, > > > > > > > > On Wed, Jan 06, 2021 at 10:44:13AM -0800, Hemant Kumar wrote: > > > > > This patch series adds support for UCI driver. UCI driver enables userspace > > > > > clients to communicate to external MHI devices like modem. UCI driver probe > > > > > creates standard character device file nodes for userspace clients to > > > > > perform open, read, write, poll and release file operations. These file > > > > > operations call MHI core layer APIs to perform data transfer using MHI bus > > > > > to communicate with MHI device. > > > > > > > > > > This interface allows exposing modem control channel(s) such as QMI, MBIM, > > > > > or AT commands to userspace which can be used to configure the modem using > > > > > tools such as libqmi, ModemManager, minicom (for AT), etc over MHI. This is > > > > > required as there are no kernel APIs to access modem control path for device > > > > > configuration. Data path transporting the network payload (IP), however, is > > > > > routed to the Linux network via the mhi-net driver. Currently driver supports > > > > > QMI channel. libqmi is userspace MHI client which communicates to a QMI > > > > > service using QMI channel. Please refer to > > > > > https://www.freedesktop.org/wiki/Software/libqmi/ for additional information > > > > > on libqmi. > > > > > > > > > > Patch is tested using arm64 and x86 based platform. > > > > > > > > > > > > > This series looks good to me and I'd like to merge it into mhi-next. You > > > > shared your reviews on the previous revisions, so I'd like to get your > > > > opinion first. > > > > > > If you get the networking people to give you an ack on this, it's fine > > > with me. > > > > > > > As discussed in previous iteration, this series is not belonging to networking > > subsystem. The functionality provided by this series allows us to configure the > > modem over MHI bus and the rest of the networking stuff happens over the > > networking subsystem as usual. > > Great, then it should be easy to get their acceptance :) > > > This holds the same with USB and serial modems which we are having over decades > > in mainline. > > I don't see the connection here, sorry. > For instance USB_NET_CDC_MBIM driver creates the /dev/cdc-wdmX chardev node for configuring the modems which supports MBIM protocol over USB. Like that, this driver creates /dev/mhiX_MBIM chardev node for configuring the modem over MHI bus instead of USB. The question arised why we are creating a chardev node for each supported configuration (channels in the case of MHI) and why can't we use the existing /dev/cdc-wdmZ interfaces? The anwser is there is no standard subsystem for WWAN and all the drivers represent a chardev which gets used by the userspace tools such a Network manager for establishing connection. And /dev/cdc-wdmX is restricted to the USB CDC devices. Hope this clarifies! Thanks, Mani > thanks, > > greg k-h
+ Jakub, Dave On Mon, Feb 01, 2021 at 05:43:22PM +0530, Manivannan Sadhasivam wrote: > On Mon, Feb 01, 2021 at 12:15:51PM +0100, Greg KH wrote: > > On Mon, Feb 01, 2021 at 04:25:49PM +0530, Manivannan Sadhasivam wrote: > > > Hi Greg, > > > > > > On Wed, Jan 27, 2021 at 04:15:42PM +0100, Greg KH wrote: > > > > On Wed, Jan 13, 2021 at 08:56:25PM +0530, Manivannan Sadhasivam wrote: > > > > > Hi Greg, > > > > > > > > > > On Wed, Jan 06, 2021 at 10:44:13AM -0800, Hemant Kumar wrote: > > > > > > This patch series adds support for UCI driver. UCI driver enables userspace > > > > > > clients to communicate to external MHI devices like modem. UCI driver probe > > > > > > creates standard character device file nodes for userspace clients to > > > > > > perform open, read, write, poll and release file operations. These file > > > > > > operations call MHI core layer APIs to perform data transfer using MHI bus > > > > > > to communicate with MHI device. > > > > > > > > > > > > This interface allows exposing modem control channel(s) such as QMI, MBIM, > > > > > > or AT commands to userspace which can be used to configure the modem using > > > > > > tools such as libqmi, ModemManager, minicom (for AT), etc over MHI. This is > > > > > > required as there are no kernel APIs to access modem control path for device > > > > > > configuration. Data path transporting the network payload (IP), however, is > > > > > > routed to the Linux network via the mhi-net driver. Currently driver supports > > > > > > QMI channel. libqmi is userspace MHI client which communicates to a QMI > > > > > > service using QMI channel. Please refer to > > > > > > https://www.freedesktop.org/wiki/Software/libqmi/ for additional information > > > > > > on libqmi. > > > > > > > > > > > > Patch is tested using arm64 and x86 based platform. > > > > > > > > > > > > > > > > This series looks good to me and I'd like to merge it into mhi-next. You > > > > > shared your reviews on the previous revisions, so I'd like to get your > > > > > opinion first. > > > > > > > > If you get the networking people to give you an ack on this, it's fine > > > > with me. > > > > > > > > > > As discussed in previous iteration, this series is not belonging to networking > > > subsystem. The functionality provided by this series allows us to configure the > > > modem over MHI bus and the rest of the networking stuff happens over the > > > networking subsystem as usual. > > > > Great, then it should be easy to get their acceptance :) > > > > > This holds the same with USB and serial modems which we are having over decades > > > in mainline. > > > > I don't see the connection here, sorry. > > > > For instance USB_NET_CDC_MBIM driver creates the /dev/cdc-wdmX chardev node for > configuring the modems which supports MBIM protocol over USB. Like that, this > driver creates /dev/mhiX_MBIM chardev node for configuring the modem over MHI > bus instead of USB. The question arised why we are creating a chardev node for > each supported configuration (channels in the case of MHI) and why can't we use > the existing /dev/cdc-wdmZ interfaces? The anwser is there is no standard > subsystem for WWAN and all the drivers represent a chardev which gets used by > the userspace tools such a Network manager for establishing connection. > > And /dev/cdc-wdmX is restricted to the USB CDC devices. > > Hope this clarifies! > Jakub, Dave, Adding you both to get your reviews on this series. I've provided an explanation above and in the previous iteration [1]. Thanks, Mani [1] https://lkml.org/lkml/2020/12/12/16 > Thanks, > Mani > > > thanks, > > > > greg k-h
On Tue, 2 Feb 2021 09:52:08 +0530 Manivannan Sadhasivam wrote: > > > I don't see the connection here, sorry. > > > > For instance USB_NET_CDC_MBIM driver creates the /dev/cdc-wdmX chardev node for > > configuring the modems which supports MBIM protocol over USB. Like that, this > > driver creates /dev/mhiX_MBIM chardev node for configuring the modem over MHI > > bus instead of USB. The question arised why we are creating a chardev node for > > each supported configuration (channels in the case of MHI) and why can't we use > > the existing /dev/cdc-wdmZ interfaces? The anwser is there is no standard > > subsystem for WWAN and all the drivers represent a chardev which gets used by > > the userspace tools such a Network manager for establishing connection. > > > > And /dev/cdc-wdmX is restricted to the USB CDC devices. > > > > Hope this clarifies! > > Jakub, Dave, Adding you both to get your reviews on this series. I've > provided an explanation above and in the previous iteration [1]. Let's be clear what the review would be for. Yet another QMI chardev or the "UCI" direct generic user space to firmware pipe?
Hi Jakub, On 3 February 2021 9:40:08 AM IST, Jakub Kicinski <kuba@kernel.org> wrote: >On Tue, 2 Feb 2021 09:52:08 +0530 Manivannan Sadhasivam wrote: >> > > I don't see the connection here, sorry. >> > >> > For instance USB_NET_CDC_MBIM driver creates the /dev/cdc-wdmX >chardev node for >> > configuring the modems which supports MBIM protocol over USB. Like >that, this >> > driver creates /dev/mhiX_MBIM chardev node for configuring the >modem over MHI >> > bus instead of USB. The question arised why we are creating a >chardev node for >> > each supported configuration (channels in the case of MHI) and why >can't we use >> > the existing /dev/cdc-wdmZ interfaces? The anwser is there is no >standard >> > subsystem for WWAN and all the drivers represent a chardev which >gets used by >> > the userspace tools such a Network manager for establishing >connection. >> > >> > And /dev/cdc-wdmX is restricted to the USB CDC devices. >> > >> > Hope this clarifies! >> >> Jakub, Dave, Adding you both to get your reviews on this series. I've >> provided an explanation above and in the previous iteration [1]. > >Let's be clear what the review would be for. Yet another QMI chardev >or the "UCI" direct generic user space to firmware pipe? The current patchset only supports QMI channel so I'd request you to review the chardev node created for it. The QMI chardev node created will be unique for the MHI bus and the number of nodes depends on the MHI controllers in the system (typically 1 but not limited). Thanks, Mani
On Wed, 03 Feb 2021 09:45:06 +0530 Manivannan Sadhasivam wrote: > >> Jakub, Dave, Adding you both to get your reviews on this series. I've > >> provided an explanation above and in the previous iteration [1]. > > > >Let's be clear what the review would be for. Yet another QMI chardev > >or the "UCI" direct generic user space to firmware pipe? > > The current patchset only supports QMI channel so I'd request you to > review the chardev node created for it. The QMI chardev node created > will be unique for the MHI bus and the number of nodes depends on the > MHI controllers in the system (typically 1 but not limited). If you want to add a MHI QMI driver, please write a QMI-only driver. This generic "userspace client interface" driver is a no go. Nobody will have the time and attention to police what you throw in there later.
Hi Jakub, On Wed, 3 Feb 2021 at 19:05, Jakub Kicinski <kuba@kernel.org> wrote: > > On Wed, 03 Feb 2021 09:45:06 +0530 Manivannan Sadhasivam wrote: > > >> Jakub, Dave, Adding you both to get your reviews on this series. I've > > >> provided an explanation above and in the previous iteration [1]. > > > > > >Let's be clear what the review would be for. Yet another QMI chardev > > >or the "UCI" direct generic user space to firmware pipe? > > > > The current patchset only supports QMI channel so I'd request you to > > review the chardev node created for it. The QMI chardev node created > > will be unique for the MHI bus and the number of nodes depends on the > > MHI controllers in the system (typically 1 but not limited). > > If you want to add a MHI QMI driver, please write a QMI-only driver. > This generic "userspace client interface" driver is a no go. Nobody will > have the time and attention to police what you throw in there later. Think it should be seen as filtered userspace access to MHI bus (filtered because not all channels are exposed), again it's not specific to MHI, any bus in Linux offers that (i2c, spi, usb, serial, etc...). It will not be specific to QMI, since we will also need it for MBIM (modem control path), AT commands, and GPS (NMEA frames), all these protocols are usually handled by userspace tools and not linked to any internal Linux framework, so it would be better not having a dedicated chardev for each of them. Regards, Loic
On Wed 03 Feb 12:05 CST 2021, Jakub Kicinski wrote: > On Wed, 03 Feb 2021 09:45:06 +0530 Manivannan Sadhasivam wrote: > > >> Jakub, Dave, Adding you both to get your reviews on this series. I've > > >> provided an explanation above and in the previous iteration [1]. > > > > > >Let's be clear what the review would be for. Yet another QMI chardev > > >or the "UCI" direct generic user space to firmware pipe? > > > > The current patchset only supports QMI channel so I'd request you to > > review the chardev node created for it. The QMI chardev node created > > will be unique for the MHI bus and the number of nodes depends on the > > MHI controllers in the system (typically 1 but not limited). > > If you want to add a MHI QMI driver, please write a QMI-only driver. But said QMI driver would be identical to what is proposed here, given that the libqmi [1] communicates in the raw messages of the given MHI channel. Should I then propose another copy of the same driver for transporting debug messages between [2] and the modem? And a third copy to support firmware flashing using [3]. [1] https://www.freedesktop.org/wiki/Software/libqmi/ [2] https://github.com/andersson/diag [3] https://github.com/andersson/qdl > This generic "userspace client interface" driver is a no go. Nobody will > have the time and attention to police what you throw in there later. PCI devices implementing this must have a MHI controller driver, which explicitly needs to specify which logical channels should be exposed to userspace using the UCI driver. So in contrast to things like USBFS or the tty layer - which is used to implement "network devices" today - there is a natural point of policing this. Regards, Bjorn
On Wed, 3 Feb 2021 19:28:28 +0100 Loic Poulain wrote: > On Wed, 3 Feb 2021 at 19:05, Jakub Kicinski <kuba@kernel.org> wrote: > > On Wed, 03 Feb 2021 09:45:06 +0530 Manivannan Sadhasivam wrote: > > > The current patchset only supports QMI channel so I'd request you to > > > review the chardev node created for it. The QMI chardev node created > > > will be unique for the MHI bus and the number of nodes depends on the > > > MHI controllers in the system (typically 1 but not limited). > > > > If you want to add a MHI QMI driver, please write a QMI-only driver. > > This generic "userspace client interface" driver is a no go. Nobody will > > have the time and attention to police what you throw in there later. > > Think it should be seen as filtered userspace access to MHI bus > (filtered because not all channels are exposed), again it's not > specific to MHI, any bus in Linux offers that (i2c, spi, usb, serial, > etc...). It will not be specific to QMI, since we will also need it > for MBIM (modem control path), AT commands, and GPS (NMEA frames), all > these protocols are usually handled by userspace tools and not linked > to any internal Linux framework, so it would be better not having a > dedicated chardev for each of them. The more people argue for this backdoor interface the more distrustful of it we'll become. Keep going at your own peril.
On Wed, Feb 03, 2021 at 10:40:28AM -0800, Jakub Kicinski wrote: > On Wed, 3 Feb 2021 19:28:28 +0100 Loic Poulain wrote: > > On Wed, 3 Feb 2021 at 19:05, Jakub Kicinski <kuba@kernel.org> wrote: > > > On Wed, 03 Feb 2021 09:45:06 +0530 Manivannan Sadhasivam wrote: > > > > The current patchset only supports QMI channel so I'd request you to > > > > review the chardev node created for it. The QMI chardev node created > > > > will be unique for the MHI bus and the number of nodes depends on the > > > > MHI controllers in the system (typically 1 but not limited). > > > > > > If you want to add a MHI QMI driver, please write a QMI-only driver. > > > This generic "userspace client interface" driver is a no go. Nobody will > > > have the time and attention to police what you throw in there later. > > > > Think it should be seen as filtered userspace access to MHI bus > > (filtered because not all channels are exposed), again it's not > > specific to MHI, any bus in Linux offers that (i2c, spi, usb, serial, > > etc...). It will not be specific to QMI, since we will also need it > > for MBIM (modem control path), AT commands, and GPS (NMEA frames), all > > these protocols are usually handled by userspace tools and not linked > > to any internal Linux framework, so it would be better not having a > > dedicated chardev for each of them. > > The more people argue for this backdoor interface the more distrustful > of it we'll become. Keep going at your own peril. Sorry, I do not want this to go towards rant... But I don't think this is anyway near a backdoor interface. There are userspace tools available to evaluate the chardev node and whatever this driver supports and going to support in the future is part of the Qualcomm modems. The fact that we can't add a separate driver for MHI QMI is due to the code duplication as the underlying interface is same it is just the channel which differs. And I got your point in doing everything in the chardev'ish way here. But we don't have any standard mechanism (QMI, MBIM, firmware/crash dump download). And lot of people argued that we are too far away from creating a WWAN subsystem. And the usecase we are dealing here is specific to Qualcomm. So IMO we should go ahead with the current interface this driver offers. Thanks, Mani
On Wed 03 Feb 12:40 CST 2021, Jakub Kicinski wrote: > On Wed, 3 Feb 2021 19:28:28 +0100 Loic Poulain wrote: > > On Wed, 3 Feb 2021 at 19:05, Jakub Kicinski <kuba@kernel.org> wrote: > > > On Wed, 03 Feb 2021 09:45:06 +0530 Manivannan Sadhasivam wrote: > > > > The current patchset only supports QMI channel so I'd request you to > > > > review the chardev node created for it. The QMI chardev node created > > > > will be unique for the MHI bus and the number of nodes depends on the > > > > MHI controllers in the system (typically 1 but not limited). > > > > > > If you want to add a MHI QMI driver, please write a QMI-only driver. > > > This generic "userspace client interface" driver is a no go. Nobody will > > > have the time and attention to police what you throw in there later. > > > > Think it should be seen as filtered userspace access to MHI bus > > (filtered because not all channels are exposed), again it's not > > specific to MHI, any bus in Linux offers that (i2c, spi, usb, serial, > > etc...). It will not be specific to QMI, since we will also need it > > for MBIM (modem control path), AT commands, and GPS (NMEA frames), all > > these protocols are usually handled by userspace tools and not linked > > to any internal Linux framework, so it would be better not having a > > dedicated chardev for each of them. > > The more people argue for this backdoor interface the more distrustful > of it we'll become. Keep going at your own peril. With things such as USBDEVFS, UIO, spi-dev and i2c-dev already exposing various forms of hardware directly to userspace in an identical fashion, can you please explain why you believe this would be inappropriate for MHI devices? Thanks, Bjorn
Hey Jakub On Wed, Feb 3, 2021 at 7:41 PM Jakub Kicinski <kuba@kernel.org> wrote: > > On Wed, 3 Feb 2021 19:28:28 +0100 Loic Poulain wrote: > > On Wed, 3 Feb 2021 at 19:05, Jakub Kicinski <kuba@kernel.org> wrote: > > > On Wed, 03 Feb 2021 09:45:06 +0530 Manivannan Sadhasivam wrote: > > > > The current patchset only supports QMI channel so I'd request you to > > > > review the chardev node created for it. The QMI chardev node created > > > > will be unique for the MHI bus and the number of nodes depends on the > > > > MHI controllers in the system (typically 1 but not limited). > > > > > > If you want to add a MHI QMI driver, please write a QMI-only driver. > > > This generic "userspace client interface" driver is a no go. Nobody will > > > have the time and attention to police what you throw in there later. > > > > Think it should be seen as filtered userspace access to MHI bus > > (filtered because not all channels are exposed), again it's not > > specific to MHI, any bus in Linux offers that (i2c, spi, usb, serial, > > etc...). It will not be specific to QMI, since we will also need it > > for MBIM (modem control path), AT commands, and GPS (NMEA frames), all > > these protocols are usually handled by userspace tools and not linked > > to any internal Linux framework, so it would be better not having a > > dedicated chardev for each of them. > > The more people argue for this backdoor interface the more distrustful > of it we'll become. Keep going at your own peril. Are your worries that this driver will end up being used for many more things than the initial wwan control port management being suggested here? If so, what would be the suggested alternative for this integration? Just a different way to access those control ports instead of a chardev? A per port type specific driver? This may be a stupid suggestion, but would the integration look less a backdoor if it would have been named "mhi_wwan" and it exposed already all the AT+DIAG+QMI+MBIM+NMEA possible channels as chardevs, not just QMI?
On Tue, 9 Feb 2021 10:20:30 +0100 Aleksander Morgado wrote: > This may be a stupid suggestion, but would the integration look less a > backdoor if it would have been named "mhi_wwan" and it exposed already > all the AT+DIAG+QMI+MBIM+NMEA possible channels as chardevs, not just > QMI? What's DIAG? Who's going to remember that this is a backdoor driver a year from now when Qualcomm sends a one liner patches which just adds a single ID to open another channel?
Hey, > On Tue, 9 Feb 2021 10:20:30 +0100 Aleksander Morgado wrote: > > This may be a stupid suggestion, but would the integration look less a > > backdoor if it would have been named "mhi_wwan" and it exposed already > > all the AT+DIAG+QMI+MBIM+NMEA possible channels as chardevs, not just > > QMI? > > What's DIAG? DIAG/QCDM is an older protocol in Qualcomm based modems; in USB based devices we would get a TTY that speaks this protocol. In legacy CDMA modems this was required for actual device control (and ModemManager has a libqcdm for that https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/tree/master/libqcdm) but in all newest modems I'd say this is exclusively used for modem trace retrieval (e.g. asking the modem to enable some internal traces of the LTE stack which are downloaded in the host via this port). When debugging issues with manufacturers, this is what they would ask you to do, use this port to retrieve these traces (e.g. Quectel's QLog program does that, each manufacturer keeps its own). > Who's going to remember that this is a backdoor driver > a year from now when Qualcomm sends a one liner patches which just > adds a single ID to open another channel? I'm obviously not going to argue about that possibility; although, wouldn't it make more sense to discuss that whenever that happens? This work is implemented in a very generic way probably, but it focuses on WWAN control ports, which is what we need in userspace. Right now this mhi_uci integration can be used for QMI control of the modems, and I assume once that gets merged (if ever!), more patches would arrive to enable AT, DIAG and MBIM control ports. The channels associated to these WWAN control protocols have clearly defined channel ids, and I believe the device itself chooses which channels are exposed, so a device may e.g. say that it's going to expose only the MBIM control port. This is also very manufacturer dependent I think; I know for example that WWAN modules for laptops will probably want to expose the MBIM channel instead of QMI, so that the same HW integration is used in both Linux and Windows easily. The single and generic mhi_uci integration for all these different WWAN control ports would allow any of those combinations, very much like with USB devices and different USB configurations. Userspace is also ready for this integration, btw; at least libmbim and libqmi don't have any problem with these chardevs, and ModemManager has a branch ready to land to support this new integration. A lot of new laptops that are already being sold since last year come now with PCIe-only WWAN modules, and unfortunately I've also seen different manufacturers pushing their own out-of-tree variants of this same mhi_uci idea with better or worse luck. I personally was very glad to see this work moving forward. -- Aleksander
On Tue, Feb 09, 2021 at 08:17:44AM -0800, Jakub Kicinski wrote: > On Tue, 9 Feb 2021 10:20:30 +0100 Aleksander Morgado wrote: > > This may be a stupid suggestion, but would the integration look less a > > backdoor if it would have been named "mhi_wwan" and it exposed already > > all the AT+DIAG+QMI+MBIM+NMEA possible channels as chardevs, not just > > QMI? > > What's DIAG? Who's going to remember that this is a backdoor driver > a year from now when Qualcomm sends a one liner patches which just > adds a single ID to open another channel? I really appreciate your feedback on this driver eventhough I'm not inclined with you calling this driver a "backdoor interface". But can you please propose a solution on how to make this driver a good one as per your thoughts? I really don't know what bothers you even if the userspace tools making use of these chardevs are available openly (you can do the audit and see if anything wrong we are doing). And exposing the raw access to the hardware is not a new thing in kernel. There are several existing subsystems/drivers does this as pointed out by Bjorn. Moreover we don't have in-kernel APIs for the functionalities exposed by this driver and creating one is not feasible as explained by many. So please let us know the path forward on this series. We are open to any suggestions but you haven't provided one till now. Thanks, Mani
On Wed, 10 Feb 2021 11:55:31 +0530 Manivannan Sadhasivam wrote: > On Tue, Feb 09, 2021 at 08:17:44AM -0800, Jakub Kicinski wrote: > > On Tue, 9 Feb 2021 10:20:30 +0100 Aleksander Morgado wrote: > > > This may be a stupid suggestion, but would the integration look less a > > > backdoor if it would have been named "mhi_wwan" and it exposed already > > > all the AT+DIAG+QMI+MBIM+NMEA possible channels as chardevs, not just > > > QMI? > > > > What's DIAG? Who's going to remember that this is a backdoor driver > > a year from now when Qualcomm sends a one liner patches which just > > adds a single ID to open another channel? > > I really appreciate your feedback on this driver eventhough I'm not > inclined with you calling this driver a "backdoor interface". But can > you please propose a solution on how to make this driver a good one as > per your thoughts? > > I really don't know what bothers you even if the userspace tools making > use of these chardevs are available openly (you can do the audit and see > if anything wrong we are doing). What bothers me is maintaining shim drivers which just shuttle opaque messages between user space and firmware. One of which definitely is, and the other may well be, proprietary. This is an open source project, users are supposed to be able to meaningfully change the behavior of the system. What bothers me is that we have 3 WWAN vendors all doing their own thing and no common Linux API for WWAN. It may have been fine 10 years ago, but WWAN is increasingly complex and important. > And exposing the raw access to the > hardware is not a new thing in kernel. There are several existing > subsystems/drivers does this as pointed out by Bjorn. Moreover we don't > have in-kernel APIs for the functionalities exposed by this driver and > creating one is not feasible as explained by many. > > So please let us know the path forward on this series. We are open to > any suggestions but you haven't provided one till now. Well. You sure know how to aggravate people. I said clearly that you can move forward on purpose build drivers (e.g. for WWAN). There is no way forward on this common shim driver as far as I'm concerned.
On 2/10/2021 11:41 AM, Jakub Kicinski wrote: > On Wed, 10 Feb 2021 11:55:31 +0530 Manivannan Sadhasivam wrote: >> On Tue, Feb 09, 2021 at 08:17:44AM -0800, Jakub Kicinski wrote: >>> On Tue, 9 Feb 2021 10:20:30 +0100 Aleksander Morgado wrote: >>>> This may be a stupid suggestion, but would the integration look less a >>>> backdoor if it would have been named "mhi_wwan" and it exposed already >>>> all the AT+DIAG+QMI+MBIM+NMEA possible channels as chardevs, not just >>>> QMI? >>> >>> What's DIAG? Who's going to remember that this is a backdoor driver >>> a year from now when Qualcomm sends a one liner patches which just >>> adds a single ID to open another channel? >> >> I really appreciate your feedback on this driver eventhough I'm not >> inclined with you calling this driver a "backdoor interface". But can >> you please propose a solution on how to make this driver a good one as >> per your thoughts? >> >> I really don't know what bothers you even if the userspace tools making >> use of these chardevs are available openly (you can do the audit and see >> if anything wrong we are doing). > > What bothers me is maintaining shim drivers which just shuttle opaque > messages between user space and firmware. One of which definitely is, > and the other may well be, proprietary. This is an open source project, > users are supposed to be able to meaningfully change the behavior of > the system. Interesting. So, based on that, the TCP/IP stack is going to be ripped out of Linux? I can write a proprietary userspace application which uses the TCP/IP stack to shuttle opaque messages through the kernel to a remote system, which could be running Windows (a proprietary OS with typically proprietary applications). I've infact done that in another life. Proprietary talking to proprietary with the Linux kernel in the middle. I suspect you'll have an aggressively different opinion, but at this simplified level, it's really no different from the proposed mhi_uci driver here, or any of the numerous other examples provided. The Linux kernel does not get to say everything must be open. There is an explicit license stating that - LICENSES/exceptions/Linux-syscall-note Yes, it's ideal if things are open, but it seems contradictory to espouse wanting choice, but then denying certain choices. Frankly, folks have pointed out open source applications that wish to use this, so no, it's not all closed. Put another way, you keep going in circles (I know you've argued the same for others in the discussion) - why is this specifically different from the other "shim drivers" which "shuttle proprietary messages" which already exist and are maintained in Linus' tree today? All I'm seeing is "I don't like it" which is not a technical reason, and "proprietary is bad" which frankly, I think the horses were let out of the barn back in 1991 when Linus first created Linux. > > What bothers me is that we have 3 WWAN vendors all doing their own > thing and no common Linux API for WWAN. It may have been fine 10 years > ago, but WWAN is increasingly complex and important. > >> And exposing the raw access to the >> hardware is not a new thing in kernel. There are several existing >> subsystems/drivers does this as pointed out by Bjorn. Moreover we don't >> have in-kernel APIs for the functionalities exposed by this driver and >> creating one is not feasible as explained by many. >> >> So please let us know the path forward on this series. We are open to >> any suggestions but you haven't provided one till now. > > Well. You sure know how to aggravate people. I said clearly that you > can move forward on purpose build drivers (e.g. for WWAN). There is no > way forward on this common shim driver as far as I'm concerned. >
On Wed 10 Feb 12:41 CST 2021, Jakub Kicinski wrote: > On Wed, 10 Feb 2021 11:55:31 +0530 Manivannan Sadhasivam wrote: > > On Tue, Feb 09, 2021 at 08:17:44AM -0800, Jakub Kicinski wrote: > > > On Tue, 9 Feb 2021 10:20:30 +0100 Aleksander Morgado wrote: > > > > This may be a stupid suggestion, but would the integration look less a > > > > backdoor if it would have been named "mhi_wwan" and it exposed already > > > > all the AT+DIAG+QMI+MBIM+NMEA possible channels as chardevs, not just > > > > QMI? > > > > > > What's DIAG? Who's going to remember that this is a backdoor driver > > > a year from now when Qualcomm sends a one liner patches which just > > > adds a single ID to open another channel? > > > > I really appreciate your feedback on this driver eventhough I'm not > > inclined with you calling this driver a "backdoor interface". But can > > you please propose a solution on how to make this driver a good one as > > per your thoughts? > > > > I really don't know what bothers you even if the userspace tools making > > use of these chardevs are available openly (you can do the audit and see > > if anything wrong we are doing). > > What bothers me is maintaining shim drivers which just shuttle opaque > messages between user space and firmware. One of which definitely is, > and the other may well be, proprietary. This is an open source project, > users are supposed to be able to meaningfully change the behavior of > the system. > You're absolutely right in that we in general don't like shim drivers and there are several examples of proper MHI drivers - for e.g. networking, WiFi Technically we could fork/reimplement https://github.com/freedesktop/libqmi, https://github.com/andersson/diag and https://github.com/andersson/qdl in the kernel as "proper drivers" - each one exposing their own userspace ABI. But to leave these in userspace and rely on something that looks exactly like USBDEVFS seems like a much better strategy. > What bothers me is that we have 3 WWAN vendors all doing their own > thing and no common Linux API for WWAN. It may have been fine 10 years > ago, but WWAN is increasingly complex and important. > We had a deep discussion and a few prototypes for a WWAN framework going around 1-1.5 years ago. Unfortunately, what did fit Intel's view of what a WWAN device is didn't fit at all with what's run and exposed by the "modem" DSP in a Qualcomm platform. After trying to find various contrived ways to model this we gave up. > > And exposing the raw access to the > > hardware is not a new thing in kernel. There are several existing > > subsystems/drivers does this as pointed out by Bjorn. Moreover we don't > > have in-kernel APIs for the functionalities exposed by this driver and > > creating one is not feasible as explained by many. > > > > So please let us know the path forward on this series. We are open to > > any suggestions but you haven't provided one till now. > > Well. You sure know how to aggravate people. I said clearly that you > can move forward on purpose build drivers (e.g. for WWAN). There is no > way forward on this common shim driver as far as I'm concerned. But what is a WWAN device? What features does it have? What kind of APIs does it expose? Note that in this sense "QMI" really is a "binary equivalent" of AT commands, the data flows over a DMA engine, which is not part of the "WWAN device" and other services, such as GPS, already has specific transports available upstream. Regards, Bjorn
> What bothers me is maintaining shim drivers which just shuttle opaque > messages between user space and firmware. One of which definitely is, > and the other may well be, proprietary. This is an open source project, > users are supposed to be able to meaningfully change the behavior of > the system. libqmi is an open source library under the LGPL; so all the messages that are passed between e.g. ModemManager and the modem firmware can be easily inspected by anyone. It is true, though, that libqmi may also allow passing "unknown" messages between other proprietary third party applications and the firmware, but that is very much like any other modem control port that we already have; be it a plain tty, or a ttyUSB or a ttyACM or a cdc-wdm port. The kernel drivers are passing unknown stuff between modem firmware and userspace; I don't see how the kernel driver would be interested in any other thing really. QMI and MBIM are just 2 binary protocols (and we have libqmi and libmbim), and there's a generic 3GPP AT command set, but every vendor then has its own interpretation of that AT command set, and vendor-specific AT commands, and what not. From my point of view, it's not like the kernel should know or have much to say on what's being passed to the modem. > > What bothers me is that we have 3 WWAN vendors all doing their own > thing and no common Linux API for WWAN. It may have been fine 10 years > ago, but WWAN is increasingly complex and important. > A WWAN modem is nowadays a complete Linux system itself with tons of features, and if there is sometime a generic WWAN system in the kernel providing API/ABI for generic features (e.g. data connection), that API/ABI should anyway provide access to pass messages (be it binary, or text AT commands) between firmware and userspace, for all the other side features for which no generic API/ABI is provided by that hypothetical generic WWAN system. Unless we don't want any of those side features... like Voice call management, SMS, USSD, GNSS, SAR, OMA-DM, carrier config selection, multi-SIM setups...
Hey Manivannan, Jakub & all, > > So please let us know the path forward on this series. We are open to > any suggestions but you haven't provided one till now. > I just found out that Sierra Wireless also provides their own version of mhi-net and mhi-uci in precompiled binaries for several Ubuntu kernel versions and other setups; and that made me extremely unhappy. They're not the only manufacturer doing that; most of them are doing it, because we don't have yet a common solution in upstream Linux. Not the first time we've seen this either, see the per-vendor GobiNet implementations vs the upstream qmi_wwan one. I was hoping we could avoid that mess again with the newer Qualcomm modules! :) In ModemManager we've always *forced* all manufacturers we interact with to first do the work in upstream Linux, and then we integrate support in MM for those drivers. We've never accepted support for vendor-specific proprietary kernel drivers, and that's something I would personally like to keep on doing. The sad status right now is that any user that wants to use the newer 5G modules with Qualcomm chipsets, they need to go look for manufacturer-built precompiled drivers for their specific kernel, and also then patch ModemManager and the tools themselves. Obviously almost no one is doing all that, except for some company with resources or a lot of interest. Some of these new 5G modules are PCIe-only by default, unless some pin in the chipset is brought up and then some of them may switch to USB support. No one is really doing that either, as tampering with the hardware voids warranty. The iosm driver is also stalled in the mailing list and there doesn't seem to be a lot of real need for a new common wwan subsystem to rework everything... I'm not involved with the mhi-uci driver development at all, and I also don't have anything to say on what goes in the upstream kernel and what doesn't. But as one of the ModemManager/libqmi/libmbim maintainers I would like to represent all the users of these modules that are right now forced to look for shady binary precompiled drivers out there... that is no better solution than this proposed mhi-uci common driver. Manivannan, are you attempting to rework the mhi-uci driver in a different way, or have you given up? Is there anything I could help with? Jakub, is there really no way you can be convinced that this mhi-uci driver isn't that bad after all? :) All the mhi-net bits are already integrated I think, even the MBIM support over MHI in the net device, but all that is truly useless without a way to control the modem sending and receiving messages. Sorry for being back again with this discussion :) Cheers! -- Aleksander https://aleksander.es
On Sun, Feb 28, 2021 at 03:12:42PM +0100, Aleksander Morgado wrote: > Hey Manivannan, Jakub & all, > > > > > So please let us know the path forward on this series. We are open to > > any suggestions but you haven't provided one till now. > > > > I just found out that Sierra Wireless also provides their own version > of mhi-net and mhi-uci in precompiled binaries for several Ubuntu > kernel versions and other setups; and that made me extremely unhappy. > They're not the only manufacturer doing that; most of them are doing > it, because we don't have yet a common solution in upstream Linux. Not > the first time we've seen this either, see the per-vendor GobiNet > implementations vs the upstream qmi_wwan one. I was hoping we could > avoid that mess again with the newer Qualcomm modules! :) > > In ModemManager we've always *forced* all manufacturers we interact > with to first do the work in upstream Linux, and then we integrate > support in MM for those drivers. We've never accepted support for > vendor-specific proprietary kernel drivers, and that's something I > would personally like to keep on doing. The sad status right now is > that any user that wants to use the newer 5G modules with Qualcomm > chipsets, they need to go look for manufacturer-built precompiled > drivers for their specific kernel, and also then patch ModemManager > and the tools themselves. Obviously almost no one is doing all that, > except for some company with resources or a lot of interest. Some of > these new 5G modules are PCIe-only by default, unless some pin in the > chipset is brought up and then some of them may switch to USB support. > No one is really doing that either, as tampering with the hardware > voids warranty. > > The iosm driver is also stalled in the mailing list and there doesn't > seem to be a lot of real need for a new common wwan subsystem to > rework everything... > > I'm not involved with the mhi-uci driver development at all, and I > also don't have anything to say on what goes in the upstream kernel > and what doesn't. But as one of the ModemManager/libqmi/libmbim > maintainers I would like to represent all the users of these modules > that are right now forced to look for shady binary precompiled drivers > out there... that is no better solution than this proposed mhi-uci > common driver. > > Manivannan, are you attempting to rework the mhi-uci driver in a > different way, or have you given up? Is there anything I could help > with? > Hemant is currently in-charge of the MHI UCI development effort. We were thinking about doing "mhi-wwan" driver which just exposes the channels needed for WWAN as Jakub said "you can move forward on purpose build drivers (e.g. for WWAN)." But we are open to other suggestions also. Thanks, Mani