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
@@ -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];
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]>:
> 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
> @@ -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];
>
Am Donnerstag, 29. November 2007 01:13:05 schrieb Pete Zaitcev:
> 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
Am Donnerstag, 29. November 2007 07:33:03 schrieb Johann Wilhelm:
> 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
On Thu, 29 Nov 2007 08:38:59 +0100, Oliver Neukum <[email protected]> wrote:
> Am Donnerstag, 29. November 2007 01:13:05 schrieb Pete Zaitcev:
> > 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
On Thu, 29 Nov 2007 08:44:38 +0100, Oliver Neukum <[email protected]> wrote:
> 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
Am Donnerstag, 29. November 2007 08:52:37 schrieb Pete Zaitcev:
> On Thu, 29 Nov 2007 08:38:59 +0100, Oliver Neukum <[email protected]> wrote:
> > Am Donnerstag, 29. November 2007 01:13:05 schrieb Pete Zaitcev:
> > > 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?
> 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
On Thu, 29 Nov 2007 09:04:28 +0100, Oliver Neukum <[email protected]> wrote:
> > > 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
Am Donnerstag, 29. November 2007 09:01:49 schrieb Pete Zaitcev:
> On Thu, 29 Nov 2007 08:44:38 +0100, Oliver Neukum <[email protected]> wrote:
> > 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
On Thu, Nov 29, 2007 at 09:14:47AM +0100, Oliver Neukum wrote:
> Am Donnerstag, 29. November 2007 09:01:49 schrieb Pete Zaitcev:
> > On Thu, 29 Nov 2007 08:44:38 +0100, Oliver Neukum <[email protected]> wrote:
> > > 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
--
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
Matthew Dharm wrote:
> On Thu, Nov 29, 2007 at 09:14:47AM +0100, Oliver Neukum wrote:
>
>> Am Donnerstag, 29. November 2007 09:01:49 schrieb Pete Zaitcev:
>>
>>> On Thu, 29 Nov 2007 08:44:38 +0100, Oliver Neukum <[email protected]> wrote:
>>>
>>>> 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.
>
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
> Matt
>
>
Am Donnerstag, 29. November 2007 11:01:34 schrieb Rui Santos:
> > 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.
OK, can you provide "lsusb -v" for the device in the CD mode and in
the modem mode?
Regards
Oliver
Oliver Neukum wrote:
> Am Donnerstag, 29. November 2007 11:01:34 schrieb Rui Santos:
>
>>> 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.
>>
>
> 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
Am Donnerstag 29 November 2007 schrieb Rui Santos:
> >> 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
----
--- a/drivers/usb/serial/option.c 2007-11-29 12:35:09.000000000 +0100
+++ b/drivers/usb/serial/option.c 2007-11-29 12:47:34.000000000 +0100
@@ -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 */
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]>:
> Am Donnerstag 29 November 2007 schrieb Rui Santos:
>> >> 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
>
> ----
>
> --- a/drivers/usb/serial/option.c 2007-11-29 12:35:09.000000000 +0100
> +++ b/drivers/usb/serial/option.c 2007-11-29 12:47:34.000000000 +0100
> @@ -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 */
>
>
Hi Pete, hi all,
On Mi, 28 Nov 2007, Pete Zaitcev wrote:
> 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.
> 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.
> 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.
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.
> 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.
> 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.
> 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
On Do, 29 Nov 2007, preining wrote:
> 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
I'll give it a go later today, still on 2.6.22.4.
Any logs of interest except for obvious behavior?
On Thu, 29 Nov 2007 15:05:50 +0100
Johann Wilhelm <[email protected]> wrote:
> 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]>:
>
> > Am Donnerstag 29 November 2007 schrieb Rui Santos:
> >> >> 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
> >
> > ----
> >
> > --- a/drivers/usb/serial/option.c 2007-11-29 12:35:09.000000000 +0100
> > +++ b/drivers/usb/serial/option.c 2007-11-29 12:47:34.000000000 +0100
> > @@ -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 */
> >
> >
>
>
Am Donnerstag 29 November 2007 schrieb Kristoffer Ericson:
> 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
On Thu, Nov 29, 2007 at 12:01:49AM -0800, Pete Zaitcev wrote:
> On Thu, 29 Nov 2007 08:44:38 +0100, Oliver Neukum <[email protected]> wrote:
>
> > 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
Hi,
El jue. 29 de nov. de 2007, a las 15:05:50 +0100, Johann Wilhelm escribió:
> 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).
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index a18659e..352c94c 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -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 */
> 73
>
> Zitat von Oliver Neukum <[email protected]>:
>
>> Am Donnerstag 29 November 2007 schrieb Rui Santos:
>>> >> 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
>>
>> ----
>>
>> --- a/drivers/usb/serial/option.c 2007-11-29 12:35:09.000000000 +0100
>> +++ b/drivers/usb/serial/option.c 2007-11-29 12:47:34.000000000 +0100
>> @@ -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 wrote:
> Am Donnerstag 29 November 2007 schrieb Rui Santos:
>
>>>> 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
>
> ----
>
> --- a/drivers/usb/serial/option.c 2007-11-29 12:35:09.000000000 +0100
> +++ b/drivers/usb/serial/option.c 2007-11-29 12:47:34.000000000 +0100
> @@ -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
Am Donnerstag, 29. November 2007 19:53:39 schrieb Jaime Velasco Juan:
> Hi,
>
> El jue. 29 de nov. de 2007, a las 15:05:50 +0100, Johann Wilhelm escribió:
> > 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).
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
Signed-off-by: Oliver Neukum <[email protected]>
Signed-off-by: Jaime Velasco Juan <[email protected]>
---
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index a18659e..352c94c 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -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 */
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
On Sat, 1 Dec 2007 09:07:38 +0100, Norbert Preining <[email protected]> wrote:
> is this the only addition that should be needed, ortogether with the
> changes in option to call the huawei init function?
The only one.
> 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
On Sa, 01 Dez 2007, Pete Zaitcev wrote:
> > 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.
> 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.
> 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:
--- drivers/usb/storage/initializers.c.orig 2007-11-17 12:29:25.000000000 +0100
+++ drivers/usb/storage/initializers.c 2007-11-17 12:29:37.000000000 +0100
@@ -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
On Fri, Nov 30, 2007 at 04:30:11PM +0000, Jaime Velasco Juan wrote:
>
> Signed-off-by: Oliver Neukum <[email protected]>
> Signed-off-by: Jaime Velasco Juan <[email protected]>
> ---
>
> diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
> index a18659e..352c94c 100644
> --- a/drivers/usb/serial/option.c
> +++ b/drivers/usb/serial/option.c
> @@ -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 */
> -
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)
--
Regards/Gru?,
Boris.
On Fri, 30 Nov 2007 16:30:11 +0000, Jaime Velasco Juan <[email protected]> wrote:
> --- a/drivers/usb/serial/option.c
> +++ b/drivers/usb/serial/option.c
> - { 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
Am Mittwoch, 5. Dezember 2007 17:34:23 schrieb Pete Zaitcev:
> 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
On Wed, 5 Dec 2007 19:23:14 +0100, Oliver Neukum <[email protected]> wrote:
> Am Mittwoch, 5. Dezember 2007 17:34:23 schrieb Pete Zaitcev:
> > 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