[v17,0/3] userspace MHI client interface driver

This patch series adds support for UCI driver. UCI driver enables userspace
clients to communicate to external MHI devices like modem. UCI driver probe
creates standard character device file nodes for userspace clients to
perform open, read, write, poll and release file operations. These file
operations call MHI core layer APIs to perform data transfer using MHI bus
to communicate with MHI device. Currently driver supports QMI channel. libqmi
is userspace MHI client which communicates to a QMI service using QMI channel.
libqmi is a glib-based library for talking to WWAN modems and devices which
speaks QMI protocol. For more information about libqmi please refer
https://www.freedesktop.org/wiki/Software/libqmi/. Patch is tested using arm64
and x86 based platform.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

V3: Added documentation for MHI UCI driver.

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

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

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

On Thu, Dec 10, 2020 at 11:04:11PM -0800, Hemant Kumar wrote:
> This MHI client driver allows userspace clients to transfer
> raw data between MHI device and host using standard file operations.
> Driver instantiates UCI device object which is associated to device
> file node. UCI device object instantiates UCI channel object when device
> file node is opened. UCI channel object is used to manage MHI channels
> by calling MHI core APIs for read and write operations. MHI channels
> are started as part of device open(). MHI channels remain in start
> state until last release() is called on UCI device file node. Device
> file node is created with format
> 
> /dev/<mhi_device_name>
> 
> Currently it supports QMI channel. libqmi is userspace MHI client which
> communicates to a QMI service using QMI channel. libqmi is a glib-based
> library for talking to WWAN modems and devices which speaks QMI protocol.
> For more information about libqmi please refer
> https://www.freedesktop.org/wiki/Software/libqmi/

This says _what_ this is doing, but not _why_.

Why do you want to circumvent the normal user/kernel apis for this type
of device and move the normal network handling logic out to userspace?
What does that help with?  What does the current in-kernel api lack that
this userspace interface is going to solve, and why can't the in-kernel
api solve it instead?

You are pushing a common user/kernel api out of the kernel here, to
become very device-specific, with no apparent justification as to why
this is happening.

Also, because you are going around the existing network api, I will need
the networking maintainers to ack this type of patch.

thanks,

greg k-h

Hi Greg,

On Fri, Dec 11, 2020 at 08:44:29AM +0100, Greg KH wrote:
> On Thu, Dec 10, 2020 at 11:04:11PM -0800, Hemant Kumar wrote:
> > This MHI client driver allows userspace clients to transfer
> > raw data between MHI device and host using standard file operations.
> > Driver instantiates UCI device object which is associated to device
> > file node. UCI device object instantiates UCI channel object when device
> > file node is opened. UCI channel object is used to manage MHI channels
> > by calling MHI core APIs for read and write operations. MHI channels
> > are started as part of device open(). MHI channels remain in start
> > state until last release() is called on UCI device file node. Device
> > file node is created with format
> > 
> > /dev/<mhi_device_name>
> > 
> > Currently it supports QMI channel. libqmi is userspace MHI client which
> > communicates to a QMI service using QMI channel. libqmi is a glib-based
> > library for talking to WWAN modems and devices which speaks QMI protocol.
> > For more information about libqmi please refer
> > https://www.freedesktop.org/wiki/Software/libqmi/
> 
> This says _what_ this is doing, but not _why_.
> 
> Why do you want to circumvent the normal user/kernel apis for this type
> of device and move the normal network handling logic out to userspace?
> What does that help with?  What does the current in-kernel api lack that
> this userspace interface is going to solve, and why can't the in-kernel
> api solve it instead?
> 

Well, this driver is not moving the network handling logic out. Instead
this driver just exposes a channel which can be used to configure the
modem using the existing userspace library like libqmi. Then the networking
logic is handled by a separate in kernel driver called mhi-net which is queued
for v5.11.

This is same for most of the Qualcomm USB modems as well. They expose a chardev
node like /dev/cdc_wdm0 for configuration and once configured the networking
logic is handled by usual network interface wwan0.

The difference here is that the underlying physical layer is PCIe and there is
this MHI bus which sits on top of it.

> You are pushing a common user/kernel api out of the kernel here, to
> become very device-specific, with no apparent justification as to why
> this is happening.
> 
> Also, because you are going around the existing network api, I will need
> the networking maintainers to ack this type of patch.
> 

No, this driver is not at all touching the networking part. As said, the
networking logic is all handled by mhi-net driver.

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

On Fri, 11 Dec 2020 11:37:34 -0600 Dan Williams wrote:
> Just to re-iterate: QMI ~= AT commands ~= MBIM (not quite, but same
> level)
> 
> We already do QMI-over-USB, or AT-over-CDC-ACM. This is QMI-over-MHI.

Why do we need a different QMI-over-X for every X? If you say there 
are already chardev interfaces to configure WWAN why not provide one 
of those?

> It's not networking data plane. It's WWAN device configuration.

Ack. Not that network config doesn't fall under networking, but eh.
I wonder - did DaveM ever ack this, or was it just out of his sight
enough, behind the cdev, to never trigger a nack?

> There are no current kernel APIs for this, and I really don't think we
> want there to be. The API surface is *huge* and we definitely don't
> want that in-kernel.

It is what it is today for WWAN. I don't think anyone in the
development community or among users is particularly happy about
the situation. Which makes it rather self evident why there is 
so much apprehension about this patch set. It's going to be 
a user space channel for everything Qualcomm - AI accelerator etc.
Widening the WWAN status quo to more device types.

On Fri, Dec 11, 2020 at 08:08:16PM -0800, Jakub Kicinski wrote:
> On Fri, 11 Dec 2020 11:37:34 -0600 Dan Williams wrote:
> > Just to re-iterate: QMI ~= AT commands ~= MBIM (not quite, but same
> > level)
> > 
> > We already do QMI-over-USB, or AT-over-CDC-ACM. This is QMI-over-MHI.
> 
> Why do we need a different QMI-over-X for every X? If you say there 
> are already chardev interfaces to configure WWAN why not provide one 
> of those?
> 

Just because the underlying PHY is different and it offers more services than
just configuring the modem (downloading crash dump, firmware download etc...)

The existing chardev nodes are closely tied to the physical interfaces. For
instance, /dev/cdc_wdm is used by the USB based WWAN devices. So we really can't
reuse it for MHI/PCIe.

> > It's not networking data plane. It's WWAN device configuration.
> 
> Ack. Not that network config doesn't fall under networking, but eh.
> I wonder - did DaveM ever ack this, or was it just out of his sight
> enough, behind the cdev, to never trigger a nack?
> 
> > There are no current kernel APIs for this, and I really don't think we
> > want there to be. The API surface is *huge* and we definitely don't
> > want that in-kernel.
> 
> It is what it is today for WWAN. I don't think anyone in the
> development community or among users is particularly happy about
> the situation. Which makes it rather self evident why there is 
> so much apprehension about this patch set. It's going to be 
> a user space channel for everything Qualcomm - AI accelerator etc.
> Widening the WWAN status quo to more device types.

Well not everything Qualcomm but for just the subsystems where there is no
standardization right now. I think we went too far ahead for standardizing
the modems.

Thanks,
Mani

Hello,

Il giorno dom 13 dic 2020 alle ore 15:22 Manivannan Sadhasivam
<manivannan.sadhasivam@linaro.org> ha scritto:
>

> On Fri, Dec 11, 2020 at 08:08:16PM -0800, Jakub Kicinski wrote:

> > On Fri, 11 Dec 2020 11:37:34 -0600 Dan Williams wrote:

> > > Just to re-iterate: QMI ~= AT commands ~= MBIM (not quite, but same

> > > level)

> > >

> > > We already do QMI-over-USB, or AT-over-CDC-ACM. This is QMI-over-MHI.

> >

> > Why do we need a different QMI-over-X for every X? If you say there

> > are already chardev interfaces to configure WWAN why not provide one

> > of those?

> >

>

> Just because the underlying PHY is different and it offers more services than

> just configuring the modem (downloading crash dump, firmware download etc...)

>

> The existing chardev nodes are closely tied to the physical interfaces. For

> instance, /dev/cdc_wdm is used by the USB based WWAN devices. So we really can't

> reuse it for MHI/PCIe.

>


let me also add that the current MHI UCI approach makes sense because
it makes the switch USB -> PCIe smooth, since all the current
open-source userspace tools (e.g. libqmi and qmicli), according to my
testing until now, properly works without any need for a change,
behaving the UCI QMI char device like cdc-wdm.

While a different solution (which one?) would maybe cause to re-think
the userspace side for having the same high-level behavior.

Thanks,
Daniele

> > > It's not networking data plane. It's WWAN device configuration.

> >

> > Ack. Not that network config doesn't fall under networking, but eh.

> > I wonder - did DaveM ever ack this, or was it just out of his sight

> > enough, behind the cdev, to never trigger a nack?

> >

> > > There are no current kernel APIs for this, and I really don't think we

> > > want there to be. The API surface is *huge* and we definitely don't

> > > want that in-kernel.

> >

> > It is what it is today for WWAN. I don't think anyone in the

> > development community or among users is particularly happy about

> > the situation. Which makes it rather self evident why there is

> > so much apprehension about this patch set. It's going to be

> > a user space channel for everything Qualcomm - AI accelerator etc.

> > Widening the WWAN status quo to more device types.

>

> Well not everything Qualcomm but for just the subsystems where there is no

> standardization right now. I think we went too far ahead for standardizing

> the modems.

>

> Thanks,

> Mani

>