Thread (31 messages) 31 messages, 8 authors, 2021-02-28

Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver

From: Manivannan Sadhasivam <hidden>
Date: 2021-02-01 12:14:14
Also in: linux-arm-msm, lkml

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:
quoted
Hi Greg,

On Wed, Jan 27, 2021 at 04:15:42PM +0100, Greg KH wrote:
quoted
On Wed, Jan 13, 2021 at 08:56:25PM +0530, Manivannan Sadhasivam wrote:
quoted
Hi Greg,

On Wed, Jan 06, 2021 at 10:44:13AM -0800, Hemant Kumar wrote:
quoted
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 :)
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help