linux/drivers/usb/host, branch v2.6.32.54

USB: whci-hcd: fix endian conversion in qset_clear()

2011-12-09T17:21:43Z

commit 8746c83d538cab273d335acb2be226d096f4a5af upstream. qset->qh.link is an __le64 field and we should be using cpu_to_le64() to fill it. Signed-off-by: Dan Carpenter Signed-off-by: Greg Kroah-Hartman

QE/FHCI: fixed the CONTROL bug

2011-11-07T20:32:22Z

commit 273d23574f9dacd9c63c80e7d63639a669aad441 upstream. For USB CONTROL transaction, when the data length is zero, the IN package is needed to finish this transaction in status stage. Signed-off-by: Jerry Huang Signed-off-by: Greg Kroah-Hartman

xhci-mem.c: Check for ring->first_seg != NULL

2011-11-07T20:32:15Z

commit 0e6c7f746ea99089fb3263709075c20485a479ae upstream. There are 2 situations wherein the xhci_ring* might not get freed: - When xhci_ring_alloc() -> xhci_segment_alloc() returns NULL and we goto the fail: label in xhci_ring_alloc. In this case, the ring will not get kfreed. - When the num_segs argument to xhci_ring_alloc is passed as 0 and we try to free the rung after that. ( This doesn't really happen as of now in the code but we seem to be entertaining num_segs=0 in xhci_ring_alloc ) This should be backported to kernels as old as 2.6.31. Signed-off-by: Kautuk Consul Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman

USB: EHCI: Do not rely on PORT_SUSPEND to stop USB resuming in ehci_bus_resume().

2011-11-07T20:31:47Z

commit d0f2fb2500b1c5fe4967eb45d8c9bc758d7aef80 upstream. From EHCI Spec p.28 HC should clear PORT_SUSPEND when SW clears PORT_RESUME. In Intel Oaktrail platform, MPH (Multi-Port Host Controller) core clears PORT_SUSPEND directly when SW sets PORT_RESUME bit. If we rely on PORT_SUSPEND bit to stop USB resume, we will miss the action of clearing PORT_RESUME. This will cause unexpected long resume signal on USB bus. Signed-off-by: Wang Zhi Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

USB: xhci: fix OS want to own HC

2011-08-29T21:08:01Z

commit 6768458b17f9bf48a4c3a34e49b20344091b5f7e upstream. Software should set XHCI_HC_OS_OWNED bit to request ownership of xHC. This patch should be backported to kernels as far back as 2.6.31. Signed-off-by: JiSheng Zhang Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman

EHCI: fix direction handling for interrupt data toggles

2011-08-08T17:23:14Z

commit e04f5f7e423018bcec84c11af2058cdce87816f3 upstream. This patch (as1480) fixes a rather obscure bug in ehci-hcd. The qh_update() routine needs to know the number and direction of the endpoint corresponding to its QH argument. The number can be taken directly from the QH data structure, but the direction isn't stored there. The direction is taken instead from the first qTD linked to the QH. However, it turns out that for interrupt transfers, qh_update() gets called before the qTDs are linked to the QH. As a result, qh_update() computes a bogus direction value, which messes up the endpoint toggle handling. Under the right combination of circumstances this causes usb_reset_endpoint() not to work correctly, which causes packets to be dropped and communications to fail. Now, it's silly for the QH structure not to have direct access to all the descriptor information for the corresponding endpoint. Ultimately it may get a pointer to the usb_host_endpoint structure; for now, adding a copy of the direction flag solves the immediate problem. This allows the Spyder2 color-calibration system (a low-speed USB device that sends all its interrupt data packets with the toggle set to 0 and hance requires constant use of usb_reset_endpoint) to work when connected through a high-speed hub. Thanks to Graeme Gill for supplying the hardware that allowed me to track down this bug. Signed-off-by: Alan Stern Reported-by: Graeme Gill Signed-off-by: Greg Kroah-Hartman

EHCI: only power off port if over-current is active

2011-08-08T17:23:14Z

commit 81463c1d707186adbbe534016cd1249edeab0dac upstream. MAX4967 USB power supply chip we use on our boards signals over-current when power is not enabled; once it's enabled, over-current signal returns to normal. That unfortunately caused the endless stream of "over-current change on port" messages. The EHCI root hub code reacts on every over-current signal change with powering off the port -- such change event is generated the moment the port power is enabled, so once enabled the power is immediately cut off. I think we should only cut off power when we're seeing the active over-current signal, so I'm adding such check to that code. I also think that the fact that we've cut off the port power should be reflected in the result of GetPortStatus request immediately, hence I'm adding a PORTSCn register readback after write... Signed-off-by: Sergei Shtylyov Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

USB: OHCI: fix another regression for NVIDIA controllers

2011-08-08T17:23:09Z

commit 6ea12a04d295235ed67010a09fdea58c949e3eb0 upstream. The NVIDIA series of OHCI controllers continues to be troublesome. A few people using the MCP67 chipset have reported that even with the most recent kernels, the OHCI controller fails to handle new connections and spams the system log with "unable to enumerate USB port" messages. This is different from the other problems previously reported for NVIDIA OHCI controllers, although it is probably related. It turns out that the MCP67 controller does not like to be kept in the RESET state very long. After only a few seconds, it decides not to work any more. This patch (as1479) changes the PCI initialization quirk code so that NVIDIA controllers are switched into the SUSPEND state after 50 ms of RESET. With no interrupts enabled and all the downstream devices reset, and thus unable to send wakeup requests, this should be perfectly safe (even for non-NVIDIA hardware). The removal code in ohci-hcd hasn't been changed; it will still leave the controller in the RESET state. As a result, if someone unloads ohci-hcd and then reloads it, the controller won't work again until the system is rebooted. If anybody complains about this, the removal code can be updated similarly. This fixes Bugzilla #22052. Tested-by: Larry Finger Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

xhci: Reject double add of active endpoints.

2011-07-13T03:29:23Z

commit fa75ac379e63c2864e9049b5e8615e40f65c1e70 upstream. While trying to switch a UAS device from the BOT configuration to the UAS configuration via the bConfigurationValue file, Tanya ran into an issue in the USB core. usb_disable_device() sets entries in udev->ep_out and udev->ep_out to NULL, but doesn't call into the xHCI bandwidth management functions to remove the BOT configuration endpoints from the xHCI host's internal structures. The USB core would then attempt to add endpoints for the UAS configuration, and some of the endpoints had the same address as endpoints in the BOT configuration. The xHCI driver blindly added the endpoints again, but the xHCI host controller rejected the Configure Endpoint command because active endpoints were added without being dropped. Make the xHCI driver reject calls to xhci_add_endpoint() that attempt to add active endpoints without first calling xhci_drop_endpoint(). This should be backported to kernels as old as 2.6.31. Signed-off-by: Sarah Sharp Reported-by: Tanya Brokhman Signed-off-by: Greg Kroah-Hartman

USB: xhci - fix interval calculation for FS isoc endpoints

2011-06-23T22:24:07Z

commit cd3c18ba2fac14b34d03cae111f215009735ea06 upstream. Full-speed isoc endpoints specify interval in exponent based form in frames, not microframes, so we need to adjust accordingly. NEC xHCI host controllers will return an error code of 0x11 if a full speed isochronous endpoint is added with the Interval field set to something less than 3 (2^3 = 8 microframes, or one frame). It is impossible for a full speed device to have an interval smaller than one frame. This was always an issue in the xHCI driver, but commit dfa49c4ad120a784ef1ff0717168aa79f55a483a "USB: xhci - fix math in xhci_get_endpoint_interval()" removed the clamping of the minimum value in the Interval field, which revealed this bug. This needs to be backported to stable kernels back to 2.6.31. Reported-by: Matt Evans Signed-off-by: Dmitry Torokhov Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman