linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RESEND PATCH v18 0/3] userspace MHI client interface driver
@ 2021-01-06 18:44 Hemant Kumar
  2021-01-06 18:44 ` [RESEND PATCH v18 1/3] bus: mhi: core: Move MHI_MAX_MTU to external header file Hemant Kumar
                   ` (3 more replies)
  0 siblings, 4 replies; 31+ messages in thread
From: Hemant Kumar @ 2021-01-06 18:44 UTC (permalink / raw)
  To: manivannan.sadhasivam, gregkh
  Cc: linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev,
	Hemant Kumar

This patch series adds support for UCI driver. UCI driver enables userspace
clients to communicate to external MHI devices like modem. UCI driver probe
creates standard character device file nodes for userspace clients to
perform open, read, write, poll and release file operations. These file
operations call MHI core layer APIs to perform data transfer using MHI bus
to communicate with MHI device. 

This interface allows exposing modem control channel(s) such as QMI, MBIM,
or AT commands to userspace which can be used to configure the modem using
tools such as libqmi, ModemManager, minicom (for AT), etc over MHI. This is
required as there are no kernel APIs to access modem control path for device
configuration. Data path transporting the network payload (IP), however, is
routed to the Linux network via the mhi-net driver. Currently driver supports
QMI channel. libqmi is userspace MHI client which communicates to a QMI
service using QMI channel. Please refer to
https://www.freedesktop.org/wiki/Software/libqmi/ for additional information
on libqmi.

Patch is tested using arm64 and x86 based platform.

V18:
- Updated commit text for UCI to clarify why this driver is required for QMI
  over MHI. Also updated cover letter with same information.

v17:
- Updated commit text for UCI driver by mentioning about libqmi open-source
  userspace program that will be talking to this UCI kernel driver.
- UCI driver depends upon patch "bus: mhi: core: Add helper API to return number
  of free TREs".

v16:
- Removed reference of WLAN as an external MHI device in documentation and
  cover letter.

v15:
- Updated documentation related to poll and release operations.

V14:
- Fixed device file node format to /dev/<mhi_dev_name> instead of
  /dev/mhi_<mhi_dev_name> because "mhi" is already part of mhi device name.
  For example old format: /dev/mhi_mhi0_QMI new format: /dev/mhi0_QMI.
- Updated MHI documentation to reflect index mhi controller name in
  QMI usage example.

V13:
- Removed LOOPBACK channel from mhi_device_id table from this patch series.
  Pushing a new patch series to add support for LOOPBACK channel and the user
  space test application. Also removed the description from kernel documentation.
- Added QMI channel to mhi_device_id table. QMI channel has existing libqmi
  support from user space.
- Updated kernel Documentation for QMI channel and provided external reference
  for libqmi.
- Updated device file node name by appending mhi device name only, which already
  includes mhi controller device name.

V12:
- Added loopback test driver under selftest/drivers/mhi. Updated kernel
  documentation for the usage of the loopback test application.
- Addressed review comments for renaming variable names, updated inline
  comments and removed two redundant dev_dbg.

V11:
- Fixed review comments for UCI documentation by expanding TLAs and rewording
  some sentences.

V10:
- Replaced mutex_lock with mutex_lock_interruptible in read() and write() file
  ops call back.

V9:
- Renamed dl_lock to dl_pending _lock and pending list to dl_pending for
  clarity.
- Used read lock to protect cur_buf.
- Change transfer status check logic and only consider 0 and -EOVERFLOW as
  only success.
- Added __int to module init function.
- Print channel name instead of minor number upon successful probe.

V8:
- Fixed kernel test robot compilation error by changing %lu to %zu for
  size_t.
- Replaced uci with UCI in Kconfig, commit text, and comments in driver
  code.
- Fixed minor style related comments.

V7:
- Decoupled uci device and uci channel objects. uci device is
  associated with device file node. uci channel is associated
  with MHI channels. uci device refers to uci channel to perform
  MHI channel operations for device file operations like read()
  and write(). uci device increments its reference count for
  every open(). uci device calls mhi_uci_dev_start_chan() to start
  the MHI channel. uci channel object is tracking number of times
  MHI channel is referred. This allows to keep the MHI channel in
  start state until last release() is called. After that uci channel
  reference count goes to 0 and uci channel clean up is performed
  which stops the MHI channel. After the last call to release() if
  driver is removed uci reference count becomes 0 and uci object is
  cleaned up.
- Use separate uci channel read and write lock to fine grain locking
  between reader and writer.
- Use uci device lock to synchronize open, release and driver remove.
- Optimize for downlink only or uplink only UCI device.

V6:
- Moved uci.c to mhi directory.
- Updated Kconfig to add module information.
- Updated Makefile to rename uci object file name as mhi_uci
- Removed kref for open count

V5:
- Removed mhi_uci_drv structure.
- Used idr instead of creating global list of uci devices.
- Used kref instead of local ref counting for uci device and
  open count.
- Removed unlikely macro.

V4:
- Fix locking to protect proper struct members.
- Updated documentation describing uci client driver use cases.
- Fixed uci ref counting in mhi_uci_open for error case.
- Addressed style related review comments.

V3: Added documentation for MHI UCI driver.

V2:
- Added mutex lock to prevent multiple readers to access same
- mhi buffer which can result into use after free.

Hemant Kumar (3):
  bus: mhi: core: Move MHI_MAX_MTU to external header file
  docs: Add documentation for userspace client interface
  bus: mhi: Add userspace client interface driver

 Documentation/mhi/index.rst     |   1 +
 Documentation/mhi/uci.rst       |  95 ++++++
 drivers/bus/mhi/Kconfig         |  13 +
 drivers/bus/mhi/Makefile        |   3 +
 drivers/bus/mhi/core/internal.h |   1 -
 drivers/bus/mhi/uci.c           | 664 ++++++++++++++++++++++++++++++++++++++++
 include/linux/mhi.h             |   3 +
 7 files changed, 779 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/mhi/uci.rst
 create mode 100644 drivers/bus/mhi/uci.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[flat|nested] 31+ messages in thread

* [RESEND PATCH v18 1/3] bus: mhi: core: Move MHI_MAX_MTU to external header file
  2021-01-06 18:44 [RESEND PATCH v18 0/3] userspace MHI client interface driver Hemant Kumar
@ 2021-01-06 18:44 ` Hemant Kumar
  2021-01-06 18:44 ` [RESEND PATCH v18 2/3] docs: Add documentation for userspace client interface Hemant Kumar
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 31+ messages in thread
From: Hemant Kumar @ 2021-01-06 18:44 UTC (permalink / raw)
  To: manivannan.sadhasivam, gregkh
  Cc: linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev,
	Hemant Kumar

Currently this macro is defined in internal MHI header as
a TRE length mask. Moving it to external header allows MHI
client drivers to set this upper bound for the transmit
buffer size.

Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Reviewed-by: Jeffrey Hugo <jhugo@codeaurora.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
 drivers/bus/mhi/core/internal.h | 1 -
 include/linux/mhi.h             | 3 +++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h
index 6f80ec3..2b9c063 100644
--- a/drivers/bus/mhi/core/internal.h
+++ b/drivers/bus/mhi/core/internal.h
@@ -453,7 +453,6 @@ enum mhi_pm_state {
 #define CMD_EL_PER_RING			128
 #define PRIMARY_CMD_RING		0
 #define MHI_DEV_WAKE_DB			127
-#define MHI_MAX_MTU			0xffff
 #define MHI_RANDOM_U32_NONZERO(bmsk)	(prandom_u32_max(bmsk) + 1)
 
 enum mhi_er_type {
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index e36d575..f072605 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -15,6 +15,9 @@
 #include <linux/wait.h>
 #include <linux/workqueue.h>
 
+/* MHI client drivers to set this upper bound for tx buffer */
+#define MHI_MAX_MTU 0xffff
+
 #define MHI_MAX_OEM_PK_HASH_SEGMENTS 16
 
 struct mhi_chan;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply related	[flat|nested] 31+ messages in thread

* [RESEND PATCH v18 2/3] docs: Add documentation for userspace client interface
  2021-01-06 18:44 [RESEND PATCH v18 0/3] userspace MHI client interface driver Hemant Kumar
  2021-01-06 18:44 ` [RESEND PATCH v18 1/3] bus: mhi: core: Move MHI_MAX_MTU to external header file Hemant Kumar
@ 2021-01-06 18:44 ` Hemant Kumar
  2021-01-06 18:44 ` [RESEND PATCH v18 3/3] bus: mhi: Add userspace client interface driver Hemant Kumar
  2021-01-13 15:26 ` [RESEND PATCH v18 0/3] userspace MHI " Manivannan Sadhasivam
  3 siblings, 0 replies; 31+ messages in thread
From: Hemant Kumar @ 2021-01-06 18:44 UTC (permalink / raw)
  To: manivannan.sadhasivam, gregkh
  Cc: linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev,
	Hemant Kumar

MHI userspace client driver is creating device file node
for user application to perform file operations. File
operations are handled by MHI core driver. Currently
QMI MHI channel is supported by this driver.

Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Reviewed-by: Jeffrey Hugo <jhugo@codeaurora.org>
---
 Documentation/mhi/index.rst |  1 +
 Documentation/mhi/uci.rst   | 95 +++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 96 insertions(+)
 create mode 100644 Documentation/mhi/uci.rst

diff --git a/Documentation/mhi/index.rst b/Documentation/mhi/index.rst
index 1d8dec3..c75a371 100644
--- a/Documentation/mhi/index.rst
+++ b/Documentation/mhi/index.rst
@@ -9,6 +9,7 @@ MHI
 
    mhi
    topology
+   uci
 
 .. only::  subproject and html
 
diff --git a/Documentation/mhi/uci.rst b/Documentation/mhi/uci.rst
new file mode 100644
index 0000000..1e0a015
--- /dev/null
+++ b/Documentation/mhi/uci.rst
@@ -0,0 +1,95 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=================================
+Userspace Client Interface (UCI)
+=================================
+
+UCI driver enables userspace clients to communicate to external MHI devices
+like modem. UCI driver probe creates standard character device file nodes for
+userspace clients to perform open, read, write, poll and release file
+operations. UCI device object represents UCI device file node which gets
+instantiated as part of MHI UCI driver probe. UCI channel object represents
+MHI uplink or downlink channel.
+
+Operations
+==========
+
+open
+----
+
+Instantiates UCI channel object and starts MHI channels to move it to running
+state. Inbound buffers are queued to downlink channel transfer ring. Every
+subsequent open() increments UCI device reference count as well as UCI channel
+reference count.
+
+read
+----
+
+When data transfer is completed on downlink channel, transfer ring element
+buffer is copied to pending list. Reader is unblocked and data is copied to
+userspace buffer. Transfer ring element buffer is queued back to downlink
+channel transfer ring.
+
+write
+-----
+
+Write buffer is queued to uplink channel transfer ring if ring is not full. Upon
+uplink transfer completion buffer is freed.
+
+poll
+----
+
+Returns EPOLLIN | EPOLLRDNORM mask if pending list has buffers to be read by
+userspace. Returns EPOLLOUT | EPOLLWRNORM mask if MHI uplink channel transfer
+ring is not empty.  When the uplink channel transfer ring is non-empty, more
+data may be sent to the device. Returns EPOLLERR when UCI driver is removed.
+
+release
+-------
+
+Decrements UCI device reference count and UCI channel reference count. Upon
+last release() UCI channel clean up is performed. MHI channel moves to disable
+state and inbound buffers are freed.
+
+Usage
+=====
+
+Device file node is created with format:-
+
+/dev/<mhi_device_name>
+
+mhi_device_name includes mhi controller name and the name of the MHI channel
+being used by MHI client in userspace to send or receive data using MHI
+protocol.
+
+There is a separate character device file node created for each channel
+specified in MHI device id table. MHI channels are statically defined by MHI
+specification. The list of supported channels is in the channel list variable
+of mhi_device_id table in UCI driver.
+
+Qualcomm MSM Interface(QMI) Channel
+-----------------------------------
+
+Qualcomm MSM Interface(QMI) is a modem control messaging protocol used to
+communicate between software components in the modem and other peripheral
+subsystems. QMI communication is of request/response type or an unsolicited
+event type. libqmi is userspace MHI client which communicates to a QMI service
+using UCI device. It sends a QMI request to a QMI service using MHI channel 14
+or 16. QMI response is received using MHI channel 15 or 17 respectively. libqmi
+is a glib-based library for talking to WWAN modems and devices which speaks QMI
+protocol. For more information about libqmi please refer
+https://www.freedesktop.org/wiki/Software/libqmi/
+
+Usage Example
+~~~~~~~~~~~~~
+
+QMI command to retrieve device mode
+$ sudo qmicli -d /dev/mhi0_QMI --dms-get-model
+[/dev/mhi0_QMI] Device model retrieved:
+    Model: 'FN980m'
+
+Other Use Cases
+---------------
+
+Getting MHI device specific diagnostics information to userspace MHI diagnostic
+client using DIAG channel 4 (Host to device) and 5 (Device to Host).
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply related	[flat|nested] 31+ messages in thread

* [RESEND PATCH v18 3/3] bus: mhi: Add userspace client interface driver
  2021-01-06 18:44 [RESEND PATCH v18 0/3] userspace MHI client interface driver Hemant Kumar
  2021-01-06 18:44 ` [RESEND PATCH v18 1/3] bus: mhi: core: Move MHI_MAX_MTU to external header file Hemant Kumar
  2021-01-06 18:44 ` [RESEND PATCH v18 2/3] docs: Add documentation for userspace client interface Hemant Kumar
@ 2021-01-06 18:44 ` Hemant Kumar
  2021-01-13 15:26 ` [RESEND PATCH v18 0/3] userspace MHI " Manivannan Sadhasivam
  3 siblings, 0 replies; 31+ messages in thread
From: Hemant Kumar @ 2021-01-06 18:44 UTC (permalink / raw)
  To: manivannan.sadhasivam, gregkh
  Cc: linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev,
	Hemant Kumar

This MHI client driver allows userspace clients to transfer
raw data between MHI device and host using standard file operations.
Driver instantiates UCI device object which is associated to device
file node. UCI device object instantiates UCI channel object when device
file node is opened. UCI channel object is used to manage MHI channels
by calling MHI core APIs for read and write operations. MHI channels
are started as part of device open(). MHI channels remain in start
state until last release() is called on UCI device file node. Device
file node is created with format

/dev/<mhi_device_name>

This interface allows exposing modem control channel(s) such as QMI, MBIM,
or AT commands to userspace which can be used to configure the modem using
tools such as libqmi, ModemManager, minicom (for AT), etc over MHI. This is
required as there are no kernel APIs to access modem control path for device
configuration. Data path transporting the network payload (IP), however, is
routed to the Linux network via the mhi-net driver. Currently driver supports
QMI channel. libqmi is userspace MHI client which communicates to a QMI
service using QMI channel. Please refer to
https://www.freedesktop.org/wiki/Software/libqmi/ for additional information
on libqmi.

Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Jeffrey Hugo <jhugo@codeaurora.org>
Tested-by: Loic Poulain <loic.poulain@linaro.org>
---
 drivers/bus/mhi/Kconfig  |  13 +
 drivers/bus/mhi/Makefile |   3 +
 drivers/bus/mhi/uci.c    | 664 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 680 insertions(+)
 create mode 100644 drivers/bus/mhi/uci.c

diff --git a/drivers/bus/mhi/Kconfig b/drivers/bus/mhi/Kconfig
index da5cd0c..5194e8e 100644
--- a/drivers/bus/mhi/Kconfig
+++ b/drivers/bus/mhi/Kconfig
@@ -29,3 +29,16 @@ config MHI_BUS_PCI_GENERIC
 	  This driver provides MHI PCI controller driver for devices such as
 	  Qualcomm SDX55 based PCIe modems.
 
+config MHI_UCI
+	tristate "MHI UCI"
+	depends on MHI_BUS
+	help
+	  MHI based Userspace Client Interface (UCI) driver is used for
+	  transferring raw data between host and device using standard file
+	  operations from userspace. Open, read, write, poll and close
+	  operations are supported by this driver. Please check
+	  mhi_uci_match_table for all supported channels that are exposed to
+	  userspace.
+
+	  To compile this driver as a module, choose M here: the module will be
+	  called mhi_uci.
diff --git a/drivers/bus/mhi/Makefile b/drivers/bus/mhi/Makefile
index 0a2d778..69f2111 100644
--- a/drivers/bus/mhi/Makefile
+++ b/drivers/bus/mhi/Makefile
@@ -4,3 +4,6 @@ obj-y += core/
 obj-$(CONFIG_MHI_BUS_PCI_GENERIC) += mhi_pci_generic.o
 mhi_pci_generic-y += pci_generic.o
 
+# MHI client
+mhi_uci-y := uci.o
+obj-$(CONFIG_MHI_UCI) += mhi_uci.o
diff --git a/drivers/bus/mhi/uci.c b/drivers/bus/mhi/uci.c
new file mode 100644
index 0000000..1df2377
--- /dev/null
+++ b/drivers/bus/mhi/uci.c
@@ -0,0 +1,664 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright (c) 2018-2020, The Linux Foundation. All rights reserved.*/
+
+#include <linux/kernel.h>
+#include <linux/mhi.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/poll.h>
+
+#define MHI_UCI_DRIVER_NAME "mhi_uci"
+#define MHI_MAX_UCI_MINORS 128
+
+static DEFINE_IDR(uci_idr);
+static DEFINE_MUTEX(uci_drv_mutex);
+static struct class *uci_dev_class;
+static int uci_dev_major;
+
+/**
+ * struct uci_chan - MHI channel for a UCI device
+ * @udev: associated UCI device object
+ * @ul_wq: wait queue for writer
+ * @write_lock: mutex write lock for ul channel
+ * @dl_wq: wait queue for reader
+ * @read_lock: mutex read lock for dl channel
+ * @dl_pending_lock: spin lock for dl_pending list
+ * @dl_pending: list of dl buffers userspace is waiting to read
+ * @cur_buf: current buffer userspace is reading
+ * @dl_size: size of the current dl buffer userspace is reading
+ * @ref_count: uci_chan reference count
+ */
+struct uci_chan {
+	struct uci_dev *udev;
+	wait_queue_head_t ul_wq;
+
+	/* ul channel lock to synchronize multiple writes */
+	struct mutex write_lock;
+
+	wait_queue_head_t dl_wq;
+
+	/* dl channel lock to synchronize multiple reads */
+	struct mutex read_lock;
+
+	/*
+	 * protects pending list in bh context, channel release, read and
+	 * poll
+	 */
+	spinlock_t dl_pending_lock;
+
+	struct list_head dl_pending;
+	struct uci_buf *cur_buf;
+	size_t dl_size;
+	struct kref ref_count;
+};
+
+/**
+ * struct uci_buf - UCI buffer
+ * @data: data buffer
+ * @len: length of data buffer
+ * @node: list node of the UCI buffer
+ */
+struct uci_buf {
+	void *data;
+	size_t len;
+	struct list_head node;
+};
+
+/**
+ * struct uci_dev - MHI UCI device
+ * @minor: UCI device node minor number
+ * @mhi_dev: associated mhi device object
+ * @uchan: UCI uplink and downlink channel object
+ * @mtu: max TRE buffer length
+ * @enabled: Flag to track the state of the UCI device
+ * @lock: mutex lock to manage uchan object
+ * @ref_count: uci_dev reference count
+ */
+struct uci_dev {
+	unsigned int minor;
+	struct mhi_device *mhi_dev;
+	struct uci_chan *uchan;
+	size_t mtu;
+	bool enabled;
+
+	/* synchronize open, release and driver remove */
+	struct mutex lock;
+	struct kref ref_count;
+};
+
+static void mhi_uci_dev_chan_release(struct kref *ref)
+{
+	struct uci_buf *buf_itr, *tmp;
+	struct uci_chan *uchan =
+		container_of(ref, struct uci_chan, ref_count);
+
+	if (uchan->udev->enabled)
+		mhi_unprepare_from_transfer(uchan->udev->mhi_dev);
+
+	spin_lock_bh(&uchan->dl_pending_lock);
+	list_for_each_entry_safe(buf_itr, tmp, &uchan->dl_pending, node) {
+		list_del(&buf_itr->node);
+		kfree(buf_itr->data);
+	}
+	spin_unlock_bh(&uchan->dl_pending_lock);
+
+	wake_up(&uchan->ul_wq);
+	wake_up(&uchan->dl_wq);
+
+	mutex_lock(&uchan->read_lock);
+	if (uchan->cur_buf)
+		kfree(uchan->cur_buf->data);
+
+	uchan->cur_buf = NULL;
+	mutex_unlock(&uchan->read_lock);
+
+	mutex_destroy(&uchan->write_lock);
+	mutex_destroy(&uchan->read_lock);
+
+	uchan->udev->uchan = NULL;
+	kfree(uchan);
+}
+
+static int mhi_queue_inbound(struct uci_dev *udev)
+{
+	struct mhi_device *mhi_dev = udev->mhi_dev;
+	struct device *dev = &mhi_dev->dev;
+	int nr_desc, i, ret = -EIO;
+	size_t dl_buf_size;
+	void *buf;
+	struct uci_buf *ubuf;
+
+	/*
+	 * skip queuing without error if dl channel is not supported. This
+	 * allows open to succeed for udev, supporting ul only channel.
+	 */
+	if (!udev->mhi_dev->dl_chan)
+		return 0;
+
+	nr_desc = mhi_get_free_desc_count(mhi_dev, DMA_FROM_DEVICE);
+
+	for (i = 0; i < nr_desc; i++) {
+		buf = kmalloc(udev->mtu, GFP_KERNEL);
+		if (!buf)
+			return -ENOMEM;
+
+		dl_buf_size = udev->mtu - sizeof(*ubuf);
+
+		/* save uci_buf info at the end of buf */
+		ubuf = buf + dl_buf_size;
+		ubuf->data = buf;
+
+		dev_dbg(dev, "Allocated buf %d of %d size %zu\n", i, nr_desc,
+			dl_buf_size);
+
+		ret = mhi_queue_buf(mhi_dev, DMA_FROM_DEVICE, buf, dl_buf_size,
+				    MHI_EOT);
+		if (ret) {
+			kfree(buf);
+			dev_err(dev, "Failed to queue buffer %d\n", i);
+			return ret;
+		}
+	}
+
+	return ret;
+}
+
+static int mhi_uci_dev_start_chan(struct uci_dev *udev)
+{
+	int ret = 0;
+	struct uci_chan *uchan;
+
+	mutex_lock(&udev->lock);
+	if (!udev->uchan || !kref_get_unless_zero(&udev->uchan->ref_count)) {
+		uchan = kzalloc(sizeof(*uchan), GFP_KERNEL);
+		if (!uchan) {
+			ret = -ENOMEM;
+			goto error_chan_start;
+		}
+
+		udev->uchan = uchan;
+		uchan->udev = udev;
+		init_waitqueue_head(&uchan->ul_wq);
+		init_waitqueue_head(&uchan->dl_wq);
+		mutex_init(&uchan->write_lock);
+		mutex_init(&uchan->read_lock);
+		spin_lock_init(&uchan->dl_pending_lock);
+		INIT_LIST_HEAD(&uchan->dl_pending);
+
+		ret = mhi_prepare_for_transfer(udev->mhi_dev);
+		if (ret) {
+			dev_err(&udev->mhi_dev->dev, "Error starting transfer channels\n");
+			goto error_chan_cleanup;
+		}
+
+		ret = mhi_queue_inbound(udev);
+		if (ret)
+			goto error_chan_cleanup;
+
+		kref_init(&uchan->ref_count);
+	}
+
+	mutex_unlock(&udev->lock);
+
+	return 0;
+
+error_chan_cleanup:
+	mhi_uci_dev_chan_release(&uchan->ref_count);
+error_chan_start:
+	mutex_unlock(&udev->lock);
+	return ret;
+}
+
+static void mhi_uci_dev_release(struct kref *ref)
+{
+	struct uci_dev *udev =
+		container_of(ref, struct uci_dev, ref_count);
+
+	mutex_destroy(&udev->lock);
+
+	kfree(udev);
+}
+
+static int mhi_uci_open(struct inode *inode, struct file *filp)
+{
+	unsigned int minor = iminor(inode);
+	struct uci_dev *udev = NULL;
+	int ret;
+
+	mutex_lock(&uci_drv_mutex);
+	udev = idr_find(&uci_idr, minor);
+	if (!udev) {
+		pr_debug("uci dev: minor %d not found\n", minor);
+		mutex_unlock(&uci_drv_mutex);
+		return -ENODEV;
+	}
+
+	kref_get(&udev->ref_count);
+	mutex_unlock(&uci_drv_mutex);
+
+	ret = mhi_uci_dev_start_chan(udev);
+	if (ret) {
+		kref_put(&udev->ref_count, mhi_uci_dev_release);
+		return ret;
+	}
+
+	filp->private_data = udev;
+
+	return 0;
+}
+
+static int mhi_uci_release(struct inode *inode, struct file *file)
+{
+	struct uci_dev *udev = file->private_data;
+
+	mutex_lock(&udev->lock);
+	kref_put(&udev->uchan->ref_count, mhi_uci_dev_chan_release);
+	mutex_unlock(&udev->lock);
+
+	kref_put(&udev->ref_count, mhi_uci_dev_release);
+
+	return 0;
+}
+
+static __poll_t mhi_uci_poll(struct file *file, poll_table *wait)
+{
+	struct uci_dev *udev = file->private_data;
+	struct mhi_device *mhi_dev = udev->mhi_dev;
+	struct device *dev = &mhi_dev->dev;
+	struct uci_chan *uchan = udev->uchan;
+	__poll_t mask = 0;
+
+	poll_wait(file, &udev->uchan->ul_wq, wait);
+	poll_wait(file, &udev->uchan->dl_wq, wait);
+
+	if (!udev->enabled) {
+		mask = EPOLLERR;
+		goto done;
+	}
+
+	spin_lock_bh(&uchan->dl_pending_lock);
+	if (!list_empty(&uchan->dl_pending) || uchan->cur_buf)
+		mask |= EPOLLIN | EPOLLRDNORM;
+	spin_unlock_bh(&uchan->dl_pending_lock);
+
+	if (mhi_get_free_desc_count(mhi_dev, DMA_TO_DEVICE) > 0)
+		mask |= EPOLLOUT | EPOLLWRNORM;
+
+	dev_dbg(dev, "Client attempted to poll, returning mask 0x%x\n", mask);
+
+done:
+	return mask;
+}
+
+static ssize_t mhi_uci_write(struct file *file,
+			     const char __user *buf,
+			     size_t count,
+			     loff_t *offp)
+{
+	struct uci_dev *udev = file->private_data;
+	struct mhi_device *mhi_dev = udev->mhi_dev;
+	struct device *dev = &mhi_dev->dev;
+	struct uci_chan *uchan = udev->uchan;
+	size_t bytes_xfered = 0;
+	int ret, nr_desc = 0;
+
+	/* if ul channel is not supported return error */
+	if (!mhi_dev->ul_chan)
+		return -EOPNOTSUPP;
+
+	if (!buf || !count)
+		return -EINVAL;
+
+	dev_dbg(dev, "%s: to xfer: %zu bytes\n", __func__, count);
+
+	if (mutex_lock_interruptible(&uchan->write_lock))
+		return -EINTR;
+
+	while (count) {
+		size_t xfer_size;
+		void *kbuf;
+		enum mhi_flags flags;
+
+		/* wait for free descriptors */
+		ret = wait_event_interruptible(uchan->ul_wq,
+					       (!udev->enabled) ||
+				(nr_desc = mhi_get_free_desc_count(mhi_dev,
+					       DMA_TO_DEVICE)) > 0);
+
+		if (ret == -ERESTARTSYS) {
+			dev_dbg(dev, "Interrupted by a signal in %s, exiting\n",
+				__func__);
+			goto err_mtx_unlock;
+		}
+
+		if (!udev->enabled) {
+			ret = -ENODEV;
+			goto err_mtx_unlock;
+		}
+
+		xfer_size = min_t(size_t, count, udev->mtu);
+		kbuf = kmalloc(xfer_size, GFP_KERNEL);
+		if (!kbuf) {
+			ret = -ENOMEM;
+			goto err_mtx_unlock;
+		}
+
+		ret = copy_from_user(kbuf, buf, xfer_size);
+		if (ret) {
+			kfree(kbuf);
+			ret = -EFAULT;
+			goto err_mtx_unlock;
+		}
+
+		/* if ring is full after this force EOT */
+		if (nr_desc > 1 && (count - xfer_size))
+			flags = MHI_CHAIN;
+		else
+			flags = MHI_EOT;
+
+		ret = mhi_queue_buf(mhi_dev, DMA_TO_DEVICE, kbuf, xfer_size,
+				    flags);
+		if (ret) {
+			kfree(kbuf);
+			goto err_mtx_unlock;
+		}
+
+		bytes_xfered += xfer_size;
+		count -= xfer_size;
+		buf += xfer_size;
+	}
+
+	mutex_unlock(&uchan->write_lock);
+	dev_dbg(dev, "%s: bytes xferred: %zu\n", __func__, bytes_xfered);
+
+	return bytes_xfered;
+
+err_mtx_unlock:
+	mutex_unlock(&uchan->write_lock);
+
+	return ret;
+}
+
+static ssize_t mhi_uci_read(struct file *file,
+			    char __user *buf,
+			    size_t count,
+			    loff_t *ppos)
+{
+	struct uci_dev *udev = file->private_data;
+	struct mhi_device *mhi_dev = udev->mhi_dev;
+	struct uci_chan *uchan = udev->uchan;
+	struct device *dev = &mhi_dev->dev;
+	struct uci_buf *ubuf;
+	size_t rx_buf_size;
+	char *ptr;
+	size_t to_copy;
+	int ret = 0;
+
+	/* if dl channel is not supported return error */
+	if (!mhi_dev->dl_chan)
+		return -EOPNOTSUPP;
+
+	if (!buf)
+		return -EINVAL;
+
+	if (mutex_lock_interruptible(&uchan->read_lock))
+		return -EINTR;
+
+	spin_lock_bh(&uchan->dl_pending_lock);
+	/* No data available to read, wait */
+	if (!uchan->cur_buf && list_empty(&uchan->dl_pending)) {
+		dev_dbg(dev, "No data available to read, waiting\n");
+
+		spin_unlock_bh(&uchan->dl_pending_lock);
+		ret = wait_event_interruptible(uchan->dl_wq,
+					       (!udev->enabled ||
+					      !list_empty(&uchan->dl_pending)));
+
+		if (ret == -ERESTARTSYS) {
+			dev_dbg(dev, "Interrupted by a signal in %s, exiting\n",
+				__func__);
+			goto err_mtx_unlock;
+		}
+
+		if (!udev->enabled) {
+			ret = -ENODEV;
+			goto err_mtx_unlock;
+		}
+		spin_lock_bh(&uchan->dl_pending_lock);
+	}
+
+	/* new read, get the next descriptor from the list */
+	if (!uchan->cur_buf) {
+		ubuf = list_first_entry_or_null(&uchan->dl_pending,
+						struct uci_buf, node);
+		if (!ubuf) {
+			ret = -EIO;
+			goto err_spin_unlock;
+		}
+
+		list_del(&ubuf->node);
+		uchan->cur_buf = ubuf;
+		uchan->dl_size = ubuf->len;
+		dev_dbg(dev, "Got pkt of size: %zu\n", uchan->dl_size);
+	}
+	spin_unlock_bh(&uchan->dl_pending_lock);
+
+	ubuf = uchan->cur_buf;
+
+	/* Copy the buffer to user space */
+	to_copy = min_t(size_t, count, uchan->dl_size);
+	ptr = ubuf->data + (ubuf->len - uchan->dl_size);
+
+	ret = copy_to_user(buf, ptr, to_copy);
+	if (ret) {
+		ret = -EFAULT;
+		goto err_mtx_unlock;
+	}
+
+	dev_dbg(dev, "Copied %zu of %zu bytes\n", to_copy, uchan->dl_size);
+	uchan->dl_size -= to_copy;
+
+	/* we finished with this buffer, queue it back to hardware */
+	if (!uchan->dl_size) {
+		uchan->cur_buf = NULL;
+
+		rx_buf_size = udev->mtu - sizeof(*ubuf);
+		ret = mhi_queue_buf(mhi_dev, DMA_FROM_DEVICE, ubuf->data,
+				    rx_buf_size, MHI_EOT);
+		if (ret) {
+			dev_err(dev, "Failed to recycle element: %d\n", ret);
+			kfree(ubuf->data);
+			goto err_mtx_unlock;
+		}
+	}
+	mutex_unlock(&uchan->read_lock);
+
+	dev_dbg(dev, "%s: Returning %zu bytes\n", __func__, to_copy);
+
+	return to_copy;
+
+err_spin_unlock:
+	spin_unlock_bh(&uchan->dl_pending_lock);
+err_mtx_unlock:
+	mutex_unlock(&uchan->read_lock);
+	return ret;
+}
+
+static const struct file_operations mhidev_fops = {
+	.owner = THIS_MODULE,
+	.open = mhi_uci_open,
+	.release = mhi_uci_release,
+	.read = mhi_uci_read,
+	.write = mhi_uci_write,
+	.poll = mhi_uci_poll,
+};
+
+static void mhi_ul_xfer_cb(struct mhi_device *mhi_dev,
+			   struct mhi_result *mhi_result)
+{
+	struct uci_dev *udev = dev_get_drvdata(&mhi_dev->dev);
+	struct uci_chan *uchan = udev->uchan;
+	struct device *dev = &mhi_dev->dev;
+
+	dev_dbg(dev, "%s: status: %d xfer_len: %zu\n", __func__,
+		mhi_result->transaction_status, mhi_result->bytes_xferd);
+
+	kfree(mhi_result->buf_addr);
+
+	if (!mhi_result->transaction_status)
+		wake_up(&uchan->ul_wq);
+}
+
+static void mhi_dl_xfer_cb(struct mhi_device *mhi_dev,
+			   struct mhi_result *mhi_result)
+{
+	struct uci_dev *udev = dev_get_drvdata(&mhi_dev->dev);
+	struct uci_chan *uchan = udev->uchan;
+	struct device *dev = &mhi_dev->dev;
+	struct uci_buf *ubuf;
+	size_t dl_buf_size = udev->mtu - sizeof(*ubuf);
+
+	dev_dbg(dev, "%s: status: %d receive_len: %zu\n", __func__,
+		mhi_result->transaction_status, mhi_result->bytes_xferd);
+
+	if (mhi_result->transaction_status &&
+	    mhi_result->transaction_status != -EOVERFLOW) {
+		kfree(mhi_result->buf_addr);
+		return;
+	}
+
+	ubuf = mhi_result->buf_addr + dl_buf_size;
+	ubuf->data = mhi_result->buf_addr;
+	ubuf->len = mhi_result->bytes_xferd;
+	spin_lock_bh(&uchan->dl_pending_lock);
+	list_add_tail(&ubuf->node, &uchan->dl_pending);
+	spin_unlock_bh(&uchan->dl_pending_lock);
+
+	wake_up(&uchan->dl_wq);
+}
+
+static int mhi_uci_probe(struct mhi_device *mhi_dev,
+			 const struct mhi_device_id *id)
+{
+	struct uci_dev *udev;
+	struct device *dev;
+	int index;
+
+	udev = kzalloc(sizeof(*udev), GFP_KERNEL);
+	if (!udev)
+		return -ENOMEM;
+
+	kref_init(&udev->ref_count);
+	mutex_init(&udev->lock);
+	udev->mhi_dev = mhi_dev;
+
+	mutex_lock(&uci_drv_mutex);
+	index = idr_alloc(&uci_idr, udev, 0, MHI_MAX_UCI_MINORS, GFP_KERNEL);
+	mutex_unlock(&uci_drv_mutex);
+	if (index < 0) {
+		kfree(udev);
+		return index;
+	}
+
+	udev->minor = index;
+
+	udev->mtu = min_t(size_t, id->driver_data, MHI_MAX_MTU);
+	dev_set_drvdata(&mhi_dev->dev, udev);
+	udev->enabled = true;
+
+	/* create device file node /dev/<mhi_dev_name> */
+	dev = device_create(uci_dev_class, &mhi_dev->dev,
+			    MKDEV(uci_dev_major, index), udev, "%s",
+			    dev_name(&mhi_dev->dev));
+	if (IS_ERR(dev)) {
+		mutex_lock(&uci_drv_mutex);
+		idr_remove(&uci_idr, udev->minor);
+		mutex_unlock(&uci_drv_mutex);
+		dev_set_drvdata(&mhi_dev->dev, NULL);
+		kfree(udev);
+		return PTR_ERR(dev);
+	}
+
+	dev_dbg(&mhi_dev->dev, "probed uci dev: %s\n", id->chan);
+
+	return 0;
+};
+
+static void mhi_uci_remove(struct mhi_device *mhi_dev)
+{
+	struct uci_dev *udev = dev_get_drvdata(&mhi_dev->dev);
+
+	/* disable the node */
+	mutex_lock(&udev->lock);
+	udev->enabled = false;
+
+	/* delete the node to prevent new opens */
+	device_destroy(uci_dev_class, MKDEV(uci_dev_major, udev->minor));
+
+	/* return error for any blocked read or write */
+	if (udev->uchan) {
+		wake_up(&udev->uchan->ul_wq);
+		wake_up(&udev->uchan->dl_wq);
+	}
+	mutex_unlock(&udev->lock);
+
+	mutex_lock(&uci_drv_mutex);
+	idr_remove(&uci_idr, udev->minor);
+	kref_put(&udev->ref_count, mhi_uci_dev_release);
+	mutex_unlock(&uci_drv_mutex);
+}
+
+/* .driver_data stores max mtu */
+static const struct mhi_device_id mhi_uci_match_table[] = {
+	{ .chan = "QMI", .driver_data = 0x1000},
+	{},
+};
+MODULE_DEVICE_TABLE(mhi, mhi_uci_match_table);
+
+static struct mhi_driver mhi_uci_driver = {
+	.id_table = mhi_uci_match_table,
+	.remove = mhi_uci_remove,
+	.probe = mhi_uci_probe,
+	.ul_xfer_cb = mhi_ul_xfer_cb,
+	.dl_xfer_cb = mhi_dl_xfer_cb,
+	.driver = {
+		.name = MHI_UCI_DRIVER_NAME,
+	},
+};
+
+static int __init mhi_uci_init(void)
+{
+	int ret;
+
+	ret = register_chrdev(0, MHI_UCI_DRIVER_NAME, &mhidev_fops);
+	if (ret < 0)
+		return ret;
+
+	uci_dev_major = ret;
+	uci_dev_class = class_create(THIS_MODULE, MHI_UCI_DRIVER_NAME);
+	if (IS_ERR(uci_dev_class)) {
+		unregister_chrdev(uci_dev_major, MHI_UCI_DRIVER_NAME);
+		return PTR_ERR(uci_dev_class);
+	}
+
+	ret = mhi_driver_register(&mhi_uci_driver);
+	if (ret) {
+		class_destroy(uci_dev_class);
+		unregister_chrdev(uci_dev_major, MHI_UCI_DRIVER_NAME);
+	}
+
+	return ret;
+}
+
+static void __exit mhi_uci_exit(void)
+{
+	mhi_driver_unregister(&mhi_uci_driver);
+	class_destroy(uci_dev_class);
+	unregister_chrdev(uci_dev_major, MHI_UCI_DRIVER_NAME);
+	idr_destroy(&uci_idr);
+}
+
+module_init(mhi_uci_init);
+module_exit(mhi_uci_exit);
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("MHI UCI Driver");
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply related	[flat|nested] 31+ messages in thread

* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
  2021-01-06 18:44 [RESEND PATCH v18 0/3] userspace MHI client interface driver Hemant Kumar
                   ` (2 preceding siblings ...)
  2021-01-06 18:44 ` [RESEND PATCH v18 3/3] bus: mhi: Add userspace client interface driver Hemant Kumar
@ 2021-01-13 15:26 ` Manivannan Sadhasivam
  2021-01-19  9:42   ` Manivannan Sadhasivam
  2021-01-27 15:15   ` Greg KH
  3 siblings, 2 replies; 31+ messages in thread
From: Manivannan Sadhasivam @ 2021-01-13 15:26 UTC (permalink / raw)
  To: gregkh
  Cc: gregkh, linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev

Hi Greg,

On Wed, Jan 06, 2021 at 10:44:13AM -0800, Hemant Kumar wrote:
> This patch series adds support for UCI driver. UCI driver enables userspace
> clients to communicate to external MHI devices like modem. UCI driver probe
> creates standard character device file nodes for userspace clients to
> perform open, read, write, poll and release file operations. These file
> operations call MHI core layer APIs to perform data transfer using MHI bus
> to communicate with MHI device. 
> 
> This interface allows exposing modem control channel(s) such as QMI, MBIM,
> or AT commands to userspace which can be used to configure the modem using
> tools such as libqmi, ModemManager, minicom (for AT), etc over MHI. This is
> required as there are no kernel APIs to access modem control path for device
> configuration. Data path transporting the network payload (IP), however, is
> routed to the Linux network via the mhi-net driver. Currently driver supports
> QMI channel. libqmi is userspace MHI client which communicates to a QMI
> service using QMI channel. Please refer to
> https://www.freedesktop.org/wiki/Software/libqmi/ for additional information
> on libqmi.
> 
> Patch is tested using arm64 and x86 based platform.
> 

This series looks good to me and I'd like to merge it into mhi-next. You
shared your reviews on the previous revisions, so I'd like to get your
opinion first.

Thanks,
Mani

> V18:
> - Updated commit text for UCI to clarify why this driver is required for QMI
>   over MHI. Also updated cover letter with same information.
> 
> v17:
> - Updated commit text for UCI driver by mentioning about libqmi open-source
>   userspace program that will be talking to this UCI kernel driver.
> - UCI driver depends upon patch "bus: mhi: core: Add helper API to return number
>   of free TREs".
> 
> v16:
> - Removed reference of WLAN as an external MHI device in documentation and
>   cover letter.
> 
> v15:
> - Updated documentation related to poll and release operations.
> 
> V14:
> - Fixed device file node format to /dev/<mhi_dev_name> instead of
>   /dev/mhi_<mhi_dev_name> because "mhi" is already part of mhi device name.
>   For example old format: /dev/mhi_mhi0_QMI new format: /dev/mhi0_QMI.
> - Updated MHI documentation to reflect index mhi controller name in
>   QMI usage example.
> 
> V13:
> - Removed LOOPBACK channel from mhi_device_id table from this patch series.
>   Pushing a new patch series to add support for LOOPBACK channel and the user
>   space test application. Also removed the description from kernel documentation.
> - Added QMI channel to mhi_device_id table. QMI channel has existing libqmi
>   support from user space.
> - Updated kernel Documentation for QMI channel and provided external reference
>   for libqmi.
> - Updated device file node name by appending mhi device name only, which already
>   includes mhi controller device name.
> 
> V12:
> - Added loopback test driver under selftest/drivers/mhi. Updated kernel
>   documentation for the usage of the loopback test application.
> - Addressed review comments for renaming variable names, updated inline
>   comments and removed two redundant dev_dbg.
> 
> V11:
> - Fixed review comments for UCI documentation by expanding TLAs and rewording
>   some sentences.
> 
> V10:
> - Replaced mutex_lock with mutex_lock_interruptible in read() and write() file
>   ops call back.
> 
> V9:
> - Renamed dl_lock to dl_pending _lock and pending list to dl_pending for
>   clarity.
> - Used read lock to protect cur_buf.
> - Change transfer status check logic and only consider 0 and -EOVERFLOW as
>   only success.
> - Added __int to module init function.
> - Print channel name instead of minor number upon successful probe.
> 
> V8:
> - Fixed kernel test robot compilation error by changing %lu to %zu for
>   size_t.
> - Replaced uci with UCI in Kconfig, commit text, and comments in driver
>   code.
> - Fixed minor style related comments.
> 
> V7:
> - Decoupled uci device and uci channel objects. uci device is
>   associated with device file node. uci channel is associated
>   with MHI channels. uci device refers to uci channel to perform
>   MHI channel operations for device file operations like read()
>   and write(). uci device increments its reference count for
>   every open(). uci device calls mhi_uci_dev_start_chan() to start
>   the MHI channel. uci channel object is tracking number of times
>   MHI channel is referred. This allows to keep the MHI channel in
>   start state until last release() is called. After that uci channel
>   reference count goes to 0 and uci channel clean up is performed
>   which stops the MHI channel. After the last call to release() if
>   driver is removed uci reference count becomes 0 and uci object is
>   cleaned up.
> - Use separate uci channel read and write lock to fine grain locking
>   between reader and writer.
> - Use uci device lock to synchronize open, release and driver remove.
> - Optimize for downlink only or uplink only UCI device.
> 
> V6:
> - Moved uci.c to mhi directory.
> - Updated Kconfig to add module information.
> - Updated Makefile to rename uci object file name as mhi_uci
> - Removed kref for open count
> 
> V5:
> - Removed mhi_uci_drv structure.
> - Used idr instead of creating global list of uci devices.
> - Used kref instead of local ref counting for uci device and
>   open count.
> - Removed unlikely macro.
> 
> V4:
> - Fix locking to protect proper struct members.
> - Updated documentation describing uci client driver use cases.
> - Fixed uci ref counting in mhi_uci_open for error case.
> - Addressed style related review comments.
> 
> V3: Added documentation for MHI UCI driver.
> 
> V2:
> - Added mutex lock to prevent multiple readers to access same
> - mhi buffer which can result into use after free.
> 
> Hemant Kumar (3):
>   bus: mhi: core: Move MHI_MAX_MTU to external header file
>   docs: Add documentation for userspace client interface
>   bus: mhi: Add userspace client interface driver
> 
>  Documentation/mhi/index.rst     |   1 +
>  Documentation/mhi/uci.rst       |  95 ++++++
>  drivers/bus/mhi/Kconfig         |  13 +
>  drivers/bus/mhi/Makefile        |   3 +
>  drivers/bus/mhi/core/internal.h |   1 -
>  drivers/bus/mhi/uci.c           | 664 ++++++++++++++++++++++++++++++++++++++++
>  include/linux/mhi.h             |   3 +
>  7 files changed, 779 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/mhi/uci.rst
>  create mode 100644 drivers/bus/mhi/uci.c
> 
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
  2021-01-13 15:26 ` [RESEND PATCH v18 0/3] userspace MHI " Manivannan Sadhasivam
@ 2021-01-19  9:42   ` Manivannan Sadhasivam
  2021-01-19 10:28     ` Greg KH
  2021-01-27 15:15   ` Greg KH
  1 sibling, 1 reply; 31+ messages in thread
From: Manivannan Sadhasivam @ 2021-01-19  9:42 UTC (permalink / raw)
  To: gregkh
  Cc: linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev,
	hemantk

Hi Greg,

On Wed, Jan 13, 2021 at 08:56:25PM +0530, Manivannan Sadhasivam wrote:
> Hi Greg,
> 
> On Wed, Jan 06, 2021 at 10:44:13AM -0800, Hemant Kumar wrote:
> > This patch series adds support for UCI driver. UCI driver enables userspace
> > clients to communicate to external MHI devices like modem. UCI driver probe
> > creates standard character device file nodes for userspace clients to
> > perform open, read, write, poll and release file operations. These file
> > operations call MHI core layer APIs to perform data transfer using MHI bus
> > to communicate with MHI device. 
> > 
> > This interface allows exposing modem control channel(s) such as QMI, MBIM,
> > or AT commands to userspace which can be used to configure the modem using
> > tools such as libqmi, ModemManager, minicom (for AT), etc over MHI. This is
> > required as there are no kernel APIs to access modem control path for device
> > configuration. Data path transporting the network payload (IP), however, is
> > routed to the Linux network via the mhi-net driver. Currently driver supports
> > QMI channel. libqmi is userspace MHI client which communicates to a QMI
> > service using QMI channel. Please refer to
> > https://www.freedesktop.org/wiki/Software/libqmi/ for additional information
> > on libqmi.
> > 
> > Patch is tested using arm64 and x86 based platform.
> > 
> 
> This series looks good to me and I'd like to merge it into mhi-next. You
> shared your reviews on the previous revisions, so I'd like to get your
> opinion first.
> 

Ping!

Thanks,
Mani

> Thanks,
> Mani
> 
> > V18:
> > - Updated commit text for UCI to clarify why this driver is required for QMI
> >   over MHI. Also updated cover letter with same information.
> > 
> > v17:
> > - Updated commit text for UCI driver by mentioning about libqmi open-source
> >   userspace program that will be talking to this UCI kernel driver.
> > - UCI driver depends upon patch "bus: mhi: core: Add helper API to return number
> >   of free TREs".
> > 
> > v16:
> > - Removed reference of WLAN as an external MHI device in documentation and
> >   cover letter.
> > 
> > v15:
> > - Updated documentation related to poll and release operations.
> > 
> > V14:
> > - Fixed device file node format to /dev/<mhi_dev_name> instead of
> >   /dev/mhi_<mhi_dev_name> because "mhi" is already part of mhi device name.
> >   For example old format: /dev/mhi_mhi0_QMI new format: /dev/mhi0_QMI.
> > - Updated MHI documentation to reflect index mhi controller name in
> >   QMI usage example.
> > 
> > V13:
> > - Removed LOOPBACK channel from mhi_device_id table from this patch series.
> >   Pushing a new patch series to add support for LOOPBACK channel and the user
> >   space test application. Also removed the description from kernel documentation.
> > - Added QMI channel to mhi_device_id table. QMI channel has existing libqmi
> >   support from user space.
> > - Updated kernel Documentation for QMI channel and provided external reference
> >   for libqmi.
> > - Updated device file node name by appending mhi device name only, which already
> >   includes mhi controller device name.
> > 
> > V12:
> > - Added loopback test driver under selftest/drivers/mhi. Updated kernel
> >   documentation for the usage of the loopback test application.
> > - Addressed review comments for renaming variable names, updated inline
> >   comments and removed two redundant dev_dbg.
> > 
> > V11:
> > - Fixed review comments for UCI documentation by expanding TLAs and rewording
> >   some sentences.
> > 
> > V10:
> > - Replaced mutex_lock with mutex_lock_interruptible in read() and write() file
> >   ops call back.
> > 
> > V9:
> > - Renamed dl_lock to dl_pending _lock and pending list to dl_pending for
> >   clarity.
> > - Used read lock to protect cur_buf.
> > - Change transfer status check logic and only consider 0 and -EOVERFLOW as
> >   only success.
> > - Added __int to module init function.
> > - Print channel name instead of minor number upon successful probe.
> > 
> > V8:
> > - Fixed kernel test robot compilation error by changing %lu to %zu for
> >   size_t.
> > - Replaced uci with UCI in Kconfig, commit text, and comments in driver
> >   code.
> > - Fixed minor style related comments.
> > 
> > V7:
> > - Decoupled uci device and uci channel objects. uci device is
> >   associated with device file node. uci channel is associated
> >   with MHI channels. uci device refers to uci channel to perform
> >   MHI channel operations for device file operations like read()
> >   and write(). uci device increments its reference count for
> >   every open(). uci device calls mhi_uci_dev_start_chan() to start
> >   the MHI channel. uci channel object is tracking number of times
> >   MHI channel is referred. This allows to keep the MHI channel in
> >   start state until last release() is called. After that uci channel
> >   reference count goes to 0 and uci channel clean up is performed
> >   which stops the MHI channel. After the last call to release() if
> >   driver is removed uci reference count becomes 0 and uci object is
> >   cleaned up.
> > - Use separate uci channel read and write lock to fine grain locking
> >   between reader and writer.
> > - Use uci device lock to synchronize open, release and driver remove.
> > - Optimize for downlink only or uplink only UCI device.
> > 
> > V6:
> > - Moved uci.c to mhi directory.
> > - Updated Kconfig to add module information.
> > - Updated Makefile to rename uci object file name as mhi_uci
> > - Removed kref for open count
> > 
> > V5:
> > - Removed mhi_uci_drv structure.
> > - Used idr instead of creating global list of uci devices.
> > - Used kref instead of local ref counting for uci device and
> >   open count.
> > - Removed unlikely macro.
> > 
> > V4:
> > - Fix locking to protect proper struct members.
> > - Updated documentation describing uci client driver use cases.
> > - Fixed uci ref counting in mhi_uci_open for error case.
> > - Addressed style related review comments.
> > 
> > V3: Added documentation for MHI UCI driver.
> > 
> > V2:
> > - Added mutex lock to prevent multiple readers to access same
> > - mhi buffer which can result into use after free.
> > 
> > Hemant Kumar (3):
> >   bus: mhi: core: Move MHI_MAX_MTU to external header file
> >   docs: Add documentation for userspace client interface
> >   bus: mhi: Add userspace client interface driver
> > 
> >  Documentation/mhi/index.rst     |   1 +
> >  Documentation/mhi/uci.rst       |  95 ++++++
> >  drivers/bus/mhi/Kconfig         |  13 +
> >  drivers/bus/mhi/Makefile        |   3 +
> >  drivers/bus/mhi/core/internal.h |   1 -
> >  drivers/bus/mhi/uci.c           | 664 ++++++++++++++++++++++++++++++++++++++++
> >  include/linux/mhi.h             |   3 +
> >  7 files changed, 779 insertions(+), 1 deletion(-)
> >  create mode 100644 Documentation/mhi/uci.rst
> >  create mode 100644 drivers/bus/mhi/uci.c
> > 
> > -- 
> > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> > a Linux Foundation Collaborative Project
> > 

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
  2021-01-19  9:42   ` Manivannan Sadhasivam
@ 2021-01-19 10:28     ` Greg KH
  0 siblings, 0 replies; 31+ messages in thread
From: Greg KH @ 2021-01-19 10:28 UTC (permalink / raw)
  To: Manivannan Sadhasivam
  Cc: linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev,
	hemantk

On Tue, Jan 19, 2021 at 03:12:50PM +0530, Manivannan Sadhasivam wrote:
> Hi Greg,
> 
> On Wed, Jan 13, 2021 at 08:56:25PM +0530, Manivannan Sadhasivam wrote:
> > Hi Greg,
> > 
> > On Wed, Jan 06, 2021 at 10:44:13AM -0800, Hemant Kumar wrote:
> > > This patch series adds support for UCI driver. UCI driver enables userspace
> > > clients to communicate to external MHI devices like modem. UCI driver probe
> > > creates standard character device file nodes for userspace clients to
> > > perform open, read, write, poll and release file operations. These file
> > > operations call MHI core layer APIs to perform data transfer using MHI bus
> > > to communicate with MHI device. 
> > > 
> > > This interface allows exposing modem control channel(s) such as QMI, MBIM,
> > > or AT commands to userspace which can be used to configure the modem using
> > > tools such as libqmi, ModemManager, minicom (for AT), etc over MHI. This is
> > > required as there are no kernel APIs to access modem control path for device
> > > configuration. Data path transporting the network payload (IP), however, is
> > > routed to the Linux network via the mhi-net driver. Currently driver supports
> > > QMI channel. libqmi is userspace MHI client which communicates to a QMI
> > > service using QMI channel. Please refer to
> > > https://www.freedesktop.org/wiki/Software/libqmi/ for additional information
> > > on libqmi.
> > > 
> > > Patch is tested using arm64 and x86 based platform.
> > > 
> > 
> > This series looks good to me and I'd like to merge it into mhi-next. You
> > shared your reviews on the previous revisions, so I'd like to get your
> > opinion first.
> > 
> 
> Ping!

Sorry, it's in my to-review queue, buried with other stuff at the
moment, but it's not lost...

greg k-h

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
  2021-01-13 15:26 ` [RESEND PATCH v18 0/3] userspace MHI " Manivannan Sadhasivam
  2021-01-19  9:42   ` Manivannan Sadhasivam
@ 2021-01-27 15:15   ` Greg KH
  2021-01-27 16:24     ` Bjorn Andersson
  2021-02-01 10:55     ` Manivannan Sadhasivam
  1 sibling, 2 replies; 31+ messages in thread
From: Greg KH @ 2021-01-27 15:15 UTC (permalink / raw)
  To: Manivannan Sadhasivam
  Cc: linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev

On Wed, Jan 13, 2021 at 08:56:25PM +0530, Manivannan Sadhasivam wrote:
> Hi Greg,
> 
> On Wed, Jan 06, 2021 at 10:44:13AM -0800, Hemant Kumar wrote:
> > This patch series adds support for UCI driver. UCI driver enables userspace
> > clients to communicate to external MHI devices like modem. UCI driver probe
> > creates standard character device file nodes for userspace clients to
> > perform open, read, write, poll and release file operations. These file
> > operations call MHI core layer APIs to perform data transfer using MHI bus
> > to communicate with MHI device. 
> > 
> > This interface allows exposing modem control channel(s) such as QMI, MBIM,
> > or AT commands to userspace which can be used to configure the modem using
> > tools such as libqmi, ModemManager, minicom (for AT), etc over MHI. This is
> > required as there are no kernel APIs to access modem control path for device
> > configuration. Data path transporting the network payload (IP), however, is
> > routed to the Linux network via the mhi-net driver. Currently driver supports
> > QMI channel. libqmi is userspace MHI client which communicates to a QMI
> > service using QMI channel. Please refer to
> > https://www.freedesktop.org/wiki/Software/libqmi/ for additional information
> > on libqmi.
> > 
> > Patch is tested using arm64 and x86 based platform.
> > 
> 
> This series looks good to me and I'd like to merge it into mhi-next. You
> shared your reviews on the previous revisions, so I'd like to get your
> opinion first.

If you get the networking people to give you an ack on this, it's fine
with me.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
  2021-01-27 15:15   ` Greg KH
@ 2021-01-27 16:24     ` Bjorn Andersson
  2021-02-01 10:55     ` Manivannan Sadhasivam
  1 sibling, 0 replies; 31+ messages in thread
From: Bjorn Andersson @ 2021-01-27 16:24 UTC (permalink / raw)
  To: Greg KH
  Cc: Manivannan Sadhasivam, linux-arm-msm, linux-kernel, jhugo,
	bbhatt, loic.poulain, netdev

On Wed 27 Jan 09:15 CST 2021, Greg KH wrote:

> On Wed, Jan 13, 2021 at 08:56:25PM +0530, Manivannan Sadhasivam wrote:
> > Hi Greg,
> > 
> > On Wed, Jan 06, 2021 at 10:44:13AM -0800, Hemant Kumar wrote:
> > > This patch series adds support for UCI driver. UCI driver enables userspace
> > > clients to communicate to external MHI devices like modem. UCI driver probe
> > > creates standard character device file nodes for userspace clients to
> > > perform open, read, write, poll and release file operations. These file
> > > operations call MHI core layer APIs to perform data transfer using MHI bus
> > > to communicate with MHI device. 
> > > 
> > > This interface allows exposing modem control channel(s) such as QMI, MBIM,
> > > or AT commands to userspace which can be used to configure the modem using
> > > tools such as libqmi, ModemManager, minicom (for AT), etc over MHI. This is
> > > required as there are no kernel APIs to access modem control path for device
> > > configuration. Data path transporting the network payload (IP), however, is
> > > routed to the Linux network via the mhi-net driver. Currently driver supports
> > > QMI channel. libqmi is userspace MHI client which communicates to a QMI
> > > service using QMI channel. Please refer to
> > > https://www.freedesktop.org/wiki/Software/libqmi/ for additional information
> > > on libqmi.
> > > 
> > > Patch is tested using arm64 and x86 based platform.
> > > 
> > 
> > This series looks good to me and I'd like to merge it into mhi-next. You
> > shared your reviews on the previous revisions, so I'd like to get your
> > opinion first.
> 
> If you get the networking people to give you an ack on this, it's fine
> with me.
> 

Why? As concluded in previous iterations of this series this does not
relate to networking.

Regards,
Bjorn

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
  2021-01-27 15:15   ` Greg KH
  2021-01-27 16:24     ` Bjorn Andersson
@ 2021-02-01 10:55     ` Manivannan Sadhasivam
  2021-02-01 11:15       ` Greg KH
  1 sibling, 1 reply; 31+ messages in thread
From: Manivannan Sadhasivam @ 2021-02-01 10:55 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev

Hi Greg,

On Wed, Jan 27, 2021 at 04:15:42PM +0100, Greg KH wrote:
> On Wed, Jan 13, 2021 at 08:56:25PM +0530, Manivannan Sadhasivam wrote:
> > Hi Greg,
> > 
> > On Wed, Jan 06, 2021 at 10:44:13AM -0800, Hemant Kumar wrote:
> > > This patch series adds support for UCI driver. UCI driver enables userspace
> > > clients to communicate to external MHI devices like modem. UCI driver probe
> > > creates standard character device file nodes for userspace clients to
> > > perform open, read, write, poll and release file operations. These file
> > > operations call MHI core layer APIs to perform data transfer using MHI bus
> > > to communicate with MHI device. 
> > > 
> > > This interface allows exposing modem control channel(s) such as QMI, MBIM,
> > > or AT commands to userspace which can be used to configure the modem using
> > > tools such as libqmi, ModemManager, minicom (for AT), etc over MHI. This is
> > > required as there are no kernel APIs to access modem control path for device
> > > configuration. Data path transporting the network payload (IP), however, is
> > > routed to the Linux network via the mhi-net driver. Currently driver supports
> > > QMI channel. libqmi is userspace MHI client which communicates to a QMI
> > > service using QMI channel. Please refer to
> > > https://www.freedesktop.org/wiki/Software/libqmi/ for additional information
> > > on libqmi.
> > > 
> > > Patch is tested using arm64 and x86 based platform.
> > > 
> > 
> > This series looks good to me and I'd like to merge it into mhi-next. You
> > shared your reviews on the previous revisions, so I'd like to get your
> > opinion first.
> 
> If you get the networking people to give you an ack on this, it's fine
> with me.
> 

As discussed in previous iteration, this series is not belonging to networking
subsystem. The functionality provided by this series allows us to configure the
modem over MHI bus and the rest of the networking stuff happens over the
networking subsystem as usual.

This holds the same with USB and serial modems which we are having over decades
in mainline.

Thanks,
Mani

> thanks,
> 
> greg k-h

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
  2021-02-01 10:55     ` Manivannan Sadhasivam
@ 2021-02-01 11:15       ` Greg KH
  2021-02-01 12:13         ` Manivannan Sadhasivam
  0 siblings, 1 reply; 31+ messages in thread
From: Greg KH @ 2021-02-01 11:15 UTC (permalink / raw)
  To: Manivannan Sadhasivam
  Cc: linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev

On Mon, Feb 01, 2021 at 04:25:49PM +0530, Manivannan Sadhasivam wrote:
> Hi Greg,
> 
> On Wed, Jan 27, 2021 at 04:15:42PM +0100, Greg KH wrote:
> > On Wed, Jan 13, 2021 at 08:56:25PM +0530, Manivannan Sadhasivam wrote:
> > > Hi Greg,
> > > 
> > > On Wed, Jan 06, 2021 at 10:44:13AM -0800, Hemant Kumar wrote:
> > > > This patch series adds support for UCI driver. UCI driver enables userspace
> > > > clients to communicate to external MHI devices like modem. UCI driver probe
> > > > creates standard character device file nodes for userspace clients to
> > > > perform open, read, write, poll and release file operations. These file
> > > > operations call MHI core layer APIs to perform data transfer using MHI bus
> > > > to communicate with MHI device. 
> > > > 
> > > > This interface allows exposing modem control channel(s) such as QMI, MBIM,
> > > > or AT commands to userspace which can be used to configure the modem using
> > > > tools such as libqmi, ModemManager, minicom (for AT), etc over MHI. This is
> > > > required as there are no kernel APIs to access modem control path for device
> > > > configuration. Data path transporting the network payload (IP), however, is
> > > > routed to the Linux network via the mhi-net driver. Currently driver supports
> > > > QMI channel. libqmi is userspace MHI client which communicates to a QMI
> > > > service using QMI channel. Please refer to
> > > > https://www.freedesktop.org/wiki/Software/libqmi/ for additional information
> > > > on libqmi.
> > > > 
> > > > Patch is tested using arm64 and x86 based platform.
> > > > 
> > > 
> > > This series looks good to me and I'd like to merge it into mhi-next. You
> > > shared your reviews on the previous revisions, so I'd like to get your
> > > opinion first.
> > 
> > If you get the networking people to give you an ack on this, it's fine
> > with me.
> > 
> 
> As discussed in previous iteration, this series is not belonging to networking
> subsystem. The functionality provided by this series allows us to configure the
> modem over MHI bus and the rest of the networking stuff happens over the
> networking subsystem as usual.

Great, then it should be easy to get their acceptance :)

> This holds the same with USB and serial modems which we are having over decades
> in mainline.

I don't see the connection here, sorry.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
  2021-02-01 11:15       ` Greg KH
@ 2021-02-01 12:13         ` Manivannan Sadhasivam
  2021-02-02  4:22           ` Manivannan Sadhasivam
  0 siblings, 1 reply; 31+ messages in thread
From: Manivannan Sadhasivam @ 2021-02-01 12:13 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev

On Mon, Feb 01, 2021 at 12:15:51PM +0100, Greg KH wrote:
> On Mon, Feb 01, 2021 at 04:25:49PM +0530, Manivannan Sadhasivam wrote:
> > Hi Greg,
> > 
> > On Wed, Jan 27, 2021 at 04:15:42PM +0100, Greg KH wrote:
> > > On Wed, Jan 13, 2021 at 08:56:25PM +0530, Manivannan Sadhasivam wrote:
> > > > Hi Greg,
> > > > 
> > > > On Wed, Jan 06, 2021 at 10:44:13AM -0800, Hemant Kumar wrote:
> > > > > This patch series adds support for UCI driver. UCI driver enables userspace
> > > > > clients to communicate to external MHI devices like modem. UCI driver probe
> > > > > creates standard character device file nodes for userspace clients to
> > > > > perform open, read, write, poll and release file operations. These file
> > > > > operations call MHI core layer APIs to perform data transfer using MHI bus
> > > > > to communicate with MHI device. 
> > > > > 
> > > > > This interface allows exposing modem control channel(s) such as QMI, MBIM,
> > > > > or AT commands to userspace which can be used to configure the modem using
> > > > > tools such as libqmi, ModemManager, minicom (for AT), etc over MHI. This is
> > > > > required as there are no kernel APIs to access modem control path for device
> > > > > configuration. Data path transporting the network payload (IP), however, is
> > > > > routed to the Linux network via the mhi-net driver. Currently driver supports
> > > > > QMI channel. libqmi is userspace MHI client which communicates to a QMI
> > > > > service using QMI channel. Please refer to
> > > > > https://www.freedesktop.org/wiki/Software/libqmi/ for additional information
> > > > > on libqmi.
> > > > > 
> > > > > Patch is tested using arm64 and x86 based platform.
> > > > > 
> > > > 
> > > > This series looks good to me and I'd like to merge it into mhi-next. You
> > > > shared your reviews on the previous revisions, so I'd like to get your
> > > > opinion first.
> > > 
> > > If you get the networking people to give you an ack on this, it's fine
> > > with me.
> > > 
> > 
> > As discussed in previous iteration, this series is not belonging to networking
> > subsystem. The functionality provided by this series allows us to configure the
> > modem over MHI bus and the rest of the networking stuff happens over the
> > networking subsystem as usual.
> 
> Great, then it should be easy to get their acceptance :)
> 
> > This holds the same with USB and serial modems which we are having over decades
> > in mainline.
> 
> I don't see the connection here, sorry.
> 

For instance USB_NET_CDC_MBIM driver creates the /dev/cdc-wdmX chardev node for
configuring the modems which supports MBIM protocol over USB. Like that, this
driver creates /dev/mhiX_MBIM chardev node for configuring the modem over MHI
bus instead of USB. The question arised why we are creating a chardev node for
each supported configuration (channels in the case of MHI) and why can't we use
the existing /dev/cdc-wdmZ interfaces? The anwser is there is no standard
subsystem for WWAN and all the drivers represent a chardev which gets used by
the userspace tools such a Network manager for establishing connection.

And /dev/cdc-wdmX is restricted to the USB CDC devices.

Hope this clarifies!

Thanks,
Mani

> thanks,
> 
> greg k-h

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
  2021-02-01 12:13         ` Manivannan Sadhasivam
@ 2021-02-02  4:22           ` Manivannan Sadhasivam
  2021-02-03  4:10             ` Jakub Kicinski
  0 siblings, 1 reply; 31+ messages in thread
From: Manivannan Sadhasivam @ 2021-02-02  4:22 UTC (permalink / raw)
  To: Greg KH, kuba, davem
  Cc: linux-arm-msm, linux-kernel, jhugo, bbhatt, loic.poulain, netdev

+ Jakub, Dave

On Mon, Feb 01, 2021 at 05:43:22PM +0530, Manivannan Sadhasivam wrote:
> On Mon, Feb 01, 2021 at 12:15:51PM +0100, Greg KH wrote:
> > On Mon, Feb 01, 2021 at 04:25:49PM +0530, Manivannan Sadhasivam wrote:
> > > Hi Greg,
> > > 
> > > On Wed, Jan 27, 2021 at 04:15:42PM +0100, Greg KH wrote:
> > > > On Wed, Jan 13, 2021 at 08:56:25PM +0530, Manivannan Sadhasivam wrote:
> > > > > Hi Greg,
> > > > > 
> > > > > On Wed, Jan 06, 2021 at 10:44:13AM -0800, Hemant Kumar wrote:
> > > > > > This patch series adds support for UCI driver. UCI driver enables userspace
> > > > > > clients to communicate to external MHI devices like modem. UCI driver probe
> > > > > > creates standard character device file nodes for userspace clients to
> > > > > > perform open, read, write, poll and release file operations. These file
> > > > > > operations call MHI core layer APIs to perform data transfer using MHI bus
> > > > > > to communicate with MHI device. 
> > > > > > 
> > > > > > This interface allows exposing modem control channel(s) such as QMI, MBIM,
> > > > > > or AT commands to userspace which can be used to configure the modem using
> > > > > > tools such as libqmi, ModemManager, minicom (for AT), etc over MHI. This is
> > > > > > required as there are no kernel APIs to access modem control path for device
> > > > > > configuration. Data path transporting the network payload (IP), however, is
> > > > > > routed to the Linux network via the mhi-net driver. Currently driver supports
> > > > > > QMI channel. libqmi is userspace MHI client which communicates to a QMI
> > > > > > service using QMI channel. Please refer to
> > > > > > https://www.freedesktop.org/wiki/Software/libqmi/ for additional information
> > > > > > on libqmi.
> > > > > > 
> > > > > > Patch is tested using arm64 and x86 based platform.
> > > > > > 
> > > > > 
> > > > > This series looks good to me and I'd like to merge it into mhi-next. You
> > > > > shared your reviews on the previous revisions, so I'd like to get your
> > > > > opinion first.
> > > > 
> > > > If you get the networking people to give you an ack on this, it's fine
> > > > with me.
> > > > 
> > > 
> > > As discussed in previous iteration, this series is not belonging to networking
> > > subsystem. The functionality provided by this series allows us to configure the
> > > modem over MHI bus and the rest of the networking stuff happens over the
> > > networking subsystem as usual.
> > 
> > Great, then it should be easy to get their acceptance :)
> > 
> > > This holds the same with USB and serial modems which we are having over decades
> > > in mainline.
> > 
> > I don't see the connection here, sorry.
> > 
> 
> For instance USB_NET_CDC_MBIM driver creates the /dev/cdc-wdmX chardev node for
> configuring the modems which supports MBIM protocol over USB. Like that, this
> driver creates /dev/mhiX_MBIM chardev node for configuring the modem over MHI
> bus instead of USB. The question arised why we are creating a chardev node for
> each supported configuration (channels in the case of MHI) and why can't we use
> the existing /dev/cdc-wdmZ interfaces? The anwser is there is no standard
> subsystem for WWAN and all the drivers represent a chardev which gets used by
> the userspace tools such a Network manager for establishing connection.
> 
> And /dev/cdc-wdmX is restricted to the USB CDC devices.
> 
> Hope this clarifies!
> 

