linux-toradex.git/drivers/usb/host, branch v2.6.27.13

USB: isp1760: use a specific PLX bridge instead of any bdridge

2009-01-18T18:35:29+00:00

commit 6c0735687d37e25a65866823881bcbf39a6a023f upstream.

this driver can't handle (of course) any brdige class devices. So we
now are just active on one specific bridge which should be only the
isp1761 chip behind a PLX bridge.

Signed-off-by: Sebastian Andrzej Siewior 
Tested-by: Karl Bongers 
Signed-off-by: Greg Kroah-Hartman

USB: fix SB600 USB subsystem hang bug

2008-12-05T18:55:09+00:00

commit 0a99e8ac430a27825bd055719765fd0d65cd797f upstream.

This patch is required for all AMD SB600 revisions to avoid USB subsystem hang
symptom. The USB subsystem hang symptom is observed when the system has
multiple USB devices connected to it. In some cases a USB hub may be required
to observe this symptom.

Reported in bugzilla as #11599, the similar patch for SB700 old revision is:
commit b09bc6cbae4dd3a2d35722668ef2c502a7b8b093

Reported-by: raffaele 
Tested-by: Roman Mamedov 
Signed-off-by: Shane Huang 
Signed-off-by: Greg Kroah-Hartman

USB: fix SB700 usb subsystem hang bug

2008-12-05T18:55:09+00:00

commit b09bc6cbae4dd3a2d35722668ef2c502a7b8b093 upstream.

This patch is required for AMD SB700 south bridge revision A12 and A13 to avoid
USB subsystem hang symptom. The USB subsystem hang symptom is observed when the
system has multiple USB devices connected to it. In some cases a USB hub may be
required to observe this symptom.

This patch works around the problem by correcting the internal register setting
that will help by changing the behavior of the internal logic to avoid the
USB subsystem hang issue. The change in the behavior of the logic does not
impact the normal operation of the USB subsystem.

Reported-by: Volker Armin Hemmann 
Tested-by: Volker Armin Hemmann 
Signed-off-by: Andiry Xu 
Signed-off-by: Libin Yang 
Signed-off-by: Greg Kroah-Hartman

USB: EHCI: fix handling of dead controllers

2008-11-20T22:54:52+00:00

commit 67b2e029743a52670d77864723b4d0d40f7733b5 upstream.

This patch (as1165) makes a few small changes in the logic used by
ehci-hcd when it encounters a controller error:

	Instead of printing out the masked status, it prints the
	original status as read directly from the hardware.

	It doesn't check for the STS_HALT status bit before taking
	action.  The mere fact that the STS_FATAL bit is set means
	that something bad has happened and the controller needs to
	be reset.  With the old code this test could never succeed
	because the STS_HALT bit was masked out from the status.

I anticipate that this will prevent the occasional "irq X: nobody cared"
problem people encounter when their EHCI controllers die.

Signed-off-by: Alan Stern 
Cc: David Brownell 
Signed-off-by: Greg Kroah-Hartman

USB: EHCI: fix divide-by-zero bug

2008-11-20T22:54:52+00:00

commit 372dd6e8ed924e876f3beb598721e813ad7fa323 upstream.

This patch (as1164) fixes a bug in the EHCI scheduler.  The interval
value it uses is already in linear format, not logarithmically coded.
The existing code can sometimes crash the system by trying to divide
by zero.

Signed-off-by: Alan Stern 
Cc: David Brownell 
Signed-off-by: Greg Kroah-Hartman

USB: Fix PS3 USB shutdown problems

2008-11-20T22:54:52+00:00

commit ddcb01ff9bf49c4dbbb058423559f7bc90b89374 upstream.

Add ehci_shutdown() or ohci_shutdown() calls to the USB
PS3 bus glue.  ehci_shutdown() and ohci_shutdown() do some
controller specific cleanups not done by usb_remove_hcd().

Fixes errors on shutdown or reboot similar to these:

  ps3-ehci-driver sb_07: HC died; cleaning up
  irq 51: nobody cared (try booting with the "irqpoll" option)

Related bugzilla reports:

  http://bugzilla.kernel.org/show_bug.cgi?id=11819
  http://bugzilla.terrasoftsolutions.com/show_bug.cgi?id=317

Signed-off-by: Geoff Levand 
Signed-off-by: Greg Kroah-Hartman

