+ 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
