Re: Handshaking on USB serial devices

[David Newall]

Greg KH wrote:
> On Thu, Feb 14, 2008 at 07:55:44PM +1030, David Newall wrote:
>   
>> The current 2.6 driver maintains it's own buffer.  I think that's a bad
>> thing: usbserial already buffers writes, and the extra buffer copy seems
>> unnecessary, however it does solve the putchar problem.  Buffered (i.e.
>> by the 2.6 series pl2303 driver) data is written as soon as practicable,
>> regardless of CTS/DTR.  The same general workaround, but placed in
>> pl2303_send seems correct to me; that is, stop submitting write urbs
>> when the remote end lowers CTS/DTR, and trigger the resume from the
>> interrupt callback (specifically in update_line_status.)
>> 
>
> Where does the usbserial core buffer writes on 2.6?  The serial_write()
> function just passes the data straight down to the usb-serial child
> driver directly, no copying or buffering happens that I can see.
>   

You're right.  I haven't examined the 2.6 stack as closely as the 2.4. 
I noticed the buffer in 2.6 pl2303, but didn't check 2.6 usb-serial.  I
think I prefer the buffer in usb-serial, because its centralised rather
than in each driver, but I'm not going to step up to the plate and
propose changing that!

>> To make it clear: Even aside from the buffer in 2.6's pl2303.c, there's
>> a race: An in-flight write URB can fill all hardware buffers, making
>> unsafe what previously appeared to be a safe write.  I think it's
>> essential to delay submission of the URB on a stop-transmit condition.
>> 
>
> It's up to the individual driver to know when their buffers are filled
> up.  The big problem is, a lot of these cheap usb-serial devices (like
> the pl2303) don't have a way to report the uart queue filled-state back
> to the host, so things can easily get over-run as you have found out.
>   

My understanding of the problem has developed over the last couple of
days; going from wrist-deep to elbow-deep into the guts of things does
that.  There is a problem, and the solution I've been developing
addresses it, but maybe there's a simpler answer.  Hope to have a patch
together soon.
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Handshaking on USB serial devices

[David Newall]

Alan Cox wrote:
>> byte of a packet is being thrown away about .1% of the time for the pl2303, 
>> but I'm not sure if the FTDI driver still suffers from a similar rash.  I 
>> 
>
> A 20 byte low speed message is too small for flow control to account for
> it.

I agree.  I've observed the first byte of received data disappears on
pl2303 devices, but haven't spent time finding out why.  (It's on my list.)
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Add Novatel X950D to unusual_devs.h

[Brian Tuchten]

I don't know what you mean by "wait for the device to fully come up",
but wouldn't you have to wait for that in any case?  After all, how can
your patch eject it or do anything else if isn't fully up?

You don't have to wait for it to be mounted; the "eject" program is
perfectly happy to eject an unmounted CD.  It will even eject an audio
CD.

And don't you have to wait for hotplug to see the new device even with
your patch installed?


Thanks Alan.  Actually the driver ejects the card before hotplug even sees it, so it is 
much faster than waiting 10-15 seconds for hotplug to finish searching for the 
product/vendor ID in it's list, and then run a script to eject the device (remember it's a 
slow system).  The driver patch ejects it immediately which then allows the modem to be 
presented to the OS, and to hotplug as well.  We do need to wait for hotplug to see the 
modem device, so we needed to get the non-wanted device out of the way as fast as 
possible, which is what the driver hack helps achieve.


In our embedded platform when and/or if a CDMA type modem stops responding, or possibly 
for some reason no longer sees a tower, it is faster to logically eject/insert the card 
rather than reboot a unit when the modem is having problems.  A card could be reset 
several times a day ( or if there is a network outage, many more).  So when a customer 
wants as little downtime as possible, those 15 second waits can add up a lot.


I see your point that there are lots of other options other than a change to a USB driver. 
So possibly this is not a good feature for the USB driver to have when it can be done in 
user space.


-Brian Tuchten 


-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Add Novatel X950D to unusual_devs.h

[Alan Stern]

On Thu, 14 Feb 2008, Brian Tuchten wrote:

> 
> > Why don't you just write a udev rule to run the "eject" program when it
> > sees the Novatel device has been plugged in?
> >
> > Alan Stern
> 
> We could, but we don't use udev or eject.  If we did then we would need to 
> wait for the device to 
> fully come up, get mounted, and then eject it, then wait for hotplug to see 
> the new device. On a 486 
> 100mhz platform needing to access a modem for data, that can be an eternity 
> to wait =).

The situation probably isn't as bad as you make it out to be.  
(Although not using udev does make it difficult to utilize a udev 
script... but a hotplug script should work just as well.)

I don't know what you mean by "wait for the device to fully come up", 
but wouldn't you have to wait for that in any case?  After all, how can 
your patch eject it or do anything else if isn't fully up?

You don't have to wait for it to be mounted; the "eject" program is 
perfectly happy to eject an unmounted CD.  It will even eject an audio 
CD.

And don't you have to wait for hotplug to see the new device even with
your patch installed?

Finally, these delays are incurred only once, when the device is first 
plugged in.  Since plugging in a device is a manual operation, a short 
delay (a second or two) shouldn't matter much.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Gadgetfs problem.

[David Brownell]

On Thursday 14 February 2008, hui zhuu wrote:
> > > Thanks, anyway, how can I find the if version of
> > the
> > > gadgetfs.h is wrong?
> > 
> > Use the version of the header from the kernel that
> > you're running with.
> 
> I just did that, the problem is still there.
> 
> This is strange, as our d12 driver works ok with the
> serial/ether/file_storage gadget, from this point can
> I suppose it is sufficient to hooks up with gadgetfs?

It could be.  Does g_zero work well in stress test mode?
(That is, running all the tests in the test script, for
several days at a time ... try it over this weekend.)

Usually the problem with gadgetfs has been a mode for
handling control transfers that isn't widely used ...
except in gadgetfs, and g_file_storage.

 
> The gadget code i am working with is form 2.6.20.4
> kernel tree, I think it's pretty new. Did I miss
> anything else?

I've not used gadgetfs much lately, beyond just a
quick sanity test on 2.6.24 to sort out that one
issue (which turned out to be in userspace).

So, all I can say for sure is:  try 2.6.24 and see
if that works for you too.

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re: Re: Gadgetfs problem.

[hui zhuu]

> > Thanks, anyway, how can I find the if version of
> the
> > gadgetfs.h is wrong?
> 
> Use the version of the header from the kernel that
> you're running with.

I just did that, the problem is still there.

This is strange, as our d12 driver works ok with the
serial/ether/file_storage gadget, from this point can
I suppose it is sufficient to hooks up with gadgetfs?

The gadget code i am working with is form 2.6.20.4
kernel tree, I think it's pretty new. Did I miss
anything else?



> > --- David Brownell <[EMAIL PROTECTED]>写道:
> >
> > > On Thursday 14 February 2008, hui zhuu wrote:
> > > > gadgetfs: bound to d12 driver
> > > 
> > > My first suspicion would be this "d12" driver
> ... is
> > > it behaving right?
> > > 
> > > Though of course, you might also have a problem
> > > where you're using the wrong version of the
> gadgetfs.h
> > > header.
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-usb" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> 



  ___ 
雅虎邮箱传递新年祝福，个性贺卡送亲朋！ 
http://cn.mail.yahoo.com/gc/index.html?entry=5&souce=mail_mailletter_tagline
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re: Gadgetfs problem.

[David Brownell]

> Thanks, anyway, how can I find the if version of the
> gadgetfs.h is wrong?

Use the version of the header from the kernel that
you're running with.


> --- David Brownell <[EMAIL PROTECTED]>写道:
>
> > On Thursday 14 February 2008, hui zhuu wrote:
> > > gadgetfs: bound to d12 driver
> > 
> > My first suspicion would be this "d12" driver ... is
> > it behaving right?
> > 
> > Though of course, you might also have a problem
> > where you're using the wrong version of the gadgetfs.h
> > header.
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re: Gadgetfs problem.

[hui zhuu]

Hi David,

Thanks, anyway, how can I find the if version of the
gadgetfs.h is wrong?

--- David Brownell <[EMAIL PROTECTED]>写道:

> On Thursday 14 February 2008, hui zhuu wrote:
> > gadgetfs: bound to d12 driver
> 
> My first suspicion would be this "d12" driver ... is
> it
> behaving right?
> 
> Though of course, you might also have a problem
> where
> you're using the wrong version of the gadgetfs.h
> header.
> 
> 



  ___ 
雅虎邮箱传递新年祝福，个性贺卡送亲朋！ 
http://cn.mail.yahoo.com/gc/index.html?entry=5&souce=mail_mailletter_tagline
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: problem with starting 2.5.25-rc1 and latest git

[Greg KH]

On Wed, Feb 13, 2008 at 11:16:02PM +0100, Mariusz Kozlowski wrote:
> Hello,
> 
>   I tried 2.6.25-rc1 and latest git on my laptop (x86 32bit) and have a 
> problem.
> Linux boots but with huge delay due to some issue with loading usb modules.
> Udev complains:
> 
> 'Could not lock modprobe uhci_hcd'
> 'Could not lock modprobe yenta_socket'
> 'Unknown symbol usb_*'
> 'Gave up waiting for init of module usbcore'
> 
> at the same time I can see these messages in syslog (look at timing - grep by 
> usb):
> 
> Feb 13 21:34:22 laptop kernel: usbcore: registered new interface driver usbfs
> Feb 13 21:34:22 laptop kernel: usbcore: registered new interface driver hub
> Feb 13 21:34:22 laptop kernel: usbcore: registered new device driver usb
> Feb 13 21:34:22 laptop kernel: ehci_hcd: gave up waiting for init of module 
> usbcore.

