netdev - Re: [PATCH v17 3/3] bus: mhi: Add userspace client interface driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 12 Dec 2020 11:38:18 +0530
From:   Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Dan Williams <dcbw@...hat.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Hemant Kumar <hemantk@...eaurora.org>,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        jhugo@...eaurora.org, bbhatt@...eaurora.org,
        loic.poulain@...aro.org, netdev@...r.kernel.org
Subject: Re: [PATCH v17 3/3] bus: mhi: Add userspace client interface driver

On Fri, Dec 11, 2020 at 08:08:16PM -0800, Jakub Kicinski wrote:
> On Fri, 11 Dec 2020 11:37:34 -0600 Dan Williams wrote:
> > Just to re-iterate: QMI ~= AT commands ~= MBIM (not quite, but same
> > level)
> > 
> > We already do QMI-over-USB, or AT-over-CDC-ACM. This is QMI-over-MHI.
> 
> Why do we need a different QMI-over-X for every X? If you say there 
> are already chardev interfaces to configure WWAN why not provide one 
> of those?
> 

Just because the underlying PHY is different and it offers more services than
just configuring the modem (downloading crash dump, firmware download etc...)

The existing chardev nodes are closely tied to the physical interfaces. For
instance, /dev/cdc_wdm is used by the USB based WWAN devices. So we really can't
reuse it for MHI/PCIe.

> > It's not networking data plane. It's WWAN device configuration.
> 
> Ack. Not that network config doesn't fall under networking, but eh.
> I wonder - did DaveM ever ack this, or was it just out of his sight
> enough, behind the cdev, to never trigger a nack?
> 
> > There are no current kernel APIs for this, and I really don't think we
> > want there to be. The API surface is *huge* and we definitely don't
> > want that in-kernel.
> 
> It is what it is today for WWAN. I don't think anyone in the
> development community or among users is particularly happy about
> the situation. Which makes it rather self evident why there is 
> so much apprehension about this patch set. It's going to be 
> a user space channel for everything Qualcomm - AI accelerator etc.
> Widening the WWAN status quo to more device types.

Well not everything Qualcomm but for just the subsystems where there is no
standardization right now. I think we went too far ahead for standardizing
the modems.

Thanks,
Mani