Add the infamous Huawei E220 to option.c

Pete Zaitcev

author

2007-11-29 00:13 UTC #0 lore raw

Hi, All:

It looks like the Huawei E220 saga is not over yet. A collegue of mine, David Russll, reported that the modem does not work reliably on Fedora 8, which does have the initializer in usb-storage.

The problem stems from the fact that both option and usb-storage can bind to the modem when in storage mode: the former binds because of the storage class, the latter binds because of VID/PID match. The modprobe loads both, it's random which wins. If usb-storage wins, everything is fine. If option wins, it binds to modem still in storage mode and does not work.

I propose we add the same initializer that usb-storage has to the option. This way no matter which driver wins the modem gets initialized. The patch is tested on David's modem, but I would like someone give it more testing.

I dunno, do we want some kind of code sharing between storage and option? They both could use the normal usb_control_msg, I think.

Also, from archives it looks like Johann may need PID 0x1004 added.

Since we're on topic, David's modem has exactly same IDs as Norbert's, but works fine with the length of 1. Although it's possible that the firmware is different without different firmware reported in USB desc- riptors. Does anyone know a magic AT command? ATI or something? Norbert, please try my patch, maybe it'll work this time.

And finally, pleas stop using that script from the polish website and above all quit using the generic serial subdriver. The option must work now with the patch. Please let me know if it fails.

Thanks in advance,
-- Pete

drivers/usb/serial/option.c +32 -1

diff -urp -X dontdiff linux-2.6.23.1-42.fc8/drivers/usb/serial/option.c linux-2.6.23.1-42.fc8.e220.1/drivers/usb/serial/option.c
@@ -448,7 +448,7 @@ static void option_indat_callback(struct
 			err = usb_submit_urb(urb, GFP_ATOMIC);
 			if (err)
 				printk(KERN_ERR "%s: resubmit read urb failed. "
-					"(%d)", __FUNCTION__, err);
+					"(%d)\n", __FUNCTION__, err);
 		}
 	}
 	return;

@@ -728,6 +728,35 @@ static int option_send_setup(struct usb_
 	return 0;
 }
 
