thank you for your help and incredible knowledge. I would never have arrived to this depth of details and conclusion. Effectively, it looks like a firmware for such a product, is practically a collage. The complexity is so high, so many parts of the code aren't provided even to manufacturers and crutfs are all over. XD So - should I add the new interface to the driver? Thank you. On Thu, 27 Jun 2013, Bj?rn Mork wrote: ==Date: Thu, 27 Jun 2013 17:44:46 +0200 ==From: Bj?rn Mork <bjorn@xxxxxxx> ==To: Enrico Mioso <mrkiko.rs@xxxxxxxxx> ==Cc: linux-usb@xxxxxxxxxxxxxxx, == Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>, == Dan Williams <dcbw@xxxxxxxxxx>, Johan Hovold <jhovold@xxxxxxxxx>, == Richard Weinberger <richard@xxxxxx>, antony.marsico@xxxxxxxxx ==Subject: Re: [PATCH / RFC] qcserial: Add support for ONYX 3G (Alfa network) == ==Enrico Mioso <mrkiko.rs@xxxxxxxxx> writes: == ==> Hi Bjorn and thank you very much for your kindness, attention and reply! ==> ==> Yes - I tested the all three ports of the device, even because my understanding ==> of the Windows INF files is very primitive! ==> And yes - I have verified that the device doesn't correspond to any of the goby ==> layouts, even if I would like more opinions on this. I', a newbie in USB ==> reverse engineering, if we can define it this way! :) ==> ==> both the true MODEM and management ports are working as expected, and also the ==> NMEA is. Infact, I got voice audio from that port. You can also empirically get ==> the signal with aplay and some exoteric settings. == ==OK, that's much more verification than we usually do. Thanks. == == ==> then the next topic - QMI. I was already thinking of it, but wanted to try to ==> do the work in a different time frame. ==> So: we're mapping interfaces 0, 2, 3 and 4. The missing interface 1 remains ==> out, and I was thinking it's QMI, as is the case of Huawei E173. ==> This doesn't impress me so much, since you can see traces of a primitive Huawei ==> design looking at the command-set and in some comments in the inf files. ==> another thing that makes me think it would be QMI, is the following answer from ==> the device: ==> Command: at+msmtype ==> Answer: MSM90VO 1 [Feb 04 2008 05:00:00] ==> ==> And I remember QMI was adopted in MSM series. So I tried modifying the ==> qmi_wwan.c driver in a rudimentary way to test this out. ==> ... ==> {QMI_FIXED_INTF(0x05c6, 0x0023, 1)}, ==> ... ==> ==> But, the driver probe fails with the following error: ==> ==> [272967.950680] qmi_wwan: probe of 2-2:1.1 failed with error -22 ==> [272967.951911] usbcore: registered new interface driver qmi_wwan ==> ==> And I don't know how to move on. What is the meaning of the -22 error? == ==22 = EINVAL. And looking at the driver, the likely cause is a missing ==interrupt endpoint. Which matches the lsusb output. Interface #1 ==cannot be a QMI/wwan function. 3 endpoints are required for that: ==interrupt in and bulk in+out. == == == == == I was ==> remembering somehow a "Resource is busy" kind of error, but, looking at what ==> libusb tells: ==> bus=2, addr=15, idVendor=05c6, idProduct=0023 ==> interface 0: kernel driver active //qcserial ==> interface 1: no active driver ==> interface 2: kernel driver active //qcserial ==> interface 3: kernel driver active //qcserial ==> interface 4: kernel driver active //usb-storage (mmc + cd-rom) ==> ==> Might be this is not QMI? I don't think it's CDC, but I send here the lsusb -vv ==> output: ==> ==> Bus 002 Device 015: ID 05c6:0023 Qualcomm, Inc. ==> Device Descriptor: ==> bLength 18 ==> bDescriptorType 1 ==> bcdUSB 1.10 ==> bDeviceClass 0 (Defined at Interface level) ==> bDeviceSubClass 0 ==> bDeviceProtocol 0 ==> bMaxPacketSize0 64 ==> idVendor 0x05c6 Qualcomm, Inc. ==> idProduct 0x0023 ==> bcdDevice 0.00 ==> iManufacturer 1 3G USB Modem ?? ==> iProduct 2 (error) == ==Fascinating. The complete lack of testing of these modem firmwares ==still surprise me. But the real wonder is that some of it sort of ==works anyway. == ==> Interface Descriptor: ==> bLength 9 ==> bDescriptorType 4 ==> bInterfaceNumber 1 ==> bAlternateSetting 0 ==> bNumEndpoints 2 ==> bInterfaceClass 255 Vendor Specific Class ==> bInterfaceSubClass 255 Vendor Specific Subclass ==> bInterfaceProtocol 255 Vendor Specific Protocol ==> iInterface 3 3G Devices ==> Endpoint Descriptor: ==> bLength 7 ==> bDescriptorType 5 ==> bEndpointAddress 0x84 EP 4 IN ==> bmAttributes 2 ==> Transfer Type Bulk ==> Synch Type None ==> Usage Type Data ==> wMaxPacketSize 0x0040 1x 64 bytes ==> bInterval 0 ==> Endpoint Descriptor: ==> bLength 7 ==> bDescriptorType 5 ==> bEndpointAddress 0x04 EP 4 OUT ==> bmAttributes 2 ==> Transfer Type Bulk ==> Synch Type None ==> Usage Type Data ==> wMaxPacketSize 0x0040 1x 64 bytes ==> bInterval 0 == == ==This is most likely another serial port of some sort. Maybe QCDM if the =="management port" speaks AT commands? == == ==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