USB fixes for 2.6.26-rc4

Here are some USB patches for your 2.6.25-git tree.

They include:
- bugfixes
- new driver for the isight webcam device to drop firmware into it to make it work. It's very tiny and self-contained.
- new device ids. Lots of them. They overshadow the new driver, which is pretty funny.
- usb quirks
- usb-storage quirks

Please pull from:

	master.kernel.org:/pub/scm/linux/kernel/git/gregkh/usb-2.6.git/

All of these patches have been in the -mm tree for a while, as well as -next.

The full patches will be sent to the linux-usb mailing list, if anyone wants to see them.

thanks,

greg k-h

------------

 drivers/usb/core/generic.c         |    5 -
 drivers/usb/core/hcd.h             |    2 +
 drivers/usb/core/hub.c             |   15 ++-
 drivers/usb/core/quirks.c          |    4 +
 drivers/usb/core/sysfs.c           |   44 +++---
 drivers/usb/gadget/fsl_usb2_udc.c  |    2 +
 drivers/usb/host/ehci-au1xxx.c     |    1 +
 drivers/usb/host/ehci-fsl.c        |    7 +-
 drivers/usb/host/ehci-hcd.c        |    3 +-
 drivers/usb/host/ehci-hub.c        |   16 ++-
 drivers/usb/host/ehci-ixp4xx.c     |    4 +-
 drivers/usb/host/ehci-orion.c      |    8 +-
 drivers/usb/host/ehci-pci.c        |    4 +-
 drivers/usb/host/ehci-ppc-of.c     |    2 +
 drivers/usb/host/ehci-ppc-soc.c    |    1 +
 drivers/usb/host/ehci-ps3.c        |    1 +
 drivers/usb/host/ehci-q.c          |   15 +-
 drivers/usb/host/ehci-sched.c      |   67 ++++++---
 drivers/usb/host/ehci.h            |    5 +-
 drivers/usb/misc/Kconfig           |   11 ++
 drivers/usb/misc/Makefile          |    1 +
 drivers/usb/misc/isight_firmware.c |  131 ++++++++++++++++++
 drivers/usb/serial/ftdi_sio.c      |  264 +++++++++++++++++++++++++++++++++++-
 drivers/usb/serial/ftdi_sio.h      |  265 +++++++++++++++++++++++++++++++++++-
 drivers/usb/serial/option.c        |   34 +++---
 drivers/usb/serial/pl2303.c        |    1 +
 drivers/usb/serial/pl2303.h        |    1 +
 drivers/usb/storage/unusual_devs.h |   10 +-
 28 files changed, 821 insertions(+), 103 deletions(-)
 create mode 100644 drivers/usb/misc/isight_firmware.c

---------------

Alan Stern (8):
USB: fix possible deadlock involving sysfs attributes
USB: add all configs to the "descriptors" attribute
USB: EHCI: fix up root-hub TT mess
USB: EHCI: suppress unwanted error messages
USB: EHCI: fix remote-wakeup regression
USB: EHCI: fix bug in Iso scheduling
USB: EHCI: fix performance regression
USB: usb-storage: unusual_devs update for Cypress ATACB

Javier Smaldone (1):
USB: Add support for ROKR W5 in unusual_devs.h

Li Yang (1):
USB: fsl_usb2_udc: fix recursive lock

Matthew Garrett (1):
USB: Firmware loader driver for USB Apple iSight camera

Michael Karcher (1):
USB: usb-serial: option: Don't match Huawei driver CD images

Phil Dibowitz (1):
USB: Fix M600i unusual_devs entry

Ray Molenkamp (1):
USB: FTDI_SIO : Add support for Matrix Orbital PID Range

René Rebe (1):
USB: add another scanner quirk

Steve Murphy (1):
USB: pl2303: another product ID

Hi Greg,

Sorry not to have spotted this sooner, but I don't like this one. Why do we need a specific kernel driver when a userspace tool (fxload) exists to perform the same task, especially when the tool handles udev integration nicely ? The Apple iSight uses an EZ-USB chipset. If we really want a kernel driver for that it should probably be made more generic to handle all EZ-USB-based devices.

Best regards,

Laurent Pinchart

That's not a regresssion at all! Plus, this patch shouldn't have included the timeout change. The timeout change is why I didn't ACK this patch...

Well, perhaps because no one did this kind of integration before? :)

I'll take this driver out later, if the infrastructure is put into place, and some kind of driver package is created for the distros to use to implement this.

But until then, the easiest way to get this hardware working for users is a tiny kernel firmware loader just like this one. If you think we should turn it into something for all ezusb devices, that's also a possiblity.

thanks,

greg k-h

Well, I was misinformed by Alan Stern about this then, sorry for missing that you didn't ack this one (you acked the other patches in this series though.)

