libqmi / Quectel EC21/EC25
Sebastian Sjoholm
sebastian.sjoholm at gmail.com
Sat Oct 8 22:10:12 UTC 2016
> On Oct 8, 2016, at 23:06 , Bjørn Mork <bjorn at mork.no> wrote:
>
> Sebastian Sjoholm <sebastian.sjoholm at gmail.com> writes:
>
>>>
>>>> Hi,
>>>>
>>>> So regarding my issue with Quectel EC21/EC25, I guess most of the times the problem is between the keyboard and the chair, and I guess it was now as well.
>>>>
>>>> When I followed the Quectel documentation on Linux integration I left the raw-ip implementation because linux kernel already have raw-ip support in the kernel, however at the end of that chapter was some crucial changes that I of course did not include. So, after included the changes in “qmi_wwan_bind”, it started to work.
>>>>
>>>> I have included the diff from my changes and the Linux Kernel 4.7.7.
>>>>
>>>> I have only verified EC25, but will soon run EC21 as well.
>>>>
>>>> /drivers/net/usb/qmi_wwan.c
>>>> 436,451d435
>>>> <
>>>> < /* Quectel */
>>>> < if (dev->udev->descriptor.idVendor == cpu_to_le16(0x2C7C)) {
>>>> < dev_info(&intf->dev, "Quectel EC21&EC25&EC20 R2.0 work on RawIP mode\n");
>>>> < dev->net->flags |= IFF_NOARP;
>>>> <
>>>> < usb_control_msg(
>>>> < interface_to_usbdev(intf),
>>>> < usb_sndctrlpipe(interface_to_usbdev(intf), 0),
>>>> < 0x22, //USB_CDC_REQ_SET_CONTROL_LINE_STATE
>>>> < 0x21, //USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE
>>>> < 1, //active CDC DTR
>>>> < intf->cur_altsetting->desc.bInterfaceNumber,
>>>> < NULL, 0, 100);
>>>> < }
>>>
>>>
>>> I don't understand. Except for the redundant IFF_NOARP (set in
>>> qmi_wwan_netdev_setup), this should be exactly the same as the
>>>
>>> qmi_wwan_change_dtr(dev, true);
>>>
>>> I asked you to try to enable unconditionally. And that didn't work?
>>>
>>
>> I did try that, yes, but I got the same timeout error with qmicli, but I will check again, and let you know.
>>
>> Just to make sure I get it right;
>>
>> instead of
>>
>> if (le16_to_cpu(dev->udev->descriptor.bcdUSB) >= 0x0201) {
>> qmi_wwan_manage_power(dev, 1);
>> qmi_wwan_change_dtr(dev, true);
>> }
>>
>> I will just have
>>
>> qmi_wwan_manage_power(dev, 1);
>> qmi_wwan_change_dtr(dev, true);
>>
>> And of course comment out the changes in “qmi_wwan_bind”.
>
> Yes. That should have the same effect. If it doesn't, then there must
> be something magic going on. Could be related to timing/ordering of
> course. Could you generate a context diff (diff -u) of the changes you
> have made, so that we can see where that control message is sent?
>
Here are now the changes in qmi_wwan.c
# diff -u linux-stable/drivers/net/usb/qmi_wwan.c linux-stable/drivers/net/usb/qmi_wwan.c_original
--- linux-stable/drivers/net/usb/qmi_wwan.c 2016-10-08 23:30:53.781557826 +0200
+++ linux-stable/drivers/net/usb/qmi_wwan.c_original 2016-10-08 10:33:16.800256426 +0200
@@ -413,14 +413,10 @@
* MDM9x30 is the first QMI chipset with USB3 support. Abuse
* this fact to enable the quirk.
*/
- /*
if (le16_to_cpu(dev->udev->descriptor.bcdUSB) >= 0x0201) {
qmi_wwan_manage_power(dev, 1);
qmi_wwan_change_dtr(dev, true);
}
- */
- qmi_wwan_manage_power(dev, 1);
- qmi_wwan_change_dtr(dev, true);
/* Never use the same address on both ends of the link, even if the
* buggy firmware told us to. Or, if device is assigned the well-known
@@ -928,12 +924,8 @@
{QMI_GOBI_DEVICE(0x05c6, 0x9225)}, /* Sony Gobi 2000 Modem device (N0279, VU730) */
{QMI_GOBI_DEVICE(0x05c6, 0x9245)}, /* Samsung Gobi 2000 Modem device (VL176) */
{QMI_GOBI_DEVICE(0x03f0, 0x251d)}, /* HP Gobi 2000 Modem device (VP412) */
- /* Quectel conflicts with Acer */
- /* {QMI_GOBI_DEVICE(0x05c6, 0x9215)},*/ /* Acer Gobi 2000 Modem device (VP413) */
- {QMI_FIXED_INTF(0x05c6, 0x9215, 4)}, /* Quectel EC20 Mini PCIe */
- {QMI_FIXED_INTF(0x05c6, 0x9003, 4)}, /* Quectel UC20 Mini PCIe */
- {QMI_FIXED_INTF(0x2C7C, 0x0125, 4)}, /* Quectel EC25, EC20 R2.0 Mini PCIe */
- {QMI_FIXED_INTF(0x2C7C, 0x0121, 4)}, /* Quectel EC21 Mini PCIe */
+ {QMI_GOBI_DEVICE(0x05c6, 0x9215)}, /* Acer Gobi 2000 Modem device (VP413) */
+ {QMI_FIXED_INTF(0x05c6, 0x9215, 4)}, /* Quectel EC20 Mini PCIe */
{QMI_GOBI_DEVICE(0x05c6, 0x9265)}, /* Asus Gobi 2000 Modem device (VR305) */
{QMI_GOBI_DEVICE(0x05c6, 0x9235)}, /* Top Global Gobi 2000 Modem device (VR306) */
{QMI_GOBI_DEVICE(0x05c6, 0x9275)}, /* iRex Technologies Gobi 2000 Modem device (VR307) */
#
And now I am able to access the EC25 as well.
# /usr/bin/qmicli -d /dev/cdc-wdm0 -E raw-ip
[/dev/cdc-wdm0] expected data format set to: raw-ip
# /usr/bin/qmicli -d /dev/cdc-wdm0 --wds-start-network=lte1.dynamic.com --client-no-release-cid
[/dev/cdc-wdm0] Network started
Packet data handle: '2274932272'
[/dev/cdc-wdm0] Client ID not released:
Service: 'wds'
CID: '19'
# /sbin/udhcpc -q -f -S -n -i wwan0
udhcpc (v1.22.1) started
Sending discover...
Sending select for 10.39.14.15...
Lease of 10.39.14.15 obtained, lease time 7200
ip: RTNETLINK answers: File exists
# /sbin/route -v add -host 10.218.245.160 dev wwan0
# ping -c 5 10.218.245.160
PING 10.218.245.160 (10.218.245.160) 56(84) bytes of data.
64 bytes from 10.218.245.160: icmp_seq=1 ttl=62 time=214 ms
64 bytes from 10.218.245.160: icmp_seq=2 ttl=62 time=30.4 ms
64 bytes from 10.218.245.160: icmp_seq=3 ttl=62 time=29.2 ms
64 bytes from 10.218.245.160: icmp_seq=4 ttl=62 time=38.6 ms
64 bytes from 10.218.245.160: icmp_seq=5 ttl=62 time=37.1 ms
--- 10.218.245.160 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 29.215/70.001/214.599/72.391 ms
# /usr/bin/qmicli -d /dev/cdc-wdm0 --wds-stop-network=2274932272 --client-cid=19
Network cancelled... releasing resources
[/dev/cdc-wdm0] Network stopped
#
Go figure, I don’t really know what difference my changes was from now and the previous tests. Maybe I revert the ‘qmi_wwan_change_dtr’ just to make sure I get the same fault again, that I had earlier.
-Sebastian
More information about the libqmi-devel
mailing list