Jakub, Dave, Adding you both to get your reviews on this series. I've
provided an explanation above and in the previous iteration [1].

Thanks,
Mani

[1] https://lkml.org/lkml/2020/12/12/16

> Thanks,
> Mani
> 
> > thanks,
> > 
> > greg k-h

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
  2021-02-02  4:22           ` Manivannan Sadhasivam
@ 2021-02-03  4:10             ` Jakub Kicinski
  2021-02-03  4:15               ` Manivannan Sadhasivam
  0 siblings, 1 reply; 31+ messages in thread
From: Jakub Kicinski @ 2021-02-03  4:10 UTC (permalink / raw)
  To: Manivannan Sadhasivam
  Cc: Greg KH, davem, linux-arm-msm, linux-kernel, jhugo, bbhatt,
	loic.poulain, netdev

On Tue, 2 Feb 2021 09:52:08 +0530 Manivannan Sadhasivam wrote:
> > > I don't see the connection here, sorry.
> > 
> > For instance USB_NET_CDC_MBIM driver creates the /dev/cdc-wdmX chardev node for
> > configuring the modems which supports MBIM protocol over USB. Like that, this
> > driver creates /dev/mhiX_MBIM chardev node for configuring the modem over MHI
> > bus instead of USB. The question arised why we are creating a chardev node for
> > each supported configuration (channels in the case of MHI) and why can't we use
> > the existing /dev/cdc-wdmZ interfaces? The anwser is there is no standard
> > subsystem for WWAN and all the drivers represent a chardev which gets used by
> > the userspace tools such a Network manager for establishing connection.
> > 
> > And /dev/cdc-wdmX is restricted to the USB CDC devices.
> > 
> > Hope this clarifies!
> 
> Jakub, Dave, Adding you both to get your reviews on this series. I've
> provided an explanation above and in the previous iteration [1].

Let's be clear what the review would be for. Yet another QMI chardev 
or the "UCI" direct generic user space to firmware pipe?

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
  2021-02-03  4:10             ` Jakub Kicinski
