Message-ID: <20210201121322.GC108653@thinkpad>
Date:   Mon, 1 Feb 2021 17:43:22 +0530
From:   Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        jhugo@...eaurora.org, bbhatt@...eaurora.org,
        loic.poulain@...aro.org, netdev@...r.kernel.org
Subject: Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver

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!

Thanks,
Mani

> thanks,
> 
> greg k-h

Powered by blists - more mailing lists