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