[v9,0/4] userspace MHI client interface driver

This patch series adds support for UCI driver. UCI driver enables userspace
clients to communicate to external MHI devices like modem and WLAN. 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. Patch is tested using arm64 based platform.

V9:
- Renamed dl_lock to dl_pending _lock and pending list to dl_pending for
  clarity.
- Used read lock to protect cur_buf.
- Change transfer status check logic and only consider 0 and -EOVERFLOW as
  only success.
- Added __int to module init function.
- Print channel name instead of minor number upon successful probe.

V8:
- Fixed kernel test robot compilation error by changing %lu to %zu for
  size_t.
- Replaced uci with UCI in Kconfig, commit text, and comments in driver
  code.
- Fixed minor style related comments.

V7:
- Decoupled uci device and uci channel objects. uci device is
  associated with device file node. uci channel is associated
  with MHI channels. uci device refers to uci channel to perform
  MHI channel operations for device file operations like read()
  and write(). uci device increments its reference count for
  every open(). uci device calls mhi_uci_dev_start_chan() to start
  the MHI channel. uci channel object is tracking number of times
  MHI channel is referred. This allows to keep the MHI channel in
  start state until last release() is called. After that uci channel
  reference count goes to 0 and uci channel clean up is performed
  which stops the MHI channel. After the last call to release() if
  driver is removed uci reference count becomes 0 and uci object is
  cleaned up.
- Use separate uci channel read and write lock to fine grain locking
  between reader and writer.
- Use uci device lock to synchronize open, release and driver remove.
- Optimize for downlink only or uplink only UCI device.

V6:
- Moved uci.c to mhi directory.
- Updated Kconfig to add module information.
- Updated Makefile to rename uci object file name as mhi_uci
- Removed kref for open count

V5:
- Removed mhi_uci_drv structure.
- Used idr instead of creating global list of uci devices.
- Used kref instead of local ref counting for uci device and
  open count.
- Removed unlikely macro.

V4:
- Fix locking to protect proper struct members.
- Updated documentation describing uci client driver use cases.
- Fixed uci ref counting in mhi_uci_open for error case.
- Addressed style related review comments.

V3: Added documentation for MHI UCI driver.

V2: Added mutex lock to prevent multiple readers to access same
mhi buffer which can result into use after free.

Hemant Kumar (4):
  bus: mhi: core: Add helper API to return number of free TREs
  bus: mhi: core: Move MHI_MAX_MTU to external header file
  docs: Add documentation for userspace client interface
  bus: mhi: Add userspace client interface driver

 Documentation/mhi/index.rst     |   1 +
 Documentation/mhi/uci.rst       |  83 +++++
 drivers/bus/mhi/Kconfig         |  13 +
 drivers/bus/mhi/Makefile        |   4 +
 drivers/bus/mhi/core/internal.h |   1 -
 drivers/bus/mhi/core/main.c     |  12 +
 drivers/bus/mhi/uci.c           | 658 ++++++++++++++++++++++++++++++++++++++++
 include/linux/mhi.h             |  12 +
 8 files changed, 783 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/mhi/uci.rst
 create mode 100644 drivers/bus/mhi/uci.c

On 10/26/2020 7:46 AM, Dan Williams wrote:
> On Mon, 2020-10-26 at 07:38 -0600, Jeffrey Hugo wrote:
>> On 10/25/2020 3:46 PM, Jakub Kicinski wrote:
>>> On Fri, 23 Oct 2020 16:17:54 -0700 Hemant Kumar wrote:
>>>> +UCI driver enables userspace clients to communicate to external
>>>> MHI devices
>>>> +like modem and WLAN. UCI driver probe creates standard character
>>>> device file
>>>> +nodes for userspace clients to perform open, read, write, poll
>>>> and release file
>>>> +operations.
>>>
>>> What's the user space that talks to this?
>>>
>>
>> Multiple.
>>
>> Each channel has a different purpose.  There it is expected that a
>> different userspace application would be using it.
>>
>> Hemant implemented the loopback channel, which is a simple channel
>> that
>> just sends you back anything you send it.  Typically this is consumed
>> by
>> a test application.
>>
>> Diag is a typical channel to be consumed by userspace.  This is
>> consumed
>> by various applications that talk to the remote device for
>> diagnostic
>> information (logs and such).
> 
> QMI too?
> Dan

Interesting question.  My product doesn't use QMI.  I would expect that 
all QMI runs through Router these days, but I am seeing some QMI 
channels in the downstream source.

Hemant, Do you know what is the usecase for the QMI0/QMI1 channels?

On 10/26/20 6:56 AM, Jeffrey Hugo wrote:
> On 10/26/2020 7:46 AM, Dan Williams wrote:
>> On Mon, 2020-10-26 at 07:38 -0600, Jeffrey Hugo wrote:
>>> On 10/25/2020 3:46 PM, Jakub Kicinski wrote:
>>>> On Fri, 23 Oct 2020 16:17:54 -0700 Hemant Kumar wrote:
>>>>> +UCI driver enables userspace clients to communicate to external
>>>>> MHI devices
>>>>> +like modem and WLAN. UCI driver probe creates standard character
>>>>> device file
>>>>> +nodes for userspace clients to perform open, read, write, poll
>>>>> and release file
>>>>> +operations.
>>>>
>>>> What's the user space that talks to this?
>>>>
>>>
>>> Multiple.
>>>
>>> Each channel has a different purpose.  There it is expected that a
>>> different userspace application would be using it.
>>>
>>> Hemant implemented the loopback channel, which is a simple channel
>>> that
>>> just sends you back anything you send it.  Typically this is consumed
>>> by
>>> a test application.
>>>
>>> Diag is a typical channel to be consumed by userspace.  This is
>>> consumed
>>> by various applications that talk to the remote device for
>>> diagnostic
>>> information (logs and such).
>>
>> QMI too?
>> Dan
> 
> Interesting question.  My product doesn't use QMI.  I would expect that 
> all QMI runs through Router these days, but I am seeing some QMI 
> channels in the downstream source.
> 
> Hemant, Do you know what is the usecase for the QMI0/QMI1 channels?
> 
QMI0/QMI1 is used to send QMI message (control path) to bring the qmi 
rmnet data call.

Thanks,
Hemant

On Mon, 26 Oct 2020 07:38:46 -0600 Jeffrey Hugo wrote:
> On 10/25/2020 3:46 PM, Jakub Kicinski wrote:
> > On Fri, 23 Oct 2020 16:17:54 -0700 Hemant Kumar wrote:  
> >> +UCI driver enables userspace clients to communicate to external MHI devices
> >> +like modem and WLAN. UCI driver probe creates standard character device file
> >> +nodes for userspace clients to perform open, read, write, poll and release file
> >> +operations.  
> > 
> > What's the user space that talks to this?
> 
> Multiple.
> 
> Each channel has a different purpose.  There it is expected that a 
> different userspace application would be using it.
> 
> Hemant implemented the loopback channel, which is a simple channel that 
> just sends you back anything you send it.  Typically this is consumed by 
> a test application.
> 
> Diag is a typical channel to be consumed by userspace.  This is consumed 
> by various applications that talk to the remote device for diagnostic 
> information (logs and such).
> 
> Sahara is another common channel that is usually used for the multistage 
> firmware loading process.

Thanks for the info, are there any open source tests based on the 
loopback channel (perhaps even in tree?) 

Since that's the only channel enabled in this set its the only one 
we can comment on.