kernel/git/stable/linux.git/drivers/usb/host, branch linux-2.6.31.y

USB: EHCI & UHCI: fix race between root-hub suspend and port resume

2010-04-01T22:55:37+00:00

commit cec3a53c7fe794237b582e8e77fc0e48465e65ee upstream. This patch (as1321) fixes a problem with EHCI and UHCI root-hub suspends: If the suspend occurs while a port is trying to resume, the resume doesn't finish and simply gets lost. When remote wakeup is enabled, this is undesirable behavior. The patch checks first to see if any port resumes are in progress, and if they are then it fails the root-hub suspend with -EBUSY. Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

USB: EHCI: fix handling of unusual interrupt intervals

2010-04-01T22:55:37+00:00

commit 1b9a38bfa6e664ff02511314f5586d711c83cc91 upstream. This patch (as1320) fixes two problems related to interrupt-URB scheduling in ehci-hcd. URBs with an interval of 2 or 4 microframes aren't handled. For the time being, the patch reduces to interval to 1 uframe. URBs are constrained to have an interval no larger than 1024 frames by usb_submit_urb(). But some EHCI controllers allow use of a schedule as short as 256 frames; for these controllers we may have to decrease the interval to the actual schedule length. The second problem isn't very significant since few devices expose interrupt endpoints with an interval larger than 256 frames. But the first problem is critical; it will prevent the kernel from working with devices having interrupt intervals of 2 or 4 uframes. Signed-off-by: Alan Stern Tested-by: Glynn Farrow Signed-off-by: Greg Kroah-Hartman

USB: add missing delay during remote wakeup

2010-04-01T22:55:36+00:00

commit 49d0f078f494b9d81e820a13dd8093a9bfb0b6b1 upstream. This patch (as1330) fixes a bug in khbud's handling of remote wakeups. When a device sends a remote-wakeup request, the parent hub (or the host controller driver, for directly attached devices) begins the resume sequence and notifies khubd when the sequence finishes. At this point the port's SUSPEND feature is automatically turned off. However the device needs an additional 10-ms resume-recovery time (TRSMRCY in the USB spec). Khubd does not wait for this delay if the SUSPEND feature is off, and as a result some devices fail to behave properly following a remote wakeup. This patch adds the missing delay to the remote-wakeup path. It also extends the resume-signalling delay used by ehci-hcd and uhci-hcd from 20 ms (the value in the spec) to 25 ms (the value we use for non-remote-wakeup resumes). The extra time appears to help some devices. Signed-off-by: Alan Stern Cc: Rickard Bellini Signed-off-by: Greg Kroah-Hartman

USB: work around for EHCI with quirky periodic schedules

2009-12-08T18:22:16+00:00

commit ee4ecb8ac63a5792bec448037d4b82ec4144f94b upstream. a quirky chipset needs periodic schedules to run for a minimum time before they can be disabled again. This enforces the requirement with a time stamp and a calculated delay Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman

USB: EHCI: don't send Clear-TT-Buffer following a STALL

2009-12-08T18:22:12+00:00

commit c2f6595fbdb408d3d6850cfae590c8fa93e27399 upstream. This patch (as1304) fixes a regression in ehci-hcd. Evidently some hubs don't handle Clear-TT-Buffer requests correctly, so we should avoid sending them when they don't appear to be absolutely necessary. The reported symptom is that output on a downstream audio device cuts out because the hub stops relaying isochronous packets. The patch prevents Clear-TT-Buffer requests from being sent following a STALL handshake. In theory a STALL indicates either that the downstream device sent a STALL or that no matching TT buffer could be found. In either case, the transfer is completed and the TT buffer does not remain busy, so it doesn't need to be cleared. Also, the patch fixes a minor flaw in the code that actually sends the Clear-TT-Buffer requests. Although the pipe direction isn't really used for control transfers, it should be a Send rather than a Receive. Signed-off-by: Alan Stern Reported-by: Javier Kohen CC: David Brownell Signed-off-by: Greg Kroah-Hartman

USB: xhci: Fix scratchpad deallocation.

2009-12-08T18:21:31+00:00

commit 5294bea40666db5c5d6c336b8e4e55d69fa576ca upstream. The scratchpad_free() function uses xhci->page_size to free some memory with pci_free_consistent(). However, the page_size is set to zero before the call, causing kernel oopses on driver unload. Call scratchpad_free() before setting xhci->page_size to zero. Signed-off-by: Sarah Sharp Acked-by: John Youn Signed-off-by: Greg Kroah-Hartman

USB: xhci: Fix TRB physical to virtual address translation.

2009-12-08T18:21:30+00:00

commit 2fa88daa6f299bfb83672c3b525d786ad03b4735 upstream. The trb_in_td() function in the xHCI driver is supposed to translate a physical transfer buffer request (TRB) into a virtual pointer to the ring segment that TRB is in. Unfortunately, a mistake in this function may cause endless loops as the driver searches through the linked list of ring segments over and over again. Fix a couple bugs that may lead to loops or bad output: 1. Bail out if we get a NULL pointer when translating the segment's private structure and the starting DMA address of the segment chunk. If this happens, we've been handed a starting TRB pointer from a different ring. 2. Make sure the function works when there's multiple segments in the ring. In the while loop to search through the ring segments, use the current segment variable (cur_seg), rather than the starting segment variable (start_seg) that is passed in. 3. Stop searching the ring if we've run through all the segments in the ring. Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman

USB: xhci: Fix bug memory free after failed initialization.

2009-12-08T18:21:29+00:00

commit d94c05e33d9212ee67b8d4998f984cc71df8168b upstream. If the xHCI driver fails during the memory initialization, xhci->ir_set may not be a valid pointer. Check that it points to valid DMA'able memory before writing to that address during the memory freeing process. Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman

USB: ohci: quirk AMD prefetch for USB 1.1 ISO transfer

2009-12-08T18:21:25+00:00

commit a1f17a872bc7b1cb7efdd5486a2963e88a536e61 upstream. The following patch in the driver is required to avoid USB 1.1 device failures that may occur due to requests from USB OHCI controllers may be overwritten if the latency for any pending request by the USB controller is very long (in the range of milliseconds). Signed-off-by: Libin Yang Cc: David Brownell Cc: Alan Stern Signed-off-by: Greg Kroah-Hartman

USB: xhci: Support interrupt transfers.

2009-10-05T16:32:53+00:00

commit 624defa12f304b4d11eda309bc207fa5a1900d0f upstream. Interrupt transfers are submitted to the xHCI hardware using the same TRB type as bulk transfers. Re-use the bulk transfer enqueueing code to enqueue interrupt transfers. Interrupt transfers are a bit different than bulk transfers. When the interrupt endpoint is to be serviced, the xHC will consume (at most) one TD. A TD (comprised of sg list entries) can take several service intervals to transmit. The important thing for device drivers to note is that if they use the scatter gather interface to submit interrupt requests, they will not get data sent from two different scatter gather lists in the same service interval. For now, the xHCI driver will use the service interval from the endpoint's descriptor (bInterval). Drivers will need a hook to poll at a more frequent interval. Set urb->interval to the interval that the xHCI hardware will use. Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman