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?
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
