Date:   Sun, 6 Dec 2020 10:33:02 +0200
From:   Leon Romanovsky <leon@...nel.org>
To:     Jeffrey Hugo <jhugo@...eaurora.org>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        Hemant Kumar <hemantk@...eaurora.org>,
        manivannan.sadhasivam@...aro.org, gregkh@...uxfoundation.org,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        bbhatt@...eaurora.org, loic.poulain@...aro.org,
        netdev@...r.kernel.org, linux-wireless@...r.kernel.org,
        Kalle Valo <kvalo@...eaurora.org>
Subject: Re: [PATCH v13 0/4] userspace MHI client interface driver

On Tue, Dec 01, 2020 at 09:59:53PM -0700, Jeffrey Hugo wrote:
> On 12/1/2020 7:55 PM, Jakub Kicinski wrote:
> > 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).
>
> Funny, that exactly what the GPS "API" in the kernel is, although a bit
> limited to the specifics on the standardized GPS "sentences" and not
> covering implementation specific configuration.
>
> >
> > > > > 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.
> >
>
> No I'm saying (and Bjorn/Mani by the looks of things), that there is
> commonality in the core features - IP traffic, Wi-Fi, etc but then there are
> vendor specific things which are either things you don't actually want in
> the kernel, don't want the kernel doing, or have little commonality between
> vendors such that attempting to unify them gains you little to nothing.
>
> Over in the networking space, I can see where standardization is plenty
> useful.
>
> I can't speak for other vendors, but a "modem" or a "wlan" device from
> Qualcomm is not something that just provides one service.  They tend to
> provide dozens of different functionalities, some of those are
> "standardized" like wi-fi where common wi-fi interfaces are used. Others are
> unique to Qualcomm.
>
> The point is "wlan device" is a superset of "wi-fi".  You seem to be
> equating them to be the same in a "shoot first, ask questions later" manner.
>
> This series provides a way for userspace to talk to remote MHI "widgets" for
> usecases not covered elsewhere.  Those "widgets" just happen to commonly
> provide modem/wlan services, but ones that don't are not excluded.
>
> Regarding not coming near networking, I'd like to remind you it was you that
> decided to come over here to the non-networking area and try to make this
> about networking.

Like it or not, but Jakub is absolutely right with his claim that
providing user-visible interfaces without any standardization is proven
as wrong.

Thanks

>
> --
> Jeffrey Hugo
> Qualcomm Technologies, Inc. is a member of the
> Code Aurora Forum, a Linux Foundation Collaborative Project.

Powered by blists - more mailing lists