I don't see how this is a usb issue, it looks to be a module loading
issue, which is in the module core and module-init-tools.

What version of module-init-tools do you have, and are you using an
initramfs that loads these modules?  If so, what distro and version are
you using?

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Add Novatel X950D to unusual_devs.h

[Brian Tuchten]

Why don't you just write a udev rule to run the "eject" program when it
sees the Novatel device has been plugged in?

Alan Stern


We could, but we don't use udev or eject.  If we did then we would need to wait for the device to 
fully come up, get mounted, and then eject it, then wait for hotplug to see the new device. On a 486 
100mhz platform needing to access a modem for data, that can be an eternity to wait =).


-Brian 


-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Add Novatel X950D to unusual_devs.h

[Alan Stern]

On Thu, 14 Feb 2008, Brian Tuchten wrote:

> Thanks Phil,
> 
> >Your patch disables the USB Storage card all together in order to get access
> >to the modem. We have other such hacks in the tree, but is there no way to
> >simply "eject" the USB Storage device so we don't have to actually disable
> >it for all users and they can choose which component of the device they'd
> >like to use?
> 
> We are actually using the 2.6.17.7 kernel ( old I know ) but we found a way 
> from some other GPL code 
> in the "zy" driver to actually eject the device.  I don't know if you want to 
> work it into 
> ~/drivers/usb/storage/usb.c or not.  The way we are ejecting is actually not 
> propor since it will 
> eject _any_ unusual device, but we don't look for any other unusual devices 
> in our embedded 
> platform.  Possibly a better way to go would to have a define to be used in 
> unusual_devs.h called 
> US_FL_EJECT_DEVICE to eject only certain devices.  I know the patch is 
> crappy, but if I was using a 
> more recent kernel, I would have written it better.
> 
> The Novatel X950D modem comes with a virtual CD, which has MAC OS/Wind*ws 
> installer.  So it is 
> useless to Linux. But until the virtual CD is ejected, you can't access the 
> modem ( times out after 
> about 5 minutes, which is too long to wait ).

Why don't you just write a udev rule to run the "eject" program when it 
sees the Novatel device has been plugged in?

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Handshaking on USB serial devices

[Gene Heskett]

On Thursday 14 February 2008, Krzysztof Halasa wrote:
>Gene Heskett <[EMAIL PROTECTED]> writes:
>> Apparently they do not Alan, the pl2303 in particular is a problem child,
>> throwing several lost com errors a day when doing nothing more strenuous
>> than talking to my belkin UPS from apcupsd, very small packets there, 20
>> bytes I believe at several second intervals.
>
>Is your UPS using "modern" hardware handshaking (CTS = PC can send,
>with RTS practically always asserted)? Or perhaps the "old",
>"half-duplex" V.24-style (RTS asserted before TX and then waiting for
>CTS)?
>
>Are you sure it uses hw handshaking at all? Most (all?) UPSes I used
>had only TxD and RxD (for RS-232).

ATM, its plugged into a USB port, but for some reason was not recognized at 
the last bootup.  And I just installed the rpm for a newer version of apcupsd 
when I found apcupsd was logging an error and exiting about 2 seconds after 
being started by the 'service' utility.  So I'm a bit puzzled.  From the 
dmesg at boot time there is no mention of it being found, from the current 
dmesg, after unplugging the USB cable from the back of it and replugging it 
about a second later, and got this:

[180077.652645] usb 1-1.1: USB disconnect, address 6
[180080.387154] usb 1-1.1: new low speed USB device using ehci_hcd and address 
11
[180080.586706] usb 1-1.1: configuration #1 chosen from 1 choice
[180081.339062] hiddev97hidraw3: USB HID v1.11 Device [Belkin  Belkin UPS] on 
usb-:00:02.2-1.1

As to why it wasn't found at bootup, call me bumfuzzled.  Uptime is about 2d 
3h and I wasn't aware it wasn't running until I wanted to see if anything was 
different about how it handled my belkin, which is not well, but it does take 
care of the graceful shutdown.

I just found this:
[EMAIL PROTECTED] ~]# dmesg |grep -A2 'address 6'
[   30.990194] usb 1-1.1: new low speed USB device using ehci_hcd and address 
6
[   31.183832] usb 1-1.1: configuration #1 chosen from 1 choice
[   31.190504] usb 1-1.1: can't set config #1, error -32
--
[180077.652645] usb 1-1.1: USB disconnect, address 6
[180080.387154] usb 1-1.1: new low speed USB device using ehci_hcd and address 
11
[180080.586706] usb 1-1.1: configuration #1 chosen from 1 choice

So something wasn't available at bootup.   And I'm still puzzled...

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The most important early product on the way to developing a good product
is an imperfect version.
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Add Novatel X950D to unusual_devs.h

[Brian Tuchten]

Thanks Phil,


Your patch disables the USB Storage card all together in order to get access
to the modem. We have other such hacks in the tree, but is there no way to
simply "eject" the USB Storage device so we don't have to actually disable
it for all users and they can choose which component of the device they'd
like to use?


We are actually using the 2.6.17.7 kernel ( old I know ) but we found a way from some other GPL code 
in the "zy" driver to actually eject the device.  I don't know if you want to work it into 
~/drivers/usb/storage/usb.c or not.  The way we are ejecting is actually not propor since it will 
eject _any_ unusual device, but we don't look for any other unusual devices in our embedded 
platform.  Possibly a better way to go would to have a define to be used in unusual_devs.h called 
US_FL_EJECT_DEVICE to eject only certain devices.  I know the patch is crappy, but if I was using a 
more recent kernel, I would have written it better.


The Novatel X950D modem comes with a virtual CD, which has MAC OS/Wind*ws installer.  So it is 
useless to Linux. But until the virtual CD is ejected, you can't access the modem ( times out after 
about 5 minutes, which is too long to wait ).


-Brian

--- linux-2.6.17.7/drivers/usb/storage/usb.c.orig  2008-01-05 
16:05:35.0 -0600
+++ linux-2.6.17.7/drivers/usb/storage/usb.c   2008-01-05 
19:50:06.0 -0600
@@ -885,6 +895,55 @@
   complete_and_exit(&threads_gone, 0);
}

+//Added eject routine, modeled from zy driver
+static int eject_installer(struct usb_interface *intf)
+{
+   struct usb_device *udev = interface_to_usbdev(intf);
+   struct usb_host_interface *iface_desc = &intf->altsetting[0];
+   struct usb_endpoint_descriptor *endpoint;
+   unsigned char *cmd;
+   u8 bulk_out_ep;
+   int r;
+
+   /* Find bulk out endpoint */
+   endpoint = &iface_desc->endpoint[1].desc;
+   if ((endpoint->bEndpointAddress & USB_TYPE_MASK) == USB_DIR_OUT &&
+   (endpoint->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) ==
+   USB_ENDPOINT_XFER_BULK) {
+   bulk_out_ep = endpoint->bEndpointAddress;
+   } else {
+   dev_err(&udev->dev,
+   "zd1211rw: Could not find bulk out endpoint\n");
+   return -ENODEV;
+   }
+
+   cmd = kzalloc(31, GFP_KERNEL);
+   if (cmd == NULL)
+   return -ENODEV;
+
+   /* USB bulk command block */
+   cmd[0] = 0x55;  /* bulk command signature */
+   cmd[1] = 0x53;  /* bulk command signature */
+   cmd[2] = 0x42;  /* bulk command signature */
+   cmd[3] = 0x43;  /* bulk command signature */
+   cmd[14] = 6;/* command length */
+
+   cmd[15] = 0x1b; /* SCSI command: START STOP UNIT */
+   cmd[19] = 0x2;  /* eject disc */
+
+   dev_info(&udev->dev, "Ejecting virtual installer media...\n");
+   r = usb_bulk_msg(udev, usb_sndbulkpipe(udev, bulk_out_ep),
+   cmd, 31, NULL, 2000);
+   kfree(cmd);
+   if (r)
+   return r;
+
+   /* At this point, the device disconnects and reconnects with the real
+* ID numbers. */
+
+   usb_set_intfdata(intf, NULL);
+   return 0;
+}

/* Probe to see if we can drive a newly-connected USB device */
static int storage_probe(struct usb_interface *intf,
@@ -930,7 +989,10 @@
* of the match from the usb_device_id table, so we can find the
* corresponding entry in the private table.
*/
-   get_device_info(us, id);
+   result = get_device_info(us, id);
+   if (result)
+   goto BadDevice;

   /* Get the transport, protocol, and pipe settings */
   result = get_transport(us);
@@ -975,7 +1037,11 @@

   /* We come here if there are any problems */
BadDevice:
-   US_DEBUGP("storage_probe() failed\n");
+   US_DEBUGP("storage_probe() failed, result %d\n", result);
+   if (0 == eject_installer(intf))
+   printk(KERN_INFO USB_STORAGE "Ejected Unusual Device \n");
+   else
+   printk(KERN_INFO USB_STORAGE "Eject Failed on Unusual 
Device\n");
   release_everything(us);
   return result;
} 


-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Handshaking on USB serial devices

[Krzysztof Halasa]

Gene Heskett <[EMAIL PROTECTED]> writes:

> Apparently they do not Alan, the pl2303 in particular is a problem child, 
> throwing several lost com errors a day when doing nothing more strenuous than 
> talking to my belkin UPS from apcupsd, very small packets there, 20 bytes I 
> believe at several second intervals.

Is your UPS using "modern" hardware handshaking (CTS = PC can send,
with RTS practically always asserted)? Or perhaps the "old",
"half-duplex" V.24-style (RTS asserted before TX and then waiting for
CTS)?

Are you sure it uses hw handshaking at all? Most (all?) UPSes I used
had only TxD and RxD (for RS-232).
-- 
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: problem with starting 2.6.25-rc1 and latest git

[Jean Delvare]

On Thu, 14 Feb 2008 00:27:34 +0100, Mariusz Kozlowski wrote:
> Of course there is a typo in the subject :)
> 
> 2.5.25-rc1 -> 2.6.25-rc1
> 
> > Hello,
> > 
> > I tried 2.6.25-rc1 and latest git on my laptop (x86 32bit) and have a 
> > problem.
> > Linux boots but with huge delay due to some issue with loading usb modules.
> > Udev complains:
> > 
> > 'Could not lock modprobe uhci_hcd'
> > 'Could not lock modprobe yenta_socket'
> > 'Unknown symbol usb_*'
> > 'Gave up waiting for init of module usbcore'

FWIW: I have the exact same problem here, running 2.6.25-rc1-git3 on x86_64.
Distribution is openSuse 10.2, module-init-tools version 3.2.2, udev 103.
I can do any test you want me to.

-- 
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Add another Novatel U727 ID to the device table for usbserial

[Warren Turkal]

Signed-off-by: Warren Turkal <[EMAIL PROTECTED]>
---
 drivers/usb/serial/option.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 5e8bf1b..b7cb102 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -174,6 +174,7 @@ static struct usb_device_id option_ids[] = {
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x2410) }, /* Novatel EU740 */
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x4100) }, /* Novatel U727 */
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x4400) }, /* Novatel MC950 */
+   { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, 0x5010) }, /* Novatel U727 */
{ USB_DEVICE(DELL_VENDOR_ID, 0x8114) }, /* Dell Wireless 5700 Mobile 
Broadband CDMA/EVDO Mini-Card == Novatel Expedite EV620 CDMA/EV-DO */
{ USB_DEVICE(DELL_VENDOR_ID, 0x8115) }, /* Dell Wireless 5500 Mobile 
Broadband HSDPA Mini-Card == Novatel Expedite EU740 HSDPA/3G */
{ USB_DEVICE(DELL_VENDOR_ID, 0x8116) }, /* Dell Wireless 5505 Mobile 
Broadband HSDPA Mini-Card == Novatel Expedite EU740 HSDPA/3G */
-- 
1.5.2.5

-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Problems with VIA PCMCIA USB controller and uhci_hcd

[Julius Schwartzenberg]

Hello,

I'm using an ASUS Desknote with a SiS chipset. It has 4 USB ports which 
work well, except when I try to use my camera and audio stick at the 
same time (also have a harddisk and mouse connected), then the camera 
kicks off the audio stick and dmesg shows "out of bandwidth" messages.


That's why I bought a second controller. Which works with PCMCIA and 
seems to contain a VIA chipset. I can't get this thing to work stably at 
all though. Even when I just connect my mouse, it stops working after a 
short while. dmesg prints errors that something really bad happened.


I'm using Ubuntu Gutsy with it's 2.6.22 kernel. Here is the ouput from 
dmesg and lspci:

http://haar.student.utwente.nl/~julius/desknote/dmesg
http://haar.student.utwente.nl/~julius/desknote/lspci

What could I look into to solve this problem? Is there any more 
information I could give?


Thanks in advance,
Julius
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Handshaking on USB serial devices

[Gene Heskett]

On Thursday 14 February 2008, Greg KH wrote:
>On Thu, Feb 14, 2008 at 03:04:41PM -0500, Gene Heskett wrote:
>> On Thursday 14 February 2008, Alan Cox wrote:
>> >> byte of a packet is being thrown away about .1% of the time for the
>> >> pl2303, but I'm not sure if the FTDI driver still suffers from a
>> >> similar rash.  I
>> >
>> >A 20 byte low speed message is too small for flow control to account for
>> >it.
>>
>> Where then could the first byte go?  Note I'm not fussing about flow
>> controls per sei, so the subject line maybe needs to be adjusted, but they
>> obviously work well enough that a multimegabyte transfer to my printer
>> works very well, but about usb trying to entirely replace serial here. 
>> There does seem to be a problem but I'm not 100% positive where it is in
>> the chain of a usb packets travels.  What I've observed, with hidraw I
>> think it was, is that the first 'wake up' byte incoming didn't seem to be
>> there.
>
>I have not seen this kind of error in years, why have you not reported
>it?
I did make some noise, probably over a year ago now, but I guess it fell 
through the cracks or no one else could duplicate it.  And my expiry on this 
list means any and all such messages have been expired for several months.

>Can you enable debugging in the pl2303 driver with a simple:
>   modprobe pl2303 debug=1
>or when the driver is running with:
>   echo 1 > /sys/module/pl2303/parameters/debug
>
>That way you can see the data flowing through the device.  If the host
>sends it to the device, perhaps your device is just dropping it somehow?
>
>These pl2303 devices are really cheap, there are lots of different
>variations of them, and none of them are documented at all.  We might be
>missing some kind of interaction here, but in my tests, I have not had
>any lost data.

I have two, both very early models sold by Radio Shack but they have been 
hanging on the pegs except for when I take roadnav with me on a long trip.

>Are you sure your userspace program isn't constantly setting the line
>settings?  We have seen instances where the device does get confused and
>resets itself if that happens a lot.  That was just fixed in the last
>kernel release.

Maybe that is what I was seeing?  ATM runing on 2.6.24 final. Just for grins I 
fired up a 'cat /dev/hideaw0 | hexdump -v' and I'm seeing traffic, mostly 
from the motion sensor, but because hexdump makes a 16 byte line out of one 
byte, and may display that byte anyplace in that 16 byte buffer, I can't tell 
what is right and what is wrong even though I am familiar with the x10 
protocol.  Do we have another such tool that will output only those bytes 
actually received as they come in?  Something that prints the hex value of 
the byte, and then issues a newline to the screen?  Or some way to ship the 
$00's to /dev/null so hexdump ignores them?

>thanks,
>
>greg k-h



-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
"But I don't like Spam"
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: serial: move zte MF330 from sierra to option

[Greg KH]

On Thu, Feb 14, 2008 at 01:12:28PM -0800, Andrew Morton wrote:
> On Mon, 11 Feb 2008 12:29:33 -0800
> Kevin Lloyd <[EMAIL PROTECTED]> wrote:
> 
> > From: Kevin Lloyd <[EMAIL PROTECTED]>
> > 
> > Moves the Onda H600/ZTE MF33 device from the sierra driver to the option 
> > driver.
> > 
> 
> A changelog should describe why a change was made, not simply what the
> change is.

I know the history behind it, I'll flush it out when I add it to my
tree.  Kevin sent this patch because I asked for it, so I'll take the
blame here.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Add Novatel X950D to unusual_devs.h

[Phil Dibowitz]

Alan Stern wrote:
> On Thu, 14 Feb 2008, Phil Dibowitz wrote:
> 
>> It occurs to me we need to change the email list in unusual_devs.h to the
>> new linux-usb-devel email address. Whoops. I'll submit a patch.
> 
> While you're at it, you should also change the mailing list address
> mentioned in usb.c:get_device_info().

Cool, thanks. This weekend I'll submit a patch to change it everywhere I can
find it.

-- 
Phil Dibowitz [EMAIL PROTECTED]
Open Source software and tech docsInsanity Palace of Metallica
http://www.phildev.net/   http://www.ipom.com/

"Never write it in C if you can do it in 'awk';
 Never do it in 'awk' if 'sed' can handle it;
 Never use 'sed' when 'tr' can do the job;
 Never invoke 'tr' when 'cat' is sufficient;
 Avoid using 'cat' whenever possible" -- Taylor's Laws of Programming




signature.asc
Description: OpenPGP digital signature

Re: [PATCH] usb: serial: move zte MF330 from sierra to option

[Andrew Morton]

On Mon, 11 Feb 2008 12:29:33 -0800
Kevin Lloyd <[EMAIL PROTECTED]> wrote:

> From: Kevin Lloyd <[EMAIL PROTECTED]>
> 
> Moves the Onda H600/ZTE MF33 device from the sierra driver to the option 
> driver.
> 

A changelog should describe why a change was made, not simply what the
change is.

