[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201201120302.474d4c9b@kicinski-fedora-pc1c0hjn.DHCP.thefacebook.com>
Date: Tue, 1 Dec 2020 12:03:02 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Jeffrey Hugo <jhugo@...eaurora.org>
Cc: 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, 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.
> 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.
> Off the top of my head, this driver is useful for modems, wlan, and AI
> accelerators.
And other Qualcomm products are available as well :/
Kernel is supposed to create abstract interfaces for user space to
utilize. I will never understand why kernel is expected to be in
business of shipping this sort of vendor backdoors :/
Powered by blists - more mailing lists