* [RESEND PATCH v18 0/3] userspace MHI client interface driver @ 2021-01-06 18:44 Hemant Kumar 2021-01-06 18:44 ` [RESEND PATCH v18 1/3] bus: mhi: core: Move MHI_MAX_MTU to external header file Hemant Kumar ` (3 more replies) 0 siblings, 4 replies; 31+ messages in thread From: Hemant Kumar @ 2021-01-06 18:44 UTC (permalink / raw) To: manivannan.sadhasivam, gregkh Cc: linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev, Hemant Kumar 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. 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* [RESEND PATCH v18 1/3] bus: mhi: core: Move MHI_MAX_MTU to external header file 2021-01-06 18:44 [RESEND PATCH v18 0/3] userspace MHI client interface driver Hemant Kumar @ 2021-01-06 18:44 ` Hemant Kumar 2021-01-06 18:44 ` [RESEND PATCH v18 2/3] docs: Add documentation for userspace client interface Hemant Kumar ` (2 subsequent siblings) 3 siblings, 0 replies; 31+ messages in thread From: Hemant Kumar @ 2021-01-06 18:44 UTC (permalink / raw) To: manivannan.sadhasivam, gregkh Cc: linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev, Hemant Kumar Currently this macro is defined in internal MHI header as a TRE length mask. Moving it to external header allows MHI client drivers to set this upper bound for the transmit buffer size. Signed-off-by: Hemant Kumar <hemantk@codeaurora.org> Reviewed-by: Jeffrey Hugo <jhugo@codeaurora.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> --- drivers/bus/mhi/core/internal.h | 1 - include/linux/mhi.h | 3 +++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h index 6f80ec3..2b9c063 100644 --- a/drivers/bus/mhi/core/internal.h +++ b/drivers/bus/mhi/core/internal.h @@ -453,7 +453,6 @@ enum mhi_pm_state { #define CMD_EL_PER_RING 128 #define PRIMARY_CMD_RING 0 #define MHI_DEV_WAKE_DB 127 -#define MHI_MAX_MTU 0xffff #define MHI_RANDOM_U32_NONZERO(bmsk) (prandom_u32_max(bmsk) + 1) enum mhi_er_type { diff --git a/include/linux/mhi.h b/include/linux/mhi.h index e36d575..f072605 100644 --- a/include/linux/mhi.h +++ b/include/linux/mhi.h @@ -15,6 +15,9 @@ #include <linux/wait.h> #include <linux/workqueue.h> +/* MHI client drivers to set this upper bound for tx buffer */ +#define MHI_MAX_MTU 0xffff + #define MHI_MAX_OEM_PK_HASH_SEGMENTS 16 struct mhi_chan; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ^ permalink raw reply related [flat|nested] 31+ messages in thread
* [RESEND PATCH v18 2/3] docs: Add documentation for userspace client interface 2021-01-06 18:44 [RESEND PATCH v18 0/3] userspace MHI client interface driver Hemant Kumar 2021-01-06 18:44 ` [RESEND PATCH v18 1/3] bus: mhi: core: Move MHI_MAX_MTU to external header file Hemant Kumar @ 2021-01-06 18:44 ` Hemant Kumar 2021-01-06 18:44 ` [RESEND PATCH v18 3/3] bus: mhi: Add userspace client interface driver Hemant Kumar 2021-01-13 15:26 ` [RESEND PATCH v18 0/3] userspace MHI " Manivannan Sadhasivam 3 siblings, 0 replies; 31+ messages in thread From: Hemant Kumar @ 2021-01-06 18:44 UTC (permalink / raw) To: manivannan.sadhasivam, gregkh Cc: linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev, Hemant Kumar MHI userspace client driver is creating device file node for user application to perform file operations. File operations are handled by MHI core driver. Currently QMI MHI channel is supported by this driver. Signed-off-by: Hemant Kumar <hemantk@codeaurora.org> Reviewed-by: Jeffrey Hugo <jhugo@codeaurora.org> --- Documentation/mhi/index.rst | 1 + Documentation/mhi/uci.rst | 95 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 96 insertions(+) create mode 100644 Documentation/mhi/uci.rst diff --git a/Documentation/mhi/index.rst b/Documentation/mhi/index.rst index 1d8dec3..c75a371 100644 --- a/Documentation/mhi/index.rst +++ b/Documentation/mhi/index.rst @@ -9,6 +9,7 @@ MHI mhi topology + uci .. only:: subproject and html diff --git a/Documentation/mhi/uci.rst b/Documentation/mhi/uci.rst new file mode 100644 index 0000000..1e0a015 --- /dev/null +++ b/Documentation/mhi/uci.rst @@ -0,0 +1,95 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================= +Userspace Client Interface (UCI) +================================= + +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. UCI device object represents UCI device file node which gets +instantiated as part of MHI UCI driver probe. UCI channel object represents +MHI uplink or downlink channel. + +Operations +========== + +open +---- + +Instantiates UCI channel object and starts MHI channels to move it to running +state. Inbound buffers are queued to downlink channel transfer ring. Every +subsequent open() increments UCI device reference count as well as UCI channel +reference count. + +read +---- + +When data transfer is completed on downlink channel, transfer ring element +buffer is copied to pending list. Reader is unblocked and data is copied to +userspace buffer. Transfer ring element buffer is queued back to downlink +channel transfer ring. + +write +----- + +Write buffer is queued to uplink channel transfer ring if ring is not full. Upon +uplink transfer completion buffer is freed. + +poll +---- + +Returns EPOLLIN | EPOLLRDNORM mask if pending list has buffers to be read by +userspace. Returns EPOLLOUT | EPOLLWRNORM mask if MHI uplink channel transfer +ring is not empty. When the uplink channel transfer ring is non-empty, more +data may be sent to the device. Returns EPOLLERR when UCI driver is removed. + +release +------- + +Decrements UCI device reference count and UCI channel reference count. Upon +last release() UCI channel clean up is performed. MHI channel moves to disable +state and inbound buffers are freed. + +Usage +===== + +Device file node is created with format:- + +/dev/<mhi_device_name> + +mhi_device_name includes mhi controller name and the name of the MHI channel +being used by MHI client in userspace to send or receive data using MHI +protocol. + +There is a separate character device file node created for each channel +specified in MHI device id table. MHI channels are statically defined by MHI +specification. The list of supported channels is in the channel list variable +of mhi_device_id table in UCI driver. + +Qualcomm MSM Interface(QMI) Channel +----------------------------------- + +Qualcomm MSM Interface(QMI) is a modem control messaging protocol used to +communicate between software components in the modem and other peripheral +subsystems. QMI communication is of request/response type or an unsolicited +event type. libqmi is userspace MHI client which communicates to a QMI service +using UCI device. It sends a QMI request to a QMI service using MHI channel 14 +or 16. QMI response is received using MHI channel 15 or 17 respectively. 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/ + +Usage Example +~~~~~~~~~~~~~ + +QMI command to retrieve device mode +$ sudo qmicli -d /dev/mhi0_QMI --dms-get-model +[/dev/mhi0_QMI] Device model retrieved: + Model: 'FN980m' + +Other Use Cases +--------------- + +Getting MHI device specific diagnostics information to userspace MHI diagnostic +client using DIAG channel 4 (Host to device) and 5 (Device to Host). -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ^ permalink raw reply related [flat|nested] 31+ messages in thread
* [RESEND PATCH v18 3/3] bus: mhi: Add userspace client interface driver 2021-01-06 18:44 [RESEND PATCH v18 0/3] userspace MHI client interface driver Hemant Kumar 2021-01-06 18:44 ` [RESEND PATCH v18 1/3] bus: mhi: core: Move MHI_MAX_MTU to external header file Hemant Kumar 2021-01-06 18:44 ` [RESEND PATCH v18 2/3] docs: Add documentation for userspace client interface Hemant Kumar @ 2021-01-06 18:44 ` Hemant Kumar 2021-01-13 15:26 ` [RESEND PATCH v18 0/3] userspace MHI " Manivannan Sadhasivam 3 siblings, 0 replies; 31+ messages in thread From: Hemant Kumar @ 2021-01-06 18:44 UTC (permalink / raw) To: manivannan.sadhasivam, gregkh Cc: linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev, Hemant Kumar 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/<mhi_device_name> 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. Signed-off-by: Hemant Kumar <hemantk@codeaurora.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Jeffrey Hugo <jhugo@codeaurora.org> Tested-by: Loic Poulain <loic.poulain@linaro.org> --- drivers/bus/mhi/Kconfig | 13 + drivers/bus/mhi/Makefile | 3 + drivers/bus/mhi/uci.c | 664 +++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 680 insertions(+) create mode 100644 drivers/bus/mhi/uci.c diff --git a/drivers/bus/mhi/Kconfig b/drivers/bus/mhi/Kconfig index da5cd0c..5194e8e 100644 --- a/drivers/bus/mhi/Kconfig +++ b/drivers/bus/mhi/Kconfig @@ -29,3 +29,16 @@ config MHI_BUS_PCI_GENERIC This driver provides MHI PCI controller driver for devices such as Qualcomm SDX55 based PCIe modems. +config MHI_UCI + tristate "MHI UCI" + depends on MHI_BUS + help + MHI based Userspace Client Interface (UCI) driver is used for + transferring raw data between host and device using standard file + operations from userspace. Open, read, write, poll and close + operations are supported by this driver. Please check + mhi_uci_match_table for all supported channels that are exposed to + userspace. + + To compile this driver as a module, choose M here: the module will be + called mhi_uci. diff --git a/drivers/bus/mhi/Makefile b/drivers/bus/mhi/Makefile index 0a2d778..69f2111 100644 --- a/drivers/bus/mhi/Makefile +++ b/drivers/bus/mhi/Makefile @@ -4,3 +4,6 @@ obj-y += core/ obj-$(CONFIG_MHI_BUS_PCI_GENERIC) += mhi_pci_generic.o mhi_pci_generic-y += pci_generic.o +# MHI client +mhi_uci-y := uci.o +obj-$(CONFIG_MHI_UCI) += mhi_uci.o diff --git a/drivers/bus/mhi/uci.c b/drivers/bus/mhi/uci.c new file mode 100644 index 0000000..1df2377 --- /dev/null +++ b/drivers/bus/mhi/uci.c @@ -0,0 +1,664 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* Copyright (c) 2018-2020, The Linux Foundation. All rights reserved.*/ + +#include <linux/kernel.h> +#include <linux/mhi.h> +#include <linux/mod_devicetable.h> +#include <linux/module.h> +#include <linux/poll.h> + +#define MHI_UCI_DRIVER_NAME "mhi_uci" +#define MHI_MAX_UCI_MINORS 128 + +static DEFINE_IDR(uci_idr); +static DEFINE_MUTEX(uci_drv_mutex); +static struct class *uci_dev_class; +static int uci_dev_major; + +/** + * struct uci_chan - MHI channel for a UCI device + * @udev: associated UCI device object + * @ul_wq: wait queue for writer + * @write_lock: mutex write lock for ul channel + * @dl_wq: wait queue for reader + * @read_lock: mutex read lock for dl channel + * @dl_pending_lock: spin lock for dl_pending list + * @dl_pending: list of dl buffers userspace is waiting to read + * @cur_buf: current buffer userspace is reading + * @dl_size: size of the current dl buffer userspace is reading + * @ref_count: uci_chan reference count + */ +struct uci_chan { + struct uci_dev *udev; + wait_queue_head_t ul_wq; + + /* ul channel lock to synchronize multiple writes */ + struct mutex write_lock; + + wait_queue_head_t dl_wq; + + /* dl channel lock to synchronize multiple reads */ + struct mutex read_lock; + + /* + * protects pending list in bh context, channel release, read and + * poll + */ + spinlock_t dl_pending_lock; + + struct list_head dl_pending; + struct uci_buf *cur_buf; + size_t dl_size; + struct kref ref_count; +}; + +/** + * struct uci_buf - UCI buffer + * @data: data buffer + * @len: length of data buffer + * @node: list node of the UCI buffer + */ +struct uci_buf { + void *data; + size_t len; + struct list_head node; +}; + +/** + * struct uci_dev - MHI UCI device + * @minor: UCI device node minor number + * @mhi_dev: associated mhi device object + * @uchan: UCI uplink and downlink channel object + * @mtu: max TRE buffer length + * @enabled: Flag to track the state of the UCI device + * @lock: mutex lock to manage uchan object + * @ref_count: uci_dev reference count + */ +struct uci_dev { + unsigned int minor; + struct mhi_device *mhi_dev; + struct uci_chan *uchan; + size_t mtu; + bool enabled; + + /* synchronize open, release and driver remove */ + struct mutex lock; + struct kref ref_count; +}; + +static void mhi_uci_dev_chan_release(struct kref *ref) +{ + struct uci_buf *buf_itr, *tmp; + struct uci_chan *uchan = + container_of(ref, struct uci_chan, ref_count); + + if (uchan->udev->enabled) + mhi_unprepare_from_transfer(uchan->udev->mhi_dev); + + spin_lock_bh(&uchan->dl_pending_lock); + list_for_each_entry_safe(buf_itr, tmp, &uchan->dl_pending, node) { + list_del(&buf_itr->node); + kfree(buf_itr->data); + } + spin_unlock_bh(&uchan->dl_pending_lock); + + wake_up(&uchan->ul_wq); + wake_up(&uchan->dl_wq); + + mutex_lock(&uchan->read_lock); + if (uchan->cur_buf) + kfree(uchan->cur_buf->data); + + uchan->cur_buf = NULL; + mutex_unlock(&uchan->read_lock); + + mutex_destroy(&uchan->write_lock); + mutex_destroy(&uchan->read_lock); + + uchan->udev->uchan = NULL; + kfree(uchan); +} + +static int mhi_queue_inbound(struct uci_dev *udev) +{ + struct mhi_device *mhi_dev = udev->mhi_dev; + struct device *dev = &mhi_dev->dev; + int nr_desc, i, ret = -EIO; + size_t dl_buf_size; + void *buf; + struct uci_buf *ubuf; + + /* + * skip queuing without error if dl channel is not supported. This + * allows open to succeed for udev, supporting ul only channel. + */ + if (!udev->mhi_dev->dl_chan) + return 0; + + nr_desc = mhi_get_free_desc_count(mhi_dev, DMA_FROM_DEVICE); + + for (i = 0; i < nr_desc; i++) { + buf = kmalloc(udev->mtu, GFP_KERNEL); + if (!buf) + return -ENOMEM; + + dl_buf_size = udev->mtu - sizeof(*ubuf); + + /* save uci_buf info at the end of buf */ + ubuf = buf + dl_buf_size; + ubuf->data = buf; + + dev_dbg(dev, "Allocated buf %d of %d size %zu\n", i, nr_desc, + dl_buf_size); + + ret = mhi_queue_buf(mhi_dev, DMA_FROM_DEVICE, buf, dl_buf_size, + MHI_EOT); + if (ret) { + kfree(buf); + dev_err(dev, "Failed to queue buffer %d\n", i); + return ret; + } + } + + return ret; +} + +static int mhi_uci_dev_start_chan(struct uci_dev *udev) +{ + int ret = 0; + struct uci_chan *uchan; + + mutex_lock(&udev->lock); + if (!udev->uchan || !kref_get_unless_zero(&udev->uchan->ref_count)) { + uchan = kzalloc(sizeof(*uchan), GFP_KERNEL); + if (!uchan) { + ret = -ENOMEM; + goto error_chan_start; + } + + udev->uchan = uchan; + uchan->udev = udev; + init_waitqueue_head(&uchan->ul_wq); + init_waitqueue_head(&uchan->dl_wq); + mutex_init(&uchan->write_lock); + mutex_init(&uchan->read_lock); + spin_lock_init(&uchan->dl_pending_lock); + INIT_LIST_HEAD(&uchan->dl_pending); + + ret = mhi_prepare_for_transfer(udev->mhi_dev); + if (ret) { + dev_err(&udev->mhi_dev->dev, "Error starting transfer channels\n"); + goto error_chan_cleanup; + } + + ret = mhi_queue_inbound(udev); + if (ret) + goto error_chan_cleanup; + + kref_init(&uchan->ref_count); + } + + mutex_unlock(&udev->lock); + + return 0; + +error_chan_cleanup: + mhi_uci_dev_chan_release(&uchan->ref_count); +error_chan_start: + mutex_unlock(&udev->lock); + return ret; +} + +static void mhi_uci_dev_release(struct kref *ref) +{ + struct uci_dev *udev = + container_of(ref, struct uci_dev, ref_count); + + mutex_destroy(&udev->lock); + + kfree(udev); +} + +static int mhi_uci_open(struct inode *inode, struct file *filp) +{ + unsigned int minor = iminor(inode); + struct uci_dev *udev = NULL; + int ret; + + mutex_lock(&uci_drv_mutex); + udev = idr_find(&uci_idr, minor); + if (!udev) { + pr_debug("uci dev: minor %d not found\n", minor); + mutex_unlock(&uci_drv_mutex); + return -ENODEV; + } + + kref_get(&udev->ref_count); + mutex_unlock(&uci_drv_mutex); + + ret = mhi_uci_dev_start_chan(udev); + if (ret) { + kref_put(&udev->ref_count, mhi_uci_dev_release); + return ret; + } + + filp->private_data = udev; + + return 0; +} + +static int mhi_uci_release(struct inode *inode, struct file *file) +{ + struct uci_dev *udev = file->private_data; + + mutex_lock(&udev->lock); + kref_put(&udev->uchan->ref_count, mhi_uci_dev_chan_release); + mutex_unlock(&udev->lock); + + kref_put(&udev->ref_count, mhi_uci_dev_release); + + return 0; +} + +static __poll_t mhi_uci_poll(struct file *file, poll_table *wait) +{ + struct uci_dev *udev = file->private_data; + struct mhi_device *mhi_dev = udev->mhi_dev; + struct device *dev = &mhi_dev->dev; + struct uci_chan *uchan = udev->uchan; + __poll_t mask = 0; + + poll_wait(file, &udev->uchan->ul_wq, wait); + poll_wait(file, &udev->uchan->dl_wq, wait); + + if (!udev->enabled) { + mask = EPOLLERR; + goto done; + } + + spin_lock_bh(&uchan->dl_pending_lock); + if (!list_empty(&uchan->dl_pending) || uchan->cur_buf) + mask |= EPOLLIN | EPOLLRDNORM; + spin_unlock_bh(&uchan->dl_pending_lock); + + if (mhi_get_free_desc_count(mhi_dev, DMA_TO_DEVICE) > 0) + mask |= EPOLLOUT | EPOLLWRNORM; + + dev_dbg(dev, "Client attempted to poll, returning mask 0x%x\n", mask); + +done: + return mask; +} + +static ssize_t mhi_uci_write(struct file *file, + const char __user *buf, + size_t count, + loff_t *offp) +{ + struct uci_dev *udev = file->private_data; + struct mhi_device *mhi_dev = udev->mhi_dev; + struct device *dev = &mhi_dev->dev; + struct uci_chan *uchan = udev->uchan; + size_t bytes_xfered = 0; + int ret, nr_desc = 0; + + /* if ul channel is not supported return error */ + if (!mhi_dev->ul_chan) + return -EOPNOTSUPP; + + if (!buf || !count) + return -EINVAL; + + dev_dbg(dev, "%s: to xfer: %zu bytes\n", __func__, count); + + if (mutex_lock_interruptible(&uchan->write_lock)) + return -EINTR; + + while (count) { + size_t xfer_size; + void *kbuf; + enum mhi_flags flags; + + /* wait for free descriptors */ + ret = wait_event_interruptible(uchan->ul_wq, + (!udev->enabled) || + (nr_desc = mhi_get_free_desc_count(mhi_dev, + DMA_TO_DEVICE)) > 0); + + if (ret == -ERESTARTSYS) { + dev_dbg(dev, "Interrupted by a signal in %s, exiting\n", + __func__); + goto err_mtx_unlock; + } + + if (!udev->enabled) { + ret = -ENODEV; + goto err_mtx_unlock; + } + + xfer_size = min_t(size_t, count, udev->mtu); + kbuf = kmalloc(xfer_size, GFP_KERNEL); + if (!kbuf) { + ret = -ENOMEM; + goto err_mtx_unlock; + } + + ret = copy_from_user(kbuf, buf, xfer_size); + if (ret) { + kfree(kbuf); + ret = -EFAULT; + goto err_mtx_unlock; + } + + /* if ring is full after this force EOT */ + if (nr_desc > 1 && (count - xfer_size)) + flags = MHI_CHAIN; + else + flags = MHI_EOT; + + ret = mhi_queue_buf(mhi_dev, DMA_TO_DEVICE, kbuf, xfer_size, + flags); + if (ret) { + kfree(kbuf); + goto err_mtx_unlock; + } + + bytes_xfered += xfer_size; + count -= xfer_size; + buf += xfer_size; + } + + mutex_unlock(&uchan->write_lock); + dev_dbg(dev, "%s: bytes xferred: %zu\n", __func__, bytes_xfered); + + return bytes_xfered; + +err_mtx_unlock: + mutex_unlock(&uchan->write_lock); + + return ret; +} + +static ssize_t mhi_uci_read(struct file *file, + char __user *buf, + size_t count, + loff_t *ppos) +{ + struct uci_dev *udev = file->private_data; + struct mhi_device *mhi_dev = udev->mhi_dev; + struct uci_chan *uchan = udev->uchan; + struct device *dev = &mhi_dev->dev; + struct uci_buf *ubuf; + size_t rx_buf_size; + char *ptr; + size_t to_copy; + int ret = 0; + + /* if dl channel is not supported return error */ + if (!mhi_dev->dl_chan) + return -EOPNOTSUPP; + + if (!buf) + return -EINVAL; + + if (mutex_lock_interruptible(&uchan->read_lock)) + return -EINTR; + + spin_lock_bh(&uchan->dl_pending_lock); + /* No data available to read, wait */ + if (!uchan->cur_buf && list_empty(&uchan->dl_pending)) { + dev_dbg(dev, "No data available to read, waiting\n"); + + spin_unlock_bh(&uchan->dl_pending_lock); + ret = wait_event_interruptible(uchan->dl_wq, + (!udev->enabled || + !list_empty(&uchan->dl_pending))); + + if (ret == -ERESTARTSYS) { + dev_dbg(dev, "Interrupted by a signal in %s, exiting\n", + __func__); + goto err_mtx_unlock; + } + + if (!udev->enabled) { + ret = -ENODEV; + goto err_mtx_unlock; + } + spin_lock_bh(&uchan->dl_pending_lock); + } + + /* new read, get the next descriptor from the list */ + if (!uchan->cur_buf) { + ubuf = list_first_entry_or_null(&uchan->dl_pending, + struct uci_buf, node); + if (!ubuf) { + ret = -EIO; + goto err_spin_unlock; + } + + list_del(&ubuf->node); + uchan->cur_buf = ubuf; + uchan->dl_size = ubuf->len; + dev_dbg(dev, "Got pkt of size: %zu\n", uchan->dl_size); + } + spin_unlock_bh(&uchan->dl_pending_lock); + + ubuf = uchan->cur_buf; + + /* Copy the buffer to user space */ + to_copy = min_t(size_t, count, uchan->dl_size); + ptr = ubuf->data + (ubuf->len - uchan->dl_size); + + ret = copy_to_user(buf, ptr, to_copy); + if (ret) { + ret = -EFAULT; + goto err_mtx_unlock; + } + + dev_dbg(dev, "Copied %zu of %zu bytes\n", to_copy, uchan->dl_size); + uchan->dl_size -= to_copy; + + /* we finished with this buffer, queue it back to hardware */ + if (!uchan->dl_size) { + uchan->cur_buf = NULL; + + rx_buf_size = udev->mtu - sizeof(*ubuf); + ret = mhi_queue_buf(mhi_dev, DMA_FROM_DEVICE, ubuf->data, + rx_buf_size, MHI_EOT); + if (ret) { + dev_err(dev, "Failed to recycle element: %d\n", ret); + kfree(ubuf->data); + goto err_mtx_unlock; + } + } + mutex_unlock(&uchan->read_lock); + + dev_dbg(dev, "%s: Returning %zu bytes\n", __func__, to_copy); + + return to_copy; + +err_spin_unlock: + spin_unlock_bh(&uchan->dl_pending_lock); +err_mtx_unlock: + mutex_unlock(&uchan->read_lock); + return ret; +} + +static const struct file_operations mhidev_fops = { + .owner = THIS_MODULE, + .open = mhi_uci_open, + .release = mhi_uci_release, + .read = mhi_uci_read, + .write = mhi_uci_write, + .poll = mhi_uci_poll, +}; + +static void mhi_ul_xfer_cb(struct mhi_device *mhi_dev, + struct mhi_result *mhi_result) +{ + struct uci_dev *udev = dev_get_drvdata(&mhi_dev->dev); + struct uci_chan *uchan = udev->uchan; + struct device *dev = &mhi_dev->dev; + + dev_dbg(dev, "%s: status: %d xfer_len: %zu\n", __func__, + mhi_result->transaction_status, mhi_result->bytes_xferd); + + kfree(mhi_result->buf_addr); + + if (!mhi_result->transaction_status) + wake_up(&uchan->ul_wq); +} + +static void mhi_dl_xfer_cb(struct mhi_device *mhi_dev, + struct mhi_result *mhi_result) +{ + struct uci_dev *udev = dev_get_drvdata(&mhi_dev->dev); + struct uci_chan *uchan = udev->uchan; + struct device *dev = &mhi_dev->dev; + struct uci_buf *ubuf; + size_t dl_buf_size = udev->mtu - sizeof(*ubuf); + + dev_dbg(dev, "%s: status: %d receive_len: %zu\n", __func__, + mhi_result->transaction_status, mhi_result->bytes_xferd); + + if (mhi_result->transaction_status && + mhi_result->transaction_status != -EOVERFLOW) { + kfree(mhi_result->buf_addr); + return; + } + + ubuf = mhi_result->buf_addr + dl_buf_size; + ubuf->data = mhi_result->buf_addr; + ubuf->len = mhi_result->bytes_xferd; + spin_lock_bh(&uchan->dl_pending_lock); + list_add_tail(&ubuf->node, &uchan->dl_pending); + spin_unlock_bh(&uchan->dl_pending_lock); + + wake_up(&uchan->dl_wq); +} + +static int mhi_uci_probe(struct mhi_device *mhi_dev, + const struct mhi_device_id *id) +{ + struct uci_dev *udev; + struct device *dev; + int index; + + udev = kzalloc(sizeof(*udev), GFP_KERNEL); + if (!udev) + return -ENOMEM; + + kref_init(&udev->ref_count); + mutex_init(&udev->lock); + udev->mhi_dev = mhi_dev; + + mutex_lock(&uci_drv_mutex); + index = idr_alloc(&uci_idr, udev, 0, MHI_MAX_UCI_MINORS, GFP_KERNEL); + mutex_unlock(&uci_drv_mutex); + if (index < 0) { + kfree(udev); + return index; + } + + udev->minor = index; + + udev->mtu = min_t(size_t, id->driver_data, MHI_MAX_MTU); + dev_set_drvdata(&mhi_dev->dev, udev); + udev->enabled = true; + + /* create device file node /dev/<mhi_dev_name> */ + dev = device_create(uci_dev_class, &mhi_dev->dev, + MKDEV(uci_dev_major, index), udev, "%s", + dev_name(&mhi_dev->dev)); + if (IS_ERR(dev)) { + mutex_lock(&uci_drv_mutex); + idr_remove(&uci_idr, udev->minor); + mutex_unlock(&uci_drv_mutex); + dev_set_drvdata(&mhi_dev->dev, NULL); + kfree(udev); + return PTR_ERR(dev); + } + + dev_dbg(&mhi_dev->dev, "probed uci dev: %s\n", id->chan); + + return 0; +}; + +static void mhi_uci_remove(struct mhi_device *mhi_dev) +{ + struct uci_dev *udev = dev_get_drvdata(&mhi_dev->dev); + + /* disable the node */ + mutex_lock(&udev->lock); + udev->enabled = false; + + /* delete the node to prevent new opens */ + device_destroy(uci_dev_class, MKDEV(uci_dev_major, udev->minor)); + + /* return error for any blocked read or write */ + if (udev->uchan) { + wake_up(&udev->uchan->ul_wq); + wake_up(&udev->uchan->dl_wq); + } + mutex_unlock(&udev->lock); + + mutex_lock(&uci_drv_mutex); + idr_remove(&uci_idr, udev->minor); + kref_put(&udev->ref_count, mhi_uci_dev_release); + mutex_unlock(&uci_drv_mutex); +} + +/* .driver_data stores max mtu */ +static const struct mhi_device_id mhi_uci_match_table[] = { + { .chan = "QMI", .driver_data = 0x1000}, + {}, +}; +MODULE_DEVICE_TABLE(mhi, mhi_uci_match_table); + +static struct mhi_driver mhi_uci_driver = { + .id_table = mhi_uci_match_table, + .remove = mhi_uci_remove, + .probe = mhi_uci_probe, + .ul_xfer_cb = mhi_ul_xfer_cb, + .dl_xfer_cb = mhi_dl_xfer_cb, + .driver = { + .name = MHI_UCI_DRIVER_NAME, + }, +}; + +static int __init mhi_uci_init(void) +{ + int ret; + + ret = register_chrdev(0, MHI_UCI_DRIVER_NAME, &mhidev_fops); + if (ret < 0) + return ret; + + uci_dev_major = ret; + uci_dev_class = class_create(THIS_MODULE, MHI_UCI_DRIVER_NAME); + if (IS_ERR(uci_dev_class)) { + unregister_chrdev(uci_dev_major, MHI_UCI_DRIVER_NAME); + return PTR_ERR(uci_dev_class); + } + + ret = mhi_driver_register(&mhi_uci_driver); + if (ret) { + class_destroy(uci_dev_class); + unregister_chrdev(uci_dev_major, MHI_UCI_DRIVER_NAME); + } + + return ret; +} + +static void __exit mhi_uci_exit(void) +{ + mhi_driver_unregister(&mhi_uci_driver); + class_destroy(uci_dev_class); + unregister_chrdev(uci_dev_major, MHI_UCI_DRIVER_NAME); + idr_destroy(&uci_idr); +} + +module_init(mhi_uci_init); +module_exit(mhi_uci_exit); +MODULE_LICENSE("GPL v2"); +MODULE_DESCRIPTION("MHI UCI Driver"); -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ^ permalink raw reply related [flat|nested] 31+ messages in thread
* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver 2021-01-06 18:44 [RESEND PATCH v18 0/3] userspace MHI client interface driver Hemant Kumar ` (2 preceding siblings ...) 2021-01-06 18:44 ` [RESEND PATCH v18 3/3] bus: mhi: Add userspace client interface driver Hemant Kumar @ 2021-01-13 15:26 ` Manivannan Sadhasivam 2021-01-19 9:42 ` Manivannan Sadhasivam 2021-01-27 15:15 ` Greg KH 3 siblings, 2 replies; 31+ messages in thread From: Manivannan Sadhasivam @ 2021-01-13 15:26 UTC (permalink / raw) To: gregkh Cc: gregkh, linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev 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 > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver 2021-01-13 15:26 ` [RESEND PATCH v18 0/3] userspace MHI " Manivannan Sadhasivam @ 2021-01-19 9:42 ` Manivannan Sadhasivam 2021-01-19 10:28 ` Greg KH 2021-01-27 15:15 ` Greg KH 1 sibling, 1 reply; 31+ messages in thread From: Manivannan Sadhasivam @ 2021-01-19 9:42 UTC (permalink / raw) To: gregkh Cc: linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev, hemantk 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 > > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver 2021-01-19 9:42 ` Manivannan Sadhasivam @ 2021-01-19 10:28 ` Greg KH 0 siblings, 0 replies; 31+ messages in thread From: Greg KH @ 2021-01-19 10:28 UTC (permalink / raw) To: Manivannan Sadhasivam Cc: linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev, hemantk 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver 2021-01-13 15:26 ` [RESEND PATCH v18 0/3] userspace MHI " Manivannan Sadhasivam 2021-01-19 9:42 ` Manivannan Sadhasivam @ 2021-01-27 15:15 ` Greg KH 2021-01-27 16:24 ` Bjorn Andersson 2021-02-01 10:55 ` Manivannan Sadhasivam 1 sibling, 2 replies; 31+ messages in thread From: Greg KH @ 2021-01-27 15:15 UTC (permalink / raw) To: Manivannan Sadhasivam Cc: linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver 2021-01-27 15:15 ` Greg KH @ 2021-01-27 16:24 ` Bjorn Andersson 2021-02-01 10:55 ` Manivannan Sadhasivam 1 sibling, 0 replies; 31+ messages in thread From: Bjorn Andersson @ 2021-01-27 16:24 UTC (permalink / raw) To: Greg KH Cc: Manivannan Sadhasivam, linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver 2021-01-27 15:15 ` Greg KH 2021-01-27 16:24 ` Bjorn Andersson @ 2021-02-01 10:55 ` Manivannan Sadhasivam 2021-02-01 11:15 ` Greg KH 1 sibling, 1 reply; 31+ messages in thread From: Manivannan Sadhasivam @ 2021-02-01 10:55 UTC (permalink / raw) To: Greg KH; +Cc: linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver 2021-02-01 10:55 ` Manivannan Sadhasivam @ 2021-02-01 11:15 ` Greg KH 2021-02-01 12:13 ` Manivannan Sadhasivam 0 siblings, 1 reply; 31+ messages in thread From: Greg KH @ 2021-02-01 11:15 UTC (permalink / raw) To: Manivannan Sadhasivam Cc: linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver 2021-02-01 11:15 ` Greg KH @ 2021-02-01 12:13 ` Manivannan Sadhasivam 2021-02-02 4:22 ` Manivannan Sadhasivam 0 siblings, 1 reply; 31+ messages in thread From: Manivannan Sadhasivam @ 2021-02-01 12:13 UTC (permalink / raw) To: Greg KH; +Cc: linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver 2021-02-01 12:13 ` Manivannan Sadhasivam @ 2021-02-02 4:22 ` Manivannan Sadhasivam 2021-02-03 4:10 ` Jakub Kicinski 0 siblings, 1 reply; 31+ messages in thread From: Manivannan Sadhasivam @ 2021-02-02 4:22 UTC (permalink / raw) To: Greg KH, kuba, davem Cc: linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev + 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver 2021-02-02 4:22 ` Manivannan Sadhasivam @ 2021-02-03 4:10 ` Jakub Kicinski 2021-02-03 4:15 ` Manivannan Sadhasivam 0 siblings, 1 reply; 31+ messages in thread From: Jakub Kicinski @ 2021-02-03 4:10 UTC (permalink / raw) To: Manivannan Sadhasivam Cc: Greg KH, davem, linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev 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? ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver 2021-02-03 4:10 ` Jakub Kicinski @ 2021-02-03 4:15 ` Manivannan Sadhasivam 2021-02-03 18:05 ` Jakub Kicinski 0 siblings, 1 reply; 31+ messages in thread From: Manivannan Sadhasivam @ 2021-02-03 4:15 UTC (permalink / raw) To: Jakub Kicinski Cc: Greg KH, davem, linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev 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 -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver 2021-02-03 4:15 ` Manivannan Sadhasivam @ 2021-02-03 18:05 ` Jakub Kicinski 2021-02-03 18:28 ` Loic Poulain 2021-02-03 18:34 ` Bjorn Andersson 0 siblings, 2 replies; 31+ messages in thread From: Jakub Kicinski @ 2021-02-03 18:05 UTC (permalink / raw) To: Manivannan Sadhasivam Cc: Greg KH, davem, linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver 2021-02-03 18:05 ` Jakub Kicinski @ 2021-02-03 18:28 ` Loic Poulain 2021-02-03 18:40 ` Jakub Kicinski 2021-02-03 18:34 ` Bjorn Andersson 1 sibling, 1 reply; 31+ messages in thread From: Loic Poulain @ 2021-02-03 18:28 UTC (permalink / raw) To: Jakub Kicinski Cc: Manivannan Sadhasivam, Greg KH, David Miller, linux-arm-msm, open list, Jeffrey Hugo, Bhaumik Bhatt, Network Development 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver 2021-02-03 18:28 ` Loic Poulain @ 2021-02-03 18:40 ` Jakub Kicinski 2021-02-04 4:07 ` Manivannan Sadhasivam ` (2 more replies) 0 siblings, 3 replies; 31+ messages in thread From: Jakub Kicinski @ 2021-02-03 18:40 UTC (permalink / raw) To: Loic Poulain Cc: Manivannan Sadhasivam, Greg KH, David Miller, linux-arm-msm, open list, Jeffrey Hugo, Bhaumik Bhatt, Network Development 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver 2021-02-03 18:40 ` Jakub Kicinski @ 2021-02-04 4:07 ` Manivannan Sadhasivam 2021-02-04 5:53 ` Bjorn Andersson 2021-02-09 9:20 ` Aleksander Morgado 2 siblings, 0 replies; 31+ messages in thread From: Manivannan Sadhasivam @ 2021-02-04 4:07 UTC (permalink / raw) To: Jakub Kicinski Cc: Loic Poulain, Greg KH, David Miller, linux-arm-msm, open list, Jeffrey Hugo, Bhaumik Bhatt, Network Development 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver 2021-02-03 18:40 ` Jakub Kicinski 2021-02-04 4:07 ` Manivannan Sadhasivam @ 2021-02-04 5:53 ` Bjorn Andersson 2021-02-09 9:20 ` Aleksander Morgado 2 siblings, 0 replies; 31+ messages in thread From: Bjorn Andersson @ 2021-02-04 5:53 UTC (permalink / raw) To: Jakub Kicinski, Greg KH Cc: Loic Poulain, Manivannan Sadhasivam, David Miller, linux-arm-msm, open list, Jeffrey Hugo, Bhaumik Bhatt, Network Development 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver 2021-02-03 18:40 ` Jakub Kicinski 2021-02-04 4:07 ` Manivannan Sadhasivam 2021-02-04 5:53 ` Bjorn Andersson @ 2021-02-09 9:20 ` Aleksander Morgado 2021-02-09 16:17 ` Jakub Kicinski 2 siblings, 1 reply; 31+ messages in thread From: Aleksander Morgado @ 2021-02-09 9:20 UTC (permalink / raw) To: Jakub Kicinski Cc: Loic Poulain, Manivannan Sadhasivam, Greg KH, David Miller, linux-arm-msm, open list, Jeffrey Hugo, Bhaumik Bhatt, Network Development 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? -- Aleksander ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver 2021-02-09 9:20 ` Aleksander Morgado @ 2021-02-09 16:17 ` Jakub Kicinski 2021-02-09 16:49 ` Aleksander Morgado 2021-02-10 6:25 ` Manivannan Sadhasivam 0 siblings, 2 replies; 31+ messages in thread From: Jakub Kicinski @ 2021-02-09 16:17 UTC (permalink / raw) To: Aleksander Morgado Cc: Loic Poulain, Manivannan Sadhasivam, Greg KH, David Miller, linux-arm-msm, open list, Jeffrey Hugo, Bhaumik Bhatt, Network Development 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? ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver 2021-02-09 16:17 ` Jakub Kicinski @ 2021-02-09 16:49 ` Aleksander Morgado 2021-02-10 6:25 ` Manivannan Sadhasivam 1 sibling, 0 replies; 31+ messages in thread From: Aleksander Morgado @ 2021-02-09 16:49 UTC (permalink / raw) To: Jakub Kicinski Cc: Loic Poulain, Manivannan Sadhasivam, Greg KH, David Miller, linux-arm-msm, open list, Jeffrey Hugo, Bhaumik Bhatt, Network Development 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver 2021-02-09 16:17 ` Jakub Kicinski 2021-02-09 16:49 ` Aleksander Morgado @ 2021-02-10 6:25 ` Manivannan Sadhasivam 2021-02-10 18:41 ` Jakub Kicinski 2021-02-28 14:12 ` Aleksander Morgado 1 sibling, 2 replies; 31+ messages in thread From: Manivannan Sadhasivam @ 2021-02-10 6:25 UTC (permalink / raw) To: Jakub Kicinski Cc: Aleksander Morgado, Loic Poulain, Greg KH, David Miller, linux-arm-msm, open list, Jeffrey Hugo, Bhaumik Bhatt, Network Development 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver 2021-02-10 6:25 ` Manivannan Sadhasivam @ 2021-02-10 18:41 ` Jakub Kicinski 2021-02-10 19:18 ` Jeffrey Hugo ` (2 more replies) 2021-02-28 14:12 ` Aleksander Morgado 1 sibling, 3 replies; 31+ messages in thread From: Jakub Kicinski @ 2021-02-10 18:41 UTC (permalink / raw) To: Manivannan Sadhasivam Cc: Aleksander Morgado, Loic Poulain, Greg KH, David Miller, linux-arm-msm, open list, Jeffrey Hugo, Bhaumik Bhatt, Network Development 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver 2021-02-10 18:41 ` Jakub Kicinski @ 2021-02-10 19:18 ` Jeffrey Hugo 2021-02-10 22:08 ` Bjorn Andersson 2021-02-11 9:26 ` Aleksander Morgado 2 siblings, 0 replies; 31+ messages in thread From: Jeffrey Hugo @ 2021-02-10 19:18 UTC (permalink / raw) To: Jakub Kicinski, Manivannan Sadhasivam Cc: Aleksander Morgado, Loic Poulain, Greg KH, David Miller, linux-arm-msm, open list, Bhaumik Bhatt, Network Development 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. > -- Jeffrey Hugo Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver 2021-02-10 18:41 ` Jakub Kicinski 2021-02-10 19:18 ` Jeffrey Hugo @ 2021-02-10 22:08 ` Bjorn Andersson 2021-02-11 9:26 ` Aleksander Morgado 2 siblings, 0 replies; 31+ messages in thread From: Bjorn Andersson @ 2021-02-10 22:08 UTC (permalink / raw) To: Jakub Kicinski Cc: Manivannan Sadhasivam, Aleksander Morgado, Loic Poulain, Greg KH, David Miller, linux-arm-msm, open list, Jeffrey Hugo, Bhaumik Bhatt, Network Development 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver 2021-02-10 18:41 ` Jakub Kicinski 2021-02-10 19:18 ` Jeffrey Hugo 2021-02-10 22:08 ` Bjorn Andersson @ 2021-02-11 9:26 ` Aleksander Morgado 2 siblings, 0 replies; 31+ messages in thread From: Aleksander Morgado @ 2021-02-11 9:26 UTC (permalink / raw) To: Jakub Kicinski Cc: Manivannan Sadhasivam, Loic Poulain, Greg KH, David Miller, linux-arm-msm, open list, Jeffrey Hugo, Bhaumik Bhatt, Network Development > 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... -- Aleksander ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver 2021-02-10 6:25 ` Manivannan Sadhasivam 2021-02-10 18:41 ` Jakub Kicinski @ 2021-02-28 14:12 ` Aleksander Morgado 2021-02-28 15:52 ` Manivannan Sadhasivam 1 sibling, 1 reply; 31+ messages in thread From: Aleksander Morgado @ 2021-02-28 14:12 UTC (permalink / raw) To: Manivannan Sadhasivam Cc: Jakub Kicinski, Loic Poulain, Greg KH, David Miller, linux-arm-msm, open list, Jeffrey Hugo, Bhaumik Bhatt, Network Development 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver 2021-02-28 14:12 ` Aleksander Morgado @ 2021-02-28 15:52 ` Manivannan Sadhasivam 0 siblings, 0 replies; 31+ messages in thread From: Manivannan Sadhasivam @ 2021-02-28 15:52 UTC (permalink / raw) To: Aleksander Morgado Cc: Jakub Kicinski, Loic Poulain, Greg KH, David Miller, linux-arm-msm, open list, Jeffrey Hugo, Bhaumik Bhatt, Network Development 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver 2021-02-03 18:05 ` Jakub Kicinski 2021-02-03 18:28 ` Loic Poulain @ 2021-02-03 18:34 ` Bjorn Andersson 1 sibling, 0 replies; 31+ messages in thread From: Bjorn Andersson @ 2021-02-03 18:34 UTC (permalink / raw) To: Jakub Kicinski Cc: Manivannan Sadhasivam, Greg KH, davem, linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2021-02-28 15:53 UTC | newest] Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-01-06 18:44 [RESEND PATCH v18 0/3] userspace MHI client interface driver Hemant Kumar 2021-01-06 18:44 ` [RESEND PATCH v18 1/3] bus: mhi: core: Move MHI_MAX_MTU to external header file Hemant Kumar 2021-01-06 18:44 ` [RESEND PATCH v18 2/3] docs: Add documentation for userspace client interface Hemant Kumar 2021-01-06 18:44 ` [RESEND PATCH v18 3/3] bus: mhi: Add userspace client interface driver Hemant Kumar 2021-01-13 15:26 ` [RESEND PATCH v18 0/3] userspace MHI " Manivannan Sadhasivam 2021-01-19 9:42 ` Manivannan Sadhasivam 2021-01-19 10:28 ` Greg KH 2021-01-27 15:15 ` Greg KH 2021-01-27 16:24 ` Bjorn Andersson 2021-02-01 10:55 ` Manivannan Sadhasivam 2021-02-01 11:15 ` Greg KH 2021-02-01 12:13 ` Manivannan Sadhasivam 2021-02-02 4:22 ` Manivannan Sadhasivam 2021-02-03 4:10 ` Jakub Kicinski 2021-02-03 4:15 ` Manivannan Sadhasivam 2021-02-03 18:05 ` Jakub Kicinski 2021-02-03 18:28 ` Loic Poulain 2021-02-03 18:40 ` Jakub Kicinski 2021-02-04 4:07 ` Manivannan Sadhasivam 2021-02-04 5:53 ` Bjorn Andersson 2021-02-09 9:20 ` Aleksander Morgado 2021-02-09 16:17 ` Jakub Kicinski 2021-02-09 16:49 ` Aleksander Morgado 2021-02-10 6:25 ` Manivannan Sadhasivam 2021-02-10 18:41 ` Jakub Kicinski 2021-02-10 19:18 ` Jeffrey Hugo 2021-02-10 22:08 ` Bjorn Andersson 2021-02-11 9:26 ` Aleksander Morgado 2021-02-28 14:12 ` Aleksander Morgado 2021-02-28 15:52 ` Manivannan Sadhasivam 2021-02-03 18:34 ` Bjorn Andersson
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.