1. 03 6月, 2011 3 次提交
  2. 02 6月, 2011 1 次提交
  3. 28 5月, 2011 3 次提交
    • S
      Intel xhci: Limit number of active endpoints to 64. · 2cf95c18
      Sarah Sharp 提交于
      The Panther Point chipset has an xHCI host controller that has a limit to
      the number of active endpoints it can handle.  Ideally, it would signal
      that it can't handle anymore endpoints by returning a Resource Error for
      the Configure Endpoint command, but they don't.  Instead it needs software
      to keep track of the number of active endpoints, across configure endpoint
      commands, reset device commands, disable slot commands, and address device
      commands.
      
      Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
      to track the number of endpoints the xHC has active.  This gets a little
      tricky, because commands to change the number of active endpoints can
      fail.  This patch adds a new xHCI quirk for these Intel hosts, and the new
      code should not have any effect on other xHCI host controllers.
      
      Fail a new device allocation if we don't have room for the new default
      control endpoint.  Use the endpoint ring pointers to determine what
      endpoints were active before a Reset Device command or a Disable Slot
      command, and drop those once the command completes.
      
      Fail a configure endpoint command if it would add too many new endpoints.
      We have to be a bit over zealous here, and only count the number of new
      endpoints to be added, without subtracting the number of dropped
      endpoints.  That's because a second configure endpoint command for a
      different device could sneak in before we know if the first command is
      completed.  If the first command dropped resources, the host controller
      fails the command for some reason, and we're nearing the limit of
      endpoints, we could end up oversubscribing the host.
      
      To fix this race condition, when evaluating whether a configure endpoint
      command will fix in our bandwidth budget, only add the new endpoints to
      xhci->num_active_eps, and don't subtract the dropped endpoints.  Ignore
      changed endpoints (ones that are dropped and then re-added), as that
      shouldn't effect the host's endpoint resources.  When the configure
      endpoint command completes, subtract off the dropped endpoints.
      
      This may mean some configuration changes may temporarily fail, but it's
      always better to under-subscribe than over-subscribe resources.
      
      (Originally my plan had been to push the resource allocation down into the
      ring allocation functions.  However, that would cause us to allocate
      unnecessary resources when endpoints were changed, because the xHCI driver
      allocates a new ring for the changed endpoint, and only deletes the old
      ring once the Configure Endpoint command succeeds.  A further complication
      would have been dealing with the per-device endpoint ring cache.)
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      2cf95c18
    • S
      Intel xhci: Ignore spurious successful event. · ad808333
      Sarah Sharp 提交于
      The xHCI host controller in the Panther Point chipset sometimes produces
      spurious events on the event ring.  If it receives a short packet, it
      first puts a Transfer Event with a short transfer completion code on the
      event ring.  Then it puts a Transfer Event with a successful completion
      code on the ring for the same TD.  The xHCI driver correctly processes the
      short transfer completion code, gives the URB back to the driver, and then
      prints a warning in dmesg about the spurious event.  These warning
      messages really fill up dmesg when an HD webcam is plugged into xHCI.
      
      This spurious successful event behavior isn't technically disallowed by
      the xHCI specification, so make the xHCI driver just ignore the spurious
      completion event.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      ad808333
    • S
      Intel xhci: Support EHCI/xHCI port switching. · 69e848c2
      Sarah Sharp 提交于
      The Intel Panther Point chipsets contain an EHCI and xHCI host controller
      that shares some number of skew-dependent ports.  These ports can be
      switched from the EHCI to the xHCI host (and vice versa) by a hardware MUX
      that is controlled by registers in the xHCI PCI configuration space.  The
      USB 3.0 SuperSpeed terminations on the xHCI ports can be controlled
      separately from the USB 2.0 data wires.
      
      This switchover mechanism is there to support users who do a custom
      install of certain non-Linux operating systems that don't have official
      USB 3.0 support.  By default, the ports are under EHCI, SuperSpeed
      terminations are off, and USB 3.0 devices will show up under the EHCI
      controller at reduced speeds.  (This was more palatable for the marketing
      folks than having completely dead USB 3.0 ports if no xHCI drivers are
      available.)  Users should be able to turn on xHCI by default through a
      BIOS option, but users are happiest when they don't have to change random
      BIOS settings.
      
      This patch introduces a driver method to switchover the ports from EHCI to
      xHCI before the EHCI driver finishes PCI enumeration.  We want to switch
      the ports over before the USB core has the chance to enumerate devices
      under EHCI, or boot from USB mass storage will fail if the boot device
      connects under EHCI first, and then gets disconnected when the port
      switches over to xHCI.
      
      Add code to the xHCI PCI quirk to switch the ports from EHCI to xHCI.  The
      PCI quirks code will run before any other PCI probe function is called, so
      this avoids the issue with boot devices.
      
      Another issue is with BIOS behavior during system resume from hibernate.
      If the BIOS doesn't support xHCI, it may switch the devices under EHCI to
      allow use of the USB keyboard, mice, and mass storage devices.  It's
      supposed to remember the value of the port routing registers and switch
      them back when the OS attempts to take control of the xHCI host controller,
      but we all know not to trust BIOS writers.
      
      Make both the xHCI driver and the EHCI driver attempt to switchover the
      ports in their PCI resume functions.  We can't guarantee which PCI device
      will be resumed first, so this avoids any race conditions.  Writing a '1'
      to an already set port switchover bit or a '0' to a cleared port switchover
      bit should have no effect.
      
      The xHCI PCI configuration registers will be documented in the EDS-level
      chipset spec, which is not public yet.  I have permission from legal and
      the Intel chipset group to release this patch early to allow good Linux
      support at product launch.  I've tried to document the registers as much
      as possible, so please let me know if anything is unclear.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      69e848c2
  4. 27 5月, 2011 1 次提交
  5. 26 5月, 2011 5 次提交
    • S
      xhci: STFU: Be quieter during URB submission and completion. · f444ff27
      Sarah Sharp 提交于
      Unsurprisingly, URBs get submitted and completed a lot in the xHCI
      driver.  If we have to print 10 lines of debug for every URB submitted
      or completed, then that can cause the whole system to stay in the
      interrupt handler too long, and can cause Missed Service completion
      codes for isochronous transfers.
      
      Cut down the debugging in the URB submission and completion paths:
       - Don't squawk about successful transfers, only unsuccessful ones.
       - Only print the number of bytes transferred if this was a short
         transfer.
       - Don't print the endpoint index for successful transfers (will add
         more debug to failed transfers to show endpoint index there later).
       - Stop printing MMIO writes.  This debugging shows up when the endpoint
         doorbell is rung a to start a transfer (basically for every URB).
       - Don't print out the ring enqueue and dequeue pointers
       - Stop printing when we're pointing to a link TRB.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      f444ff27
    • S
      xhci: STFU: Don't print event ring dequeue pointer. · 5153b7b3
      Sarah Sharp 提交于
      Stop printing out the event ring dequeue pointer and status register in
      the operational register set.  The host will report an OK status 99% of
      the time the interrupt handler is called, and usually when it's really
      hosed, a host controller won't even call the interrupt handler.  So the
      line is really useless.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      5153b7b3
    • S
      xhci: STFU: Remove function tracing. · 380032c3
      Sarah Sharp 提交于
      Remove unnecessary debugging from the xHCI driver.  We don't need to
      know what function we're calling or returning from.  Now I know how to
      use markup-oops.pl to de-mystify stack dumps of crashes.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      380032c3
    • 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
  6. 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
  7. 20 5月, 2011 9 次提交
  8. 19 5月, 2011 2 次提交
  9. 18 5月, 2011 12 次提交
  10. 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
  11. 14 5月, 2011 1 次提交
    • S
      xhci: Fix full speed bInterval encoding. · b513d447
      Sarah Sharp 提交于
      Dmitry's patch
      
      dfa49c4a USB: xhci - fix math in xhci_get_endpoint_interval()
      
      introduced a bug.  The USB 2.0 spec says that full speed isochronous endpoints'
      bInterval must be decoded as an exponent to a power of two (e.g. interval =
      2^(bInterval - 1)).  Full speed interrupt endpoints, on the other hand, don't
      use exponents, and the interval in frames is encoded straight into bInterval.
      
      Dmitry's patch was supposed to fix up the full speed isochronous to parse
      bInterval as an exponent, but instead it changed the *interrupt* endpoint
      bInterval decoding.  The isochronous endpoint encoding was the same.
      
      This caused full speed devices with interrupt endpoints (including mice, hubs,
      and USB to ethernet devices) to fail under NEC 0.96 xHCI host controllers:
      
      [  100.909818] xhci_hcd 0000:06:00.0: add ep 0x83, slot id 1, new drop flags = 0x0, new add flags = 0x99, new slot info = 0x38100000
      [  100.909821] xhci_hcd 0000:06:00.0: xhci_check_bandwidth called for udev ffff88011f0ea000
      ...
      [  100.910187] xhci_hcd 0000:06:00.0: ERROR: unexpected command completion code 0x11.
      [  100.910190] xhci_hcd 0000:06:00.0: xhci_reset_bandwidth called for udev ffff88011f0ea000
      
      When the interrupt endpoint was added and a Configure Endpoint command was
      issued to the host, the host controller would return a very odd error message
      (0x11 means "Slot Not Enabled", which isn't true because the slot was enabled).
      Probably the host controller was getting very confused with the bad encoding.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Dmitry Torokhov <dtor@vmware.com>
      Reported-by: NThomas Lindroth <thomas.lindroth@gmail.com>
      Tested-by: NThomas Lindroth <thomas.lindroth@gmail.com>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b513d447