Changes in MBIM v1.0 "Errata" 1

[Aleksander Morgado]

Hey!

> I briefly looked through the documents side by side, and noted the
> following differences (numbering refer to the updated version, dated May
> 2013).  Also including my personal view on how this affects the driver
> and libmbim:
> 

Superb! Thanks for doing this

> 
>   Section 6.5 MBIM EXTENDED FUNCTIONAL DESCRIPTOR
>     new functional descriptor
> 
>     driver: useless new functionaliy
>     libmbim: should use bMaxOutstandingCommandMessages 
> 

Any idea how libmbim is going to get this property? Will you update the
driver with a new ioctl()? In libmbim side we just need to keep count of
how many ongoing requests the MbimDevice has sent, and avoid sending
more than the max allowed. Clients using the MbimDevice won't need to
take care of anything.

> 
>   Section 7 DATA TRANSPORT
>     giving explicit minimum datagram lengths for IPv4 (20) IPv6 (40)
>     and DSS (0)
> 
>     driver: implements this for IPv4 and DSS, but reuse the IPv4 limit
>             for IPv6.  Should be fixed.
>     libmbim: no effect
> 
> 
>   Section 7.1.5 MBIM ALLOWS MULTIPLE NDPS WITHIN ONE NTB
>     wNextNdpIndex cannot be reserved if we are to support multiplexing
>     sessions within a single NTB
> 
>     driver: as already implemented
>     libmbim: no effect
> 
> 
>   Section 9.1 MBIM MESSAGE HEADER
>     TransactionId 0 is reserved for exclusive use by notifications and
>     by MBIM_FUNCTION_ERROR_MSG if the TransactionId of the control
>     message causing the error cannot be determined.
> 
>     driver: no effect
>     libmbim: as already implemented?
> 

It is probably fine as we handle it right now, but I would need to
check... specially because I internally treated 0 as invalid.

> 
>   Section 9.3.1.1 MBIM_OPEN_MSG FORMAT
>     If the MaxControlTransfer is less than 64 bytes the device behavior
>     is unspecified.
> 
>     For test purposes the function shall support a MaxControlTransfer of
>     64 bytes.  In addition any other value shall be a multiple of the
>     maximum control endpoint size
> 
>     driver: no effect
>     libmbim: no effect (this affects only the device side)
> 
> 
>   Section 9.5 FRAGMENTATION OF MESSAGES
> 
>     If the function receives a first fragment of a new command with a
>     new TransactionId, the function shall discard the previous command
>     and start handling the new command. If the function receives a
>     fragment that is not the first fragment of a new command with a new
>     TransactionId, both commands shall be discarded. One
>     MBIM_FUNCTION_ERROR_MSG message per TransactionId shall be sent.
> 
>     driver: no effect
>     libmbim: no effect (this affects only the device side)
> 

In libmbim side, we should make sure that multiple fragments of
different requests are never mixed. I believe this is the current
approach, but will check it anyway.

> 
>   Section 10.5.1 MBIM_CID_DEVICE_CAPS
> 
>     This is a bitmap that represents the control capabilities that the
>     device supports. The following table shows the valid MBIM_CTRL_CAPS
>     settings for GSM-based and CDMA-based devices. Devices that support
>     CDMA must specify MBIMCtrlCapsCdmaMobileIp, or
>     MBIMCtrlCapsCdmaSimpleIp, or both flags to inform the host about the
>     type of IP that the device supports.
> 
>     driver: no effect
>     libmbim: no effect (this affects only the device side) ?
> 

I'd love to have a CDMA-based MBIM device; still need to support those
properly in MM.

> 
> 
> That's as far as I got.  Haven't checked the rest yet.  And I could very
> well have missed important changes when manually diffing the documents
> like this...
> 

So far, not much to be changed, if anything, in libmbim.

-- 
Aleksander