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

Date:   Sun, 28 Feb 2021 21:22:36 +0530
From:   Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
To:     Aleksander Morgado <aleksander@...ksander.es>
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

On Sun, Feb 28, 2021 at 03:12:42PM +0100, Aleksander Morgado wrote:
> 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?
> 

Hemant is currently in-charge of the MHI UCI development effort. We were
thinking about doing "mhi-wwan" driver which just exposes the channels needed
for WWAN as Jakub said "you can move forward on purpose build drivers
(e.g. for WWAN)." But we are open to other suggestions also.

Thanks,
Mani