> 
> ---
>  drivers/usb/serial/sierra.c |   1 -
>  drivers/usb/serial/option.c |   2 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> --- linux-2.6.25-rc1/drivers/usb/serial/sierra.c.orig 2008-02-11 
> 11:34:06.0 -0800
> +++ linux-2.6.25-rc1/drivers/usb/serial/sierra.c  2008-02-11 
> 11:34:36.0 -0800
> @@ -178,7 +178,6 @@ static struct usb_device_id id_table [] 
>  
>   { USB_DEVICE(0x1199, 0x0112), .driver_info = DEVICE_1_PORT }, /* Sierra 
> Wireless AirCard 580 */
>   { USB_DEVICE(0x0F3D, 0x0112), .driver_info = DEVICE_1_PORT }, /* 
> Airprime/Sierra PC 5220 */
> - { USB_DEVICE(0x05C6, 0x6613), .driver_info = DEVICE_1_PORT }, /* Onda 
> H600/ZTE MF330 */
>  
>   { USB_DEVICE(0x1199, 0x0FFF), .driver_info = DEVICE_INSTALLER},
>   { }
> --- linux-2.6.25-rc1/drivers/usb/serial/option.c.orig 2008-02-11 
> 11:42:10.0 -0800
> +++ linux-2.6.25-rc1/drivers/usb/serial/option.c  2008-02-11 
> 11:42:18.0 -0800
> @@ -121,6 +121,8 @@ static int  option_send_setup(struct usb
>  #define BANDRICH_PRODUCT_C100_1  0x1002
>  #define BANDRICH_PRODUCT_C100_2  0x1003
>  
> +#define QUALCOMM_VENDOR_ID   0x05C6
> +
>  static struct usb_device_id option_ids[] = {
>   { USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_COLT) },
>   { USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_RICOLA) },
> @@ -186,6 +188,7 @@ static struct usb_device_id option_ids[]
>   { USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_500A) },
>   { USB_DEVICE(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_C100_1) },
>   { USB_DEVICE(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_C100_2) },
> + { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE MF330 */
>   { } /* Terminating entry */
>  };
>  MODULE_DEVICE_TABLE(usb, option_ids);

Because I, for one, don't have a clue why you did this?
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Add Novatel X950D to unusual_devs.h

[Alan Stern]

On Thu, 14 Feb 2008, Phil Dibowitz wrote:

> It occurs to me we need to change the email list in unusual_devs.h to the
> new linux-usb-devel email address. Whoops. I'll submit a patch.

While you're at it, you should also change the mailing list address
mentioned in usb.c:get_device_info().

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Handshaking on USB serial devices

[Greg KH]

On Thu, Feb 14, 2008 at 03:04:41PM -0500, Gene Heskett wrote:
> On Thursday 14 February 2008, Alan Cox wrote:
> >> byte of a packet is being thrown away about .1% of the time for the
> >> pl2303, but I'm not sure if the FTDI driver still suffers from a similar
> >> rash.  I
> >
> >A 20 byte low speed message is too small for flow control to account for
> >it.
> 
> Where then could the first byte go?  Note I'm not fussing about flow controls 
> per sei, so the subject line maybe needs to be adjusted, but they obviously 
> work well enough that a multimegabyte transfer to my printer works very well, 
> but about usb trying to entirely replace serial here.  There does seem to be 
> a problem but I'm not 100% positive where it is in the chain of a usb packets 
> travels.  What I've observed, with hidraw I think it was, is that the 
> first 'wake up' byte incoming didn't seem to be there.

I have not seen this kind of error in years, why have you not reported
it?

Can you enable debugging in the pl2303 driver with a simple:
modprobe pl2303 debug=1
or when the driver is running with:
echo 1 > /sys/module/pl2303/parameters/debug

That way you can see the data flowing through the device.  If the host
sends it to the device, perhaps your device is just dropping it somehow?

These pl2303 devices are really cheap, there are lots of different
variations of them, and none of them are documented at all.  We might be
missing some kind of interaction here, but in my tests, I have not had
any lost data.

Are you sure your userspace program isn't constantly setting the line
settings?  We have seen instances where the device does get confused and
resets itself if that happens a lot.  That was just fixed in the last
kernel release.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Handshaking on USB serial devices

[Greg KH]

On Thu, Feb 14, 2008 at 07:55:44PM +1030, David Newall wrote:
> The current 2.6 driver maintains it's own buffer.  I think that's a bad
> thing: usbserial already buffers writes, and the extra buffer copy seems
> unnecessary, however it does solve the putchar problem.  Buffered (i.e.
> by the 2.6 series pl2303 driver) data is written as soon as practicable,
> regardless of CTS/DTR.  The same general workaround, but placed in
> pl2303_send seems correct to me; that is, stop submitting write urbs
> when the remote end lowers CTS/DTR, and trigger the resume from the
> interrupt callback (specifically in update_line_status.)

Where does the usbserial core buffer writes on 2.6?  The serial_write()
function just passes the data straight down to the usb-serial child
driver directly, no copying or buffering happens that I can see.

> To make it clear: Even aside from the buffer in 2.6's pl2303.c, there's
> a race: An in-flight write URB can fill all hardware buffers, making
> unsafe what previously appeared to be a safe write.  I think it's
> essential to delay submission of the URB on a stop-transmit condition.

It's up to the individual driver to know when their buffers are filled
up.  The big problem is, a lot of these cheap usb-serial devices (like
the pl2303) don't have a way to report the uart queue filled-state back
to the host, so things can easily get over-run as you have found out.

If you really want to use a usb-serial device in an environment where
such kinds of flow control are essential, then you have to buy the more
expensive ones.  The I/O networks devices handle this kind of thing very
well, and have done so since the 2.3 days, but they cost much more than
the cheap pl2303-based devices.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Add Novatel X950D to unusual_devs.h

[Phil Dibowitz]

It occurs to me we need to change the email list in unusual_devs.h to the
new linux-usb-devel email address. Whoops. I'll submit a patch.

Anyway, the following patch was submitted to my by Brian Tuchten.

Brian,

Your patch disables the USB Storage card all together in order to get access
to the modem. We have other such hacks in the tree, but is there no way to
simply "eject" the USB Storage device so we don't have to actually disable
it for all users and they can choose which component of the device they'd
like to use?

