linux-toradex.git/drivers/usb/core/hub.c, branch v3.0.68

USB: hub: handle claim of enabled remote wakeup after reset

2013-01-17T16:44:12+00:00

commit 07e72b95f5038cc82304b9a4a2eb7f9fc391ea68 upstream.

Some touchscreens have buggy firmware which claims
remote wakeup to be enabled after a reset. They nevertheless
crash if the feature is cleared by the host.
Add a check for reset resume before checking for
an enabled remote wakeup feature. On compliant
devices the feature must be cleared after a reset anyway.

Signed-off-by: Oliver Neukum 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

USB: Increase reset timeout.

2013-01-17T16:44:12+00:00

commit 77c7f072c87fa951e9a74805febf26466f31170c upstream.

John's NEC 0.96 xHCI host controller needs a longer timeout for a warm
reset to complete.  The logs show it takes 650ms to complete the warm
reset, so extend the hub reset timeout to 800ms to be on the safe side.

This commit should be backported to kernels as old as 3.2, that contain
the commit 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine
warm reset logic".

Signed-off-by: Sarah Sharp 
Acked-by: Alan Stern 
Reported-by: John Covici 
Signed-off-by: Greg Kroah-Hartman

usb hub: send clear_tt_buffer_complete events when canceling TT clear work

2012-10-31T16:51:35+00:00

commit 3b6054da68f9b0d5ed6a7ed0f42a79e61904352c upstream.

There is a race condition in the USB hub code with regard to handling
TT clear requests that can get the HCD driver in a deadlock. Usually
when an TT clear request is scheduled it will be executed immediately:

<7>[    6.077583] usb 2-1.3: unlink qh1-0e01/f4d4db00 start 0 [1/2 us]
<3>[    6.078041] usb 2-1: clear tt buffer port 3, a3 ep2 t04048d82
<7>[    6.078299] hub_tt_work:731
<7>[    9.309089] usb 2-1.5: link qh1-0e01/f4d506c0 start 0 [1/2 us]
<7>[    9.324526] ehci_hcd 0000:00:1d.0: reused qh f4d4db00 schedule
<7>[    9.324539] usb 2-1.3: link qh1-0e01/f4d4db00 start 0 [1/2 us]
<7>[    9.341530] usb 1-1.1: link qh4-0e01/f397aec0 start 2 [1/2 us]
<7>[   10.116159] usb 2-1.3: unlink qh1-0e01/f4d4db00 start 0 [1/2 us]
<3>[   10.116459] usb 2-1: clear tt buffer port 3, a3 ep2 t04048d82
<7>[   10.116537] hub_tt_work:731

However, if a suspend operation is triggered before hub_tt_work is
scheduled, hub_quiesce will cancel the work without notifying the HCD
driver:

<3>[   35.033941] usb 2-1: clear tt buffer port 3, a3 ep2 t04048d80
<5>[   35.034022] sd 0:0:0:0: [sda] Stopping disk
<7>[   35.034039] hub 2-1:1.0: hub_suspend
<7>[   35.034067] usb 2-1: unlink qh256-0001/f3b1ab00 start 1 [1/0 us]
<7>[   35.035085] hub 1-0:1.0: hub_suspend
<7>[   35.035102] usb usb1: bus suspend, wakeup 0
<7>[   35.035106] ehci_hcd 0000:00:1a.0: suspend root hub
<7>[   35.035298] hub 2-0:1.0: hub_suspend
<7>[   35.035313] usb usb2: bus suspend, wakeup 0
<7>[   35.035315] ehci_hcd 0000:00:1d.0: suspend root hub
<6>[   35.250017] PM: suspend of devices complete after 216.979 msecs
<6>[   35.250822] PM: late suspend of devices complete after 0.799 msecs
<7>[   35.252343] ehci_hcd 0000:00:1d.0: wakeup: 1
<7>[   35.262923] ehci_hcd 0000:00:1d.0: --> PCI D3hot
<7>[   35.263302] ehci_hcd 0000:00:1a.0: wakeup: 1
<7>[   35.273912] ehci_hcd 0000:00:1a.0: --> PCI D3hot
<6>[   35.274254] PM: noirq suspend of devices complete after 23.442 msecs
<6>[   35.274975] ACPI: Preparing to enter system sleep state S3
<6>[   35.292666] PM: Saving platform NVS memory
<7>[   35.295030] Disabling non-boot CPUs ...
<6>[   35.297351] CPU 1 is now offline
<6>[   35.300345] CPU 2 is now offline
<6>[   35.303929] CPU 3 is now offline
<7>[   35.303931] lockdep: fixing up alternatives.
<6>[   35.304825] Extended CMOS year: 2000