+static void option_start_huawei(struct usb_serial *serial)
+{
+	struct usb_device *dev = serial->dev;
+	char *buf;
+	int rc;
+
+	if (!(le16_to_cpu(dev->descriptor.idVendor) == HUAWEI_VENDOR_ID &&
+	    le16_to_cpu(dev->descriptor.idProduct) == HUAWEI_PRODUCT_E220))
+		return;
+
+	if ((buf = kmalloc(1, GFP_KERNEL)) == 0)
+		goto err_buf;
+
+	buf[0] = 0x1;
+	rc = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
+		USB_REQ_SET_FEATURE, USB_TYPE_STANDARD | USB_RECIP_DEVICE,
+		0x01, 0x0, buf, 1, 1000);
+	if (rc) {
+		printk(KERN_ERR "%s: HUAWEI E220 setup failed (%d)\n",
+		    __FUNCTION__, rc);
+	}
+
+	kfree(buf);
+	return;
+
+err_buf:
+	;
+}
+
 static int option_startup(struct usb_serial *serial)
 {
 	int i, err;

@@ -736,6 +765,8 @@ static int option_startup(struct usb_ser
 
 	dbg("%s", __FUNCTION__);
 
+	option_start_huawei(serial);
+
 	/* Now setup per port private data */
 	for (i = 0; i < serial->num_ports; i++) {
 		port = serial->port[i];

Johann Wilhelm

2007-11-29 07:40 UTC #1 lore raw

Hi there,

Well your code basically looks nice... but keep in mind that there are several different E220-devices (in fact i know of 2 different PIDs... and I would be really surprised if they only use 2 of them...). So you should check all possible PIDs...

But in my opinion the the modul-load-order should be forced by udev... this should work and we only have 1 position to keep in mind if we eg. get a new E220, support for the E270 or something else...

73

Zitat von Pete Zaitcev <[email protected]>:

Quoted 95 lines

Hi, All:
It looks like the Huawei E220 saga is not over yet. A collegue of mine, David Russll, reported that the modem does not work reliably on Fedora 8, which does have the initializer in usb-storage.
The problem stems from the fact that both option and usb-storage can bind to the modem when in storage mode: the former binds because of the storage class, the latter binds because of VID/PID match. The modprobe loads both, it's random which wins. If usb-storage wins, everything is fine. If option wins, it binds to modem still in storage mode and does not work.
I propose we add the same initializer that usb-storage has to the option. This way no matter which driver wins the modem gets initialized. The patch is tested on David's modem, but I would like someone give it more testing.
I dunno, do we want some kind of code sharing between storage and option? They both could use the normal usb_control_msg, I think.
Also, from archives it looks like Johann may need PID 0x1004 added.
Since we're on topic, David's modem has exactly same IDs as Norbert's, but works fine with the length of 1. Although it's possible that the firmware is different without different firmware reported in USB desc- riptors. Does anyone know a magic AT command? ATI or something? Norbert, please try my patch, maybe it'll work this time.
And finally, pleas stop using that script from the polish website and above all quit using the generic serial subdriver. The option must work now with the patch. Please let me know if it fails.
Thanks in advance,
-- Pete
diff -urp -X dontdiff linux-2.6.23.1-42.fc8/drivers/usb/serial/option.c linux-2.6.23.1-42.fc8.e220.1/drivers/usb/serial/option.c
--- linux-2.6.23.1-42.fc8/drivers/usb/serial/option.c 2007-10-09
13:31:38.000000000 -0700
+++
linux-2.6.23.1-42.fc8.e220.1/drivers/usb/serial/option.c 2007-11-27 21:36:11.000000000 -0800
drivers/usb/serial/option.c +32 -1
@@ -448,7 +448,7 @@ static void option_indat_callback(struct
 			err = usb_submit_urb(urb, GFP_ATOMIC);
 			if (err)
 				printk(KERN_ERR "%s: resubmit read urb failed. "
-					"(%d)", __FUNCTION__, err);
+					"(%d)\n", __FUNCTION__, err);
 		}
 	}
 	return;
@@ -728,6 +728,35 @@ static int option_send_setup(struct usb_
 	return 0;
 }
 
+static void option_start_huawei(struct usb_serial *serial)
+{
+	struct usb_device *dev = serial->dev;
+	char *buf;
+	int rc;
+
+	if (!(le16_to_cpu(dev->descriptor.idVendor) == HUAWEI_VENDOR_ID &&
+	    le16_to_cpu(dev->descriptor.idProduct) == HUAWEI_PRODUCT_E220))
+		return;
+
+	if ((buf = kmalloc(1, GFP_KERNEL)) == 0)
+		goto err_buf;
+
+	buf[0] = 0x1;
+	rc = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
+		USB_REQ_SET_FEATURE, USB_TYPE_STANDARD | USB_RECIP_DEVICE,
+		0x01, 0x0, buf, 1, 1000);
+	if (rc) {
+		printk(KERN_ERR "%s: HUAWEI E220 setup failed (%d)\n",
+		    __FUNCTION__, rc);
+	}
+
+	kfree(buf);
+	return;
+
+err_buf:
+	;
+}
+
 static int option_startup(struct usb_serial *serial)
 {
 	int i, err;
@@ -736,6 +765,8 @@ static int option_startup(struct usb_ser
 
 	dbg("%s", __FUNCTION__);
 
+	option_start_huawei(serial);
+
 	/* Now setup per port private data */
 	for (i = 0; i < serial->num_ports; i++) {
 		port = serial->port[i];

Oliver Neukum

2007-11-29 07:45 UTC #2 lore raw

Am Donnerstag, 29. November 2007 07:33:03 schrieb Johann Wilhelm:

Quoted 3 lines

But in my opinion the the modul-load-order should be forced by udev... this should work and we only have 1 position to keep in mind if we eg. get a new E220, support for the E270 or something else...

No, udev cannot help here because any of the two modules may already be loaded when you plug in your device. You also need to get the kernel space probing corrected. Basically you have three options.

1. Make both drivers handle the issue. That means code duplication
2. Make the option driver fail gracefully in probe()
3. Make sure usbcore doesn't probe the devices in the wrong mode with the option driver

Regards
Oliver

Pete Zaitcev

author

2007-11-29 08:02 UTC #3 lore raw

Quoted 2 lines · Oliver Neukum

3. Make sure usbcore doesn't probe the devices in the wrong mode with the option driver

This fixes duplication. And to take it further, why don't we turn this idea around and let usb-storage fail to attach with some "ignore" quirk? I suspect that someone put the initializer into usb-storage in order to let the generic usb serial to work, but this simply was a bad idea.

-- Pete

Oliver Neukum

2007-11-29 08:15 UTC #4 lore raw

Am Donnerstag, 29. November 2007 09:01:49 schrieb Pete Zaitcev:

Quoted 8 lines · Oliver Neukum

Quoted 2 lines
3. Make sure usbcore doesn't probe the devices in the wrong mode with the option driver
This fixes duplication. And to take it further, why don't we turn this idea around and let usb-storage fail to attach with some "ignore" quirk? I suspect that someone put the initializer into usb-storage in order to let the generic usb serial to work, but this simply was a bad idea.

Yes, you are right. That's the correct approach.

Regards
Oliver

Matthew Dharm

2007-11-29 09:10 UTC #5 lore raw

Quoted 11 lines · Oliver Neukum

Am Donnerstag, 29. November 2007 09:01:49 schrieb Pete Zaitcev:
Quoted 8 lines · Oliver Neukum
Quoted 2 lines
3. Make sure usbcore doesn't probe the devices in the wrong mode with the option driver
This fixes duplication. And to take it further, why don't we turn this idea around and let usb-storage fail to attach with some "ignore" quirk? I suspect that someone put the initializer into usb-storage in order to let the generic usb serial to work, but this simply was a bad idea.
Yes, you are right. That's the correct approach.

Changing the unusual_devs.h flag to IGNORE_DEVICE should accomplish what you want.

Matt

Signature · 7 lines

Matthew Dharm                              Home: [email protected] 
Maintainer, Linux USB Mass Storage Driver

C:  Like the Furby?
DP: He gives me the creeps.  Think the SPCA will take him?
					-- Cobb and Dust Puppy
User Friendly, 1/2/1999

Rui Santos

2007-11-29 10:21 UTC #6 lore raw

Quoted 14 lines · Matthew Dharm

Quoted 12 lines · Oliver Neukum
Am Donnerstag, 29. November 2007 09:01:49 schrieb Pete Zaitcev:
Quoted 10 lines · Oliver Neukum
Quoted 4 lines
3. Make sure usbcore doesn't probe the devices in the wrong mode with the option driver
This fixes duplication. And to take it further, why don't we turn this idea around and let usb-storage fail to attach with some "ignore" quirk? I suspect that someone put the initializer into usb-storage in order to let the generic usb serial to work, but this simply was a bad idea.

Quoted 6 lines

Quoted 2 lines
Yes, you are right. That's the correct approach.
Changing the unusual_devs.h flag to IGNORE_DEVICE should accomplish what you want.

If the IGNORE_DEVICE flag is set, access to the device's virtual-cd is no longer possible, and might not be the correct approach. Just as an example, one of my country's ISP has an ini file on it, with quite relevant information: Dial number, login, password and APN. Of course that, all of this information could be obtained with a simple phone call to that ISP.

Just to remember that that specific flag was one SET and, was removed, in part, because of what I state. Of course we aim at perfection but, if the benefits are only for a few situations and, will cause all this problems for all other, perhaps the reinsert of that flag would be a positive action.

Regards,
Rui Santos

Quoted 3 lines

Matt

Oliver Neukum

2007-11-29 10:50 UTC #7 lore raw

Am Donnerstag, 29. November 2007 11:01:34 schrieb Rui Santos:

Quoted 11 lines

Quoted 3 lines
Changing the unusual_devs.h flag to IGNORE_DEVICE should accomplish what you want.
If the IGNORE_DEVICE flag is set, access to the device's virtual-cd is no longer possible, and might not be the correct approach. Just as an example, one of my country's ISP has an ini file on it, with quite relevant information: Dial number, login, password and APN. Of course that, all of this information could be obtained with a simple phone call to that ISP.

Quoted 5 lines

Just to remember that that specific flag was one SET and, was removed, in part, because of what I state. Of course we aim at perfection but, if the benefits are only for a few situations and, will cause all this problems for all other, perhaps the reinsert of that flag would be a positive action.

OK, can you provide "lsusb -v" for the device in the CD mode and in the modem mode?

Regards
Oliver

Rui Santos

2007-11-29 11:07 UTC #8 lore raw

Quoted 20 lines · Oliver Neukum

Am Donnerstag, 29. November 2007 11:01:34 schrieb Rui Santos:
Quoted 11 lines
Quoted 4 lines
Changing the unusual_devs.h flag to IGNORE_DEVICE should accomplish what you want.
If the IGNORE_DEVICE flag is set, access to the device's virtual-cd is no longer possible, and might not be the correct approach. Just as an example, one of my country's ISP has an ini file on it, with quite relevant information: Dial number, login, password and APN. Of course that, all of this information could be obtained with a simple phone call to that ISP.
Quoted 6 lines
Just to remember that that specific flag was one SET and, was removed, in part, because of what I state. Of course we aim at perfection but, if the benefits are only for a few situations and, will cause all this problems for all other, perhaps the reinsert of that flag would be a positive action.

Quoted 3 lines

OK, can you provide "lsusb -v" for the device in the CD mode and in the modem mode?

Of course. Heri it is.

lsusb -v in "usb-storage only" mode:

Bus 005 Device 005: ID 12d1:1003
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10

  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x12d1
  idProduct          0x1003
  bcdDevice            0.00
  iManufacturer           1 HUAWEI Technologies
  iProduct                2 HUAWEI Mobile
  iSerial                 0
  bNumConfigurations      1

Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 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
Device Status: 0x0000
(Bus Powered)

lsusb -v in "modem + usb-storage" mode:

Bus 005 Device 011: ID 12d1:1003
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10

  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x12d1
  idProduct          0x1003
  bcdDevice            0.00
  iManufacturer           1 HUAWEI Technologies
  iProduct                2 HUAWEI Mobile
  iSerial                 0
  bNumConfigurations      1

Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 85
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 3 Data Interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 128
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 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 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
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 Data Interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 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 0x05 EP 5 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 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
Device Status: 0x0000
(Bus Powered)

If you ( on anyone ), need any other info or requires any testing on these devices, don't hesitate to ask.

Rui Santos

Oliver Neukum

2007-11-29 11:54 UTC #9 lore raw

Am Donnerstag 29 November 2007 schrieb Rui Santos:

Quoted 11 lines

Quoted 10 lines
Quoted 6 lines
Just to remember that that specific flag was one SET and, was removed, in part, because of what I state. Of course we aim at perfection but, if the benefits are only for a few situations and, will cause all this problems for all other, perhaps the reinsert of that flag would be a positive action.
OK, can you provide "lsusb -v" for the device in the CD mode and in the modem mode?
Of course. Heri it is.

Thanks. Please try this patch.

Regards
Oliver

----

drivers/usb/serial/option.c +1 -1

@@ -158,7 +158,7 @@ static struct usb_device_id option_ids[]
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_MODEM) },
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_NETWORK) },
 	{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E600) },