Brian Tuchten wrote:
> 
> --- /tmp/linux-2.6.23.13/drivers/usb/storage/unusual_devs.h.orig   
> 2008-02-08 09:17:05.0 -0600
> +++ /tmp/linux-2.6.23.13/drivers/usb/storage/unusual_devs.h
> 2008-02-08 09:23:19.0 -0600
> @@ -1491,6 +1491,15 @@
> US_SC_DEVICE, US_PR_DEVICE, NULL,
> US_FL_IGNORE_RESIDUE ),
>  
> +/* Novatel X950D GSM card w/USB storage needs to be
> +   ejected before the modem can be accessed.
> +   Reported by Brian Tuchten <[EMAIL PROTECTED]
> > */
> +UNUSUAL_DEV(  0x1410, 0x5010, 0x, 0x,
> +"Novatel Wireless",
> +"USB Storage on X950D HSUPA Modem",
> +US_SC_DEVICE, US_PR_DEVICE, NULL,
> +US_FL_IGNORE_DEVICE),
> +
>  /* Reported by Francesco Foresti <[EMAIL PROTECTED]
> > */
>  UNUSUAL_DEV(  0x14cd, 0x6600, 0x0201, 0x0201,
> "Super Top",
>  
>  
> [root]# cat /proc/bus/usb/devices
> T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
> B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
> D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
> P:  Vendor= ProdID= Rev= 2.06
> S:  Manufacturer=Linux 2.6.17.7JBM ohci_hcd
> S:  Product=OHCI Host Controller
> S:  SerialNumber=:01:00.1
> C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
> I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
> E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms
>  
> T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 3
> B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
> D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
> P:  Vendor= ProdID= Rev= 2.06
> S:  Manufacturer=Linux 2.6.17.7JBM ohci_hcd
> S:  Product=OHCI Host Controller
> S:  SerialNumber=:01:00.0
> C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
> I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
> E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms
>  
> T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
> D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
> P:  Vendor=1410 ProdID=1450 Rev= 0.00
> S:  Manufacturer=Novatel Wireless
> S:  Product=Novatel Wireless HSUPA Modem
> S:  SerialNumber=356922010063991
> C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=500mA
> I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=airprime
> E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=128ms
> E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
> E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
> I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=airprime
> E:  Ad=84(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
> E:  Ad=04(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
> I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=airprime
> E:  Ad=85(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
> E:  Ad=05(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms


-- 
Phil Dibowitz [EMAIL PROTECTED]
Open Source software and tech docsInsanity Palace of Metallica
http://www.phildev.net/   http://www.ipom.com/

"Never write it in C if you can do it in 'awk';
 Never do it in 'awk' if 'sed' can handle it;
 Never use 'sed' when 'tr' can do the job;
 Never invoke 'tr' when 'cat' is sufficient;
 Avoid using 'cat' whenever possible" -- Taylor's Laws of Programming




signature.asc
Description: OpenPGP digital signature

Re: Handshaking on USB serial devices

[Gene Heskett]

On Thursday 14 February 2008, Alan Cox wrote:
>> byte of a packet is being thrown away about .1% of the time for the
>> pl2303, but I'm not sure if the FTDI driver still suffers from a similar
>> rash.  I
>
>A 20 byte low speed message is too small for flow control to account for
>it.

Where then could the first byte go?  Note I'm not fussing about flow controls 
per sei, so the subject line maybe needs to be adjusted, but they obviously 
work well enough that a multimegabyte transfer to my printer works very well, 
but about usb trying to entirely replace serial here.  There does seem to be 
a problem but I'm not 100% positive where it is in the chain of a usb packets 
travels.  What I've observed, with hidraw I think it was, is that the 
first 'wake up' byte incoming didn't seem to be there.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Whenever people agree with me I always feel I must be wrong.
-- Oscar Wilde
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Handshaking on USB serial devices

[Alan Cox]

> byte of a packet is being thrown away about .1% of the time for the pl2303, 
> but I'm not sure if the FTDI driver still suffers from a similar rash.  I 

A 20 byte low speed message is too small for flow control to account for
it.
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Handshaking on USB serial devices

[Alan Cox]

> That's a very good point.  Even so: on the 2.4 driver, write_room isn't
> implemented (refer to a previous message by Alan); and in 2.6, a 1k
> buffer is built into the driver, with nothing to prevent it being sent
> when the hardware buffer fills.  These could be bugs in the two versions

Which isn't a bug if the hardware handles it internally as most does.

> of pl2303, if you like; in fact I suppose they are; but there's a wider
> problem: The same weakness can be found in aircable.c, airprime.c,
> cyberjack.c, cypress_m8.c (I think), empeg.c, ftdi_sio (I think),
> io_ti.c, and that's where I stop checking, and declare it's widespread.

Careful - a lot of hardware handles this properly itself, you simply
don't get the URB completing until its all done.

> now that you've mentioned it, I can't see that anything to stop the
> driver from overflowing the internal buffer, which is very perplexing. 
> Would that be right?  That seems a pretty dramatic weakness; how do you
> write a large report to a slow printer without losing data?

pl2303 implements write room in 2.6 (and 2.4 I don't care about at all)
so the driver appears entirely correct in respect of its internal buffer
management. Someone with docs will have to comment on whether it handles
flow control in firmware or needs pl2303_send to do further checks as you
propose.

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Flushing URBs for small control URBs

[Greg KH]

On Thu, Feb 14, 2008 at 10:51:10AM -0800, David Brownell wrote:
> On Thursday 14 February 2008, Andrew McKay wrote:
> > What would be the best way to implement a loop to handle flashing the LED 
> > in 
> > kernel space. ?Is this a good task for a kthread? ?Or is there a simpler 
> > construct to do this with?
> 
> Use the LED framework ... it supports a variety of triggers.
> For example, "heartbeat" blinks faster as system load increases,
> "timer" has easily settable periods, and you can manually set
> the brightness ... all under sysfs control.

And, best of all, you tie into the standard Linux API for LEDs, always a
much better idea than implementing your own API through a custom ioctl
that no one else is going to know about.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: tracking the linux usb tree

[Greg KH]

On Thu, Feb 14, 2008 at 10:48:37AM -0800, Warren Turkal wrote:
> Hello Greg or others,
> 
> I have a small change I'd like to make the usbserial driver. Is there
> a particular remote branch that I should be tracking with git to make
> sure that I can submit it easily?

Just do it against Linus's latest tree, or the latest -rc release,
whichever is easier for you.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Huawei E220 and usb storage

[Pete Zaitcev]

On Fri, 16 Nov 2007 14:22:56 +0100, Norbert Preining <[EMAIL PROTECTED]> wrote:

> > > The difference with huaweiAktBbo.c seems that kernel uses a nonzero 
> > > length.
> > > Can you try zero length with the kernel? It's the second argument to the 
> > > last.
> > 
> > I tried with the git patch plus changing the penultimage argument from
> > 0x1 to 0.
> 
> Ok, did new tests with 2.6.24-rc2:
> - with plain kernel the usb-storage modules attaches and detaches
>   permanently a virtual cd drive, I stopped after 30+ iterations.

It looks like between Dave Russel and I, we hit the same problem
that you did, after taking care of detection and initialization.
Look at his dmesg in comment #44 in this:
 https://bugzilla.redhat.com/show_bug.cgi?id=253096#c44

> - changing the penultimage argument in the usb_stor_huawei_e220_init
>   function from 0x1 to 0 stopped this misbehaviour, but
> 
> - with the change from 0x1 to 0 the initialization works automatically.

I may be able to test this.

As you recall, Huawei people themselves suggested nonzero length,
this is why we didn't want to change it. But perhaps they are
mistaken about the operation of their own hardware. Stranger
things happened...

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Handshaking on USB serial devices

[Gene Heskett]

On Thursday 14 February 2008, Alan Cox wrote:
>O> believe at several second intervals.  I can cut those messages to about
>
>> weekly by using an FDTI adaptor in its place, or I can stop them entirely
>> if
>
>Sorry don't see the connection between the two stories ?
>
>Alan

The connection is that windows people don't see those errors, linux folks do. 
I believe, but don't know how to use the tools to verify it, that the first 
byte of a packet is being thrown away about .1% of the time for the pl2303, 
but I'm not sure if the FTDI driver still suffers from a similar rash.  I 
have only one such FTDI adapter in the system atm, and its in series with 
manual heyu commands only, so it doesn't get regularly exercised.  I figure 
it will do the least damage there.  The pl2303's are all hanging on a peg 
waiting for emergency use only, they were just too much trouble when they 
miss-fire and the system issues -wall warnings several times per hour.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The revolution will not be televised.
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Handshaking on USB serial devices

[David Brownell]

On Thursday 14 February 2008, David Newall wrote:
> RS232 is (normally) so much slower than USB that, on an extended
> transmission, the buffer internal to the local hardware can fill well
> before the remote device has demanded that transmission stop.  In fact,
> now that you've mentioned it, I can't see that anything to stop the
> driver from overflowing the internal buffer, which is very perplexing. 
> Would that be right? 

Only for stupidly designed hardware ... which you might well
be using, though I happen to never have seen anything that's
quite *that* stupid.  (There's always a first time though.)

USB has enough control flow to prevent that from happening.
If the host sends data that the peripheral isn't ready to
accept, the peripheral just refuses to accept it, and the
host will retry later.

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Flushing URBs for small control URBs

[David Brownell]

On Thursday 14 February 2008, Andrew McKay wrote:
> What would be the best way to implement a loop to handle flashing the LED in 
> kernel space.  Is this a good task for a kthread?  Or is there a simpler 
> construct to do this with?

Use the LED framework ... it supports a variety of triggers.
For example, "heartbeat" blinks faster as system load increases,
"timer" has easily settable periods, and you can manually set
the brightness ... all under sysfs control.

The simplest way to plug into that is to just to submit your
URBs asynchronously.  Save it away when it completes, so you
don't have to re-allocate another URB later.

You don't need a task for this.

- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb-storage and S.M.A.R.T.

[Matthew Dharm]

On Thu, Feb 14, 2008 at 06:19:46PM +0100, René Rebe wrote:
> Hi all,
> 
> due to some failing dics I got myself a JMicro USB<->ATA,SATA
> cable for data recovery and co.
> 
> However, I was quite suprised that the SMART (...) status querries
> would not go thru.
> 
> # smartctl -a /dev/sdb
> smartctl version 5.37 [x86_64-t2-linux-gnu] Copyright (C) 2002-6 Bruce Allen
> Home page is http://smartmontools.sourceforge.net/
> 
> Device: SAMSUNG  SP1654N  Version: 0-37
> Device type: disk
> Local Time is: Thu Feb 14 18:19:09 2008 CET
> Device does not support SMART
> 
> Error Counter logging not supported
> Device does not support Self Test logging
> 
> 
> As I do not know the underlying protocols off-hand, is that a driver /
> sub-system limitation or not possible to get thru this USB mass
> storage protocol?

The protocol will carry the commands just fine.  The problem is that most
USB/ATA converter chips won't translate the command properly.

Matt

-- 
Matthew Dharm  Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

It was a new hope.
-- Dust Puppy
User Friendly, 12/25/1998


pgplpvJ1RKlRd.pgp
Description: PGP signature

tracking the linux usb tree

[Warren Turkal]

Hello Greg or others,

I have a small change I'd like to make the usbserial driver. Is there
a particular remote branch that I should be tracking with git to make
sure that I can submit it easily?

Thanks,
wt
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Handshaking on USB serial devices

[David Newall]

Alan Cox wrote:
>> To make it clear: Even aside from the buffer in 2.6's pl2303.c, there's
>> a race: An in-flight write URB can fill all hardware buffers, making
>> unsafe what previously appeared to be a safe write.  I think it's
>> essential to delay submission of the URB on a stop-transmit condition.
>> 
>
> Hardware flow control *is* a race, and always will be. The remote end has
> a delay in signalling 'stop' there is a propogation delay and a response
> delay. This is why most implementations assert stop a bit *before* they
> run out.
>   

That's a very good point.  Even so: on the 2.4 driver, write_room isn't
implemented (refer to a previous message by Alan); and in 2.6, a 1k
buffer is built into the driver, with nothing to prevent it being sent
when the hardware buffer fills.  These could be bugs in the two versions
of pl2303, if you like; in fact I suppose they are; but there's a wider
problem: The same weakness can be found in aircable.c, airprime.c,
cyberjack.c, cypress_m8.c (I think), empeg.c, ftdi_sio (I think),
io_ti.c, and that's where I stop checking, and declare it's widespread.

> Given the size of transfers and the internal buffering one would hope the
> USB devices do their own flow control if told to properly.
>   

RS232 is (normally) so much slower than USB that, on an extended
transmission, the buffer internal to the local hardware can fill well
before the remote device has demanded that transmission stop.  In fact,
now that you've mentioned it, I can't see that anything to stop the
driver from overflowing the internal buffer, which is very perplexing. 
Would that be right?  That seems a pretty dramatic weakness; how do you
write a large report to a slow printer without losing data?


I'm beginning to realise that overflowing the internal buffer is the
greatest risk of data loss.  Hardware flow control almost seems
serendipitous.  It gives us a reason to stop submitting bulk writes.

This is the essence of the change that I looking at for pl2303.c. 
(Patch relative to kernel 2.6.23.14.)  Does it make sense?

--- pl2303.c2008-01-15 07:19:56.0 +1030
+++ pl2303.c.new2008-02-15 04:22:12.0 +1030
@@ -370,6 +370,18 @@
 
spin_lock_irqsave(&priv->lock, flags);
 
+   /*
+* there's a limit to how much we can buffer, so don't accept data while
+* CTS or DSR are low.  XXX I don't know what to do about XON/XOFF.
+*/
+   if ((priv->line_control | CONTROL_RTS && !(priv->line_status & 
UART_CTS)) || \
+   (priv->line_control | CONTROL_DTR && !(priv->line_status & 
UART_DSR))) {
+   /* 
+   spin_unlock_irqrestore(&priv->lock, flags);
+   dbg("%s: send paused by remote flow control", __FUNCTION__);
+   return;
+   }
+
if (priv->write_urb_in_use) {
spin_unlock_irqrestore(&priv->lock, flags);
return;
@@ -957,6 +969,9 @@
 
pl2303_update_line_status(port, data, actual_length);
 
+   /* send any buffered data */
+   pl2303_send(port);
+
 exit:
retval = usb_submit_urb(urb, GFP_ATOMIC);
if (retval)


-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Flushing URBs for small control URBs

[Andrew McKay]

Sorry for all the questions, but I do appreciate the help.


Off = unactive
On = active
Flashing = error talking to connected device


You might want to add the "flash" functionality within the kernel driver
itself, so you can get a bit tighter timing than relying on a
userspace/kernelspace turn around to provide an accurate timing loop.



What would be the best way to implement a loop to handle flashing the LED in 
kernel space.  Is this a good task for a kthread?  Or is there a simpler 
construct to do this with?


Thanks,
Andrew
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

usb-storage and S.M.A.R.T.

[René Rebe]

Hi all,

due to some failing dics I got myself a JMicro USB<->ATA,SATA
cable for data recovery and co.

However, I was quite suprised that the SMART (...) status querries
would not go thru.

# smartctl -a /dev/sdb
smartctl version 5.37 [x86_64-t2-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

Device: SAMSUNG  SP1654N  Version: 0-37
Device type: disk
Local Time is: Thu Feb 14 18:19:09 2008 CET
Device does not support SMART

Error Counter logging not supported
Device does not support Self Test logging


As I do not know the underlying protocols off-hand, is that a driver /
sub-system limitation or not possible to get thru this USB mass
storage protocol?

Any pointer appreciated,
  René

-- 
  René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
  http://exactcode.de | http://t2-project.org | http://rene.rebe.name
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ONDA N501HS (aka ZTE MF330) flow control

[Greg KH]

On Thu, Feb 14, 2008 at 03:32:46PM +, Sergio Callegari wrote:
> > >> 
> > >
> > >   make M=drivers/usb/serial/
> > > will build only that one directory.
> > >
> > > Or:
> > >   make drivers/usb/serial/option.ko
> > > should build only that module.
> > >
> > > You might have to do a 'make oldconfig' and 'make prepare' first though.
> > >
> > > Hope this helps,
> > >
> 
> Ok, I think I did it.  I had to modify the patch a little since it does not
> apply cleanly on 2.6.22 and I had to manually mkdir .tmp_versions in my kernel
> tree, but compiling the two modules only worked nice and _fast_.
> 
> Now I have a minor problem in that my system still tries to load the sierra
> driver when I put in the card. Dmesg says:
> [  131.612000]
> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB
> Serial support registered for Sierra USB modem (1 port)
> [  131.612000]
> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB
> Serial support registered for Sierra USB modem (3 port)
> [  131.612000] usbcore: registered new interface driver sierra
> [  131.612000] drivers/usb/serial/sierra.c: USB Driver for Sierra Wireless USB
> modems: v.1.0.6
> 
> so I have to manually unload sierra an manually load option.  Then I get
> 
> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB
> Serial support registered for GSM modem (1-port)
> [  154.136000] option 7-1:1.0: GSM modem (1-port) converter detected
> [  154.136000] usb 7-1: GSM modem (1-port) converter now attached to ttyUSB0
> [  154.136000] option 7-1:1.1: GSM modem (1-port) converter detected
> [  154.136000] usb 7-1: GSM modem (1-port) converter now attached to ttyUSB1
> [  154.136000] option 7-1:1.2: GSM modem (1-port) converter detected
> [  154.136000] usb 7-1: GSM modem (1-port) converter now attached to ttyUSB2
> [  154.136000] usbcore: registered new interface driver option
> [  154.136000] drivers/usb/serial/option.c: USB Driver for GSM modems: v0.7.1
> 
> Any clue at where the automatic loading of the sierra module is triggered?

udev does this.  Try just deleting the module, or moving it somewhere
out of the /lib/modules/KERNEL_VERSION/ directory tree.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ONDA N501HS (aka ZTE MF330) flow control

[Greg KH]

On Thu, Feb 14, 2008 at 03:20:26PM +0100, Sergio Callegari wrote:
> Greg KH wrote:
>> On Wed, Feb 13, 2008 at 03:54:38PM +, Sergio Callegari wrote:
>>   
>>> Hi,
>>>
>>> I have an ONDA N501HS (namely a rebranded ZTE MF330) UMTS pc card.
>>>
>>> I am currently using this card with the sierra driver (as in current 
>>> kernels).
>>> 
>>
>> Which kernel version specifically?
>>   
> Ubuntu's 32bit i386 2.6.22

Please try .24 if at all possible.

Ubuntu is also known for patching their kernel to the mountains and
back, so you will really only be able to get kernel help from them, as
we have no idea what they have added to their tree.

If you want to use a kernel.org kernel, we will be glad to help you out.

>>> However I am noticing the following problem:
>>>
>>> - when I use the card for downloading from the internet, everything is 
>>> fine;
>>> - when I use the card for uploading to the internet, after a few tens kB, 
>>> the
>>> card freezes.
>>>
>>> Freezing goes as follows:
>>>
>>> the card provides 3 ports: ttyUSB0 to ttyUSB2. The port ttyUSB0 that is 
>>> used for
>>> data stops working completely. It becomes impossible to talk to it, until 
>>> the
>>> pc-card is extracted and put again in the pcmcia slot.  The other ports 
>>> keep
>>> working.
>>>
>>> I wonder if this might have something to do with flow control (or lack 
>>> thereof)
>>> that causes the card to be flooded with data from the computer until it 
>>> locks.
>>> 
>>
>> Probably.
>>
>>   
>>> I believe that flow control might be the issue, since if I use upload 
>>> programs
>>> that let me decide the data rate and I pick a low enough rate everything 
>>> goes
>>> just fine.
>>>
>>> I have also seen that the ZTE MF330 has just been moved from the sierra 
>>> driver
>>> to the option driver.
>>> Is there any chance that this might fix my problem?
>>> 
>>
>> Well, it might, as it turns out that this really is not a sierra
>> wireless based device, it's something else.
>>
>> So try changing drivers and see if that gets better.
>>   
> Ok. Il'll give the option driver a try and provide some feedback.
> The option driver has the words
>
> This driver exists because the "normal" serial driver doesn't work too well
>  with GSM modems. Issues:
>  - data loss -- one single Receive URB is not nearly enough
>  - nonstandard flow (Option devices) control
>  - controlling the baud rate doesn't make sense
>
> at the beginning... I hope that the thing about flow control applies and is 
> not an "Option" specific thing.
>
> In any case, I know that ZTE MF330 is not a sierra, but if I am not wrong 
> it should have the same qualcomm chipset as sierra devices, with different 
> firmware.

Firmware makes all the difference in the world for these kinds of things :)

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Gadgetfs problem.

[David Brownell]

On Thursday 14 February 2008, hui zhuu wrote:
> gadgetfs: bound to d12 driver

My first suspicion would be this "d12" driver ... is it
behaving right?

Though of course, you might also have a problem where
you're using the wrong version of the gadgetfs.h header.

-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Handshaking on USB serial devices

[Alan Cox]

O> believe at several second intervals.  I can cut those messages to about 
> weekly by using an FDTI adaptor in its place, or I can stop them entirely if 

Sorry don't see the connection between the two stories ?

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Handshaking on USB serial devices

[Gene Heskett]

On Thursday 14 February 2008, Alan Cox wrote:
>> To make it clear: Even aside from the buffer in 2.6's pl2303.c, there's
>> a race: An in-flight write URB can fill all hardware buffers, making
>> unsafe what previously appeared to be a safe write.  I think it's
>> essential to delay submission of the URB on a stop-transmit condition.
>
>Hardware flow control *is* a race, and always will be. The remote end has
>a delay in signalling 'stop' there is a propogation delay and a response
>delay. This is why most implementations assert stop a bit *before* they
>run out.
>
>Given the size of transfers and the internal buffering one would hope the
>USB devices do their own flow control if told to properly.
>
>Alan

Apparently they do not Alan, the pl2303 in particular is a problem child, 
throwing several lost com errors a day when doing nothing more strenuous than 
talking to my belkin UPS from apcupsd, very small packets there, 20 bytes I 
believe at several second intervals.  I can cut those messages to about 
weekly by using an FDTI adaptor in its place, or I can stop them entirely if 
a pure rs232 connection is used.  Unforch, pure rs232 is going the way of the 
dodo bird, and the adapters in general fail such applications badly.  I want 
to build a new machine, but the first thing I'd have to get after a new video 
card is a serial card.  And there goes a slot I'll need for something else.  
My current home automation via heyu, the ups, and the Garmin GPS all require 
serial ports.

Another linux app, a route navigator program that uses the output of a GPS to 
display where you are, also has errors several times an hour when using a 
pl2303 to connect a low baud rate Garmin 12 with no flow control to it.  I 
just recently used it for a 3000 mile nearly month long trip.

So IMO, neither of the 2 readily available devices for usb-serial use is quite 
ready for mission critical usage.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
No extensible language will be universal.
-- T. Cheatham
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ONDA N501HS (aka ZTE MF330) flow control

[Sergio Callegari]

> >> 
> >
> > make M=drivers/usb/serial/
> > will build only that one directory.
> >
> > Or:
> > make drivers/usb/serial/option.ko
> > should build only that module.
> >
> > You might have to do a 'make oldconfig' and 'make prepare' first though.
> >
> > Hope this helps,
> >

Ok, I think I did it.  I had to modify the patch a little since it does not
apply cleanly on 2.6.22 and I had to manually mkdir .tmp_versions in my kernel
tree, but compiling the two modules only worked nice and _fast_.

Now I have a minor problem in that my system still tries to load the sierra
driver when I put in the card. Dmesg says:
[  131.612000]
/build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB
Serial support registered for Sierra USB modem (1 port)
[  131.612000]
/build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB
Serial support registered for Sierra USB modem (3 port)
[  131.612000] usbcore: registered new interface driver sierra
[  131.612000] drivers/usb/serial/sierra.c: USB Driver for Sierra Wireless USB
modems: v.1.0.6

so I have to manually unload sierra an manually load option.  Then I get

/build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB
Serial support registered for GSM modem (1-port)
[  154.136000] option 7-1:1.0: GSM modem (1-port) converter detected
[  154.136000] usb 7-1: GSM modem (1-port) converter now attached to ttyUSB0
[  154.136000] option 7-1:1.1: GSM modem (1-port) converter detected
[  154.136000] usb 7-1: GSM modem (1-port) converter now attached to ttyUSB1
[  154.136000] option 7-1:1.2: GSM modem (1-port) converter detected
[  154.136000] usb 7-1: GSM modem (1-port) converter now attached to ttyUSB2
[  154.136000] usbcore: registered new interface driver option
[  154.136000] drivers/usb/serial/option.c: USB Driver for GSM modems: v0.7.1

Any clue at where the automatic loading of the sierra module is triggered?

Now I am on UMTS _with_ the option module.  So far so good.
As soon as I need to upload some bigger file, I'll let you know how it goes.
(won't do it now, because I have 500MB per month and I need to be carefull about
it).

Sergio


-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Some Questions about QHD

[Alan Stern]

On Thu, 14 Feb 2008, vichy wrote:

> Dear all:
> I list the initial sequences that I observed from source code.
> If I get something wrong, please let me know.
> 
> Suppose I get 3 devices connected to a host, A, B and C.
> A plugs in.
> We use QH with device-address = 0, ep = 0 to get A's device descriptor.
> Set A's device address to 1.

Okay.

> B plugs in.
> We use QH with device-address = 0, ep = 0 to get B's device descriptor.
> Set A's device address to 2.

No.  Instead, set B's device address to 2.

> C plugs in.
> We use QH with device-address = 0, ep = 0 to get C's device descriptor.
> Set A's device address to 2.

No.  Instead, set C's device address to 3.

> So Qh with device-address = 0, ep = 0 is always the default and least QH to
> get every device's device descriptor, right?

I don't understand your question.

Resetting a device sets its address to 0.  Each device is automatically
reset when you plug it in; that's why we need to use a QH with device
address = 0 to read the device descriptor.  But once the device
descriptor (more precisely, the maximum packet size for endpoint 0,
which is stored in the device descriptor) is known, the device is
assigned a unique address.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: convert usb.h struct usb_device to kernel-doc

[Alan Stern]

On Wed, 13 Feb 2008, Randy Dunlap wrote:

> Thanks, Alan.  Updated patch...  Any more comments/corrections?

This looks good.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Gadgetfs problem.

[hui zhuu]

Hello all,

I ran into this gadgetfs problem on our custom board.

We use 2.6.20.4 kernel tree and run gadget stuff on
our PDIUSBD12 device. The device works good with
g_serial, g_ether and g_file_storage, but with
gadgetfs, when I invoke usb.c to test it, it reports
the following
message:

gadgetfs: bound to d12 driver
Registered gadget driver 'gadgetfs'
/dev/gadget/d12 ep0 configured
serial="l62jhhux1uwojpo45k1wwojihjbed0z4s0nwq3eq6syjj9qinafiqjb1eslqb41"
gadgetfs: connected

** Thu Jan gadgetfs: disconnected
 1 00:33:28 1970
CONNECT full speed
DISCONNECT
gadgetfs: connected
CONNECT full speed
SETUP 80.06 v0300 i 255
... get string 0 lang 
write string data: Device or resource busy
ep0 read after poll: Level 2 halted
poll: Interrupgadgetfs: disconnected
unregistered gadget driver 'gadgetfs'


It seems that usb.c can be notified the get string
request, but when try to respond, it crashed.

So how can I fix the problem?  Try latest kernel, such
as 2.6.24, or something else?

thanks


  ___ 
雅虎邮箱传递新年祝福，个性贺卡送亲朋！ 
http://cn.mail.yahoo.com/gc/index.html?entry=5&souce=mail_mailletter_tagline
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ONDA N501HS (aka ZTE MF330) flow control

[Sergio Callegari]

Greg KH wrote:

On Wed, Feb 13, 2008 at 03:54:38PM +, Sergio Callegari wrote:
  

Hi,

I have an ONDA N501HS (namely a rebranded ZTE MF330) UMTS pc card.

I am currently using this card with the sierra driver (as in current kernels).



Which kernel version specifically?
  

Ubuntu's 32bit i386 2.6.22

However I am noticing the following problem:

- when I use the card for downloading from the internet, everything is fine;
- when I use the card for uploading to the internet, after a few tens kB, the
card freezes.

Freezing goes as follows:

the card provides 3 ports: ttyUSB0 to ttyUSB2. The port ttyUSB0 that is used for
data stops working completely. It becomes impossible to talk to it, until the
pc-card is extracted and put again in the pcmcia slot.  The other ports keep
working.

I wonder if this might have something to do with flow control (or lack thereof)
that causes the card to be flooded with data from the computer until it locks.



Probably.

  

I believe that flow control might be the issue, since if I use upload programs
that let me decide the data rate and I pick a low enough rate everything goes
just fine.

I have also seen that the ZTE MF330 has just been moved from the sierra driver
to the option driver.
Is there any chance that this might fix my problem?



Well, it might, as it turns out that this really is not a sierra
wireless based device, it's something else.

So try changing drivers and see if that gets better.
  

Ok. Il'll give the option driver a try and provide some feedback.
The option driver has the words

This driver exists because the "normal" serial driver doesn't work too well
 with GSM modems. Issues:
 - data loss -- one single Receive URB is not nearly enough
 - nonstandard flow (Option devices) control
 - controlling the baud rate doesn't make sense

at the beginning... I hope that the thing about flow control applies and 
is not an "Option" specific thing.


In any case, I know that ZTE MF330 is not a sierra, but if I am not 
wrong it should have the same qualcomm chipset as sierra devices, with 
different firmware.
Hence I wonder if someone else might have experienced similar issues as 
mine on other cards.
  

If this is the case, having my distribution kernel source, once I have applied
the patch, how can I rebuild _only_ the sierra and the option modules?



make M=drivers/usb/serial/
will build only that one directory.

Or:
make drivers/usb/serial/option.ko
should build only that module.

You might have to do a 'make oldconfig' and 'make prepare' first though.

Hope this helps,

greg k-h
  

Thanks!

Sergio

-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Handshaking on USB serial devices

[Alan Cox]

> To make it clear: Even aside from the buffer in 2.6's pl2303.c, there's
> a race: An in-flight write URB can fill all hardware buffers, making
> unsafe what previously appeared to be a safe write.  I think it's
> essential to delay submission of the URB on a stop-transmit condition.

Hardware flow control *is* a race, and always will be. The remote end has
a delay in signalling 'stop' there is a propogation delay and a response
delay. This is why most implementations assert stop a bit *before* they
run out.

Given the size of transfers and the internal buffering one would hope the
USB devices do their own flow control if told to properly.

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH] make usbnet work with rndis_host

[Jean-Christophe Dubois]

Just for my information, is this patch accepted or are you expecting some 
other changes?

Thanks

JC

On Monday 11 February 2008 17:52:13 Jean-Christophe Dubois wrote:
> On Saturday 09 February 2008 10:51:06 David Brownell wrote:
> > So I'd rather see a one-line fix to the RNDIS host code, instead of
> > this more elaborate approach.  Could you give that a try?
>
> So here is the new proposal.
>
> Signed-off-by: Jean-Christophe Dubois <[EMAIL PROTECTED]>
> ---
>
> diff -ruN linux-source-2.6.24/drivers/net/usb/rndis_host.c
> linux-source-2.6.24.new/drivers/net/usb/rndis_host.c ---
> linux-source-2.6.24/drivers/net/usb/rndis_host.c  2008-01-24
> 11:52:31.0 +0100 +++
> linux-source-2.6.24.new/drivers/net/usb/rndis_host.c  2008-02-11
> 17:43:48.0 +0100 @@ -499,8 +499,18 @@
>   net->hard_header_len += sizeof (struct rndis_data_hdr);
>   dev->hard_mtu = net->mtu + net->hard_header_len;
>
> + /* now we need to compute dev->maxpacket */
> + dev->maxpacket = usb_maxpacket (dev->udev, dev->out, 1);
> +
> + if (dev->maxpacket == 0) {
> + dev_err(&intf->dev, "dev->maxpacket can't be 0\n");
> + retval = -EINVAL;
> + goto fail_and_release;
> + }
> +
>   dev->rx_urb_size = dev->hard_mtu + (dev->maxpacket + 1);
>   dev->rx_urb_size &= ~(dev->maxpacket - 1);
> +
>   u.init->max_transfer_size = cpu_to_le32(dev->rx_urb_size);
>
>   net->change_mtu = NULL;
> -
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Some Questions about QHD

[Pandita, Vikram]

Vichy

>Sent: Thursday, February 14, 2008 1:35 PM
>
>Dear all:
>I list the initial sequences that I observed from source code.
>If I get something wrong, please let me know.
>
>Suppose I get 3 devices connected to a host, A, B and C.
>A plugs in.
>We use QH with device-address = 0, ep = 0 to get A's device descriptor.
>Set A's device address to 1.
>
>B plugs in.
>We use QH with device-address = 0, ep = 0 to get B's device descriptor.
>Set A's device address to 2.
>
>C plugs in.
>We use QH with device-address = 0, ep = 0 to get C's device descriptor.
>Set A's device address to 2.
>
>So Qh with device-address = 0, ep = 0 is always the default and least QH to
>get every device's device descriptor, right?

Each URB will have an endpoint EP, each EP will have "one" QH associated with 
it when URB is submitted and the QH will have multiple transfer descriptors 
dynamically created as per the request. 

Now its it's a control EP0 URB, a QH would be created with Address=0 and tds 
with setup token etc.

>
>Appreciate your help,
>vichy
>
>-Original Message-
>From: Alan Stern [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, February 12, 2008 1:44 AM
>To: Pandita, Vikram
>Cc: vichy; linux-usb@vger.kernel.org
>Subject: RE: Some Questions about QHD
>
>On Mon, 11 Feb 2008, Pandita, Vikram wrote:
>
>> >> 2. What is the "device address" used for in QH?
>> >
>> >There is no "device address" field in a QH -- at least, there isn't in
>> >uhci-hcd or ehci-hcd.  Maybe other controller drivers do have such a
>> >field.
>>
>> I have a doubt -
>> Referring to ehci spec 3.6, looks like the QH has a Device Address that
>gets tracked in qh->hw_info1 field.
>>
>> Refer -
>> qh_make (
>> ...
>> info1 |= usb_pipeendpoint (urb->pipe) << 8;
>> info1 |= usb_pipedevice (urb->pipe) << 0;
>> ...
>> qh->hw_info1 = cpu_to_hc32(ehci, info1);
>> ...
>>
>> Isn't the QH identifying the destination pipe by an Endpoint Number +
>Device Address?
>
>Yes, you are right and I was wrong.
>
>The EHCI controller uses the device address field in the QH to store
>the value for the ADDR field of Token packets (see section 8.3 and 8.4
>in the USB 2.0 spec).
>
>Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Handshaking on USB serial devices

[Alan Cox]

On Wed, 13 Feb 2008 21:02:11 -0800
Greg KH <[EMAIL PROTECTED]> wrote:

> On Thu, Feb 14, 2008 at 01:15:37AM +1030, David Newall wrote:
> > Consider a USB-attached serial port that is set to do RTS/CTS (or
> > DSR/DTR) handshaking: What stops the kernel sending more data to it when
> > the remote end lowers CTS (or DTR)?
> 
> The tty layer should look at the proper flags and not send data on to
> the driver in this kind of instance.

For outgoing data the tty ldisc will check the available room indicators
the driver provides and stop when they fill. We don't want to be directly
involved in flow control if possible as most decent hardware does RTS/CTS
handshaking in hardware (except in the PC world).

If your hardware is dumb (ie you do RTS/CTS in software) then you need to
track the CTS state and termios bits (in your set_termios method) and
transmit according to flow control rules, letting the buffer fill up
otherwise.

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Setting USB keyboard repeate rate

[Johan Hedlund]

I am using a USB keyboard on a arm system running kernel 2.6.11. I want
to set the keyboard repeat rate and wonder how this can be done? Are
there some application that can be used?

/Johan
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Handshaking on USB serial devices

[David Newall]

Greg KH wrote:
> On Thu, Feb 14, 2008 at 01:15:37AM +1030, David Newall wrote:
>   
>> Consider a USB-attached serial port that is set to do RTS/CTS (or
>> DSR/DTR) handshaking: What stops the kernel sending more data to it when
>> the remote end lowers CTS (or DTR)?
>> 
>
> The tty layer should look at the proper flags and not send data on to
> the driver in this kind of instance.
>
> Is this not happening properly for you?  If so, which USB serial driver?
>   

It's not happening properly, for pl2303 (and, I admit it! on kernel
2.4.)  I think there's a widespread problem (i.e. with other drivers.) 
None of the drivers that I've examined check CTS or DTR; or, if they do,
I can't see where.  Likewise, I can't see it being done in n_tty nor
tty_io; not even in usbserial.  The best answer I can see is write_room,
but that doesn't seem quite right.  It seems that data written (via
*_write) will merrily be transmitted to the converter, even while the
remote end is signalling to stop, even if local hardware buffers fill.

I have a working solution for the 2.4 driver, but am looking towards
something for 2.6 and beyond.  The 2.4 solution is in two parts: first,
implement a write_room function, which returns 0 when transmission is
required to stop, which apparently gives a hint to the tty layer.  (NB,
doesn't help when using a different line discipline.)  The second part
is to return 0 (or maybe -EAGAIN?) in the write function when
transmission is required to stop.  This appears sound.  (Note that the
generic putchar does no error checking, and fails when the write URB is
busy.  That's a problem with a fairly obvious solution.)

The current 2.6 driver maintains it's own buffer.  I think that's a bad
thing: usbserial already buffers writes, and the extra buffer copy seems
unnecessary, however it does solve the putchar problem.  Buffered (i.e.
by the 2.6 series pl2303 driver) data is written as soon as practicable,
regardless of CTS/DTR.  The same general workaround, but placed in
pl2303_send seems correct to me; that is, stop submitting write urbs
when the remote end lowers CTS/DTR, and trigger the resume from the
interrupt callback (specifically in update_line_status.)

As I say, this appears to be a widespread problem.  I've looked at a
number of drivers and in none of them can I see anything to prevent
transmission when the remote end demands a stop.  I'm not sure that the
tty layer, which I think I said attempts to address the problem, albeit
it does a half-arsed job, is the right place to do hardware
handshaking.  Equally, I'm not sure that the wheel should be re-invented
for every driver, but that might be unavoidable.

To make it clear: Even aside from the buffer in 2.6's pl2303.c, there's
a race: An in-flight write URB can fill all hardware buffers, making
unsafe what previously appeared to be a safe write.  I think it's
essential to delay submission of the URB on a stop-transmit condition.
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Question about FRINDEX and SOF

[vichy]

Dear all:
In section 4.5 of ehci-r10.pdf, there is a phase which says
"The one micro-frame delay yields host controller periodic schedule and bus
frame boundary relationship as illustrated in Figure 4-7. This adjustment
allows software to trivially schedule the periodic start and complete-split
transactions for full and low-speed periodic endpoints, using the natural
alignment of the periodic schedule interface"
I know it tries to explain why FRINDEX is one ahead of SOF number.
But I cannot feel the trivialness which mentions in driver source, could
someone tell me why it tries to do so?
Thanks for your help,
vichy

-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Some Questions about QHD

[vichy]

Dear all:
I list the initial sequences that I observed from source code.
If I get something wrong, please let me know.

Suppose I get 3 devices connected to a host, A, B and C.
A plugs in.
We use QH with device-address = 0, ep = 0 to get A's device descriptor.
Set A's device address to 1.

B plugs in.
We use QH with device-address = 0, ep = 0 to get B's device descriptor.
Set A's device address to 2.

C plugs in.
We use QH with device-address = 0, ep = 0 to get C's device descriptor.
Set A's device address to 2.

So Qh with device-address = 0, ep = 0 is always the default and least QH to
get every device's device descriptor, right?

Appreciate your help,
vichy

-Original Message-
From: Alan Stern [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, February 12, 2008 1:44 AM
To: Pandita, Vikram
Cc: vichy; linux-usb@vger.kernel.org
Subject: RE: Some Questions about QHD

On Mon, 11 Feb 2008, Pandita, Vikram wrote:

> >> 2. What is the "device address" used for in QH?
> >
> >There is no "device address" field in a QH -- at least, there isn't in
> >uhci-hcd or ehci-hcd.  Maybe other controller drivers do have such a
> >field.
> 
> I have a doubt - 
> Referring to ehci spec 3.6, looks like the QH has a Device Address that
gets tracked in qh->hw_info1 field. 
> 
> Refer - 
> qh_make (
> ...
> info1 |= usb_pipeendpoint (urb->pipe) << 8;
> info1 |= usb_pipedevice (urb->pipe) << 0;
> ...
> qh->hw_info1 = cpu_to_hc32(ehci, info1);
> ...
> 
> Isn't the QH identifying the destination pipe by an Endpoint Number +
Device Address?

Yes, you are right and I was wrong.

The EHCI controller uses the device address field in the QH to store
the value for the ADDR field of Token packets (see section 8.3 and 8.4
in the USB 2.0 spec).

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html