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
