linux/drivers/usb/core, branch v3.2.41

USB: Fix connected device switch to Inactive state.

2013-03-20T15:03:38Z

commit d3b9d7a9051d7024a93c76a84b2f84b3b66ad6d5 upstream. A USB 3.0 device can transition to the Inactive state if a U1 or U2 exit transition fails. The current code in hub_events simply issues a warm reset, but does not call any pre-reset or post-reset driver methods (or unbind/rebind drivers without them). Therefore the drivers won't know their device has just been reset. hub_events should instead call usb_reset_device. This means hub_port_reset now needs to figure out whether it should issue a warm reset or a hot reset. Remove the FIXME note about needing disconnect() for a NOTATTACHED device. This patch fixes that. Signed-off-by: Sarah Sharp Acked-by: Alan Stern Signed-off-by: Ben Hutchings

USB: Rip out recursive call on warm port reset.

2013-03-20T15:03:38Z

commit a24a6078754f28528bc91e7e7b3e6ae86bd936d8 upstream. When a hot reset fails on a USB 3.0 port, the current port reset code recursively calls hub_port_reset inside hub_port_wait_reset. This isn't ideal, since we should avoid recursive calls in the kernel, and it also doesn't allow us to issue multiple warm resets on reset failures. Rip out the recursive call. Instead, add code to hub_port_reset to issue a warm reset if the hot reset fails, and try multiple warm resets before giving up on the port. In hub_port_wait_reset, remove the recursive call and re-indent. The code is basically the same, except: 1. It bails out early if the port has transitioned to Inactive or Compliance Mode after the reset completed. 2. It doesn't consider a connect status change to be a failed reset. If multiple warm resets needed to be issued, the connect status may have changed, so we need to ignore that and look at the port link state instead. hub_port_reset will now do that. 3. It unconditionally sets udev->speed on all types of successful resets. The old recursive code would set the port speed when the second hub_port_reset returned. The old code did not handle connected devices needing a warm reset well. There were only two situations that the old code handled correctly: an empty port needing a warm reset, and a hot reset that migrated to a warm reset. When an empty port needed a warm reset, hub_port_reset was called with the warm variable set. The code in hub_port_finish_reset would skip telling the USB core and the xHC host that the device was reset, because otherwise that would result in a NULL pointer dereference. When a USB 3.0 device reset migrated to a warm reset, the recursive call made the call stack look like this: hub_port_reset(warm = false) hub_wait_port_reset(warm = false) hub_port_reset(warm = true) hub_wait_port_reset(warm = true) hub_port_finish_reset(warm = true) (return up the call stack to the first wait) hub_port_finish_reset(warm = false) The old code didn't want to notify the USB core or the xHC host of device reset twice, so it only did it in the second call to hub_port_finish_reset, when warm was set to false. This was necessary because before patch two ("USB: Ignore xHCI Reset Device status."), the USB core would pay attention to the xHC Reset Device command error status, and the second call would always fail. Now that we no longer have the recursive call, and warm can change from false to true in hub_port_reset, we need to have hub_port_finish_reset unconditionally notify the USB core and the xHC of the device reset. In hub_port_finish_reset, unconditionally clear the connect status change (CSC) bit for USB 3.0 hubs when the port reset is done. If we had to issue multiple warm resets for a device, that bit may have been set if the device went into SS.Inactive and then was successfully warm reset. Signed-off-by: Sarah Sharp Acked-by: Alan Stern Signed-off-by: Ben Hutchings

USB: Prepare for refactoring by adding extra udev checks.

2013-03-20T15:03:38Z

commit 2d4fa940f99663c82ba55b2244638833b388e4e2 upstream. The next patch will refactor the hub port code to rip out the recursive call to hub_port_reset on a failed hot reset. In preparation for that, make sure all code paths can deal with being called with a NULL udev. The usb_device will not be valid if warm reset was issued because a port transitioned to the Inactive or Compliance Mode on a device connect. This patch should have no effect on current behavior. Signed-off-by: Sarah Sharp Acked-by: Alan Stern Signed-off-by: Ben Hutchings

USB: Don't use EHCI port sempahore for USB 3.0 hubs.

2013-03-20T15:03:37Z

commit 0fe51aa5eee51db7c7ecd201d42a977ad79c58b6 upstream. The EHCI host controller needs to prevent EHCI initialization when the UHCI or OHCI companion controller is in the middle of a port reset. It uses ehci_cf_port_reset_rwsem to do this. USB 3.0 hubs can't be under an EHCI host controller, so it makes no sense to down the semaphore for USB 3.0 hubs. It also makes the warm port reset code more complex. Don't down ehci_cf_port_reset_rwsem for USB 3.0 hubs. Signed-off-by: Sarah Sharp Acked-by: Alan Stern Signed-off-by: Ben Hutchings

