the Huawei K3806

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



And - I'm sorry , I forgot something important...
Even here you can observe the BAD CDC descriptor error - after the cdc_ether 
driver tried to attach to the device.
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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux