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

[Manivannan Sadhasivam]

+ 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