When the device will resume the EHCI driver will get stuck in
ehci_endpoint_disable waiting for the tt_clearing flag to reset:

<0>[   47.610967] usb 2-1.3: **** DPM device timeout ****
<7>[   47.610972]  f2f11c60 00000092 f2f11c0c c10624a5 00000003 f4c6e880 c1c8a4c0 c1c8a4c0
<7>[   47.610983]  15c55698 0000000b f56b34c0 f2a45b70 f4c6e880 00000082 f2a4602c f2f11c30
<7>[   47.610993]  c10787f8 f4cac000 f2a45b70 00000000 f4cac010 f2f11c58 00000046 00000001
<7>[   47.611004] Call Trace:
<7>[   47.611006]  [] ? sched_clock_cpu+0xf5/0x160
<7>[   47.611019]  [] ? lock_release_holdtime.part.22+0x88/0xf0
<7>[   47.611026]  [] ? lock_timer_base.isra.35+0x26/0x50
<7>[   47.611034]  [] ? schedule_timeout+0x133/0x290
<7>[   47.611044]  [] schedule+0x1e/0x50
<7>[   47.611051]  [] schedule_timeout+0x138/0x290
<7>[   47.611057]  [] ? sched_clock_cpu+0xf5/0x160
<7>[   47.611063]  [] ? usleep_range+0x40/0x40
<7>[   47.611070]  [] schedule_timeout_uninterruptible+0x15/0x20
<7>[   47.611077]  [] ehci_endpoint_disable+0x64/0x160
<7>[   47.611084]  [] ? usb_hcd_flush_endpoint+0x10e/0x1d0
<7>[   47.611092]  [] ? sysfs_add_file+0x13/0x20
<7>[   47.611100]  [] usb_hcd_disable_endpoint+0x29/0x40
<7>[   47.611107]  [] usb_disable_endpoint+0x5c/0x80
<7>[   47.611111]  [] usb_disable_interface+0x37/0x50
<7>[   47.611116]  [] usb_reset_and_verify_device+0x4b0/0x640
<7>[   47.611122]  [] ? hub_port_status+0xb5/0x100
<7>[   47.611129]  [] usb_port_resume+0xd5/0x220
<7>[   47.611136]  [] generic_resume+0xf/0x30
<7>[   47.611142]  [] usb_resume+0x133/0x180
<7>[   47.611147]  [] ? usb_dev_thaw+0x10/0x10
<7>[   47.611152]  [] usb_dev_resume+0xd/0x10
<7>[   47.611157]  [] dpm_run_callback+0x40/0xb0
<7>[   47.611164]  [] ? pm_runtime_enable+0x43/0x70
<7>[   47.611171]  [] device_resume+0x1a6/0x2c0
<7>[   47.611177]  [] ? dpm_show_time+0xe0/0xe0
<7>[   47.611183]  [] async_resume+0x19/0x40
<7>[   47.611189]  [] async_run_entry_fn+0x64/0x160
<7>[   47.611196]  [] ? process_one_work+0x104/0x480
<7>[   47.611203]  [] ? process_one_work+0x10c/0x480
<7>[   47.611209]  [] process_one_work+0x180/0x480
<7>[   47.611215]  [] ? process_one_work+0x104/0x480
<7>[   47.611220]  [] ? async_schedule+0x10/0x10
<7>[   47.611226]  [] worker_thread+0x11c/0x2f0
<7>[   47.611233]  [] ? manage_workers.isra.27+0x1f0/0x1f0
<7>[   47.611239]  [] kthread+0x78/0x80
<7>[   47.611244]  [] ? timer_cpu_notify+0xd6/0x20d
<7>[   47.611253]  [] ? __init_kthread_worker+0x60/0x60
<7>[   47.611258]  [] kernel_thread_helper+0x6/0xd
<7>[   47.611283] ------------[ cut here ]------------

