Re: Add the infamous Huawei E220 to option.c
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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.0 +0100
> +++ b/drivers/usb/serial/option.c 2007-11-29 12:47:34.0 +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-ROMHUAWEI 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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.c2007-11-29 12:35:09.0 +0100
>> +++ b/drivers/usb/serial/option.c2007-11-29 12:47:34.0 +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 */
>>
>>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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.0 +0100
> > +++ b/drivers/usb/serial/option.c 2007-11-29 12:47:34.0 +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 */
> >
> >
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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 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-ROMHUAWEI 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:
Re: Add the infamous Huawei E220 to option.c
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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.0 +0100
+++ b/drivers/usb/serial/option.c 2007-11-29 12:47:34.0 +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 */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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.0 +0100
+++ b/drivers/usb/serial/option.c 2007-11-29 12:47:34.0 +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 */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x12d1 idProduct 0x1003 bcdDevice0.00 iManufacturer 1 HUAWEI Technologies iProduct2 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 bInterfaceNumber0 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 bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x (Bus Powered) lsusb -v in "modem + usb-storage" mode: Bus 005 Device 011: ID 12d1:1003 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x12d1 idProduct 0x1003 bcdDevice0.00 iManufacturer 1 HUAWEI Technologies iProduct2 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 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 3 Data Interface Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 128 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes
Re: Add the infamous Huawei E220 to option.c
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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 > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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 pgppfYfR7ex3G.pgp Description: PGP signature
Re: Add the infamous Huawei E220 to option.c
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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 pgppfYfR7ex3G.pgp Description: PGP signature
Re: Add the infamous Huawei E220 to option.c
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x12d1 idProduct 0x1003 bcdDevice0.00 iManufacturer 1 HUAWEI Technologies iProduct2 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 bInterfaceNumber0 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 bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x (Bus Powered) lsusb -v in modem + usb-storage mode: Bus 005 Device 011: ID 12d1:1003 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x12d1 idProduct 0x1003 bcdDevice0.00 iManufacturer 1 HUAWEI Technologies iProduct2 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 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 3 Data Interface Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 128 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint
Re: Add the infamous Huawei E220 to option.c
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.0 +0100
+++ b/drivers/usb/serial/option.c 2007-11-29 12:47:34.0 +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 */
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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 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-ROMHUAWEI 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
Re: Add the infamous Huawei E220 to option.c
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.0 +0100
+++ b/drivers/usb/serial/option.c 2007-11-29 12:47:34.0 +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 */
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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.0 +0100
+++ b/drivers/usb/serial/option.c 2007-11-29 12:47:34.0 +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 */
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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.c2007-11-29 12:35:09.0 +0100
+++ b/drivers/usb/serial/option.c2007-11-29 12:47:34.0 +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 */
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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.0 +0100
+++ b/drivers/usb/serial/option.c 2007-11-29 12:47:34.0 +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-ROMHUAWEI 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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.0 -0700
+++
linux-2.6.23.1-42.fc8.e220.1/drivers/usb/serial/option.c 2007-11-27
21:36:11.0 -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];
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Add the infamous Huawei E220 to option.c
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.0 -0700
+++ linux-2.6.23.1-42.fc8.e220.1/drivers/usb/serial/option.c2007-11-27
21:36:11.0 -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];
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Add the infamous Huawei E220 to option.c
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.0 -0700
+++ linux-2.6.23.1-42.fc8.e220.1/drivers/usb/serial/option.c2007-11-27
21:36:11.0 -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];
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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.0 -0700
+++
linux-2.6.23.1-42.fc8.e220.1/drivers/usb/serial/option.c 2007-11-27
21:36:11.0 -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];
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Add the infamous Huawei E220 to option.c
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