@ 2021-02-03  4:15               ` Manivannan Sadhasivam
  2021-02-03 18:05                 ` Jakub Kicinski
  0 siblings, 1 reply; 31+ messages in thread
From: Manivannan Sadhasivam @ 2021-02-03  4:15 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: Greg KH, davem, linux-arm-msm, linux-kernel, jhugo, bbhatt,
	loic.poulain, netdev

Hi Jakub, 

On 3 February 2021 9:40:08 AM IST, Jakub Kicinski <kuba@kernel.org> wrote:
>On Tue, 2 Feb 2021 09:52:08 +0530 Manivannan Sadhasivam wrote:
>> > > I don't see the connection here, sorry.
>> > 
>> > For instance USB_NET_CDC_MBIM driver creates the /dev/cdc-wdmX
>chardev node for
>> > configuring the modems which supports MBIM protocol over USB. Like
>that, this
>> > driver creates /dev/mhiX_MBIM chardev node for configuring the
>modem over MHI
>> > bus instead of USB. The question arised why we are creating a
>chardev node for
>> > each supported configuration (channels in the case of MHI) and why
>can't we use
>> > the existing /dev/cdc-wdmZ interfaces? The anwser is there is no
>standard
>> > subsystem for WWAN and all the drivers represent a chardev which
>gets used by
>> > the userspace tools such a Network manager for establishing
>connection.
>> > 
>> > And /dev/cdc-wdmX is restricted to the USB CDC devices.
>> > 
>> > Hope this clarifies!
>> 
>> Jakub, Dave, Adding you both to get your reviews on this series. I've
>> provided an explanation above and in the previous iteration [1].
>
>Let's be clear what the review would be for. Yet another QMI chardev 
>or the "UCI" direct generic user space to firmware pipe?

