Dan Williams <dcbw@xxxxxxxxxx> writes: > On Fri, 2012-06-22 at 11:24 -0500, Dan Williams wrote: > >> I did try my qmitest (from git.fdo) on all ports of the device except >> the ether port, and got nothing. >> >> I'll do some Windows traces to see if it does use QMI on the Ethernet >> endpoints. I know it doesn't do QMI on any of the serial interfaces >> (ff/ff/ff) based on the Windows drivers. I could be completely wrong, >> but I'm really expecting QMI on this device, given that it's a MDM9600. > > Yeah, a whole lot of QMI over the CDC Ether interface using control > transfers. lsusb -v output for the ether interfaces is: > > Interface Association: > bLength 8 > bDescriptorType 11 > bFirstInterface 6 > bInterfaceCount 2 > bFunctionClass 2 Communications > bFunctionSubClass 0 > bFunctionProtocol 0 > iFunction 0 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 6 > bAlternateSetting 0 > bNumEndpoints 1 > bInterfaceClass 2 Communications > bInterfaceSubClass 6 Ethernet Networking > bInterfaceProtocol 0 OK, so if this device works with qmi_wwan then it's a clear candidate for the new control interface based matching in 3.6. Don't think we can support it in 3.4 and 3.5. And it will require a blacklisting entry in cdc_ether as well. But please test and verify that it works before doing that. Why didn't the test scripts work? > iInterface 0 > CDC Header: > bcdCDC 1.10 > CDC Ethernet: > iMacAddress 1 (??) That's odd. Someone forgot to add the MAC address string descriptor in the firmware? > ** UNRECOGNIZED: 2c ff 42 49 53 54 00 01 07 06 40 00 00 00 00 > 00 01 07 f4 01 02 08 f4 01 03 09 88 13 04 0a 10 27 05 0b 10 27 06 0c f4 > 01 07 0d f4 01 And what's that? Hmm, I have commented on that one before, haven't I? If so, then maybe my memory isn't all that bad after all :-) Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