-	{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220) },
+	{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220, 0xff, 0xff, 0xff) },
 	{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220BIS) },
 	{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1100) }, /* Novatel Merlin XS620/S640 */
 	{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1110) }, /* Novatel Merlin S620 */

Johann Wilhelm

2007-11-29 14:07 UTC #10 lore raw

If everything's working please also add code to also support the other E220 device... so both PID 0x1003 and 0x1004 should be treaded the same way...

to test the device with the 0x1004-PID maybe Jaime Velasco <[email protected]> could be asked.. he initialy added the lines for this device in option.c

73

Zitat von Oliver Neukum <[email protected]>:

Quoted 36 lines

Am Donnerstag 29 November 2007 schrieb Rui Santos:
Quoted 11 lines
Quoted 10 lines
Quoted 6 lines
Just to remember that that specific flag was one SET and, was removed, in part, because of what I state. Of course we aim at perfection but, if the benefits are only for a few situations and, will cause all this problems for all other, perhaps the reinsert of that flag would be a positive action.
OK, can you provide "lsusb -v" for the device in the CD mode and in the modem mode?
Of course. Heri it is.
Thanks. Please try this patch.
Regards
Oliver
----
drivers/usb/serial/option.c +1 -1
@@ -158,7 +158,7 @@ static struct usb_device_id option_ids[]
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_MODEM) },
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_NETWORK) },
 	{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E600) },
-	{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220) },
+	{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID,  
 HUAWEI_PRODUCT_E220, 0xff, 0xff, 0xff) },
 	{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220BIS) },
 	{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1100) }, /* Novatel  
Merlin XS620/S640 */
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1110) }, /* Novatel
Merlin S620 */

Kristoffer Ericson

2007-11-29 14:36 UTC #11 lore raw

I'll give it a go later today, still on 2.6.22.4.

Any logs of interest except for obvious behavior?

Quoted 50 lines · On Thu, 29 Nov 2007 15:05:50 +0100 Johann Wilhelm…

If everything's working please also add code to also support the other E220 device... so both PID 0x1003 and 0x1004 should be treaded the same way...
to test the device with the 0x1004-PID maybe Jaime Velasco <[email protected]> could be asked.. he initialy added the lines for this device in option.c
73
Zitat von Oliver Neukum <[email protected]>:
Quoted 36 lines
Am Donnerstag 29 November 2007 schrieb Rui Santos:
Quoted 11 lines
Quoted 10 lines
Quoted 6 lines
Just to remember that that specific flag was one SET and, was removed, in part, because of what I state. Of course we aim at perfection but, if the benefits are only for a few situations and, will cause all this problems for all other, perhaps the reinsert of that flag would be a positive action.
OK, can you provide "lsusb -v" for the device in the CD mode and in the modem mode?
Of course. Heri it is.
Thanks. Please try this patch.
Regards
Oliver
----
drivers/usb/serial/option.c +1 -1
@@ -158,7 +158,7 @@ static struct usb_device_id option_ids[]
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_MODEM) },
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_NETWORK) },
 	{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E600) },
-	{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220) },
+	{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID,  
 HUAWEI_PRODUCT_E220, 0xff, 0xff, 0xff) },
 	{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220BIS) },
 	{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1100) }, /* Novatel  
Merlin XS620/S640 */
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1110) }, /* Novatel
Merlin S620 */

Oliver Neukum

2007-11-29 14:40 UTC #12 lore raw

Am Donnerstag 29 November 2007 schrieb Kristoffer Ericson:

Quoted 3 lines

I'll give it a go later today, still on 2.6.22.4.
Any logs of interest except for obvious behavior?

dmesg

Regards
Oliver

Jaime Velasco Juan

2007-11-29 18:52 UTC #13 lore raw

In reply to Johann Wilhelm

Hi,

Quoted 7 lines · Johann Wilhelm

If everything's working please also add code to also support the other E220 device... so both PID 0x1003 and 0x1004 should be treaded the same way...
to test the device with the 0x1004-PID maybe Jaime Velasco <[email protected]> could be asked.. he initialy added the lines for this device in option.c

The following patch works for me (on kernel 2.6.23).

drivers/usb/serial/option.c +2 -2

index a18659e..352c94c 100644
@@ -158,8 +158,8 @@ static struct usb_device_id option_ids[] = {
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_MODEM) },
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_NETWORK) },
 	{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E600) },
-	{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220) },
-	{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220BIS) },
+	{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220, 0xff, 0xff, 0xff) },
+	{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220BIS, 0xff, 0xff, 0xff) },
 	{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1100) }, /* Novatel Merlin XS620/S640 */
 	{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1110) }, /* Novatel Merlin S620 */
 	{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1120) }, /* Novatel Merlin EX720 */

Quoted 41 lines

