Bjørn Mork bjorn at
Mon Aug 26 11:55:30 UTC 2019


The recent PCIe discussion made me realize that it's been a while since
I looked at what the USB-IF are up to. From the looks of their website,
most of the energy is currently put into making the contents hard to

But I did find one document with some relevance: "USB Multiflow
Extension for MBIM v1.0" -

This isn't simply adding new MBIM control messages, but is also
extending the data transport with the two new types

  - Raw IPv4 or IPv6 Control (signature "IPC" or "ipc")
  - Device Service Control (signature "DSC" or "dsc")

This means that the driver must be updated. Adding the new signatures
and parsing the control messages seems easy enough, so I could do that.
But before I do, I wonder if there is any point?  Does anyone care?  The
fact that this document has existed for 2 years without anyone pushing a
simple patch or asking about it is not a good sign...

And if we were to add support, what are we supposed to do with the
control messages?  Deliver them to userspace? count them? attempt to do
some qos magic?

Note that the current driver allows some debugging of these messages.
Just enable netif "rx_err" debugging and watch for any "unsupported NDP
signature" messages.  This won't show the contents, though.  I guess we
probably should add a separate debug code path with the contents, even
if we don't do anything else with these messages.

Provided there are any devices capable of sending them.  Does anyonw

And then there is the question of sending control messages to the
device.  Should that be suppported? Don't know if that is uplink or
downlink in the document terminology.  Sort of depends which side of the
link you are looking at :-) It would have been nice if they could have
used "todevice" or "fromhost" or similar for us easily confused out
there.  I never get ingress/egress or uplink/downlink right.  Probably
because I'm always looking into the wrong end of the pipe.


More information about the libmbim-devel mailing list