The current patchset only supports QMI channel so I'd request you to review the chardev node created for it. The QMI chardev node created will be unique for the MHI bus and the number of nodes depends on the MHI controllers in the system (typically 1 but not limited). 

Thanks, 
Mani

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
  2021-02-03  4:15               ` Manivannan Sadhasivam
@ 2021-02-03 18:05                 ` Jakub Kicinski
  2021-02-03 18:28                   ` Loic Poulain
  2021-02-03 18:34                   ` Bjorn Andersson
  0 siblings, 2 replies; 31+ messages in thread
From: Jakub Kicinski @ 2021-02-03 18:05 UTC (permalink / raw)
  To: Manivannan Sadhasivam
  Cc: Greg KH, davem, linux-arm-msm, linux-kernel, jhugo, bbhatt,
	loic.poulain, netdev

On Wed, 03 Feb 2021 09:45:06 +0530 Manivannan Sadhasivam wrote:
> >> Jakub, Dave, Adding you both to get your reviews on this series. I've
> >> provided an explanation above and in the previous iteration [1].  
> >
> >Let's be clear what the review would be for. Yet another QMI chardev 
> >or the "UCI" direct generic user space to firmware pipe?  
> 
> The current patchset only supports QMI channel so I'd request you to
> review the chardev node created for it. The QMI chardev node created
> will be unique for the MHI bus and the number of nodes depends on the
> MHI controllers in the system (typically 1 but not limited). 

