linux-toradex.git/drivers/usb/core, branch v3.2.44

USB: xhci: correctly enable interrupts

2013-03-27T02:41:15+00:00

commit 00eed9c814cb8f281be6f0f5d8f45025dc0a97eb upstream.

xhci has its own interrupt enabling routine, which will try to
use MSI-X/MSI if present. So the usb core shouldn't try to enable
legacy interrupts; on some machines the xhci legacy IRQ setting
is invalid.

v3: Be careful to not break XHCI_BROKEN_MSI workaround (by trenn)

Cc: Bjorn Helgaas 
Cc: Oliver Neukum 
Cc: Thomas Renninger 
Cc: Yinghai Lu 
Cc: Frederik Himpe 
Cc: David Haerdeman 
Cc: Alan Stern 
Acked-by: Sarah Sharp 
Reviewed-by: Thomas Renninger 
Signed-off-by: Hannes Reinecke 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

USB: Fix connected device switch to Inactive state.

2013-03-20T15:03:38+00:00

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:38+00:00

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:38+00:00

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:37+00:00

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:26+00:00

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:25+00:00

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:32+00:00

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

USB: Handle warm reset failure on empty port.

2013-02-06T04:33:22+00:00

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