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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Fri, 11 Dec 2020 08:55:53 +0000
From:   Carl Yin(殷张成) <carl.yin@...ctel.com>
To:     Greg KH <gregkh@...uxfoundation.org>,
        "hemantk@...eaurora.org" <hemantk@...eaurora.org>
CC:     "manivannan.sadhasivam@...aro.org" <manivannan.sadhasivam@...aro.org>,
        "linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "jhugo@...eaurora.org" <jhugo@...eaurora.org>,
        "bbhatt@...eaurora.org" <bbhatt@...eaurora.org>,
        "loic.poulain@...aro.org" <loic.poulain@...aro.org>,
        Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH v17 3/3] bus: mhi: Add userspace client interface driver

Hi,
	Maybe it is a good idea to take QMI as example. QMI is QUALCOMM private protocol, maybe lots of people do not know what is QMI?
	MHI device can be WIFI device or WWAN device, if it is WIFI device, it is a pure network device, and maybe do not need this driver.
	But for WWAN devices, it support AT/NMEA/QMI/MBIM etc. protocol. And this driver is work for these functions.
	
	There are similar drivers in the kernel for WWAN devices base on USB interface.
	Like drivers/usb/class/cdc-wdm.c (for QMI & MBIM), and drivers/usb/serial/usb_wwan.c (for AT/NMEA)
	For USB WWAN devices, open source softwares libqmi/libmbim/ModemManager/LVFS want to commutate with WWAN devices via above 2 drivers.
	For MHI WWAN devices, these open source software also need such driver.


On 11 Dec 2020 08:44:29, Greg KH 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.
> 
> Also, because you are going around the existing network api, I will need the
> networking maintainers to ack this type of patch.
> 
> thanks,
> 
> greg k-h
> 
> 
>