Odd QMI devices - ZTE MF60

Bjørn Mork bjorn at mork.no
Thu Jul 5 03:42:41 PDT 2012


Aleksander Morgado <aleksander at lanedo.com> writes:

>> The Qualcomm chips may support multiple channels, best known from the
>> Android drivers I believe.  But there are also USB device firmwares
>> supporting this, like the Sierra Wireless MC7710.  It has a mode with 3
>> channels.  For some reason I cannot get the third one to work but the
>> first two work as expected: You get two QMI/wwan interfaces on the same
>> device, mostly looking like they are completely independent of each
>> other.  Device settings are of course shared, so this is not entirely
>> true, but important services like QMI_CTL and QMI_WDS look like they are
>> completely separated.
>> 
>> Now for the interesting part:  channel 1 always returns 1, while channel
>> 0 always returns 0 as seen on other devices.
>
> Does the link ID also include the requested instance ID in your tests?
> This is, if you set instance ID '5' in channel 1, does it return '0x05
> 0x01' ?

Yes.  Sending

  01 0f 00 00 00 00 00 00  20 00 04 00 01 01 00 05

to the first QMI/wwan USB interface returns

  01 17 00 80 00 00 01 00 20 00 0c 00 02 04 00 00 00 00  00 01 02 00 05 00

Sending the same command to the second QMI/wwan USB interface returns

  01 17 00 80 00 00 01 00 20  00 0c 00 02 04 00 00 00 00 00 01 02 00 05 01

So it looks like the first byte in the reply is the requested ID, as you
guessed, and the second byte is most likely a firmware internal link ID.
Which will appear as fixed for a specific USB interface.  I assume the
firmware has a static mapping table, mapping each link ID to a specific
chip control channel.  What we are talking to is probably looking a lot
like the rmnet gadget, which maps up to 3 ports statically to 3 control
channel names:
https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=blob;f=drivers/usb/gadget/u_rmnet_ctrl_smd.c;hb=msm-3.4

I am not sure you can consider it a "request", though.  It looks more
like a dictate.  I've not been able to trigger a failure to set a
specific ID.  The same ID can be used on both channels, without any
crosstalk effects or any other error.  The same ID can also be set
repeatedly on the same channel, or new IDs can be set regardless of what
the old one was.

So I still do not understand what this is intended for...  Only that it
seems to be needed on the MF60 and doesn't do any harm on the MC7710.


Bjørn


More information about the libqmi-devel mailing list