This patch changes hub_quiesce behavior to flush the TT clear work
instead of canceling it, to make sure that no TT clear request remains
uncompleted before suspend.

Signed-off-by: Octavian Purdila 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

usb: feed USB device information to the /dev/random driver

2012-08-15T19:04:12+00:00

commit b04b3156a20d395a7faa8eed98698d1e17a36000 upstream.

Send the USB device's serial, product, and manufacturer strings to the
/dev/random driver to help seed its pools.

Cc: Linus Torvalds 
Acked-by: Greg KH 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Greg Kroah-Hartman

USB: fix deadlock in bConfigurationValue attribute method

2012-04-27T16:51:08+00:00

commit 8963c487a80b4688c9e68dcc504a90074aacc145 upstream.

This patch (as154) fixes a self-deadlock that occurs when userspace
writes to the bConfigurationValue sysfs attribute for a hub with
children.  The task tries to lock the bandwidth_mutex at a time when
it already owns the lock:

	The attribute's method calls usb_set_configuration(),
	which calls usb_disable_device() with the bandwidth_mutex
	held.

	usb_disable_device() unregisters the existing interfaces,
	which causes the hub driver to be unbound.

	The hub_disconnect() routine calls hub_quiesce(), which
	calls usb_disconnect() for each of the hub's children.

	usb_disconnect() attempts to acquire the bandwidth_mutex
	around a call to usb_disable_device().

The solution is to make usb_disable_device() acquire the mutex for
itself instead of requiring the caller to hold it.  Then the mutex can
cover only the bandwidth deallocation operation and not the region
where the interfaces are unregistered.

This has the potential to change system behavior slightly when a
config change races with another config or altsetting change.  Some of
the bandwidth released from the old config might get claimed by the
other config or altsetting, make it impossible to restore the old
config in case of a failure.  But since we don't try to recover from
config-change failures anyway, this doesn't matter.

[This should be marked for stable kernels that contain the commit
fccf4e86200b8f5edd9a65da26f150e32ba79808 "USB: Free bandwidth when
usb_disable_device is called."
That commit was marked for stable kernels as old as 2.6.32.]

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

USB: Set hub depth after USB3 hub reset

2012-03-01T00:34:22+00:00

commit a45aa3b30583e7d54e7cf4fbcd0aa699348a6e5c upstream.

The superspeed device attached to a USB 3.0 hub(such as VIA's)
doesn't respond the address device command after resume. The
root cause is the superspeed hub will miss the Hub Depth value
that is used as an offset into the route string to locate the
bits it uses to determine the downstream port number after
reset, and all packets can't be routed to the device attached
to the superspeed hub.

Hub driver sends a Set Hub Depth request to the superspeed hub
except for USB 3.0 root hub when the hub is initialized and
doesn't send the request again after reset due to the resume
process. So moving the code that sends the Set Hub Depth request
to the superspeed hub from hub_configure() to hub_activate()
is to cover those situations include initialization and reset.

The patch should be backported to kernels as old as 2.6.39.

Signed-off-by: Elric Fu 
Signed-off-by: Sarah Sharp 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

usb, xhci: Clear warm reset change event during init

2011-11-26T17:10:00+00:00

commit 79c3dd8150fd5236d95766a9e662e3e932b462c9 upstream.

I noticed on my Panther Point system that I wasn't getting hotplug events
for my usb3.0 disk on a usb3 port.  I tracked it down to the fact that the
system had the warm reset change bit still set.  This seemed to block future
events from being received, including a hotplug event.

Clearing this bit during initialization allowed the hotplug event to be
received and the disk to be recognized correctly.

This patch should be backported to kernels as old as 2.6.39.

Signed-off-by: Don Zickus 
Signed-off-by: Sarah Sharp 
Signed-off-by: Greg Kroah-Hartman

Merge branch 'for-usb-linus' of git+ssh://master.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus

2011-06-27T20:36:47+00:00

* 'for-usb-linus' of git+ssh://master.kernel.org/pub/scm/linux/kernel/git/sarah/xhci:
  USB: Fix up URB error codes to reflect implementation.
  xhci: Always set urb->status to zero for isoc endpoints.
  xhci: Add reset on resume quirk for asrock p67 host
  xHCI 1.0: Incompatible Device Error
  xHCI 1.0: Force Stopped Event(FSE)
  xhci: Don't warn about zeroed bMaxBurst descriptor field.
  USB: Free bandwidth when usb_disable_device is called.
  xhci: Reject double add of active endpoints.

USB: don't let the hub driver prevent system sleep

2011-06-16T00:44:56+00:00

This patch (as1465) continues implementation of the policy that errors
during suspend or hibernation should not prevent the system from going
to sleep.

In this case, failure to turn on the Suspend feature for a hub port
shouldn't be reported as an error.  There are situations where this
does actually occur (such as when the device plugged into that port
was disconnected in the recent past), and it turns out to be harmless.
There's no reason for it to prevent a system sleep.

Also, don't allow the hub driver to fail a system suspend if the
downstream ports aren't all suspended.  This is also harmless (and
should never happen, given the change mentioned above); printing a
warning message in the kernel log is all we really need to do.

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

