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

[Loic Poulain]

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

That would probably deserve re-wording indeed. This interface offers
access to the modem control channel(s), which can be QMI (added in
this patch), MBIM, or the old known AT protocol. Because there is no
WWAN subsystem, these control pipes are directly exposed to userspace
and accessed by tools like libqmi, ModemManager, minicom (for AT)
etc... However, the data path, transporting the network payload (IP)
is well routed to the Linux network via the mhi-net driver.

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