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] [day] [month] [year] [list]

Date:   Mon, 14 Dec 2020 10:16:44 +0100
From:   Daniele Palmas <dnlplm@...il.com>
To:     Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Cc:     Jakub Kicinski <kuba@...nel.org>, 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,
        Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH v17 3/3] bus: mhi: Add userspace client interface driver

Hello,

Il giorno dom 13 dic 2020 alle ore 15:22 Manivannan Sadhasivam
<manivannan.sadhasivam@...aro.org> ha scritto:
>
> 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.
>

let me also add that the current MHI UCI approach makes sense because
it makes the switch USB -> PCIe smooth, since all the current
open-source userspace tools (e.g. libqmi and qmicli), according to my
testing until now, properly works without any need for a change,
behaving the UCI QMI char device like cdc-wdm.

While a different solution (which one?) would maybe cause to re-think
the userspace side for having the same high-level behavior.

Thanks,
Daniele

> > > 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
>