linux/drivers/usb, branch v3.3

Revert "powerpc/usb: fix issue of CPU halt when missing USB PHY clock"

2012-03-03T00:08:54Z

This reverts commit 529febeee680dc22416fca033151a5e8bc620447. To quote Dirk: This commit introduces a check for the USB PHY clock. Problem is that CTRL_PHY_CLK_VALID bit seems not to be present on all Freescale ehci implementations, at least P1022 does not have it. So this check always fails and the driver never gets loaded. So we need to revert this patch. Reported-by: Dirk Eibach Cc: Shengzhou Liu Cc: Felipe Balbi Signed-off-by: Greg Kroah-Hartman

USB: Added Kamstrup VID/PIDs to cp210x serial driver.

2012-02-22T00:29:15Z

Signed-off-by: Bruno Thomsen Cc: stable Signed-off-by: Greg Kroah-Hartman

USB: Serial: ti_usb_3410_5052: Add Abbot Diabetes Care cable id

2012-02-22T00:29:15Z

This USB-serial cable with mini stereo jack enumerates as: Bus 001 Device 004: ID 1a61:3410 Abbott Diabetes Care It is a TI3410 inside. Signed-off-by: Andrew Lunn Cc: stable Signed-off-by: Greg Kroah-Hartman

usb-storage: fix freezing of the scanning thread

2012-02-22T00:29:15Z

This patch (as1521b) fixes the interaction between usb-storage's scanning thread and the freezer. The current implementation has a race: If the device is unplugged shortly after being plugged in and just as a system sleep begins, the scanning thread may get frozen before the khubd task. Khubd won't be able to freeze until the disconnect processing is complete, and the disconnect processing can't proceed until the scanning thread finishes, so the sleep transition will fail. The implementation in the 3.2 kernel suffers from an additional problem. There the scanning thread calls set_freezable_with_signal(), and the signals sent by the freezer will mess up the thread's I/O delays, which are all interruptible. The solution to both problems is the same: Replace the kernel thread used for scanning with a delayed-work routine on the system freezable work queue. Freezable work queues have the nice property that you can cancel a work item even while the work queue is frozen, and no signals are needed. The 3.2 version of this patch solves the problem in Bugzilla #42730. Signed-off-by: Alan Stern Acked-by: Seth Forshee CC: stable Signed-off-by: Greg Kroah-Hartman

xhci: Fix encoding for HS bulk/control NAK rate.

2012-02-21T23:48:46Z

The xHCI 0.96 spec says that HS bulk and control endpoint NAK rate must be encoded as an exponent of two number of microframes. The endpoint descriptor has the NAK rate encoded in number of microframes. We were just copying the value from the endpoint descriptor into the endpoint context interval field, which was not correct. This lead to the VIA host rejecting the add of a bulk OUT endpoint from any USB 2.0 mass storage device. The fix is to use the correct encoding. Refactor the code to convert number of frames to an exponential number of microframes, and make sure we convert the number of microframes in HS bulk and control endpoints to an exponent. This should be back ported to kernels as old as 2.6.31, that contain the commit dfa49c4ad120a784ef1ff0717168aa79f55a483a "USB: xhci - fix math in xhci_get_endpoint_interval" Signed-off-by: Sarah Sharp Tested-by: Felipe Contreras Suggested-by: Andiry Xu Cc: stable@vger.kernel.org

USB: Set hub depth after USB3 hub reset

2012-02-21T23:45:25Z

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 Cc: stable@vger.kernel.org

USB: Fix handoff when BIOS disables host PCI device.

2012-02-21T23:45:08Z

On some systems with an Intel Panther Point xHCI host controller, the BIOS disables the xHCI PCI device during boot, and switches the xHCI ports over to EHCI. This allows the BIOS to access USB devices without having xHCI support. The downside is that the xHCI BIOS handoff mechanism will fail because memory mapped I/O is not enabled for the disabled PCI device. Jesse Barnes says this is expected behavior. The PCI core will enable BARs before quirks run, but it will leave it in an undefined state, and it may not have memory mapped I/O enabled. Make the generic USB quirk handler call pci_enable_device() to re-enable MMIO, and call pci_disable_device() once the host-specific BIOS handoff is finished. This will balance the ref counts in the PCI core. When the PCI probe function is called, usb_hcd_pci_probe() will call pci_enable_device() again. This should be back ported to kernels as old as 2.6.31. That was the first kernel with xHCI support, and no one has complained about BIOS handoffs failing due to memory mapped I/O being disabled on other hosts (EHCI, UHCI, or OHCI). Signed-off-by: Sarah Sharp Acked-by: Oliver Neukum Cc: Jesse Barnes Cc: stable@vger.kernel.org

USB: option: cleanup zte 3g-dongle's pid in option.c

2012-02-14T23:08:40Z

1. Remove all old mass-storage ids's pid: 0x0026,0x0053,0x0098,0x0099,0x0149,0x0150,0x0160; 2. As the pid from 0x1401 to 0x1510 which have not surely assigned to use for serial-port or mass-storage port,so i think it should be removed now, and will re-add after it have assigned in future; 3. sort the pid to WCDMA and CDMA. Signed-off-by: Rui li Cc: stable Signed-off-by: Greg Kroah-Hartman

USB: Don't fail USB3 probe on missing legacy PCI IRQ.

2012-02-14T18:48:05Z

Intel has a PCI USB xhci host controller on a new platform. It doesn't have a line IRQ definition in BIOS. The Linux driver refuses to initialize this controller, but Windows works well because it only depends on MSI. Actually, Linux also can work for MSI. This patch avoids the line IRQ checking for USB3 HCDs in usb core PCI probe. It allows the xHCI driver to try to enable MSI or MSI-X first. It will fail the probe if MSI enabling failed and there's no legacy PCI IRQ. This patch should be backported to kernels as old as 2.6.32. Signed-off-by: Alex Shi Signed-off-by: Sarah Sharp Cc: stable@vger.kernel.org

xhci: Fix oops caused by more USB2 ports than USB3 ports.

2012-02-10T22:24:32Z

The code to set the device removable bits in the USB 2.0 roothub descriptor was accidentally looking at the USB 3.0 port registers instead of the USB 2.0 registers. This can cause an oops if there are more USB 2.0 registers than USB 3.0 registers. This should be backported to kernels as old as 2.6.39, that contain the commit 4bbb0ace9a3de8392527e3c87926309d541d3b00 "xhci: Return a USB 3.0 hub descriptor for USB3 roothub." Signed-off-by: Sarah Sharp Cc: stable@vger.kernel.org