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]
Date:   Mon, 01 Feb 2021 12:53:12 -0600
From:   Dan Williams <dcbw@...hat.com>
To:     Loic Poulain <loic.poulain@...aro.org>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        David Miller <davem@...emloft.net>,
        Network Development <netdev@...r.kernel.org>,
        Carl Yin(殷张成) 
        <carl.yin@...ctel.com>,
        Bjørn Mork <bjorn@...k.no>
Subject: Re: [PATCH net-next 3/3] net: mhi: Add mbim proto

On Mon, 2021-02-01 at 19:27 +0100, Loic Poulain wrote:
> On Mon, 1 Feb 2021 at 19:17, Dan Williams <dcbw@...hat.com> wrote:
> > On Fri, 2021-01-29 at 18:21 -0800, Jakub Kicinski wrote:
> > > On Wed, 27 Jan 2021 18:01:17 +0100 Loic Poulain wrote:
> > > > MBIM has initially been specified by USB-IF for transporting
> > > > data
> > > > (IP)
> > > > between a modem and a host over USB. However some modern modems
> > > > also
> > > > support MBIM over PCIe (via MHI). In the same way as
> > > > QMAP(rmnet),
> > > > it
> > > > allows to aggregate IP packets and to perform context
> > > > multiplexing.
> > > > 
> > > > This change adds minimal MBIM support to MHI, allowing to
> > > > support
> > > > MBIM
> > > > only modems. MBIM being based on USB NCM, it reuses some
> > > > helpers
> > > > from
> > > > the USB stack, but the cdc-mbim driver is too USB coupled to be
> > > > reused.
> > > > 
> > > > At some point it would be interesting to move on a factorized
> > > > solution,
> > > > having a generic MBIM network lib or dedicated MBIM netlink
> > > > virtual
> > > > interface support.
> > 
> > What would a kernel-side MBIM netlink interface do?  Just data-
> > plane
> > stuff (like channel setup to create new netdevs), or are you
> > thinking
> > about control-plane stuff like APN definition, radio scans, etc?
> 
> Just the data-plane (mbim encoding/decoding/muxing).

Ah yes :) If so, then fully agree.

But is that really specific to MBIM? eg, same kinds of things happen
for QMI. Johannes referred to a more generic WWAN framework that we had
discussed 1.5+ years ago to address these issues. Might be worth
restarting that, perhaps simplifying, and figuring out the minimal set
of generic bits needed to describe/add/delete a data channel for WWAN
control protocols.
Dan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