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
