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

[Daniele Palmas <dnlplm@gmail.com>]

Hello,

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