73
Zitat von Oliver Neukum <[email protected]>:
Quoted 36 lines
Am Donnerstag 29 November 2007 schrieb Rui Santos:
Quoted 11 lines
Quoted 10 lines
Quoted 6 lines
Just to remember that that specific flag was one SET and, was removed, in part, because of what I state. Of course we aim at perfection but, if the benefits are only for a few situations and, will cause all this problems for all other, perhaps the reinsert of that flag would be a positive action.
OK, can you provide "lsusb -v" for the device in the CD mode and in the modem mode?
Of course. Heri it is.
Thanks. Please try this patch.
Regards
Oliver
----
drivers/usb/serial/option.c +1 -1
@@ -158,7 +158,7 @@ static struct usb_device_id option_ids[]
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_MODEM) },
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_NETWORK) },
 	{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E600) },
-	{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220) },
+	{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220, 
 0xff, 0xff, 0xff) },
 	{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220BIS) },
 	{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1100) }, /* Novatel Merlin 
XS620/S640 */
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1110) }, /* Novatel Merlin
S620 */

Oliver Neukum

2007-11-29 23:23 UTC #14 lore raw

Am Donnerstag, 29. November 2007 19:53:39 schrieb Jaime Velasco Juan:

Quoted 7 lines

Hi,
Quoted 4 lines · Johann Wilhelm
If everything's working please also add code to also support the other E220 device... so both PID 0x1003 and 0x1004 should be treaded the same way...

Quoted 5 lines

Quoted 3 lines
to test the device with the 0x1004-PID maybe Jaime Velasco <[email protected]> could be asked.. he initialy added the lines for this device in option.c
The following patch works for me (on kernel 2.6.23).

Jaime, please add your signed off by line and resend the patch with both lines to Greg.

Signed-off-by Oliver Neukum <[email protected]>

Regards
Oliver

Jaime Velasco Juan

2007-11-30 16:28 UTC #15 lore raw

PATCH 1/1 USB: option: Bind to the correct interface of the Huawei E220

Signed-off-by Oliver Neukum <[email protected]>

Signed-off-by Jaime Velasco Juan <[email protected]>

---

drivers/usb/serial/option.c +2 -2

index a18659e..352c94c 100644
@@ -158,8 +158,8 @@ static struct usb_device_id option_ids[] = {
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_MODEM) },
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_NETWORK) },
 	{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E600) },
-	{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220) },
-	{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220BIS) },
+	{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220, 0xff, 0xff, 0xff) },
+	{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220BIS, 0xff, 0xff, 0xff) },
 	{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1100) }, /* Novatel Merlin XS620/S640 */
 	{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1110) }, /* Novatel Merlin S620 */
 	{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1120) }, /* Novatel Merlin EX720 */

Norbert Preining

2007-12-01 08:08 UTC #16 lore raw

Re: [PATCH] USB: option: Bind to the correct interface of the Huawei E220

Hi all,

is this the only addition that should be needed, ortogether with the changes in option to call the huawei init function?

I tried 2.6.24-rc3 with this patch only and it I again got the infinite loop of connect/disconnect events instantiating cdroms.

Best wishes

Norbert

-------------------------------------------------------------------------------
Dr. Norbert Preining <[email protected]> Vienna University of Technology
Debian Developer <[email protected]> Debian TeX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
Maybe somebody here tipped off the Galactic Police,' said Trillian. Everybody saw you come in.'
You mean they want to arrest me over the phone?' said Zaphod, Could be. I'm a pretty dangerous dude when I'm cornered.'
Yeah,' said a voice from under the table [Ford's now completely rat- arsed at this point], you go to pieces so fast people get hit by the shrapnel.'
--- Zaphod getting paranoid over a phone call. --- Douglas Adams, The Hitchhikers Guide to the Galaxy

Pete Zaitcev

author

2007-12-01 08:35 UTC #17 lore raw

Re: [PATCH] USB: option: Bind to the correct interface of the Huawei E220

Quoted 2 lines · Norbert Preining

is this the only addition that should be needed, ortogether with the changes in option to call the huawei init function?

The only one.

Quoted 2 lines

I tried 2.6.24-rc3 with this patch only and it I again got the infinite loop of connect/disconnect events instantiating cdroms.

Your problem is something else. Neither my patch nor Jaime's patch address it. Honestly, I'm not even sure how to tackle it. I seem to recall that I had a usbmon trace from you but I'm unable to find it now. Gettin it (again?) probably would be a good place to restart that investigation.

-- Pete

Norbert Preining

2007-12-01 10:04 UTC #18 lore raw

Re: [PATCH] USB: option: Bind to the correct interface of the Huawei E220

Quoted 4 lines · Pete Zaitcev

Quoted 2 lines
is this the only addition that should be needed, ortogether with the changes in option to call the huawei init function?
The only one.

Ok.

Quoted 2 lines

Your problem is something else. Neither my patch nor Jaime's patch address it. Honestly, I'm not even sure how to tackle it. I seem to

Ah, ok.

Quoted 3 lines

recall that I had a usbmon trace from you but I'm unable to find it now. Gettin it (again?) probably would be a good place to restart that investigation.

I am not sure that I used usbmon ...,I can't recall it, but I know what the problem is, I need this patch:

usb/storage/initializers.c renamed from usb/storage/initializers.c.orig +1 -1

@@ -100,7 +100,7 @@
 	result = usb_stor_control_msg(us, us->send_ctrl_pipe,
 				      USB_REQ_SET_FEATURE,
 				      USB_TYPE_STANDARD | USB_RECIP_DEVICE,
-				      0x01, 0x0, us->iobuf, 0x1, 1000);
+				      0x01, 0x0, us->iobuf, 0, 1000);
 	US_DEBUGP("usb_control_msg performing result is %d\n", result);
 	return (result ? 0 : -1);
 }

With this everything works really smoothly. Even better, now I do get only 2 (instead of prior 3) /dev/ttyUSB devices (that caused some problems with umtsmon).

Best wishes

Norbert

-------------------------------------------------------------------------------
Dr. Norbert Preining <[email protected]> Vienna University of Technology
Debian Developer <[email protected]> Debian TeX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
POLBATHIC (adj.)
Gifted with ability to manipulate taps using only the feet.
--- Douglas Adams, The Meaning of Liff

Borislav Petkov

2007-12-01 18:37 UTC #19 lore raw

Re: [PATCH] USB: option: Bind to the correct interface of the Huawei E220

In reply to Jaime Velasco Juan

Quoted 11 lines · Jaime Velasco Juan

Signed-off-by Oliver Neukum <[email protected]>
Signed-off-by Jaime Velasco Juan <[email protected]>
---
drivers/usb/serial/option.c +0 -0
index a18659e..352c94c 100644
@@ -158,8 +158,8 @@ static struct usb_device_id option_ids[] = {
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_MODEM) },

