Re: [PATCH v17 3/3] bus: mhi: Add userspace client interface driver

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:

quoted

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