Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 26 5月, 2011 2 次提交
    • S
      xhci: Don't submit commands when the host is dead. · fe6c6c13
      由 Sarah Sharp 提交于 
      When the xHCI host controller dies, the USB core may attempt to reset the
devices to their default configuration before disconnecting them.  This
causes calls into the xHCI bandwidth allocation functions.  Don't allow
those functions to submit commands or work on xHCI structures if the host
controller is marked as dying.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      fe6c6c13
    • S
      xhci: Clear stopped_td when Stop Endpoint command completes. · 0714a57c
      由 Sarah Sharp 提交于 
      When an URB is cancelled, the xHCI driver issues a Stop Endpoint command
so that it can manipulate the ring and remove the transfer.  The xHC
hardware then places a transfer event with the completion code "Stopped"
or "Stopped Invalid" to let the driver know what TD it was in the middle
of processing.  This TD and TRB is stored in ep->stopped_td and
ep->stopped_trb.  These pointers are also used in handling stalled
endpoints.

By design, the Stop Endpoint command can race with URB completion.  By
the time the Stop Endpoint command is handled, the URBs to be cancelled
may have been given back to the driver.  Unfortunately, the stopped_td
and stopped_trb pointers were not getting cleared in this case.

The USB core unconditionally tries to reset the toggle bits on any
endpoints when a new alternate interface setting is installed.  When the
xHCI driver saw that ep->stopped_td was still set from the Stop Endpoint
command, xhci_reset_endpoint assumed the endpoint was actually stalled,
and attempted to clean up the endpoint rings.  This would manifest
itself in a failed Reset Endpoint command and failed Set TR dequeue
Pointer command after a successful Configure Endpoint command.  It may
have also been causing driver oops when the stopped_td was accessed.

This patch should be backported to stable kernels since 2.6.31.  Before
2.6.33, stopped_td was found in the xhci_endpoint_ring, not the
xhci_virt_ep.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      0714a57c
  3. 21 5月, 2011 1 次提交
    • L
      sanitize <linux/prefetch.h> usage · 268bb0ce
      由 Linus Torvalds 提交于 
      Commit e66eed65 ("list: remove prefetching from regular list
iterators") removed the include of prefetch.h from list.h, which
uncovered several cases that had apparently relied on that rather
obscure header file dependency.

So this fixes things up a bit, using

   grep -L linux/prefetch.h $(git grep -l '[^a-z_]prefetchw*(' -- '*.[ch]')
   grep -L 'prefetchw*(' $(git grep -l 'linux/prefetch.h' -- '*.[ch]')

to guide us in finding files that either need <linux/prefetch.h>
inclusion, or have it despite not needing it.

There are more of them around (mostly network drivers), but this gets
many core ones.
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      268bb0ce
  5. 20 5月, 2011 9 次提交
  7. 19 5月, 2011 2 次提交
  9. 18 5月, 2011 12 次提交
  11. 17 5月, 2011 2 次提交
    • S
      xhci: Fix memory leak bug when dropping endpoints · 834cb0fc
      由 Sarah Sharp 提交于 
      When the USB core wants to change to an alternate interface setting that
doesn't include an active endpoint, or de-configuring the device, the xHCI
driver needs to issue a Configure Endpoint command to tell the host to
drop some endpoints from the schedule.  After the command completes, the
xHCI driver needs to free rings for any endpoints that were dropped.

Unfortunately, the xHCI driver wasn't actually freeing the endpoint rings
for dropped endpoints.  The rings would be freed if the endpoint's
information was simply changed (and a new ring was installed), but dropped
endpoints never had their rings freed.  This caused errors when the ring
segment DMA pool was freed when the xHCI driver was unloaded:

[ 5582.883995] xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff88003371d000 busy
[ 5582.884002] xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff880033716000 busy
[ 5582.884011] xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff880033455000 busy
[ 5582.884018] xhci_hcd 0000:06:00.0: Freed segment pool
[ 5582.884026] xhci_hcd 0000:06:00.0: Freed device context pool
[ 5582.884033] xhci_hcd 0000:06:00.0: Freed small stream array pool
[ 5582.884038] xhci_hcd 0000:06:00.0: Freed medium stream array pool
[ 5582.884048] xhci_hcd 0000:06:00.0: xhci_stop completed - status = 1
[ 5582.884061] xhci_hcd 0000:06:00.0: USB bus 3 deregistered
[ 5582.884193] xhci_hcd 0000:06:00.0: PCI INT A disabled

Fix this issue and free endpoint rings when their endpoints are
successfully dropped.

This patch should be backported to kernels as old as 2.6.31.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
      834cb0fc
    • S
      xhci: Fix memory leak in ring cache deallocation. · 30f89ca0
      由 Sarah Sharp 提交于 
      When an endpoint ring is freed, it is either cached in a per-device ring
cache, or simply freed if the ring cache is full.  If the ring was added
to the cache, then virt_dev->num_rings_cached is incremented.  The cache
is designed to hold up to 31 endpoint rings, in array indexes 0 to 30.
When the device is freed (when the slot was disabled),
xhci_free_virt_device() is called, it would free the cached rings in
array indexes 0 to virt_dev->num_rings_cached.

Unfortunately, the original code in xhci_free_or_cache_endpoint_ring()
would put the first entry into the ring cache in array index 1, instead of
array index 0.  This was caused by the second assignment to rings_cached:

	rings_cached = virt_dev->num_rings_cached;
	if (rings_cached < XHCI_MAX_RINGS_CACHED) {
		virt_dev->num_rings_cached++;
		rings_cached = virt_dev->num_rings_cached;
		virt_dev->ring_cache[rings_cached] =
			virt_dev->eps[ep_index].ring;

This meant that when the device was freed, cached rings with indexes 0 to
N would be freed, and the last cached ring in index N+1 would not be
freed.  When the driver was unloaded, this caused interesting messages
like:

xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff880063040000 busy

This should be queued to stable kernels back to 2.6.33.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
      30f89ca0
  13. 14 5月, 2011 8 次提交
  15. 13 5月, 2011 4 次提交