linux-kernel - Re: [RESEND PATCH v18 0/3] userspace MHI 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]

Message-ID: <CAAP7uc+Q=ToKVNz4wDv0JWHK4NTniSLE1QwMbP0eXEqVMTUwwQ@mail.gmail.com>
Date:   Sun, 28 Feb 2021 15:12:42 +0100
From:   Aleksander Morgado <aleksander@...ksander.es>
To:     Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        Loic Poulain <loic.poulain@...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 Manivannan, Jakub & all,

>
> So please let us know the path forward on this series. We are open to
> any suggestions but you haven't provided one till now.
>

I just found out that Sierra Wireless also provides their own version
of mhi-net and mhi-uci in precompiled binaries for several Ubuntu
kernel versions and other setups; and that made me extremely unhappy.
They're not the only manufacturer doing that; most of them are doing
it, because we don't have yet a common solution in upstream Linux. Not
the first time we've seen this either, see the per-vendor GobiNet
implementations vs the upstream qmi_wwan one. I was hoping we could
avoid that mess again with the newer Qualcomm modules! :)

In ModemManager we've always *forced* all manufacturers we interact
with to first do the work in upstream Linux, and then we integrate
support in MM for those drivers. We've never accepted support for
vendor-specific proprietary kernel drivers, and that's something I
would personally like to keep on doing. The sad status right now is
that any user that wants to use the newer 5G modules with Qualcomm
chipsets, they need to go look for manufacturer-built precompiled
drivers for their specific kernel, and also then patch ModemManager
and the tools themselves. Obviously almost no one is doing all that,
except for some company with resources or a lot of interest. Some of
these new 5G modules are PCIe-only by default, unless some pin in the
chipset is brought up and then some of them may switch to USB support.
No one is really doing that either, as tampering with the hardware
voids warranty.

The iosm driver is also stalled in the mailing list and there doesn't
seem to be a lot of real need for a new common wwan subsystem to
rework everything...

I'm not involved with the mhi-uci driver development at all, and I
also don't have anything to say on what goes in the upstream kernel
and what doesn't. But as one of the ModemManager/libqmi/libmbim
maintainers I would like to represent all the users of these modules
that are right now forced to look for shady binary precompiled drivers
out there... that is no better solution than this proposed mhi-uci
common driver.

Manivannan, are you attempting to rework the mhi-uci driver in a
different way, or have you given up? Is there anything I could help
with?

Jakub, is there really no way you can be convinced that this mhi-uci
driver isn't that bad after all? :) All the mhi-net bits are already
integrated I think, even the MBIM support over MHI in the net device,
but all that is truly useless without a way to control the modem
sending and receiving messages.

Sorry for being back again with this discussion :)

Cheers!

--
Aleksander
https://aleksander.es