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.
