Ok. so I will prepare a patch for option instead. Thank you!
On Thu, 27 Jun 2013, Dan Williams wrote:
==Date: Thu, 27 Jun 2013 12:56:49 -0500
==From: Dan Williams <dcbw@xxxxxxxxxx>
==To: Bj?rn Mork <bjorn@xxxxxxx>
==Cc: Enrico Mioso <mrkiko.rs@xxxxxxxxx>, linux-usb@xxxxxxxxxxxxxxx,
== Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>,
== Johan Hovold <jhovold@xxxxxxxxx>, Richard Weinberger <richard@xxxxxx>,
== antony.marsico@xxxxxxxxx
==Subject: Re: [PATCH / RFC] qcserial: Add support for ONYX 3G (Alfa network)
==
==On Thu, 2013-06-27 at 18:34 +0200, Bj?rn Mork wrote:
==> Enrico Mioso <mrkiko.rs@xxxxxxxxx> writes:
==>
==> > 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.
==>
==> Yes, I believe so.
==>
==> Although I haven't yet managed to agree with myself whether it was a
==> good idea or not so make qcserial manage such devices. This was maybe
==> what qcaux was meant for. What do you say, Dan?
==
==Non-Gobi devices that support QMI should go into option or qcaux or
==sierra or whatever, qcserial should probably be kept to actual Gobi
==devices only.
==
==Dan
==
==>
==>
==> Bj?rn
==>
==> > 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
==
==
==
--
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
