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