drivers/usb/serial/option.c static struct usb_device_id option_ids[] = {

Quoted 10 lines

drivers/usb/serial/option.c +2 -3

 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_NETWORK) },
 	{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E600) },
-	{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220) },
-	{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220BIS) },
+	{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220, 0xff, 0xff, 0xff) },
+	{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220BIS, 0xff, 0xff, 0xff) },
 	{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1100) }, /* Novatel Merlin XS620/S640 */
 	{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1110) }, /* Novatel Merlin S620 */
 	{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1120) }, /* Novatel Merlin EX720 */
-

yep, this one fixes the same problem here. Here's lsusb -v of my huawei modem:

Bus 001 Device 007: ID 12d1:1003
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10

  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x12d1 
  idProduct          0x1003 
  bcdDevice            0.00
  iManufacturer           1 HUAWEI Technologies
  iProduct                2 HUAWEI Mobile
  iSerial                 0 
  bNumConfigurations      1

Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 85
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 3 Data Interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 128
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 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 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
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 Data Interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 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 0x05 EP 5 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 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
Device Status: 0x0000
(Bus Powered)

Signature · 2 lines

Regards/Gruß,
    Boris.

Pete Zaitcev

author

2007-12-05 16:34 UTC #20 lore raw

Re: [PATCH] USB: option: Bind to the correct interface of the Huawei E220

In reply to Jaime Velasco Juan

drivers/usb/serial/option.c static struct usb_device_id option_ids[] = { · line 162

Quoted 6 lines · Jaime Velasco Juan

drivers/usb/serial/option.c +2 -2

-	{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220) },
-	{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220BIS) },
+	{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220, 0xff, 0xff, 0xff) },
+	{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220BIS, 0xff, 0xff, 0xff) },

Looks good to me, shorter than my patch, has no duplication, allows to use the storage, looks like a winner. Unfortunately, it leaves ub for dead, because ub cannot invoke the necessary initializer unless we move it to libusual. But oh well, I'll think about it.

Took me this long to test because I had to ask kind people in England to replug the modem.

Signed-off-by Pete Zaitcev <[email protected]>

-- Pete

Oliver Neukum

2007-12-05 18:23 UTC #21 lore raw

Re: [PATCH] USB: option: Bind to the correct interface of the Huawei E220

Am Mittwoch, 5. Dezember 2007 17:34:23 schrieb Pete Zaitcev:

Quoted 2 lines

Looks good to me, shorter than my patch, has no duplication, allows to use the storage, looks like a winner. Unfortunately, it leaves ub for dead,

Is that new? How could ub do this up to now?

Regards
Oliver

Pete Zaitcev

author

2007-12-05 19:15 UTC #22 lore raw

Re: [PATCH] USB: option: Bind to the correct interface of the Huawei E220

Quoted 6 lines · Oliver Neukum

Am Mittwoch, 5. Dezember 2007 17:34:23 schrieb Pete Zaitcev:
Quoted 2 lines
Looks good to me, shorter than my patch, has no duplication, allows to use the storage, looks like a winner. Unfortunately, it leaves ub for dead,
Is that new? How could ub do this up to now?

No, it's not a regression. A user-mode initializer was always required to use E220 with ub. So, the patch is good.

-- Pete

Rui Santos

2007-11-29 19:13 UTC #23 lore raw

In reply to Oliver Neukum

Quoted 27 lines · Oliver Neukum

Am Donnerstag 29 November 2007 schrieb Rui Santos:
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Just to remember that that specific flag was one SET and, was removed, in part, because of what I state. Of course we aim at perfection but, if the benefits are only for a few situations and, will cause all this problems for all other, perhaps the reinsert of that flag would be a positive action.
Quoted 6 lines
Quoted 4 lines
OK, can you provide "lsusb -v" for the device in the CD mode and in the modem mode?
Of course. Heri it is.
Thanks. Please try this patch.
Regards
Oliver
----

drivers/usb/serial/option.c static struct usb_device_id option_ids[] · line 164

Quoted 8 lines

drivers/usb/serial/option.c +1 -1

@@ -158,7 +158,7 @@ static struct usb_device_id option_ids[]
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_MODEM) },
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_ETNA_KOI_NETWORK) },
 	{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E600) },
-	{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220) },
+	{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220, 0xff, 0xff, 0xff) },
 	{ USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E220BIS) },
 	{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1100) }, /* Novatel Merlin XS620/S640 */
 	{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x1110) }, /* Novatel Merlin S620 */

This patch worked for me on linux-2.6.24-rc3-git4. There are a few errors but, it seems to be working as it should. Here is the dmesg output:

usb 4-1: new full speed USB device using uhci_hcd and address 9 usb 4-1: configuration #1 chosen from 1 choice
scsi13 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 9
usb-storage: waiting for device to settle before scanning usb 4-1: USB disconnect, address 9
usb 4-1: new full speed USB device using uhci_hcd and address 10 usb 4-1: configuration #1 chosen from 1 choice
usb-storage: probe of 4-1:1.0 failed with error -5
option 4-1:1.0: GSM modem (1-port) converter detected
usb 4-1: GSM modem (1-port) converter now attached to ttyUSB0
usb-storage: probe of 4-1:1.1 failed with error -5
option 4-1:1.1: GSM modem (1-port) converter detected
usb 4-1: GSM modem (1-port) converter now attached to ttyUSB1 scsi16 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 10
usb-storage: waiting for device to settle before scanning
scsi 16:0:0:0: CD-ROM HUAWEI Mass Storage 2.31 PQ: 0
ANSI: 2
sr0: scsi-1 drive
sr 16:0:0:0: Attached scsi CD-ROM sr0
sr 16:0:0:0: Attached scsi generic sg2 type 5
usb-storage: device scan complete
sr0: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00 20 00
sr: Sense Key : No Sense [current]
sr: Add. Sense: No additional sense information

Rui Santos

Greg KH

2007-11-29 17:10 UTC #24 lore raw

In reply to Pete Zaitcev

Quoted 9 lines · Pete Zaitcev

Quoted 2 lines · Oliver Neukum
3. Make sure usbcore doesn't probe the devices in the wrong mode with the option driver
This fixes duplication. And to take it further, why don't we turn this idea around and let usb-storage fail to attach with some "ignore" quirk? I suspect that someone put the initializer into usb-storage in order to let the generic usb serial to work, but this simply was a bad idea.