If you want to add a MHI QMI driver, please write a QMI-only driver.
This generic "userspace client interface" driver is a no go. Nobody will
have the time and attention to police what you throw in there later.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
  2021-02-03 18:05                 ` Jakub Kicinski
@ 2021-02-03 18:28                   ` Loic Poulain
  2021-02-03 18:40                     ` Jakub Kicinski
  2021-02-03 18:34                   ` Bjorn Andersson
  1 sibling, 1 reply; 31+ messages in thread
From: Loic Poulain @ 2021-02-03 18:28 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: Manivannan Sadhasivam, Greg KH, David Miller, linux-arm-msm,
	open list, Jeffrey Hugo, Bhaumik Bhatt, Network Development

Hi Jakub,

On Wed, 3 Feb 2021 at 19:05, Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Wed, 03 Feb 2021 09:45:06 +0530 Manivannan Sadhasivam wrote:
> > >> Jakub, Dave, Adding you both to get your reviews on this series. I've
> > >> provided an explanation above and in the previous iteration [1].
> > >
> > >Let's be clear what the review would be for. Yet another QMI chardev
> > >or the "UCI" direct generic user space to firmware pipe?
> >
> > The current patchset only supports QMI channel so I'd request you to
> > review the chardev node created for it. The QMI chardev node created
> > will be unique for the MHI bus and the number of nodes depends on the
> > MHI controllers in the system (typically 1 but not limited).
>
> If you want to add a MHI QMI driver, please write a QMI-only driver.
> This generic "userspace client interface" driver is a no go. Nobody will
> have the time and attention to police what you throw in there later.

Think it should be seen as filtered userspace access to MHI bus
(filtered because not all channels are exposed), again it's not
specific to MHI, any bus in Linux offers that (i2c, spi, usb, serial,
etc...). It will not be specific to QMI, since we will also need it
for MBIM (modem control path), AT commands, and GPS (NMEA frames), all
these protocols are usually handled by userspace tools and not linked
to any internal Linux framework, so it would be better not having a
dedicated chardev for each of them.

Regards,
Loic

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
  2021-02-03 18:05                 ` Jakub Kicinski
  2021-02-03 18:28                   ` Loic Poulain
@ 2021-02-03 18:34                   ` Bjorn Andersson
  1 sibling, 0 replies; 31+ messages in thread
From: Bjorn Andersson @ 2021-02-03 18:34 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: Manivannan Sadhasivam, Greg KH, davem, linux-arm-msm,
	linux-kernel, jhugo, bbhatt, loic.poulain, netdev

On Wed 03 Feb 12:05 CST 2021, Jakub Kicinski wrote:

> On Wed, 03 Feb 2021 09:45:06 +0530 Manivannan Sadhasivam wrote:
> > >> Jakub, Dave, Adding you both to get your reviews on this series. I've
> > >> provided an explanation above and in the previous iteration [1].  
> > >
> > >Let's be clear what the review would be for. Yet another QMI chardev 
> > >or the "UCI" direct generic user space to firmware pipe?  
> > 
> > The current patchset only supports QMI channel so I'd request you to
> > review the chardev node created for it. The QMI chardev node created
> > will be unique for the MHI bus and the number of nodes depends on the
> > MHI controllers in the system (typically 1 but not limited). 
> 
> If you want to add a MHI QMI driver, please write a QMI-only driver.

But said QMI driver would be identical to what is proposed here, given
that the libqmi [1] communicates in the raw messages of the given MHI
channel. Should I then propose another copy of the same driver for
transporting debug messages between [2] and the modem? And a third copy
to support firmware flashing using [3].

[1] https://www.freedesktop.org/wiki/Software/libqmi/
[2] https://github.com/andersson/diag
[3] https://github.com/andersson/qdl

> This generic "userspace client interface" driver is a no go. Nobody will
> have the time and attention to police what you throw in there later.

PCI devices implementing this must have a MHI controller driver, which
explicitly needs to specify which logical channels should be exposed to
userspace using the UCI driver. So in contrast to things like USBFS or
the tty layer - which is used to implement "network devices" today -
there is a natural point of policing this.

Regards,
Bjorn

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
  2021-02-03 18:28                   ` Loic Poulain
@ 2021-02-03 18:40                     ` Jakub Kicinski
  2021-02-04  4:07                       ` Manivannan Sadhasivam
                                         ` (2 more replies)
  0 siblings, 3 replies; 31+ messages in thread
From: Jakub Kicinski @ 2021-02-03 18:40 UTC (permalink / raw)
  To: Loic Poulain
  Cc: Manivannan Sadhasivam, Greg KH, David Miller, linux-arm-msm,
	open list, Jeffrey Hugo, Bhaumik Bhatt, Network Development

On Wed, 3 Feb 2021 19:28:28 +0100 Loic Poulain wrote:
> On Wed, 3 Feb 2021 at 19:05, Jakub Kicinski <kuba@kernel.org> wrote:
> > On Wed, 03 Feb 2021 09:45:06 +0530 Manivannan Sadhasivam wrote:  
> > > The current patchset only supports QMI channel so I'd request you to
> > > review the chardev node created for it. The QMI chardev node created
> > > will be unique for the MHI bus and the number of nodes depends on the
> > > MHI controllers in the system (typically 1 but not limited).  
> >
> > If you want to add a MHI QMI driver, please write a QMI-only driver.
> > This generic "userspace client interface" driver is a no go. Nobody will
> > have the time and attention to police what you throw in there later.  
> 
> Think it should be seen as filtered userspace access to MHI bus
> (filtered because not all channels are exposed), again it's not
> specific to MHI, any bus in Linux offers that (i2c, spi, usb, serial,
> etc...). It will not be specific to QMI, since we will also need it
> for MBIM (modem control path), AT commands, and GPS (NMEA frames), all
> these protocols are usually handled by userspace tools and not linked
> to any internal Linux framework, so it would be better not having a
> dedicated chardev for each of them.

The more people argue for this backdoor interface the more distrustful
of it we'll become. Keep going at your own peril.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
  2021-02-03 18:40                     ` Jakub Kicinski
@ 2021-02-04  4:07                       ` Manivannan Sadhasivam
  2021-02-04  5:53                       ` Bjorn Andersson
  2021-02-09  9:20                       ` Aleksander Morgado
  2 siblings, 0 replies; 31+ messages in thread
From: Manivannan Sadhasivam @ 2021-02-04  4:07 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: Loic Poulain, Greg KH, David Miller, linux-arm-msm, open list,
	Jeffrey Hugo, Bhaumik Bhatt, Network Development

On Wed, Feb 03, 2021 at 10:40:28AM -0800, Jakub Kicinski wrote:
> On Wed, 3 Feb 2021 19:28:28 +0100 Loic Poulain wrote:
> > On Wed, 3 Feb 2021 at 19:05, Jakub Kicinski <kuba@kernel.org> wrote:
> > > On Wed, 03 Feb 2021 09:45:06 +0530 Manivannan Sadhasivam wrote:  
> > > > The current patchset only supports QMI channel so I'd request you to
> > > > review the chardev node created for it. The QMI chardev node created
> > > > will be unique for the MHI bus and the number of nodes depends on the
> > > > MHI controllers in the system (typically 1 but not limited).  
> > >
> > > If you want to add a MHI QMI driver, please write a QMI-only driver.
> > > This generic "userspace client interface" driver is a no go. Nobody will
> > > have the time and attention to police what you throw in there later.  
> > 
> > Think it should be seen as filtered userspace access to MHI bus
> > (filtered because not all channels are exposed), again it's not
> > specific to MHI, any bus in Linux offers that (i2c, spi, usb, serial,
> > etc...). It will not be specific to QMI, since we will also need it
> > for MBIM (modem control path), AT commands, and GPS (NMEA frames), all
> > these protocols are usually handled by userspace tools and not linked
> > to any internal Linux framework, so it would be better not having a
> > dedicated chardev for each of them.
> 
> The more people argue for this backdoor interface the more distrustful
> of it we'll become. Keep going at your own peril.

Sorry, I do not want this to go towards rant... But I don't think this is anyway
near a backdoor interface. There are userspace tools available to evaluate the
chardev node and whatever this driver supports and going to support in the
future is part of the Qualcomm modems. The fact that we can't add a separate
driver for MHI QMI is due to the code duplication as the underlying interface is
same it is just the channel which differs.

And I got your point in doing everything in the chardev'ish way here. But we
don't have any standard mechanism (QMI, MBIM, firmware/crash dump download).
And lot of people argued that we are too far away from creating a WWAN
subsystem. And the usecase we are dealing here is specific to Qualcomm. So IMO
we should go ahead with the current interface this driver offers.

Thanks,
Mani


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
  2021-02-03 18:40                     ` Jakub Kicinski
  2021-02-04  4:07                       ` Manivannan Sadhasivam
@ 2021-02-04  5:53                       ` Bjorn Andersson
  2021-02-09  9:20                       ` Aleksander Morgado
  2 siblings, 0 replies; 31+ messages in thread
From: Bjorn Andersson @ 2021-02-04  5:53 UTC (permalink / raw)
  To: Jakub Kicinski, Greg KH
  Cc: Loic Poulain, Manivannan Sadhasivam, David Miller, linux-arm-msm,
	open list, Jeffrey Hugo, Bhaumik Bhatt, Network Development

On Wed 03 Feb 12:40 CST 2021, Jakub Kicinski wrote:

> On Wed, 3 Feb 2021 19:28:28 +0100 Loic Poulain wrote:
> > On Wed, 3 Feb 2021 at 19:05, Jakub Kicinski <kuba@kernel.org> wrote:
> > > On Wed, 03 Feb 2021 09:45:06 +0530 Manivannan Sadhasivam wrote:  
> > > > The current patchset only supports QMI channel so I'd request you to
> > > > review the chardev node created for it. The QMI chardev node created
> > > > will be unique for the MHI bus and the number of nodes depends on the
> > > > MHI controllers in the system (typically 1 but not limited).  
> > >
> > > If you want to add a MHI QMI driver, please write a QMI-only driver.
> > > This generic "userspace client interface" driver is a no go. Nobody will
> > > have the time and attention to police what you throw in there later.  
> > 
> > Think it should be seen as filtered userspace access to MHI bus
> > (filtered because not all channels are exposed), again it's not
> > specific to MHI, any bus in Linux offers that (i2c, spi, usb, serial,
> > etc...). It will not be specific to QMI, since we will also need it
> > for MBIM (modem control path), AT commands, and GPS (NMEA frames), all
> > these protocols are usually handled by userspace tools and not linked
> > to any internal Linux framework, so it would be better not having a
> > dedicated chardev for each of them.
> 
> The more people argue for this backdoor interface the more distrustful
> of it we'll become. Keep going at your own peril.

With things such as USBDEVFS, UIO, spi-dev and i2c-dev already exposing
various forms of hardware directly to userspace in an identical fashion,
can you please explain why you believe this would be inappropriate for
MHI devices?

Thanks,
Bjorn

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
  2021-02-03 18:40                     ` Jakub Kicinski
  2021-02-04  4:07                       ` Manivannan Sadhasivam
  2021-02-04  5:53                       ` Bjorn Andersson
