Changes in MBIM v1.0 "Errata" 1

[Bjørn Mork]

Aleksander Morgado <aleksander at lanedo.com> writes:

> 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.

I haven't thought about how this should be implemented yet. And I don't
think I'm going to put any effort into it until we see a device using
the descriptor. I considered adding a patch to lsusb, but at the moment
even that seems like a waste of time.  We can easily do manual parsing
of this descriptor of/when it appears, and the "UNRECOGNIZED CDC" dump
will actually help us spot it.

Better leave this as a very low priority task.  Maybe "should use" was
too strong here...

>>   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.

I read strict fragment ordering as a requirement in the initial version,
so I don't think that is new.  Only claryfied.

>>   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.

We'd all love to have more assorted MBIM devices :) Guess we'll just
have to wait and see what shows up.  I'm a bit surprised there aren't
more of them yet.

>> 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.

Yup.  And there are no new CIDs (according to the index table in section
10.1), so I don't exepect any major changes in the part that is left.


Bjørn