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]
Message-ID: <CAMZdPi8vBuFz-K8hVgvaKMw8ve=4w3wm7oQwV18XqZzCyHDXag@mail.gmail.com>
Date:   Mon, 1 Feb 2021 21:08:00 +0100
From:   Loic Poulain <loic.poulain@...aro.org>
To:     Dan Williams <dcbw@...hat.com>
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, 1 Feb 2021 at 19:53, Dan Williams <dcbw@...hat.com> wrote:
>
> 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
>

Right, it's not specific to MBIM, it would be just about decoupling
protocol from transport (though MBIM is originally specified with USB
transport). Having a WWAN framework/subsystem would indeed make sense,
at least to structure the way all modems services/channels are exposed
and grouped (today we have netdev, chardev, tty, etc) but it's far
beyond this series, I'm not against restarting the discussion though.

Regards,
Loic

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