@ 2021-02-09  9:20                       ` Aleksander Morgado
  2021-02-09 16:17                         ` Jakub Kicinski
  2 siblings, 1 reply; 31+ messages in thread
From: Aleksander Morgado @ 2021-02-09  9:20 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: Loic Poulain, Manivannan Sadhasivam, Greg KH, David Miller,
	linux-arm-msm, open list, Jeffrey Hugo, Bhaumik Bhatt,
	Network Development

Hey Jakub

On Wed, Feb 3, 2021 at 7:41 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Wed, 3 Feb 2021 19:28:28 +0100 Loic Poulain wrote:
> > On Wed, 3 Feb 2021 at 19:05, Jakub Kicinski <kuba@kernel.org> wrote:
> > > On Wed, 03 Feb 2021 09:45:06 +0530 Manivannan Sadhasivam wrote:
> > > > The current patchset only supports QMI channel so I'd request you to
> > > > review the chardev node created for it. The QMI chardev node created
> > > > will be unique for the MHI bus and the number of nodes depends on the
> > > > MHI controllers in the system (typically 1 but not limited).
> > >
> > > If you want to add a MHI QMI driver, please write a QMI-only driver.
> > > This generic "userspace client interface" driver is a no go. Nobody will
> > > have the time and attention to police what you throw in there later.
> >
> > Think it should be seen as filtered userspace access to MHI bus
> > (filtered because not all channels are exposed), again it's not
> > specific to MHI, any bus in Linux offers that (i2c, spi, usb, serial,
> > etc...). It will not be specific to QMI, since we will also need it
> > for MBIM (modem control path), AT commands, and GPS (NMEA frames), all
> > these protocols are usually handled by userspace tools and not linked
> > to any internal Linux framework, so it would be better not having a
> > dedicated chardev for each of them.
>
> The more people argue for this backdoor interface the more distrustful
> of it we'll become. Keep going at your own peril.

Are your worries that this driver will end up being used for many more
things than the initial wwan control port management being suggested
here? If so, what would be the suggested alternative for this
integration? Just a different way to access those control ports
instead of a chardev? A per port type specific driver?

This may be a stupid suggestion, but would the integration look less a
backdoor if it would have been named "mhi_wwan" and it exposed already
all the AT+DIAG+QMI+MBIM+NMEA possible channels as chardevs, not just
QMI?

-- 
Aleksander

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
  2021-02-09  9:20                       ` Aleksander Morgado
@ 2021-02-09 16:17                         ` Jakub Kicinski
  2021-02-09 16:49                           ` Aleksander Morgado
  2021-02-10  6:25                           ` Manivannan Sadhasivam
  0 siblings, 2 replies; 31+ messages in thread
From: Jakub Kicinski @ 2021-02-09 16:17 UTC (permalink / raw)
  To: Aleksander Morgado
  Cc: Loic Poulain, Manivannan Sadhasivam, Greg KH, David Miller,
	linux-arm-msm, open list, Jeffrey Hugo, Bhaumik Bhatt,
	Network Development

On Tue, 9 Feb 2021 10:20:30 +0100 Aleksander Morgado wrote:
> This may be a stupid suggestion, but would the integration look less a
> backdoor if it would have been named "mhi_wwan" and it exposed already
> all the AT+DIAG+QMI+MBIM+NMEA possible channels as chardevs, not just
> QMI?

What's DIAG? Who's going to remember that this is a backdoor driver 
a year from now when Qualcomm sends a one liner patches which just 
adds a single ID to open another channel?

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
  2021-02-09 16:17                         ` Jakub Kicinski
@ 2021-02-09 16:49                           ` Aleksander Morgado
  2021-02-10  6:25                           ` Manivannan Sadhasivam
  1 sibling, 0 replies; 31+ messages in thread
From: Aleksander Morgado @ 2021-02-09 16:49 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: Loic Poulain, Manivannan Sadhasivam, Greg KH, David Miller,
	linux-arm-msm, open list, Jeffrey Hugo, Bhaumik Bhatt,
	Network Development

Hey,

> On Tue, 9 Feb 2021 10:20:30 +0100 Aleksander Morgado wrote:
> > This may be a stupid suggestion, but would the integration look less a
> > backdoor if it would have been named "mhi_wwan" and it exposed already
> > all the AT+DIAG+QMI+MBIM+NMEA possible channels as chardevs, not just
> > QMI?
>
> What's DIAG?

DIAG/QCDM is an older protocol in Qualcomm based modems; in USB based
devices we would get a TTY that speaks this protocol. In legacy CDMA
modems this was required for actual device control (and ModemManager
has a libqcdm for that
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/tree/master/libqcdm)
but in all newest modems I'd say this is exclusively used for modem
trace retrieval (e.g. asking the modem to enable some internal traces
of the LTE stack which are downloaded in the host via this port). When
debugging issues with manufacturers, this is what they would ask you
to do, use this port to retrieve these traces (e.g. Quectel's QLog
program does that, each manufacturer keeps its own).

> Who's going to remember that this is a backdoor driver
> a year from now when Qualcomm sends a one liner patches which just
> adds a single ID to open another channel?

I'm obviously not going to argue about that possibility; although,
wouldn't it make more sense to discuss that whenever that happens?
This work is implemented in a very generic way probably, but it
focuses on WWAN control ports, which is what we need in userspace.

Right now this mhi_uci integration can be used for QMI control of the
modems, and I assume once that gets merged (if ever!), more patches
would arrive to enable AT, DIAG and MBIM control ports. The channels
associated to these WWAN control protocols have clearly defined
channel ids, and I believe the device itself chooses which channels
are exposed, so a device may e.g. say that it's going to expose only
the MBIM control port. This is also very manufacturer dependent I
think; I know for example that WWAN modules for laptops will probably
want to expose the MBIM channel instead of QMI, so that the same HW
integration is used in both Linux and Windows easily. The single and
generic mhi_uci integration for all these different WWAN control ports
would allow any of those combinations, very much like with USB devices
and different USB configurations.

Userspace is also ready for this integration, btw; at least libmbim
and libqmi don't have any problem with these chardevs, and
ModemManager has a branch ready to land to support this new
integration. A lot of new laptops that are already being sold since
last year come now with PCIe-only WWAN modules, and unfortunately I've
also seen different manufacturers pushing their own out-of-tree
variants of this same mhi_uci idea with better or worse luck. I
personally was very glad to see this work moving forward.

--
Aleksander

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
  2021-02-09 16:17                         ` Jakub Kicinski
  2021-02-09 16:49                           ` Aleksander Morgado
@ 2021-02-10  6:25                           ` Manivannan Sadhasivam
  2021-02-10 18:41                             ` Jakub Kicinski
  2021-02-28 14:12                             ` Aleksander Morgado
  1 sibling, 2 replies; 31+ messages in thread
From: Manivannan Sadhasivam @ 2021-02-10  6:25 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: Aleksander Morgado, Loic Poulain, Greg KH, David Miller,
	linux-arm-msm, open list, Jeffrey Hugo, Bhaumik Bhatt,
	Network Development

On Tue, Feb 09, 2021 at 08:17:44AM -0800, Jakub Kicinski wrote:
> On Tue, 9 Feb 2021 10:20:30 +0100 Aleksander Morgado wrote:
> > This may be a stupid suggestion, but would the integration look less a
> > backdoor if it would have been named "mhi_wwan" and it exposed already
> > all the AT+DIAG+QMI+MBIM+NMEA possible channels as chardevs, not just
> > QMI?
> 
> What's DIAG? Who's going to remember that this is a backdoor driver 
> a year from now when Qualcomm sends a one liner patches which just 
> adds a single ID to open another channel?

I really appreciate your feedback on this driver eventhough I'm not
inclined with you calling this driver a "backdoor interface". But can
you please propose a solution on how to make this driver a good one as
per your thoughts?

I really don't know what bothers you even if the userspace tools making
use of these chardevs are available openly (you can do the audit and see
if anything wrong we are doing). And exposing the raw access to the
hardware is not a new thing in kernel. There are several existing
subsystems/drivers does this as pointed out by Bjorn. Moreover we don't
have in-kernel APIs for the functionalities exposed by this driver and
creating one is not feasible as explained by many.

So please let us know the path forward on this series. We are open to
any suggestions but you haven't provided one till now.

Thanks,
Mani

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
  2021-02-10  6:25                           ` Manivannan Sadhasivam
@ 2021-02-10 18:41                             ` Jakub Kicinski
  2021-02-10 19:18                               ` Jeffrey Hugo
                                                 ` (2 more replies)
  2021-02-28 14:12                             ` Aleksander Morgado
  1 sibling, 3 replies; 31+ messages in thread
From: Jakub Kicinski @ 2021-02-10 18:41 UTC (permalink / raw)
  To: Manivannan Sadhasivam
  Cc: Aleksander Morgado, Loic Poulain, Greg KH, David Miller,
	linux-arm-msm, open list, Jeffrey Hugo, Bhaumik Bhatt,
	Network Development

On Wed, 10 Feb 2021 11:55:31 +0530 Manivannan Sadhasivam wrote:
> On Tue, Feb 09, 2021 at 08:17:44AM -0800, Jakub Kicinski wrote:
> > On Tue, 9 Feb 2021 10:20:30 +0100 Aleksander Morgado wrote:  
> > > This may be a stupid suggestion, but would the integration look less a
> > > backdoor if it would have been named "mhi_wwan" and it exposed already
> > > all the AT+DIAG+QMI+MBIM+NMEA possible channels as chardevs, not just
> > > QMI?  
> > 
> > What's DIAG? Who's going to remember that this is a backdoor driver 
> > a year from now when Qualcomm sends a one liner patches which just 
> > adds a single ID to open another channel?  
> 
> I really appreciate your feedback on this driver eventhough I'm not
> inclined with you calling this driver a "backdoor interface". But can
> you please propose a solution on how to make this driver a good one as
> per your thoughts?
> 
> I really don't know what bothers you even if the userspace tools making
> use of these chardevs are available openly (you can do the audit and see
> if anything wrong we are doing).

What bothers me is maintaining shim drivers which just shuttle opaque
messages between user space and firmware. One of which definitely is,
and the other may well be, proprietary. This is an open source project,
users are supposed to be able to meaningfully change the behavior of
the system.

What bothers me is that we have 3 WWAN vendors all doing their own
thing and no common Linux API for WWAN. It may have been fine 10 years
ago, but WWAN is increasingly complex and important.

> And exposing the raw access to the
> hardware is not a new thing in kernel. There are several existing
> subsystems/drivers does this as pointed out by Bjorn. Moreover we don't
> have in-kernel APIs for the functionalities exposed by this driver and
> creating one is not feasible as explained by many.
> 
> So please let us know the path forward on this series. We are open to
> any suggestions but you haven't provided one till now.

Well. You sure know how to aggravate people. I said clearly that you
can move forward on purpose build drivers (e.g. for WWAN). There is no
way forward on this common shim driver as far as I'm concerned.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
  2021-02-10 18:41                             ` Jakub Kicinski
