After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 698869 - [MM 0.8] zte CDMA devices don't like byte-at-a-time QCDM command writes
[MM 0.8] zte CDMA devices don't like byte-at-a-time QCDM command writes
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: ModemManager
unspecified
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2013-04-25 17:04 UTC by Dan Williams
Modified: 2013-04-30 14:39 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dan Williams 2013-04-25 17:04:07 UTC
For some reason, the ZTE CDMA device I've got (AC2726) doesn't respond to QCDM commands the way the MMQcdmSerialPort sends them, which is one-byte-at-a-time using the default MMSerialPort SendDelay of 1000us.

I tested other values, 500 and 100us, but it hates those too.  But a send delay of 0 works.  Oddly, the libqcdm test utilities, which do usleep (1000) and do send byte-at-a-time *do* work, but I'm not sure why.

In any case, I think I'll test out the QCDM-capable devices I've got with a zero send_delay and see if any of them choke; I can't think why they would.  Having a send_delay splits each byte up into separate USB transactions depending on the TTY settings.

(I have an odd feeling that this may be related to kernel driver changes, but I'm not sure.  Need to test with older kernels to see if that makes a difference with send delay.)

Known to work with zero send-delay on kernel 3.8.8:

ZTE AC2726
Novatel E362
LG Rumor2 (phone)
Novatel E725
Sanyo Katana LX (phone)
Huawei EC168C
Franklin U600
LG PM325 (phone)
Samsung M800 Instinct (phone)
Comment 1 Dan Williams 2013-04-29 15:23:17 UTC
I think we should just do this, though I'll test it also on a slightly older kernel too.  Does the following patch look fine?

diff --git a/src/mm-qcdm-serial-port.c b/src/mm-qcdm-serial-port.c
index bce8051..281d09e 100644
--- a/src/mm-qcdm-serial-port.c
+++ b/src/mm-qcdm-serial-port.c
@@ -231,6 +231,7 @@ mm_qcdm_serial_port_new (const char *name)
                                               MM_PORT_DEVICE, name,
                                               MM_PORT_SUBSYS, MM_PORT_SUBSYS_TTY,
                                               MM_PORT_TYPE, MM_PORT_TYPE_QCDM,
+                                              MM_SERIAL_PORT_SEND_DELAY, (guint64) 0,
                                               NULL));
 }
 
@@ -245,6 +246,7 @@ mm_qcdm_serial_port_new_fd (int fd)
                                               MM_PORT_DEVICE, name,
                                               MM_PORT_SUBSYS, MM_PORT_SUBSYS_TTY,
                                               MM_PORT_TYPE, MM_PORT_TYPE_QCDM,
+                                              MM_SERIAL_PORT_SEND_DELAY, (guint64) 0,
                                               MM_SERIAL_PORT_FD, fd,
                                               NULL));
     g_free (name);
Comment 2 Aleksander Morgado 2013-04-30 07:15:59 UTC
Looks good to me
Comment 3 Dan Williams 2013-04-30 14:39:30 UTC
Fix pushed.