lkml.org 
[lkml]   [2020]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v13 0/4] userspace MHI client interface driver
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.

\
 
 \ /
  Last update: 2020-12-02 03:58    [W:0.065 / U:3.548 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site