option.ko: ZTE MF636 support

option.ko: ZTE MF636 support

[Peter Hicks]

Hello

I've discovered that the ZTE MF636 USB HSUPA modem (USB ID 19d2:0033)
doesn't play well with option.ko.  This seems to be a similar problem to
the 4G W14 stick (commit a74171005f2f6474e05bdfccb05c9f0d68224a49).

The symptom of this problem is that the first three serial ports on the
MF636 take around 10s to open with modem-manager, and fail to open with
Minicom.  The fourth serial port is fine.

Blacklisting the first three interfaces in option.c results in them
opening immediately.  This reduces modem detection time in modem-manager
from 20-30 seconds to around five.

As there is only a single blacklisted device in option.c at present,
what is the best way to work around this problem?  Can somebody help me
with writing a patch to submit to fix the problem in the kernel?

Regards,


Peter

RE: option.ko: ZTE MF636 support

[Nils Radtke]

  Hi,

Got an Olivetti olicard100 UMTS/HSDPA device here.

Devices: /dev/ttyUSB{0,1,2,3,4}

Similar symptoms are the long delay on opening of devices 0 and 2.
/dev/ttyUSB0: status port
/dev/ttyUSB2: modem port (not working)

Devices 1,3,4 are not usable in any way so far.

More info about this at:

http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?t=391

What has been your solution to get the ZTE working?

With the olicard100 there's so far been only one successful connection,
since then: nothing. pppd hangs spitting out non-printable chars, but
there's no answer from uplink, lcp config reqs are timing out.

Cheers,

Nils

RE: option.ko: ZTE MF636 support

[Peter Hicks]

[-- Attachment #1: Type: text/plain, Size: 688 bytes --]

Hi Nils

On Sun, 2010-05-09 at 16:22 +0200, Nils Radtke wrote:

> Similar symptoms are the long delay on opening of devices 0 and 2.
> /dev/ttyUSB0: status port
> /dev/ttyUSB2: modem port (not working)

Does "echo > /dev/ttyUSB0" return immediately, and "echo > /dev/ttyUSB2"
take around 15 seconds to return?

> What has been your solution to get the ZTE working?

I've blacklisted devices 0, 1 and 2 using the attached patch, taken
against 2.6.34-rc6.  It should be quite straightforward to modify this
for your device.

Without the patch, I'm able to use wvdial against ttyUSB3 to dial up,
but the device is unresponsive to anything apart from a PPP LCP
disconnect.

Regards,


Peter


[-- Attachment #2: zte-mf636-blacklist.patch --]
[-- Type: text/x-patch, Size: 1350 bytes --]

--- drivers/usb/serial/option.orig.c	2010-05-09 22:46:41.761498988 +0100
+++ drivers/usb/serial/option.c	2010-05-09 22:44:49.911498986 +0100
@@ -393,6 +393,13 @@
 	.reason = OPTION_BLACKLIST_SENDSETUP
 };
 
+static const u8 zte_mf636_no_sendsetup[] = { 0, 1, 2 };
+static const struct option_blacklist_info zte_mf636_blacklist = {
+	.infolen = ARRAY_SIZE(zte_mf636_no_sendsetup),
+	.ifaceinfo = zte_mf636_no_sendsetup,
+	.reason = OPTION_BLACKLIST_SENDSETUP
+};
+
 static const struct usb_device_id option_ids[] = {
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_COLT) },
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_RICOLA) },
@@ -609,7 +616,9 @@
 	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0030, 0xff, 0xff, 0xff) },
 	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MF626, 0xff, 0xff, 0xff) },
 	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0032, 0xff, 0xff, 0xff) },
-	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0033, 0xff, 0xff, 0xff) },
+	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0033, 0xff, 0xff, 0xff),
+  	  .driver_info = (kernel_ulong_t)&zte_mf636_blacklist
+  	},
 	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0037, 0xff, 0xff, 0xff) },
 	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0039, 0xff, 0xff, 0xff) },
 	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0042, 0xff, 0xff, 0xff) },

RE: option.ko: ZTE MF636 support

[Nils Radtke]

  Hi Peter,

>> Similar symptoms are the long delay on opening of devices 0 and 2.
>> /dev/ttyUSB0: status port
>> /dev/ttyUSB2: modem port (not working)
>Does "echo > /dev/ttyUSB0" return immediately, and "echo > /dev/ttyUSB2"
>take around 15 seconds to return?
Indeed, that's exactly what's happening.