usb: Add USB_QUIRK_RESET_RESUME for all Logitech UVC webcams

2013-03-06T03:24:26Z

commit e387ef5c47ddeaeaa3cbdc54424cdb7a28dae2c0 upstream. Most Logitech UVC webcams (both early models that don't advertise UVC compatibility and newer UVC-advertised devices) require the RESET_RESUME quirk. Instead of listing each and every model, match the devices based on the UVC interface information. Signed-off-by: Laurent Pinchart Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman [bwh: Adjust context to apply after 3.2.38] Signed-off-by: Ben Hutchings

usb: Add quirk detection based on interface information

2013-03-06T03:24:25Z

commit 80da2e0df5af700518611b7d1cc4fc9945bcaf95 upstream. When a whole class of devices (possibly from a specific vendor, or across multiple vendors) require a quirk, explictly listing all devices in the class make the quirks table unnecessarily large. Fix this by allowing matching devices based on interface information. Signed-off-by: Laurent Pinchart Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings

USB: Add device quirk for Microsoft VX700 webcam

2013-02-06T04:33:32Z

commit bc009eca8d539162f7271c2daf0ab5e9e3bb90a0 upstream. Add device quirk for Microsoft Lifecam VX700 v2.0 webcams. Fixes squeaking noise of the microphone. Signed-off-by: Andreas Fleig Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

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

2013-02-06T04:33:31Z

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 Signed-off-by: Ben Hutchings

USB: Handle warm reset failure on empty port.

2013-02-06T04:33:22Z

commit 65bdac5effd15d6af619b3b7218627ef4d84ed6a upstream. An empty port can transition to either Inactive or Compliance Mode if a newly connected USB 3.0 device fails to link train. In that case, we issue a warm reset. Some devices, such as John's Roseweil eusb3 enclosure, slip back into Compliance Mode after the warm reset. The current warm reset code does not check for device connect status on warm reset completion, and it incorrectly reports the warm reset succeeded. This causes the USB core to attempt to send a Set Address control transfer to a port in Compliance Mode, which will always fail. Make hub_port_wait_reset check the current connect status and link state after the warm reset completes. Return a failure status if the device is disconnected or the link state is Compliance Mode or SS.Inactive. Make hub_events disable the port if warm reset fails. This will disable the port, and then bring it back into the RxDetect state. Make the USB core ignore the connect change until the device reconnects. Note that this patch does NOT handle connected devices slipping into the Inactive state very well. This is a concern, because devices can go into the Inactive state on U1/U2 exit failure. However, the fix for that case is too large for stable, so it will be submitted in a separate patch. This patch should be backported to kernels as old as 3.2, contain the commit ID 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm reset logic" Signed-off-by: Sarah Sharp Acked-by: Alan Stern Reported-by: John Covici Signed-off-by: Ben Hutchings

USB: Ignore port state until reset completes.

2013-02-06T04:33:21Z

commit 4f43447e62b37ee19c82a13f72f35b1ca60a74d3 upstream. The port reset code bails out early if the current connect status is cleared (device disconnected). If we're issuing a hot reset, it may also look at the link state before the reset is finished. Section 10.14.2.6 of the USB 3.0 spec says that when a port enters the Error state or Resetting state, the port connection bit retains the value from the previous state. Therefore we can't trust it until the reset finishes. Also, the xHCI spec section 4.19.1.2.5 says software shall ignore the link state while the port is resetting, as it can be in an unknown state. The port state during reset is also unknown for USB 2.0 hubs. The hub sends a reset signal by driving the bus into an SE0 state. This overwhelms the "connect" signal from the device, so the port can't tell whether anything is connected or not. Fix the port reset code to ignore the port link state and current connect bit until the reset finishes, and USB_PORT_STAT_RESET is cleared. Remove the check for USB_PORT_STAT_C_BH_RESET in the warm reset case, because it's redundant. When the warm reset finishes, the port reset bit will be cleared at the same time USB_PORT_STAT_C_BH_RESET is set. Remove the now-redundant check for a cleared USB_PORT_STAT_RESET bit in the code to deal with the finished reset. This patch should be backported to all stable kernels. Signed-off-by: Sarah Sharp Acked-by: Alan Stern Signed-off-by: Ben Hutchings