On Mon, 2021-02-01 at 19:27 +0100, Loic Poulain wrote: > On Mon, 1 Feb 2021 at 19:17, Dan Williams <d...@redhat.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