USB: Free bandwidth when usb_disable_device is called.

2011-06-15T21:05:18+00:00

Tanya ran into an issue when trying to switch a UAS device from the BOT
configuration to the UAS configuration via the bConfigurationValue sysfs
file.  Before installing the UAS configuration, set_bConfigurationValue()
calls usb_disable_device().  That function is supposed to remove all host
controller resources associated with that device, but it leaves some state
in the xHCI host controller.

Commit 0791971ba8fbc44e4f476079f856335ed45e6324
	usb: allow drivers to use allocated bandwidth until unbound
added a call to usb_disable_device() in usb_set_configuration(), before
the xHCI bandwidth functions were invoked.  That commit fixed a bug, but
also introduced a bug that is triggered when a configured device is
switched to a new configuration.

usb_disable_device() goes through all the motions of unbinding the drivers
attached to active interfaces and removing the USB core structures
associated with those interfaces, but it doesn't actually remove the
endpoints from the internal xHCI host controller bandwidth structures.

When usb_disable_device() calls usb_disable_endpoint() with reset_hardware
set to true, the entries in udev->ep_out and udev->ep_in will be set to
NULL.  Usually, when the USB core installs a new configuration,
usb_hcd_alloc_bandwidth() will drop all non-NULL endpoints in udev->ep_out
and udev->ep_in before adding any new endpoints.  However, when the new
UAS configuration was added, all those entries were null, so none of the
old endpoints in the BOT configuration were dropped.

The xHCI driver blindly added the UAS configuration endpoints, and some of
the endpoint addresses overlapped with the old BOT configuration
endpoints.  This caused the xHCI host to reject the Configure Endpoint
command.  Now that the xHCI driver code is cleaned up to reject a
double-add of active endpoints, we need to fix the USB core to properly
drop old endpoints in usb_disable_device().

If the host controller driver needs bandwidth checking support, make
usb_disable_device() call usb_disable_endpoint() with
reset_hardware set to false, drop the endpoints from the xHCI host
controller, and then call usb_disable_endpoint() again with
reset_hardware set to true.

The first call to usb_disable_endpoint() will cancel any pending URBs and
wait on them to be freed in usb_hcd_disable_endpoint(), but will keep the
pointers in udev->ep_out and udev->ep in intact.  Then
usb_hcd_alloc_bandwidth() will use those pointers to know which endpoints
to drop.

The final call to usb_disable_endpoint() will do two things:

1. It will call usb_hcd_disable_endpoint() again, which should be harmless
since the ep->urb_list should be empty after the first call to
usb_disable_endpoint() returns.

2. It will set the entries in udev->ep_out and udev->ep in to NULL, and call
usb_hcd_disable_endpoint().  That call will have no effect, since the xHCI
driver doesn't set the endpoint_disable function pointer.

Note that usb_disable_device() will now need to be called with
hcd->bandwidth_mutex held.

This should be backported to kernels as old as 2.6.32.

Signed-off-by: Sarah Sharp 
Reported-by: Tanya Brokhman 
Cc: ablay@codeaurora.org
Cc: Alan Stern 
Cc: stable@kernel.org