Dan Williams dcbw at
Mon Aug 26 16:08:19 UTC 2019

On Mon, 2019-08-26 at 13:55 +0200, Bjørn Mork wrote:
> Hello!
> 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
> find.
> 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")

Whats the 30-second overview of these types?


> 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
> 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
> know?
> 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.
> Bjørn
> _______________________________________________
> libmbim-devel mailing list
> libmbim-devel at

More information about the libmbim-devel mailing list