<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/usb/host, branch v2.6.32</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v2.6.32</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v2.6.32'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2009-12-01T00:43:16+00:00</updated>
<entry>
<title>USB: work around for EHCI with quirky periodic schedules</title>
<updated>2009-12-01T00:43:16+00:00</updated>
<author>
<name>Oliver Neukum</name>
<email>oliver@neukum.org</email>
</author>
<published>2009-11-27T14:17:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ee4ecb8ac63a5792bec448037d4b82ec4144f94b'/>
<id>urn:sha1:ee4ecb8ac63a5792bec448037d4b82ec4144f94b</id>
<content type='text'>
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 &lt;oliver@neukum.org&gt;
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;


</content>
</entry>
<entry>
<title>USB: EHCI: don't send Clear-TT-Buffer following a STALL</title>
<updated>2009-12-01T00:43:15+00:00</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2009-11-18T16:37:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c2f6595fbdb408d3d6850cfae590c8fa93e27399'/>
<id>urn:sha1:c2f6595fbdb408d3d6850cfae590c8fa93e27399</id>
<content type='text'>
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 &lt;stern@rowland.harvard.edu&gt;
Reported-by: Javier Kohen &lt;jkohen@users.sourceforge.net&gt;
CC: David Brownell &lt;david-b@pacbell.net&gt;
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>USB: xhci: Fix scratchpad deallocation.</title>
<updated>2009-11-18T00:46:34+00:00</updated>
<author>
<name>Sarah Sharp</name>
<email>sarah.a.sharp@linux.intel.com</email>
</author>
<published>2009-11-04T19:22:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5294bea40666db5c5d6c336b8e4e55d69fa576ca'/>
<id>urn:sha1:5294bea40666db5c5d6c336b8e4e55d69fa576ca</id>
<content type='text'>
The scratchpad_free() function uses xhci-&gt;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-&gt;page_size to zero.

Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
Acked-by: John Youn &lt;John.Youn@synopsys.com&gt;
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>USB: xhci: Fix TRB physical to virtual address translation.</title>
<updated>2009-11-18T00:46:34+00:00</updated>
<author>
<name>Sarah Sharp</name>
<email>sarah.a.sharp@linux.intel.com</email>
</author>
<published>2009-11-04T06:02:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2fa88daa6f299bfb83672c3b525d786ad03b4735'/>
<id>urn:sha1:2fa88daa6f299bfb83672c3b525d786ad03b4735</id>
<content type='text'>
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 &lt;sarah.a.sharp@linux.intel.com&gt;
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>USB: xhci: Fix bug memory free after failed initialization.</title>
<updated>2009-11-18T00:46:34+00:00</updated>
<author>
<name>Sarah Sharp</name>
<email>sarah.a.sharp@linux.intel.com</email>
</author>
<published>2009-11-04T06:02:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d94c05e33d9212ee67b8d4998f984cc71df8168b'/>
<id>urn:sha1:d94c05e33d9212ee67b8d4998f984cc71df8168b</id>
<content type='text'>
If the xHCI driver fails during the memory initialization, xhci-&gt;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 &lt;sarah.a.sharp@linux.intel.com&gt;
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>USB: ohci: quirk AMD prefetch for USB 1.1 ISO transfer</title>
<updated>2009-11-18T00:46:33+00:00</updated>
<author>
<name>Libin Yang</name>
<email>libin.yang@amd.com</email>
</author>
<published>2009-11-04T06:55:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a1f17a872bc7b1cb7efdd5486a2963e88a536e61'/>
<id>urn:sha1:a1f17a872bc7b1cb7efdd5486a2963e88a536e61</id>
<content type='text'>
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 &lt;libin.yang@amd.com&gt;
Cc: David Brownell &lt;dbrownell@users.sourceforge.net&gt;
Cc: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
</entry>
<entry>
<title>USB: r8a66597-hcd: fix cannot detect a device when uses_new_polling is set</title>
<updated>2009-10-30T21:57:33+00:00</updated>
<author>
<name>Yoshihiro Shimoda</name>
<email>shimoda.yoshihiro@renesas.com</email>
</author>
<published>2009-10-21T11:33:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1e6159f858f5da608612ae10d6554bb7ecac9755'/>
<id>urn:sha1:1e6159f858f5da608612ae10d6554bb7ecac9755</id>
<content type='text'>
Signed-off-by: Yoshihiro Shimoda &lt;shimoda.yoshihiro@renesas.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>USB: ehci: Fix IST boundary checking interval math.</title>
<updated>2009-10-14T21:54:43+00:00</updated>
<author>
<name>Sarah Sharp</name>
<email>sarah.a.sharp@linux.intel.com</email>
</author>
<published>2009-10-09T19:28:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=36f21329d217016f0f212f0752ae595b4a76754d'/>
<id>urn:sha1:36f21329d217016f0f212f0752ae595b4a76754d</id>
<content type='text'>
When the EHCI driver falls behind in its scheduling, the active stream's
first empty microframe may be in the past with respect to the current
microframe.  The code attempts to move the starting microframe ("start") N
number of microframes forward, where N is the interval of endpoint.
However, stream-&gt;interval is a copy of the endpoint's bInterval, which is
designated in frames for FS devices, and microframes for HS devices.
Convert stream-&gt;interval to microframes before using it to move the
starting microframe forward.

Acked-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>USB: whci-hcd: always do an update after processing a halted qTD</title>
<updated>2009-10-14T21:54:43+00:00</updated>
<author>
<name>David Vrabel</name>
<email>david.vrabel@csr.com</email>
</author>
<published>2009-10-12T15:45:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1f01ca4e0c1d4126eb663f8ea0bab03836099770'/>
<id>urn:sha1:1f01ca4e0c1d4126eb663f8ea0bab03836099770</id>
<content type='text'>
A halted qTD always triggers a hardware list update because the qset was
either removed or reactivated.

Signed-off-by: David Vrabel &lt;david.vrabel@csr.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>USB: whci-hcd: handle early deletion of endpoints</title>
<updated>2009-10-14T21:54:42+00:00</updated>
<author>
<name>David Vrabel</name>
<email>david.vrabel@csr.com</email>
</author>
<published>2009-10-12T15:45:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=171b37ee95865c052a88d52a05895c3c584f4871'/>
<id>urn:sha1:171b37ee95865c052a88d52a05895c3c584f4871</id>
<content type='text'>
If an endpoint is deleted before it's been fully added to the hardware
list, the associated qset will not be fully initialized and an oops will
occur when complete(&amp;qset-&gt;remove_complete) is called.  This can happen
if a queued URB is cancelled.

Fix this by only removing the qset from the hardware list if the
cancelled URB had qTDs.

Signed-off-by: David Vrabel &lt;david.vrabel@csr.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
</feed>
