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
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 <[email protected]>
Reviewed-by: Jeffrey Hugo <[email protected]>
---
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
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 <[email protected]>
Reviewed-by: Manivannan Sadhasivam <[email protected]>
Reviewed-by: Jeffrey Hugo <[email protected]>
Tested-by: Loic Poulain <[email protected]>
---
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
On Tue, Jan 19, 2021 at 03:12:50PM +0530, Manivannan Sadhasivam wrote:
> Hi Greg,
>
> On Wed, Jan 13, 2021 at 08:56:25PM +0530, Manivannan Sadhasivam wrote:
> > Hi Greg,
> >
> > On Wed, Jan 06, 2021 at 10:44:13AM -0800, Hemant Kumar wrote:
> > > This patch series adds support for UCI driver. UCI driver enables userspace
> > > clients to communicate to external MHI devices like modem. UCI driver probe
> > > creates standard character device file nodes for userspace clients to
> > > perform open, read, write, poll and release file operations. These file
> > > operations call MHI core layer APIs to perform data transfer using MHI bus
> > > to communicate with MHI device.
> > >
> > > This interface allows exposing modem control channel(s) such as QMI, MBIM,
> > > or AT commands to userspace which can be used to configure the modem using
> > > tools such as libqmi, ModemManager, minicom (for AT), etc over MHI. This is
> > > required as there are no kernel APIs to access modem control path for device
> > > configuration. Data path transporting the network payload (IP), however, is
> > > routed to the Linux network via the mhi-net driver. Currently driver supports
> > > QMI channel. libqmi is userspace MHI client which communicates to a QMI
> > > service using QMI channel. Please refer to
> > > https://www.freedesktop.org/wiki/Software/libqmi/ for additional information
> > > on libqmi.
> > >
> > > Patch is tested using arm64 and x86 based platform.
> > >
> >
> > This series looks good to me and I'd like to merge it into mhi-next. You
> > shared your reviews on the previous revisions, so I'd like to get your
> > opinion first.
> >
>
> Ping!
Sorry, it's in my to-review queue, buried with other stuff at the
moment, but it's not lost...
greg k-h
On Wed, Jan 13, 2021 at 08:56:25PM +0530, Manivannan Sadhasivam wrote:
> Hi Greg,
>
> On Wed, Jan 06, 2021 at 10:44:13AM -0800, Hemant Kumar wrote:
> > This patch series adds support for UCI driver. UCI driver enables userspace
> > clients to communicate to external MHI devices like modem. UCI driver probe
> > creates standard character device file nodes for userspace clients to
> > perform open, read, write, poll and release file operations. These file
> > operations call MHI core layer APIs to perform data transfer using MHI bus
> > to communicate with MHI device.
> >
> > This interface allows exposing modem control channel(s) such as QMI, MBIM,
> > or AT commands to userspace which can be used to configure the modem using
> > tools such as libqmi, ModemManager, minicom (for AT), etc over MHI. This is
> > required as there are no kernel APIs to access modem control path for device
> > configuration. Data path transporting the network payload (IP), however, is
> > routed to the Linux network via the mhi-net driver. Currently driver supports
> > QMI channel. libqmi is userspace MHI client which communicates to a QMI
> > service using QMI channel. Please refer to
> > https://www.freedesktop.org/wiki/Software/libqmi/ for additional information
> > on libqmi.
> >
> > Patch is tested using arm64 and x86 based platform.
> >
>
> This series looks good to me and I'd like to merge it into mhi-next. You
> shared your reviews on the previous revisions, so I'd like to get your
> opinion first.
If you get the networking people to give you an ack on this, it's fine
with me.
thanks,
greg k-h
On 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?
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.
On Wed, 3 Feb 2021 19:28:28 +0100 Loic Poulain wrote:
> On Wed, 3 Feb 2021 at 19:05, Jakub Kicinski <[email protected]> wrote:
> > On Wed, 03 Feb 2021 09:45:06 +0530 Manivannan Sadhasivam wrote:
> > > The current patchset only supports QMI channel so I'd request you to
> > > review the chardev node created for it. The QMI chardev node created
> > > will be unique for the MHI bus and the number of nodes depends on the
> > > MHI controllers in the system (typically 1 but not limited).
> >
> > If you want to add a MHI QMI driver, please write a QMI-only driver.
> > This generic "userspace client interface" driver is a no go. Nobody will
> > have the time and attention to police what you throw in there later.
>
> Think it should be seen as filtered userspace access to MHI bus
> (filtered because not all channels are exposed), again it's not
> specific to MHI, any bus in Linux offers that (i2c, spi, usb, serial,
> etc...). It will not be specific to QMI, since we will also need it
> for MBIM (modem control path), AT commands, and GPS (NMEA frames), all
> these protocols are usually handled by userspace tools and not linked
> to any internal Linux framework, so it would be better not having a
> dedicated chardev for each of them.
The more people argue for this backdoor interface the more distrustful
of it we'll become. Keep going at your own peril.
On 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?
On Wed, 10 Feb 2021 11:55:31 +0530 Manivannan Sadhasivam wrote:
> On Tue, Feb 09, 2021 at 08:17:44AM -0800, Jakub Kicinski wrote:
> > On Tue, 9 Feb 2021 10:20:30 +0100 Aleksander Morgado wrote:
> > > This may be a stupid suggestion, but would the integration look less a
> > > backdoor if it would have been named "mhi_wwan" and it exposed already
> > > all the AT+DIAG+QMI+MBIM+NMEA possible channels as chardevs, not just
> > > QMI?
> >
> > What's DIAG? Who's going to remember that this is a backdoor driver
> > a year from now when Qualcomm sends a one liner patches which just
> > adds a single ID to open another channel?
>
> I really appreciate your feedback on this driver eventhough I'm not
> inclined with you calling this driver a "backdoor interface". But can
> you please propose a solution on how to make this driver a good one as
> per your thoughts?
>
> I really don't know what bothers you even if the userspace tools making
> use of these chardevs are available openly (you can do the audit and see
> if anything wrong we are doing).
What bothers me is maintaining shim drivers which just shuttle opaque
messages between user space and firmware. One of which definitely is,
and the other may well be, proprietary. This is an open source project,
users are supposed to be able to meaningfully change the behavior of
the system.
What bothers me is that we have 3 WWAN vendors all doing their own
thing and no common Linux API for WWAN. It may have been fine 10 years
ago, but WWAN is increasingly complex and important.
> And exposing the raw access to the
> hardware is not a new thing in kernel. There are several existing
> subsystems/drivers does this as pointed out by Bjorn. Moreover we don't
> have in-kernel APIs for the functionalities exposed by this driver and
> creating one is not feasible as explained by many.
>
> So please let us know the path forward on this series. We are open to
> any suggestions but you haven't provided one till now.
Well. You sure know how to aggravate people. I said clearly that you
can move forward on purpose build drivers (e.g. for WWAN). There is no
way forward on this common shim driver as far as I'm concerned.
On 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
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