Re: [PATCH v13 0/4] userspace MHI client interface driver

[Jakub Kicinski]

On Tue, 1 Dec 2020 13:48:36 -0700 Jeffrey Hugo wrote:
> On 12/1/2020 1:03 PM, Jakub Kicinski wrote:
> > On Tue, 1 Dec 2020 12:40:50 -0700 Jeffrey Hugo wrote:  
> >> On 12/1/2020 12:29 PM, Jakub Kicinski wrote:  
> >>> On Fri, 27 Nov 2020 19:26:02 -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 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.  
> >>>
> >>> Wait, I thought this was for modems.
> >>>
> >>> Why do WLAN devices need to communicate with user space?
> >>>      
> >>
> >> Why does it matter what type of device it is?  Are modems somehow unique
> >> in that they are the only type of device that userspace is allowed to
> >> interact with?  
> > 
> > Yes modems are traditionally highly weird and require some serial
> > device dance I don't even know about.
> > 
> > We have proper interfaces in Linux for configuring WiFi which work
> > across vendors. Having char device access to WiFi would be a step
> > back.  
> 
> So a WLAN device is only ever allowed to do Wi-Fi?  It can't also have 
> GPS functionality for example?

No, but it's also not true that the only way to implement GPS is by
opening a full on command/packet interface between fat proprietary
firmware and custom user space (which may or may not be proprietary 
as well).

> >> However, I'll bite.  Once such usecase would be QMI.  QMI is a generic
> >> messaging protocol, and is not strictly limited to the unique operations
> >> of a modem.
> >>
> >> Another usecase would be Sahara - a custom file transfer protocol used
> >> for uploading firmware images, and downloading crashdumps.  
> > 
> > Thanks, I was asking for use cases, not which proprietary vendor
> > protocol you can implement over it.
> > 
> > None of the use cases you mention here should require a direct FW -
> > user space backdoor for WLAN.  
> 
> Uploading runtime firmware, with variations based on the runtime mode. 
> Flashing the onboard flash based on cryptographic keys.  Accessing 
> configuration data.  Accessing device logs.  Configuring device logs. 
> Synchronizing the device time reference to Linux local or remote time 
> sources.  Enabling debugging/performance hardware.  Getting software 
> diagnostic events.  Configuring redundancy hardware per workload. 
> Uploading new cryptographic keys.  Invalidating cryptographic keys. 
> Uploading factory test data and running factory tests.
> 
> Need more?

This conversation is going nowhere. Are you trying to say that creating
a common Linux API for those features is impossible and each vendor
should be allowed to add their own proprietary way?

This has been proven incorrect again and again, and Wi-Fi is a good
example.

You can do whatever you want for GPS etc. but don't come nowhere near
networking with this attitude please.