Alan, care to make up a patch to fix this? Or should I just revert it in the tree as-is?

thanks,

greg k-h

I'd certainly have no objection to making it generic, but this is the only EZ-USB hardware I have to hand. Right now I've just ended up irritated that we don't have any sort of consistent solution to dealing with this, and I'd like these webcams to work.

Matthew Garrett | [email protected]

Hi Dave,

Sure, I somewhat understand your concerns about the timeout change, but we responded to an email form you over a week ago and never received a reply regarding our viewpoint. It was sent to your personal email address as well as to the public linux-usb list. Please refer to the email titled "[PATCH 5/5] EHCI: fix performance regression" dated Wed, May 21, 2008 at 12:02 PM. In that email, we state that it doesn't make sense to reduce the timeout to 3ms and we still don't have a full understanding of why increasing it to 10 ms is such a bad idea.

While we had initially been discussing this bug with you over private emails, once we lost touch with you, we resolved it in close collaboration with Alan. We have spent many tens of hours working on this bug with Alan. We'd appreciate the ability to stay in the loop with any technical issues pertaining to and arising from the patch, and to have our concerns properly responded to.

-Leonid

The notion that this was a regression came about by mistake. It was stated that 2.6.24 worked better than 2.6.25; apparently that remark was wrong.

Given that the issues are not yet resolved among the developers, I think reverting the patch for now is the best course.

Alan Stern

Ok, will go do so.

thanks,

greg k-h

Linus, I've now reverted one of the usb patches in this tree and pushed it out, so the new diffstat is as follows:

 drivers/usb/core/generic.c         |    5 -
 drivers/usb/core/hcd.h             |    2 +
 drivers/usb/core/hub.c             |   15 ++-
 drivers/usb/core/quirks.c          |    4 +
 drivers/usb/core/sysfs.c           |   44 +++---
 drivers/usb/gadget/fsl_usb2_udc.c  |    2 +
 drivers/usb/host/ehci-au1xxx.c     |    1 +
 drivers/usb/host/ehci-fsl.c        |    7 +-
 drivers/usb/host/ehci-hub.c        |   16 ++-
 drivers/usb/host/ehci-ixp4xx.c     |    4 +-
 drivers/usb/host/ehci-orion.c      |    8 +-
 drivers/usb/host/ehci-pci.c        |    4 +-
 drivers/usb/host/ehci-ppc-of.c     |    2 +
 drivers/usb/host/ehci-ppc-soc.c    |    1 +
 drivers/usb/host/ehci-ps3.c        |    1 +
 drivers/usb/host/ehci-sched.c      |   67 ++++++---
 drivers/usb/host/ehci.h            |    5 +-
 drivers/usb/misc/Kconfig           |   11 ++
 drivers/usb/misc/Makefile          |    1 +
 drivers/usb/misc/isight_firmware.c |  131 ++++++++++++++++++
 drivers/usb/serial/ftdi_sio.c      |  264 +++++++++++++++++++++++++++++++++++-
 drivers/usb/serial/ftdi_sio.h      |  265 +++++++++++++++++++++++++++++++++++-
 drivers/usb/serial/option.c        |   34 +++---
 drivers/usb/serial/pl2303.c        |    1 +
 drivers/usb/serial/pl2303.h        |    1 +
 drivers/usb/storage/unusual_devs.h |   10 +-
 26 files changed, 811 insertions(+), 95 deletions(-)
 create mode 100644 drivers/usb/misc/isight_firmware.c

thanks,

greg k-h

Hi Alan,

Not to be overly pedantic, but you weren't so wrong to be confused on the issue of "regression". Here's the scoop:

1) Kernel versions <= 2.6.24: latency of 2/6/2/6/... uframes pattern observed between packets on the bus for nVIDIA HCs.

2) Kernel versions >= 2.6.26: latency of 8/8/8/8/... uframes pattern observed between packets on the bus for nVIDIA HCs.

3) Post-patch: latency of 1/1/1/1/... uframes on all kernels versions and all HC chipsets.

So basically there was a peripheral issue in the EHCI driver between 2.6.24 and 2.6.25 that exacerbated the problem. But the underlying issue was there long before 2.6.25. Dave is quite right that this isn't technically a "regression."

The issue itself was a bug (as opposed to a "feature" ;-) ) since the original comments in the code clearly had the right intention, but the code itself did not execute as intended in certain situations. In fact, thinking about it now, this issue could even cause significant performance degradation on nVIDIA HCs if one has multiple devices using the bus at any given time. Given this, it might be best to label the patch "USB: EHCI: fix performance issue" instead of using the word regression. But regardless, we are just worrying about symmantics at this point! :)

Hope that helps clarify and put to rest this titling issue once in for all.

-Leonid