MC7304 connection?

[Bjørn Mork]

Aleksander Morgado <aleksander at aleksander.es> writes:
> On Wed, May 21, 2014 at 10:27 AM, Bjørn Mork <bjorn at mork.no> wrote:
>> Aleksander Morgado <aleksander at aleksander.es> writes:
>>
>>> So, what to do with these two interfaces now? Should we just ignore
>>> them in the kernel driver? Is there anything else I could try with? I
>>> may try to implement "WDA Set Data Format" and play with it...
>>
>>
>> The 3rd port is probably dead until we get any further clues.  But I
>> think we should try harder to make the 2nd port work before giving up.
>> Using the WDA "set format" command is certainly worth an attempt.  I
>> don't know the exact relationship to the CTL "set format", but do note
>> that the WDA command allows assymetric settings.  Which will screw up
>> stuff for the qmi_wwan driver.
>>
>
> WDA docs say that if one client uses CTL Set Data Format and another
> one uses WDA Set Data Format, an "Invalid Operation" error will be
> returned for the second one. I'll try to play with WDA Set Data Format
> anyway.

Did you try CTL Set Data Format first to raw-ip and then back to 802.3?
That ought to reset any existing setting.

>> And did you try using e.g. '--device-set-instance-id=1' prior to the
>> --device-open-net etc command?
>>
>
> Tried now, and didn't help.

No, that makes sense now I tried it myself.  Setting the same instance
ID on both QMI functions work fine for me.  I do note that the return
TLV has two bytes.  One of these is the input ID, while the other is
fixed per function.  So I get:

bjorn at nemi:~$ qmicli -v -d /dev/cdc-wdm0 --device-set-instance-id=0
..
[21 May 2014, 11:54:35] [Debug] [/dev/cdc-wdm0] Received message (translated)...
>>>>>> QMUX:
>>>>>>   length  = 23
>>>>>>   flags   = 0x80
>>>>>>   service = "ctl"
>>>>>>   client  = 0
>>>>>> QMI:
>>>>>>   flags       = "response"
>>>>>>   transaction = 1
>>>>>>   tlv_length  = 12
>>>>>>   message     = "Set Instance ID" (0x0020)
>>>>>> TLV:
>>>>>>   type       = "Result" (0x02)
>>>>>>   length     = 4
>>>>>>   value      = 00:00:00:00
>>>>>>   translated = SUCCESS
>>>>>> TLV:
>>>>>>   type       = "Link ID" (0x01)
>>>>>>   length     = 2
>>>>>>   value      = 00:00
>>>>>>   translated = 0

[/dev/cdc-wdm0] Instance ID set:
        Link ID: '0'


And

bjorn at nemi:~$ qmicli -v -d /dev/cdc-wdm1 --device-set-instance-id=0
..
[21 May 2014, 11:55:11] [Debug] [/dev/cdc-wdm1] Received message (translated)...
>>>>>> QMUX:
>>>>>>   length  = 23
>>>>>>   flags   = 0x80
>>>>>>   service = "ctl"
>>>>>>   client  = 0
>>>>>> QMI:
>>>>>>   flags       = "response"
>>>>>>   transaction = 1
>>>>>>   tlv_length  = 12
>>>>>>   message     = "Set Instance ID" (0x0020)
>>>>>> TLV:
>>>>>>   type       = "Result" (0x02)
>>>>>>   length     = 4
>>>>>>   value      = 00:00:00:00
>>>>>>   translated = SUCCESS
>>>>>> TLV:
>>>>>>   type       = "Link ID" (0x01)
>>>>>>   length     = 2
>>>>>>   value      = 00:01
>>>>>>   translated = 256

[/dev/cdc-wdm1] Instance ID set:
        Link ID: '256'


This seems to be hardcoded in the firmware.  So I guess the configurable
ID is pointless for us.

>> usbmon snooping might also tell us something if the problem really is
>> related to framing mismatch.
>>
>
> Will try to see if usbmon helps.

Let's hope it gives us some pointers at least.  I'm completely lost now.


Bjørn