On Tue, 1 Dec 2020 13:48:36 -0700 Jeffrey Hugo wrote:

On 12/1/2020 1:03 PM, Jakub Kicinski wrote:

quoted

On Tue, 1 Dec 2020 12:40:50 -0700 Jeffrey Hugo wrote:  

quoted

On 12/1/2020 12:29 PM, Jakub Kicinski wrote:  

quoted

On Fri, 27 Nov 2020 19:26:02 -0800 Hemant Kumar wrote:  

quoted

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).

quoted

quoted

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.