@ 2021-02-10 19:18                               ` Jeffrey Hugo
  2021-02-10 22:08                               ` Bjorn Andersson
  2021-02-11  9:26                               ` Aleksander Morgado
  2 siblings, 0 replies; 31+ messages in thread
From: Jeffrey Hugo @ 2021-02-10 19:18 UTC (permalink / raw)
  To: Jakub Kicinski, Manivannan Sadhasivam
  Cc: Aleksander Morgado, Loic Poulain, Greg KH, David Miller,
	linux-arm-msm, open list, Bhaumik Bhatt, Network Development

On 2/10/2021 11:41 AM, Jakub Kicinski wrote:
> On Wed, 10 Feb 2021 11:55:31 +0530 Manivannan Sadhasivam wrote:
>> On Tue, Feb 09, 2021 at 08:17:44AM -0800, Jakub Kicinski wrote:
>>> On Tue, 9 Feb 2021 10:20:30 +0100 Aleksander Morgado wrote:
>>>> This may be a stupid suggestion, but would the integration look less a
>>>> backdoor if it would have been named "mhi_wwan" and it exposed already
>>>> all the AT+DIAG+QMI+MBIM+NMEA possible channels as chardevs, not just
>>>> QMI?
>>>
>>> What's DIAG? Who's going to remember that this is a backdoor driver
>>> a year from now when Qualcomm sends a one liner patches which just
>>> adds a single ID to open another channel?
>>
>> I really appreciate your feedback on this driver eventhough I'm not
>> inclined with you calling this driver a "backdoor interface". But can
>> you please propose a solution on how to make this driver a good one as
>> per your thoughts?
>>
>> I really don't know what bothers you even if the userspace tools making
>> use of these chardevs are available openly (you can do the audit and see
>> if anything wrong we are doing).
> 
> What bothers me is maintaining shim drivers which just shuttle opaque
> messages between user space and firmware. One of which definitely is,
> and the other may well be, proprietary. This is an open source project,
> users are supposed to be able to meaningfully change the behavior of
> the system.

Interesting.  So, based on that, the TCP/IP stack is going to be ripped 
out of Linux?  I can write a proprietary userspace application which 
uses the TCP/IP stack to shuttle opaque messages through the kernel to a 
remote system, which could be running Windows (a proprietary OS with 
typically proprietary applications).  I've infact done that in another 
life.  Proprietary talking to proprietary with the Linux kernel in the 
middle.  I suspect you'll have an aggressively different opinion, but at 
this simplified level, it's really no different from the proposed 
mhi_uci driver here, or any of the numerous other examples provided.

The Linux kernel does not get to say everything must be open.  There is 
an explicit license stating that - 
LICENSES/exceptions/Linux-syscall-note  Yes, it's ideal if things are 
open, but it seems contradictory to espouse wanting choice, but then 
denying certain choices.
Frankly, folks have pointed out open source applications that wish to 
use this, so no, it's not all closed.

Put another way, you keep going in circles (I know you've argued the 
same for others in the discussion) - why is this specifically different 
from the other "shim drivers" which "shuttle proprietary messages" which 
already exist and are maintained in Linus' tree today?  All I'm seeing 
is "I don't like it" which is not a technical reason, and "proprietary 
is bad" which frankly, I think the horses were let out of the barn back 
in 1991 when Linus first created Linux.

> 
> What bothers me is that we have 3 WWAN vendors all doing their own
> thing and no common Linux API for WWAN. It may have been fine 10 years
> ago, but WWAN is increasingly complex and important.
> 
>> And exposing the raw access to the
>> hardware is not a new thing in kernel. There are several existing
>> subsystems/drivers does this as pointed out by Bjorn. Moreover we don't
>> have in-kernel APIs for the functionalities exposed by this driver and
>> creating one is not feasible as explained by many.
>>
>> So please let us know the path forward on this series. We are open to
>> any suggestions but you haven't provided one till now.
> 
> Well. You sure know how to aggravate people. I said clearly that you
> can move forward on purpose build drivers (e.g. for WWAN). There is no
> way forward on this common shim driver as far as I'm concerned.
> 


-- 
Jeffrey Hugo
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
  2021-02-10 18:41                             ` Jakub Kicinski
  2021-02-10 19:18                               ` Jeffrey Hugo
@ 2021-02-10 22:08                               ` Bjorn Andersson
  2021-02-11  9:26                               ` Aleksander Morgado
  2 siblings, 0 replies; 31+ messages in thread
From: Bjorn Andersson @ 2021-02-10 22:08 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: Manivannan Sadhasivam, Aleksander Morgado, Loic Poulain, Greg KH,
	David Miller, linux-arm-msm, open list, Jeffrey Hugo,
	Bhaumik Bhatt, Network Development

On Wed 10 Feb 12:41 CST 2021, Jakub Kicinski wrote:

> On Wed, 10 Feb 2021 11:55:31 +0530 Manivannan Sadhasivam wrote:
> > On Tue, Feb 09, 2021 at 08:17:44AM -0800, Jakub Kicinski wrote:
> > > On Tue, 9 Feb 2021 10:20:30 +0100 Aleksander Morgado wrote:  
> > > > This may be a stupid suggestion, but would the integration look less a
> > > > backdoor if it would have been named "mhi_wwan" and it exposed already
> > > > all the AT+DIAG+QMI+MBIM+NMEA possible channels as chardevs, not just
> > > > QMI?  
> > > 
> > > What's DIAG? Who's going to remember that this is a backdoor driver 
> > > a year from now when Qualcomm sends a one liner patches which just 
> > > adds a single ID to open another channel?  
> > 
> > I really appreciate your feedback on this driver eventhough I'm not
> > inclined with you calling this driver a "backdoor interface". But can
> > you please propose a solution on how to make this driver a good one as
> > per your thoughts?
> > 
> > I really don't know what bothers you even if the userspace tools making
> > use of these chardevs are available openly (you can do the audit and see
> > if anything wrong we are doing).
> 
> What bothers me is maintaining shim drivers which just shuttle opaque
> messages between user space and firmware. One of which definitely is,
> and the other may well be, proprietary. This is an open source project,
> users are supposed to be able to meaningfully change the behavior of
> the system.
> 

You're absolutely right in that we in general don't like shim drivers
and there are several examples of proper MHI drivers - for e.g.
networking, WiFi

Technically we could fork/reimplement
https://github.com/freedesktop/libqmi, https://github.com/andersson/diag
and https://github.com/andersson/qdl in the kernel as "proper drivers" -
each one exposing their own userspace ABI.

But to leave these in userspace and rely on something that looks exactly
like USBDEVFS seems like a much better strategy.

> What bothers me is that we have 3 WWAN vendors all doing their own
> thing and no common Linux API for WWAN. It may have been fine 10 years
> ago, but WWAN is increasingly complex and important.
> 

We had a deep discussion and a few prototypes for a WWAN framework going
around 1-1.5 years ago. Unfortunately, what did fit Intel's view of what
a WWAN device is didn't fit at all with what's run and exposed by the
"modem" DSP in a Qualcomm platform. After trying to find various
contrived ways to model this we gave up.

> > And exposing the raw access to the
> > hardware is not a new thing in kernel. There are several existing
> > subsystems/drivers does this as pointed out by Bjorn. Moreover we don't
> > have in-kernel APIs for the functionalities exposed by this driver and
> > creating one is not feasible as explained by many.
> > 
> > So please let us know the path forward on this series. We are open to
> > any suggestions but you haven't provided one till now.
> 
> Well. You sure know how to aggravate people. I said clearly that you
> can move forward on purpose build drivers (e.g. for WWAN). There is no
> way forward on this common shim driver as far as I'm concerned.

But what is a WWAN device? What features does it have? What kind of APIs
does it expose?


Note that in this sense "QMI" really is a "binary equivalent" of AT
commands, the data flows over a DMA engine, which is not part of the
"WWAN device" and other services, such as GPS, already has specific
transports available upstream.

Regards,
Bjorn

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
  2021-02-10 18:41                             ` Jakub Kicinski
  2021-02-10 19:18                               ` Jeffrey Hugo
  2021-02-10 22:08                               ` Bjorn Andersson
@ 2021-02-11  9:26                               ` Aleksander Morgado
  2 siblings, 0 replies; 31+ messages in thread
From: Aleksander Morgado @ 2021-02-11  9:26 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: Manivannan Sadhasivam, Loic Poulain, Greg KH, David Miller,
	linux-arm-msm, open list, Jeffrey Hugo, Bhaumik Bhatt,
	Network Development

> What bothers me is maintaining shim drivers which just shuttle opaque
> messages between user space and firmware. One of which definitely is,
> and the other may well be, proprietary. This is an open source project,
> users are supposed to be able to meaningfully change the behavior of
> the system.

libqmi is an open source library under the LGPL; so all the messages
that are passed between e.g. ModemManager and the modem firmware can
be easily inspected by anyone. It is true, though, that libqmi may
also allow passing "unknown" messages between other proprietary third
party applications and the firmware, but that is very much like any
other modem control port that we already have; be it a plain tty, or a
ttyUSB or a ttyACM or a cdc-wdm port. The kernel drivers are passing
unknown stuff between modem firmware and userspace; I don't see how
the kernel driver would be interested in any other thing really. QMI
and MBIM are just 2 binary protocols (and we have libqmi and libmbim),
and there's a generic 3GPP AT command set, but every vendor then has
its own interpretation of that AT command set, and vendor-specific AT
commands, and what not. From my point of view, it's not like the
kernel should know or have much to say on what's being passed to the
modem.

>
> What bothers me is that we have 3 WWAN vendors all doing their own
> thing and no common Linux API for WWAN. It may have been fine 10 years
> ago, but WWAN is increasingly complex and important.
>

A WWAN modem is nowadays a complete Linux system itself with tons of
features, and if there is sometime a generic WWAN system in the kernel
providing API/ABI for generic features (e.g. data connection), that
API/ABI should anyway provide access to pass messages (be it binary,
or text AT commands) between firmware and userspace, for all the other
side features for which no generic API/ABI is provided by that
hypothetical generic WWAN system. Unless we don't want any of those
side features... like Voice call management, SMS, USSD, GNSS, SAR,
OMA-DM, carrier config selection, multi-SIM setups...

-- 
Aleksander

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
  2021-02-10  6:25                           ` Manivannan Sadhasivam
  2021-02-10 18:41                             ` Jakub Kicinski
@ 2021-02-28 14:12                             ` Aleksander Morgado
  2021-02-28 15:52                               ` Manivannan Sadhasivam
  1 sibling, 1 reply; 31+ messages in thread
From: Aleksander Morgado @ 2021-02-28 14:12 UTC (permalink / raw)
  To: Manivannan Sadhasivam
  Cc: Jakub Kicinski, Loic Poulain, Greg KH, David Miller,
	linux-arm-msm, open list, Jeffrey Hugo, Bhaumik Bhatt,
	Network Development

Hey Manivannan, Jakub & all,

>
> So please let us know the path forward on this series. We are open to
> any suggestions but you haven't provided one till now.
>

I just found out that Sierra Wireless also provides their own version
of mhi-net and mhi-uci in precompiled binaries for several Ubuntu
kernel versions and other setups; and that made me extremely unhappy.
They're not the only manufacturer doing that; most of them are doing
it, because we don't have yet a common solution in upstream Linux. Not
the first time we've seen this either, see the per-vendor GobiNet
implementations vs the upstream qmi_wwan one. I was hoping we could
avoid that mess again with the newer Qualcomm modules! :)

In ModemManager we've always *forced* all manufacturers we interact
with to first do the work in upstream Linux, and then we integrate
support in MM for those drivers. We've never accepted support for
vendor-specific proprietary kernel drivers, and that's something I
would personally like to keep on doing. The sad status right now is
that any user that wants to use the newer 5G modules with Qualcomm
chipsets, they need to go look for manufacturer-built precompiled
drivers for their specific kernel, and also then patch ModemManager
and the tools themselves. Obviously almost no one is doing all that,
except for some company with resources or a lot of interest. Some of
these new 5G modules are PCIe-only by default, unless some pin in the
chipset is brought up and then some of them may switch to USB support.
No one is really doing that either, as tampering with the hardware
voids warranty.

The iosm driver is also stalled in the mailing list and there doesn't
seem to be a lot of real need for a new common wwan subsystem to
rework everything...

I'm not involved with the mhi-uci driver development at all, and I
also don't have anything to say on what goes in the upstream kernel
and what doesn't. But as one of the ModemManager/libqmi/libmbim
maintainers I would like to represent all the users of these modules
that are right now forced to look for shady binary precompiled drivers
out there... that is no better solution than this proposed mhi-uci
common driver.

Manivannan, are you attempting to rework the mhi-uci driver in a
different way, or have you given up? Is there anything I could help
with?

Jakub, is there really no way you can be convinced that this mhi-uci
driver isn't that bad after all? :) All the mhi-net bits are already
integrated I think, even the MBIM support over MHI in the net device,
but all that is truly useless without a way to control the modem
sending and receiving messages.

Sorry for being back again with this discussion :)

Cheers!


--
Aleksander
https://aleksander.es

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
  2021-02-28 14:12                             ` Aleksander Morgado
@ 2021-02-28 15:52                               ` Manivannan Sadhasivam
  0 siblings, 0 replies; 31+ messages in thread
From: Manivannan Sadhasivam @ 2021-02-28 15:52 UTC (permalink / raw)
  To: Aleksander Morgado
  Cc: Jakub Kicinski, Loic Poulain, Greg KH, David Miller,
	linux-arm-msm, open list, Jeffrey Hugo, Bhaumik Bhatt,
	Network Development

On Sun, Feb 28, 2021 at 03:12:42PM +0100, Aleksander Morgado wrote:
> Hey Manivannan, Jakub & all,
> 
> >
> > So please let us know the path forward on this series. We are open to
> > any suggestions but you haven't provided one till now.
> >
> 
> I just found out that Sierra Wireless also provides their own version
> of mhi-net and mhi-uci in precompiled binaries for several Ubuntu
> kernel versions and other setups; and that made me extremely unhappy.
> They're not the only manufacturer doing that; most of them are doing
> it, because we don't have yet a common solution in upstream Linux. Not
> the first time we've seen this either, see the per-vendor GobiNet
> implementations vs the upstream qmi_wwan one. I was hoping we could
> avoid that mess again with the newer Qualcomm modules! :)
> 
> In ModemManager we've always *forced* all manufacturers we interact
> with to first do the work in upstream Linux, and then we integrate
> support in MM for those drivers. We've never accepted support for
> vendor-specific proprietary kernel drivers, and that's something I
> would personally like to keep on doing. The sad status right now is
> that any user that wants to use the newer 5G modules with Qualcomm
> chipsets, they need to go look for manufacturer-built precompiled
> drivers for their specific kernel, and also then patch ModemManager
> and the tools themselves. Obviously almost no one is doing all that,
> except for some company with resources or a lot of interest. Some of
> these new 5G modules are PCIe-only by default, unless some pin in the
> chipset is brought up and then some of them may switch to USB support.
> No one is really doing that either, as tampering with the hardware
> voids warranty.
> 
> The iosm driver is also stalled in the mailing list and there doesn't
> seem to be a lot of real need for a new common wwan subsystem to
> rework everything...
> 
> I'm not involved with the mhi-uci driver development at all, and I
> also don't have anything to say on what goes in the upstream kernel
> and what doesn't. But as one of the ModemManager/libqmi/libmbim
> maintainers I would like to represent all the users of these modules
> that are right now forced to look for shady binary precompiled drivers
> out there... that is no better solution than this proposed mhi-uci
> common driver.
> 
> Manivannan, are you attempting to rework the mhi-uci driver in a
> different way, or have you given up? Is there anything I could help
> with?
> 

Hemant is currently in-charge of the MHI UCI development effort. We were
thinking about doing "mhi-wwan" driver which just exposes the channels needed
for WWAN as Jakub said "you can move forward on purpose build drivers
(e.g. for WWAN)." But we are open to other suggestions also.

Thanks,
Mani

^ permalink raw reply	[flat|nested] 31+ messages in thread

end of thread, other threads:[~2021-02-28 15:53 UTC | newest]

Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-06 18:44 [RESEND PATCH v18 0/3] userspace MHI client interface driver Hemant Kumar
2021-01-06 18:44 ` [RESEND PATCH v18 1/3] bus: mhi: core: Move MHI_MAX_MTU to external header file Hemant Kumar
2021-01-06 18:44 ` [RESEND PATCH v18 2/3] docs: Add documentation for userspace client interface Hemant Kumar
2021-01-06 18:44 ` [RESEND PATCH v18 3/3] bus: mhi: Add userspace client interface driver Hemant Kumar
2021-01-13 15:26 ` [RESEND PATCH v18 0/3] userspace MHI " Manivannan Sadhasivam
2021-01-19  9:42   ` Manivannan Sadhasivam
2021-01-19 10:28     ` Greg KH
2021-01-27 15:15   ` Greg KH
2021-01-27 16:24     ` Bjorn Andersson
2021-02-01 10:55     ` Manivannan Sadhasivam
2021-02-01 11:15       ` Greg KH
2021-02-01 12:13         ` Manivannan Sadhasivam
2021-02-02  4:22           ` Manivannan Sadhasivam
2021-02-03  4:10             ` Jakub Kicinski
2021-02-03  4:15               ` Manivannan Sadhasivam
2021-02-03 18:05                 ` Jakub Kicinski
2021-02-03 18:28                   ` Loic Poulain
2021-02-03 18:40                     ` Jakub Kicinski
2021-02-04  4:07                       ` Manivannan Sadhasivam
2021-02-04  5:53                       ` Bjorn Andersson
2021-02-09  9:20                       ` Aleksander Morgado
2021-02-09 16:17                         ` Jakub Kicinski
2021-02-09 16:49                           ` Aleksander Morgado
2021-02-10  6:25                           ` Manivannan Sadhasivam
2021-02-10 18:41                             ` Jakub Kicinski
2021-02-10 19:18                               ` Jeffrey Hugo
2021-02-10 22:08                               ` Bjorn Andersson
2021-02-11  9:26                               ` Aleksander Morgado
2021-02-28 14:12                             ` Aleksander Morgado
2021-02-28 15:52                               ` Manivannan Sadhasivam
2021-02-03 18:34                   ` Bjorn Andersson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).