Message-ID: <CAAP7ucLVVTUqMX4_jFvvYNXALHgHZmcvX4WQei8cPubfUgXKGQ@mail.gmail.com>
Date:   Tue, 9 Feb 2021 17:49:50 +0100
From:   Aleksander Morgado <aleksander@...ksander.es>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Loic Poulain <loic.poulain@...aro.org>,
        Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        David Miller <davem@...emloft.net>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        Jeffrey Hugo <jhugo@...eaurora.org>,
        Bhaumik Bhatt <bbhatt@...eaurora.org>,
        Network Development <netdev@...r.kernel.org>
Subject: Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver

Hey,

> On Tue, 9 Feb 2021 10:20:30 +0100 Aleksander Morgado wrote:
> > This may be a stupid suggestion, but would the integration look less a
> > backdoor if it would have been named "mhi_wwan" and it exposed already
> > all the AT+DIAG+QMI+MBIM+NMEA possible channels as chardevs, not just
> > QMI?
>
> What's DIAG?

DIAG/QCDM is an older protocol in Qualcomm based modems; in USB based
devices we would get a TTY that speaks this protocol. In legacy CDMA
modems this was required for actual device control (and ModemManager
has a libqcdm for that
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/tree/master/libqcdm)
but in all newest modems I'd say this is exclusively used for modem
trace retrieval (e.g. asking the modem to enable some internal traces
of the LTE stack which are downloaded in the host via this port). When
debugging issues with manufacturers, this is what they would ask you
to do, use this port to retrieve these traces (e.g. Quectel's QLog
program does that, each manufacturer keeps its own).

> Who's going to remember that this is a backdoor driver
> a year from now when Qualcomm sends a one liner patches which just
> adds a single ID to open another channel?

I'm obviously not going to argue about that possibility; although,
wouldn't it make more sense to discuss that whenever that happens?
This work is implemented in a very generic way probably, but it
focuses on WWAN control ports, which is what we need in userspace.

Right now this mhi_uci integration can be used for QMI control of the
modems, and I assume once that gets merged (if ever!), more patches
would arrive to enable AT, DIAG and MBIM control ports. The channels
associated to these WWAN control protocols have clearly defined
channel ids, and I believe the device itself chooses which channels
are exposed, so a device may e.g. say that it's going to expose only
the MBIM control port. This is also very manufacturer dependent I
think; I know for example that WWAN modules for laptops will probably
want to expose the MBIM channel instead of QMI, so that the same HW
integration is used in both Linux and Windows easily. The single and
generic mhi_uci integration for all these different WWAN control ports
would allow any of those combinations, very much like with USB devices
and different USB configurations.

Userspace is also ready for this integration, btw; at least libmbim
and libqmi don't have any problem with these chardevs, and
ModemManager has a branch ready to land to support this new
integration. A lot of new laptops that are already being sold since
last year come now with PCIe-only WWAN modules, and unfortunately I've
also seen different manufacturers pushing their own out-of-tree
variants of this same mhi_uci idea with better or worse luck. I
personally was very glad to see this work moving forward.

--
Aleksander

Powered by blists - more mailing lists