Yes, I think that is what happened :(

I'll gladly take patches to fix this all up, I have a number of bug reports for the suse releases with this same problem you are seeing.

thanks,

greg k-h

Oliver Neukum

2007-11-29 07:41 UTC #25 lore raw

In reply to Pete Zaitcev

Am Donnerstag, 29. November 2007 01:13:05 schrieb Pete Zaitcev:

Quoted 3 lines

The problem stems from the fact that both option and usb-storage can bind to the modem when in storage mode: the former binds because of the storage class, the latter binds because of VID/PID match. The modprobe loads both,

Isn't it possible to fix this in option's module table?

Regards
Oliver

Pete Zaitcev

author

2007-11-29 07:53 UTC #26 lore raw

Quoted 6 lines · Oliver Neukum

Am Donnerstag, 29. November 2007 01:13:05 schrieb Pete Zaitcev:
Quoted 3 lines
The problem stems from the fact that both option and usb-storage can bind to the modem when in storage mode: the former binds because of the storage class, the latter binds because of VID/PID match. The modprobe loads both,
Isn't it possible to fix this in option's module table?

At first thought it'll need adding a field to struct usb_serial to save the driver_info from the ID table in usb_serial_probe. It's something I'd like to discuss actually. I hate fields which store information this
way: filled in one place, used in another place... From the perspective of code prettiness I would rather add another method for usb_serial_probe to call. But I'm not sure really.

-- Pete

Oliver Neukum

2007-11-29 08:05 UTC #27 lore raw

Am Donnerstag, 29. November 2007 08:52:37 schrieb Pete Zaitcev:

Quoted 11 lines · Oliver Neukum

Quoted 7 lines
Am Donnerstag, 29. November 2007 01:13:05 schrieb Pete Zaitcev:
Quoted 4 lines
The problem stems from the fact that both option and usb-storage can bind to the modem when in storage mode: the former binds because of the storage class, the latter binds because of VID/PID match. The modprobe loads both,
Isn't it possible to fix this in option's module table?
At first thought it'll need adding a field to struct usb_serial to save the driver_info from the ID table in usb_serial_probe. It's something I'd

Why? It is passed to the subdrivers in their probe(). Maybe it should simply be passed in attach(), too?

Quoted 4 lines

like to discuss actually. I hate fields which store information this
way: filled in one place, used in another place... From the perspective of code prettiness I would rather add another method for usb_serial_probe to call. But I'm not sure really.

Does the device remain a storage class device after the crucial control message?

Regards
Oliver

Pete Zaitcev

author

2007-11-29 08:11 UTC #28 lore raw

Quoted 7 lines · Oliver Neukum

Quoted 4 lines
Quoted 1 line
Isn't it possible to fix this in option's module table?
At first thought it'll need adding a field to struct usb_serial to save the driver_info from the ID table in usb_serial_probe. It's something I'd
Why? It is passed to the subdrivers in their probe(). Maybe it should simply be passed in attach(), too?

My bad, you're right. I'm just mentally dead now.

-- Pete

Norbert Preining

2007-11-29 14:15 UTC #29 lore raw

In reply to Pete Zaitcev

Hi Pete, hi all,

Quoted 3 lines · Pete Zaitcev

It looks like the Huawei E220 saga is not over yet. A collegue of mine, David Russll, reported that the modem does not work reliably on Fedora 8, which does have the initializer in usb-storage.

That is what I said.

Quoted 2 lines

it's random which wins. If usb-storage wins, everything is fine. If option wins, it binds to modem still in storage mode and does not work.

That could be the source of my disconnect/reconnect cycles.

Quoted 7 lines

This way no matter which driver wins the modem gets initialized. The patch is tested on David's modem, but I would like someone give it more testing.
I dunno, do we want some kind of code sharing between storage and option? They both could use the normal usb_control_msg, I think.

Quoted 7 lines

Also, from archives it looks like Johann may need PID 0x1004 added.
Since we're on topic, David's modem has exactly same IDs as Norbert's, but works fine with the length of 1. Although it's possible that the firmware is different without different firmware reported in USB desc- riptors. Does anyone know a magic AT command? ATI or something? Norbert, please try my patch, maybe it'll work this time.

I tried your patch with the reverted 0x1 -> 0 change. But it didn't work. I get connects/reconnects.

So to be clear: kernl 2.6.24-rc3 + your patch gives me permanent cycles and an error:
option_start_huawei: HUAWEI E220 setup failed (1)
I attach the syslog part which exhibits the behaviour.

Quoted 1 line

And finally, pleas stop using that script from the polish website and

Did it already, but without the 0x1->0 change it does not work here.

Quoted 1 line

above all quit using the generic serial subdriver. The option must

Long done, I assume that the option module depending on usbserial is not the problem.

Quoted 1 line

work now with the patch. Please let me know if it fails.

It does.

Best wishes

Norbert

-------------------------------------------------------------------------------
Dr. Norbert Preining <[email protected]> Vienna University of Technology
Debian Developer <[email protected]> Debian TeX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
MUNDERFIELD (n.) A meadow selected, whilst driving past, as being ideal for a picnic which, from a sitting position, turns out to be full of stubble, dust and cowpats, and almost impossible to enjoy yourself in.
--- Douglas Adams, The Meaning of Liff

Norbert Preining

2007-11-29 14:16 UTC #30 lore raw

Quoted 4 lines · preining

So to be clear: kernl 2.6.24-rc3 + your patch gives me permanent cycles and an error:
option_start_huawei: HUAWEI E220 setup failed (1)
I attach the syslog part which exhibits the behaviour.

Now really attached.

Best wishes

Norbert

-------------------------------------------------------------------------------
Dr. Norbert Preining <[email protected]> Vienna University of Technology
Debian Developer <[email protected]> Debian TeX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
YONDER BOGINE (n.)
The kind of restaurant advertised as 'just three minutes from this cinema' which clearly nobody ever goes to and, even if they had ever contemplated it, have certainly changed their mind since seeing the advert.
--- Douglas Adams, The Meaning of Liff

usb 2-2: new full speed USB device using uhci_hcd and address 2
PM: Adding info for usb:2-2
PM: Adding info for No Bus:usbdev2.2_ep00
usb 2-2: configuration #1 chosen from 1 choice
PM: Adding info for usb:2-2:1.0
PM: Adding info for No Bus:usbdev2.2_ep83
PM: Adding info for No Bus:usbdev2.2_ep04
PM: Adding info for No Bus:usbdev2.2
Initializing USB Mass Storage driver...
scsi2 : SCSI emulation for USB Mass Storage devices
PM: Adding info for No Bus:host2
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
usbcore: registered new interface driver usbserial drivers/usb/serial/usb-serial.c: USB Serial support registered for generic
usbcore: registered new interface driver usbserial_generic drivers/usb/serial/usb-serial.c: USB Serial Driver core drivers/usb/serial/usb-serial.c: USB Serial support registered for GSM modem (1-port)
usbcore: registered new interface driver option drivers/usb/serial/option.c: USB Driver for GSM modems: v0.7.1
usb 2-2: USB disconnect, address 2
PM: Removing info for No Bus:usbdev2.2_ep83
PM: Removing info for No Bus:usbdev2.2_ep04
PM: Removing info for No Bus:host2
PM: Removing info for usb:2-2:1.0
PM: Removing info for No Bus:usbdev2.2
PM: Removing info for No Bus:usbdev2.2_ep00
PM: Removing info for usb:2-2
usb 2-2: new full speed USB device using uhci_hcd and address 3
PM: Adding info for usb:2-2
PM: Adding info for No Bus:usbdev2.3_ep00
usb 2-2: configuration #1 chosen from 1 choice
PM: Adding info for usb:2-2:1.0
usb-storage: probe of 2-2:1.0 failed with error -5
option 2-2:1.0: GSM modem (1-port) converter detected
option_start_huawei: HUAWEI E220 setup failed (1)
PM: Adding info for usb-serial:ttyUSB0
PM: Adding info for No Bus:ttyUSB0
usb 2-2: GSM modem (1-port) converter now attached to ttyUSB0
PM: Adding info for No Bus:usbdev2.3_ep81
PM: Adding info for No Bus:usbdev2.3_ep82
PM: Adding info for No Bus:usbdev2.3_ep02
PM: Adding info for usb:2-2:1.1
usb-storage: probe of 2-2:1.1 failed with error -5
option 2-2:1.1: GSM modem (1-port) converter detected
option_start_huawei: HUAWEI E220 setup failed (1)
PM: Adding info for usb-serial:ttyUSB1
PM: Adding info for No Bus:ttyUSB1
usb 2-2: GSM modem (1-port) converter now attached to ttyUSB1
PM: Adding info for No Bus:usbdev2.3_ep85
PM: Adding info for No Bus:usbdev2.3_ep05
PM: Adding info for usb:2-2:1.2
scsi5 : SCSI emulation for USB Mass Storage devices
PM: Adding info for No Bus:host5
PM: Adding info for No Bus:usbdev2.3_ep83
PM: Adding info for No Bus:usbdev2.3_ep04
PM: Adding info for No Bus:usbdev2.3
usb-storage: device found at 3
usb-storage: waiting for device to settle before scanning
PM: Adding info for No Bus:target5:0:0
scsi 5:0:0:0: CD-ROM HUAWEI Mass Storage 2.31 PQ: 0 ANSI: 2
PM: Adding info for scsi:5:0:0:0
PM: Adding info for No Bus:target5:0:1
PM: Removing info for No Bus:target5:0:1
PM: Adding info for No Bus:target5:0:2
PM: Removing info for No Bus:target5:0:2
PM: Adding info for No Bus:target5:0:3
PM: Removing info for No Bus:target5:0:3
PM: Adding info for No Bus:target5:0:4
PM: Removing info for No Bus:target5:0:4
PM: Adding info for No Bus:target5:0:5
PM: Removing info for No Bus:target5:0:5
PM: Adding info for No Bus:target5:0:6
PM: Removing info for No Bus:target5:0:6
PM: Adding info for No Bus:target5:0:7
PM: Removing info for No Bus:target5:0:7
usb-storage: device scan complete
sr0: scsi-1 drive
Uniform CD-ROM driver Revision: 3.20
sr 5:0:0:0: Attached scsi CD-ROM sr0
sd 0:0:0:0: Attached scsi generic sg0 type 0
sr 5:0:0:0: Attached scsi generic sg1 type 5
usb 2-2: reset full speed USB device using uhci_hcd and address 3
usb 2-2: reset full speed USB device using uhci_hcd and address 3
usb 2-2: device descriptor read/64, error -71
usb 2-2: USB disconnect, address 3
PM: Removing info for No Bus:usbdev2.3_ep81
PM: Removing info for No Bus:usbdev2.3_ep82
PM: Removing info for No Bus:usbdev2.3_ep02
PM: Removing info for No Bus:ttyUSB0
option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0
PM: Removing info for usb-serial:ttyUSB0
option 2-2:1.0: device disconnected
PM: Removing info for usb:2-2:1.0
PM: Removing info for No Bus:usbdev2.3_ep85
PM: Removing info for No Bus:usbdev2.3_ep05
PM: Removing info for No Bus:ttyUSB1
option1 ttyUSB1: GSM modem (1-port) converter now disconnected from ttyUSB1
PM: Removing info for usb-serial:ttyUSB1
option 2-2:1.1: device disconnected
PM: Removing info for usb:2-2:1.1
PM: Removing info for No Bus:usbdev2.3_ep83
PM: Removing info for No Bus:usbdev2.3_ep04
PM: Removing info for scsi:5:0:0:0
PM: Removing info for No Bus:host5
PM: Removing info for usb:2-2:1.2
PM: Removing info for No Bus:usbdev2.3
PM: Removing info for No Bus:usbdev2.3_ep00
PM: Removing info for usb:2-2
PM: Removing info for No Bus:target5:0:0
usb 2-2: new full speed USB device using uhci_hcd and address 4
PM: Adding info for usb:2-2
PM: Adding info for No Bus:usbdev2.4_ep00
usb 2-2: configuration #1 chosen from 1 choice
PM: Adding info for usb:2-2:1.0
usb-storage: probe of 2-2:1.0 failed with error -5
option 2-2:1.0: GSM modem (1-port) converter detected
option_start_huawei: HUAWEI E220 setup failed (1)
PM: Adding info for usb-serial:ttyUSB0
PM: Adding info for No Bus:ttyUSB0
usb 2-2: GSM modem (1-port) converter now attached to ttyUSB0
PM: Adding info for No Bus:usbdev2.4_ep81
PM: Adding info for No Bus:usbdev2.4_ep82
PM: Adding info for No Bus:usbdev2.4_ep02
PM: Adding info for usb:2-2:1.1
usb-storage: probe of 2-2:1.1 failed with error -5
option 2-2:1.1: GSM modem (1-port) converter detected
option_start_huawei: HUAWEI E220 setup failed (1)
PM: Adding info for usb-serial:ttyUSB1
PM: Adding info for No Bus:ttyUSB1
usb 2-2: GSM modem (1-port) converter now attached to ttyUSB1
PM: Adding info for No Bus:usbdev2.4_ep85
PM: Adding info for No Bus:usbdev2.4_ep05
PM: Adding info for usb:2-2:1.2
scsi8 : SCSI emulation for USB Mass Storage devices
PM: Adding info for No Bus:host8
PM: Adding info for No Bus:usbdev2.4_ep83
PM: Adding info for No Bus:usbdev2.4_ep04
PM: Adding info for No Bus:usbdev2.4
usb-storage: device found at 4
usb-storage: waiting for device to settle before scanning
PM: Adding info for No Bus:target8:0:0
usb 2-2: reset full speed USB device using uhci_hcd and address 4
scsi 8:0:0:0: CD-ROM HUAWEI Mass Storage 2.31 PQ: 0 ANSI: 2
PM: Adding info for scsi:8:0:0:0
sr0: scsi-1 drive
sr 8:0:0:0: Attached scsi CD-ROM sr0
sr 8:0:0:0: Attached scsi generic sg1 type 5
PM: Adding info for No Bus:target8:0:1
PM: Removing info for No Bus:target8:0:1
PM: Adding info for No Bus:target8:0:2
PM: Removing info for No Bus:target8:0:2
PM: Adding info for No Bus:target8:0:3
PM: Removing info for No Bus:target8:0:3
PM: Adding info for No Bus:target8:0:4
PM: Removing info for No Bus:target8:0:4
PM: Adding info for No Bus:target8:0:5
PM: Removing info for No Bus:target8:0:5
PM: Adding info for No Bus:target8:0:6
PM: Removing info for No Bus:target8:0:6
PM: Adding info for No Bus:target8:0:7
PM: Removing info for No Bus:target8:0:7
usb-storage: device scan complete
usb 2-2: reset full speed USB device using uhci_hcd and address 4
usb 2-2: reset full speed USB device using uhci_hcd and address 4
usb 2-2: USB disconnect, address 4
PM: Removing info for No Bus:usbdev2.4_ep81
PM: Removing info for No Bus:usbdev2.4_ep82
PM: Removing info for No Bus:usbdev2.4_ep02
PM: Removing info for No Bus:ttyUSB0
option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0
PM: Removing info for usb-serial:ttyUSB0
option 2-2:1.0: device disconnected
PM: Removing info for usb:2-2:1.0
PM: Removing info for No Bus:usbdev2.4_ep85
PM: Removing info for No Bus:usbdev2.4_ep05
PM: Removing info for No Bus:ttyUSB1
option1 ttyUSB1: GSM modem (1-port) converter now disconnected from ttyUSB1
PM: Removing info for usb-serial:ttyUSB1
option 2-2:1.1: device disconnected
PM: Removing info for usb:2-2:1.1
PM: Removing info for No Bus:usbdev2.4_ep83
PM: Removing info for No Bus:usbdev2.4_ep04
PM: Removing info for scsi:8:0:0:0
PM: Removing info for No Bus:host8
PM: Removing info for usb:2-2:1.2
PM: Removing info for No Bus:usbdev2.4
PM: Removing info for No Bus:usbdev2.4_ep00
PM: Removing info for usb:2-2
PM: Removing info for No Bus:target8:0:0
usb 2-2: new full speed USB device using uhci_hcd and address 5
PM: Adding info for usb:2-2
PM: Adding info for No Bus:usbdev2.5_ep00
usb 2-2: configuration #1 chosen from 1 choice
PM: Adding info for usb:2-2:1.0
usb-storage: probe of 2-2:1.0 failed with error -5
option 2-2:1.0: GSM modem (1-port) converter detected
option_start_huawei: HUAWEI E220 setup failed (1)
PM: Adding info for usb-serial:ttyUSB0
PM: Adding info for No Bus:ttyUSB0
usb 2-2: GSM modem (1-port) converter now attached to ttyUSB0
PM: Adding info for No Bus:usbdev2.5_ep81
PM: Adding info for No Bus:usbdev2.5_ep82
PM: Adding info for No Bus:usbdev2.5_ep02
PM: Adding info for usb:2-2:1.1
usb-storage: probe of 2-2:1.1 failed with error -5
option 2-2:1.1: GSM modem (1-port) converter detected
option_start_huawei: HUAWEI E220 setup failed (1)
PM: Adding info for usb-serial:ttyUSB1
PM: Adding info for No Bus:ttyUSB1
usb 2-2: GSM modem (1-port) converter now attached to ttyUSB1
PM: Adding info for No Bus:usbdev2.5_ep85
PM: Adding info for No Bus:usbdev2.5_ep05
PM: Adding info for usb:2-2:1.2
scsi11 : SCSI emulation for USB Mass Storage devices
PM: Adding info for No Bus:host11
PM: Adding info for No Bus:usbdev2.5_ep83
PM: Adding info for No Bus:usbdev2.5_ep04
PM: Adding info for No Bus:usbdev2.5
usb-storage: device found at 5
usb-storage: waiting for device to settle before scanning
PM: Adding info for No Bus:target11:0:0
usb 2-2: reset full speed USB device using uhci_hcd and address 5
scsi 11:0:0:0: CD-ROM HUAWEI Mass Storage 2.31 PQ: 0 ANSI: 2
PM: Adding info for scsi:11:0:0:0
sr0: scsi-1 drive
sr 11:0:0:0: Attached scsi CD-ROM sr0
sr 11:0:0:0: Attached scsi generic sg1 type 5
PM: Adding info for No Bus:target11:0:1
PM: Removing info for No Bus:target11:0:1
PM: Adding info for No Bus:target11:0:2
PM: Removing info for No Bus:target11:0:2
PM: Adding info for No Bus:target11:0:3
PM: Removing info for No Bus:target11:0:3
PM: Adding info for No Bus:target11:0:4
PM: Removing info for No Bus:target11:0:4
PM: Adding info for No Bus:target11:0:5
PM: Removing info for No Bus:target11:0:5
PM: Adding info for No Bus:target11:0:6
PM: Removing info for No Bus:target11:0:6
PM: Adding info for No Bus:target11:0:7
PM: Removing info for No Bus:target11:0:7
usb-storage: device scan complete
usb 2-2: USB disconnect, address 5
PM: Removing info for No Bus:usbdev2.5_ep81
PM: Removing info for No Bus:usbdev2.5_ep82
PM: Removing info for No Bus:usbdev2.5_ep02
PM: Removing info for No Bus:ttyUSB0
option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0
PM: Removing info for usb-serial:ttyUSB0
option 2-2:1.0: device disconnected
PM: Removing info for usb:2-2:1.0
PM: Removing info for No Bus:usbdev2.5_ep85
PM: Removing info for No Bus:usbdev2.5_ep05
PM: Removing info for No Bus:ttyUSB1
option1 ttyUSB1: GSM modem (1-port) converter now disconnected from ttyUSB1
PM: Removing info for usb-serial:ttyUSB1
option 2-2:1.1: device disconnected
PM: Removing info for usb:2-2:1.1
PM: Removing info for No Bus:usbdev2.5_ep83
PM: Removing info for No Bus:usbdev2.5_ep04
PM: Removing info for scsi:11:0:0:0
PM: Removing info for No Bus:target11:0:0
PM: Removing info for No Bus:host11
PM: Removing info for usb:2-2:1.2
PM: Removing info for No Bus:usbdev2.5
PM: Removing info for No Bus:usbdev2.5_ep00
PM: Removing info for usb:2-2