>> What has been your solution to get the ZTE working?
>I've blacklisted devices 0, 1 and 2 using the attached patch, taken
>against 2.6.34-rc6.  It should be quite straightforward to modify this
>for your device.
Ah. It seems that there's been quite some change in the code base of the
option driver. Using .33.3 here. No such thing as "blacklisting".

>Without the patch, I'm able to use wvdial against ttyUSB3 to dial up,
>but the device is unresponsive to anything apart from a PPP LCP
>disconnect.
For the olicard100 it's been port 2, dialling, pppd starting up, but lcp 
cfg req timeouts. At least with the olicard100 there's been no real dialup.
Conn endpoint has never been talking to the device..

Thanks alot for your hint. Previously I intended to wait for the .34 to
come out, but regarding the promising changes in option.c I will reconѕider this.
What are your overall xp with .34 so far? rc-7 is out, quite a rc count.. Maybe
the .34 is also levelling out these days.. :)

Cheers,

Nils

2.6.34-rc7 option.c: support for olicard100 + zte636-0x0037

[Nils Radtke]

  Hi,

  using the attached patch to get the olicard100 umts-stick working. W/o success.
  No change in behaviour when trying to dial up.

  I noticed that I missed a device, no 4, in the blacklist. Re-testing soon.

  Cheers,

  Nils


Index: linux-2.6.34-rc7/drivers/usb/serial/option.c
===================================================================
--- linux-2.6.34-rc7.orig/drivers/usb/serial/option.c	2010-05-10 20:56:37.000000000 +0200
+++ linux-2.6.34-rc7/drivers/usb/serial/option.c	2010-05-10 21:00:59.000000000 +0200
@@ -302,6 +302,7 @@
 #define ZTE_PRODUCT_MF622			0x0001
 #define ZTE_PRODUCT_MF628			0x0015
 #define ZTE_PRODUCT_MF626			0x0031
+#define ZTE_PRODUCT_MF636			0x0037
 #define ZTE_PRODUCT_CDMA_TECH			0xfffe
 #define ZTE_PRODUCT_AC8710			0xfff1
 #define ZTE_PRODUCT_AC2726			0xfff5
@@ -378,6 +379,10 @@
 #define HAIER_VENDOR_ID				0x201e
 #define HAIER_PRODUCT_CE100			0x2009
 
+/* Olivetti products */
+#define OLIVETTI_VENDOR_ID				0x0b3c
+#define OLIVETTI_PRODUCT_OLICARD100			0xc000
+
 #define CINTERION_VENDOR_ID			0x0681
 
 /* some devices interfaces need special handling due to a number of reasons */
@@ -400,6 +405,13 @@
 	.reason = OPTION_BLACKLIST_SENDSETUP
 };
 
+static const u8 olivetti_olicard100_no_sendsetup[] = { 1, 3 };
+static const struct option_blacklist_info olivetti_olicard100_blacklist = {
+	.infolen = ARRAY_SIZE(olivetti_olicard100_no_sendsetup),
+	.ifaceinfo = olivetti_olicard100_no_sendsetup,
+	.reason = OPTION_BLACKLIST_SENDSETUP
+};
+
 static const struct usb_device_id option_ids[] = {
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_COLT) },
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_RICOLA) },
@@ -617,7 +629,7 @@
 	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MF626, 0xff, 0xff, 0xff) },
 	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0032, 0xff, 0xff, 0xff) },
 	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0033, 0xff, 0xff, 0xff) },
-	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0037, 0xff, 0xff, 0xff) },
+	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MF636, 0xff, 0xff, 0xff) },
 	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0039, 0xff, 0xff, 0xff) },
 	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0042, 0xff, 0xff, 0xff) },
 	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0043, 0xff, 0xff, 0xff) },
@@ -707,6 +719,9 @@
   	  .driver_info = (kernel_ulong_t)&four_g_w14_blacklist
   	},
 	{ USB_DEVICE(HAIER_VENDOR_ID, HAIER_PRODUCT_CE100) },
+	{ USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD100),
+  	  .driver_info = (kernel_ulong_t)&olivetti_olicard100_blacklist
+    },
 	/* Pirelli  */
 	{ USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_C100_1)},
 	{ USB_DEVICE(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_C100_2)},