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