USB: remove optional bus bindings in isp1760, fixing runtime warning

2008-11-20T22:54:51+00:00

commit ff30bf1ca4b548c0928dae6bfce89458b95e5bf4 upstream.

Roland Reported the following:
| kmem_cache_create: duplicate cache isp1760_qtd
| Pid: 461, comm: modprobe Tainted: G        W  2.6.28-rc2-git3-default #4
| Call Trace:
|  [] kmem_cache_create+0xc9/0x3a3
|  [] free_pages_bulk+0x16c/0x1c9
|  [] isp1760_init+0x0/0xb [isp1760]
|  [] init_kmem_once+0x18/0x5f [isp1760]
|  [] isp1760_init+0x5/0xb [isp1760]
|  [] _stext+0x4d/0x148
|  [] load_module+0x12cd/0x142e
|  [] kmem_cache_destroy+0x0/0xd7
|  [] sys_init_module+0x87/0x176
|  [] sysenter_do_call+0x12/0x2f

The reason, is that ret is initialized with ENODEV instead of 0 _or_
the kmem cache is not freed in error case with no bus binding.

The difference between OF+PCI and OF only is
| 15148     804      32   15984    3e70 isp1760-of-pci.o
| 13748     676       8   14432    3860 isp1760-of.o

about 1.5 KiB.

Until there is a checkbox where the user *must* select atleast one item,
and may select multiple entries I don't make it selectable anymore.
Having a driver which can't be used under any circumstances is broken
anyway and I've seen distros shipping it that way.

Reported-by: Roland Kletzing 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Greg Kroah-Hartman

USB: EHCI: log a warning if ehci-hcd is not loaded first

2008-10-22T21:21:22+00:00

commit 9beeee6584b9aa4f9192055512411484a2a624df upstream

This patch (as1139) adds a warning to the system log whenever ehci-hcd
is loaded after ohci-hcd or uhci-hcd.  Nowadays most distributions are
pretty good about not doing this; maybe the warning will help convince
anyone still doing it wrong.

Signed-off-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

USB: OHCI: fix endless polling behavior

2008-10-22T21:21:19+00:00

commit 71b7497c078a97e2afb774ad7c1f8ff5bdda8a60 upstream

This patch (as1149) fixes an obscure problem in OHCI polling.  In the
current code, if the RHSC interrupt status flag turns on at a time
when RHSC interrupts are disabled, it will remain on forever:

	The interrupt handler is the only place where RHSC status
	gets turned back off;

	The interrupt handler won't turn RHSC status off because it
	doesn't turn off status flags if the corresponding interrupt
	isn't enabled;

	RHSC interrupts will never get enabled because
	ohci_root_hub_state_changes() doesn't reenable RHSC if RHSC
	status is on!

As a result we will continue polling indefinitely instead of reverting
to interrupt-driven operation, and the root hub will not autosuspend.
This particular sequence of events is not at all unusual; in fact
plugging a USB device into an OHCI controller will usually cause it to
occur.

Of course, this is a bug.  The proper thing to do is to turn off RHSC
status just before reading the actual port status values.  That way
either a port status change will be detected (if it occurs before the
status read) or it will turn RHSC back on.  Possibly both, but that
won't hurt anything.

We can still check for systems in which RHSC is totally broken, by
re-reading RHSC after clearing it and before reading the port
statuses.  (This re-read has to be done anyway, to post the earlier
write.)  If RHSC is on but no port-change statuses are set, then we
know that RHSC is broken and we can avoid re-enabling it.

Signed-off-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

OHCI: Allow broken controllers to auto-stop

2008-10-22T21:21:17+00:00

commit 4a511bc3f5829bc18428bcf11c25417a79d09396 upstream

This patch (as1134) attempts to improve the way we handle OHCI
controllers with broken Root Hub Status Change interrupt support.  In
these controllers the RHSC interrupt bit essentially never turns off,
making RHSC interrupts useless -- they have to remain permanently
disabled.

Such controllers should still be allowed to turn off their root hubs
when no devices are attached.  Polling for new connections can
continue while the root hub is suspended.  The patch implements this
feature.  (It won't have much effect unless CONFIG_PM is enabled and
CONFIG_USB_SUSPEND is disabled, but since the overhead is very small
we may as well do it.)

Signed-off-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman