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. 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
  5. 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
  6. 20 5月, 2011 8 次提交
  7. 18 5月, 2011 2 次提交
    • A
      EHCI: don't rescan interrupt QHs needlessly · 1e12c910
      Alan Stern 提交于
      This patch (as1466) speeds up processing of ehci-hcd's periodic list.
      The existing code will pointlessly rescan an interrupt endpoint queue
      each time it encounters the queue's QH in the periodic list, which can
      happen quite a few times if the endpoint's period is low.  On some
      embedded systems, this useless overhead can waste so much time that
      the driver falls hopelessly behind and loses events.
      
      The patch introduces a "periodic_stamp" variable, which gets
      incremented each time scan_periodic() runs and each time the scan
      advances to a new frame.  If the corresponding stamp in an interrupt
      QH is equal to the current periodic_stamp, we assume the QH has
      already been scanned and skip over it.  Otherwise we scan the QH as
      usual, and if none of its URBs have completed then we store the
      current periodic_stamp in the QH's stamp, preventing it from being
      scanned again.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      1e12c910
    • A
      OHCI: fix regression caused by nVidia shutdown workaround · 2b7aaf50
      Alan Stern 提交于
      This patch (as1463) fixes a regression caused by commit
      3df7169e (OHCI: work around for nVidia
      shutdown problem).
      
      The original problem encountered by people using NVIDIA chipsets was
      that USB devices were not turning off when the system shut down.  For
      example, the LED on an optical mouse would remain on, draining a
      laptop's battery.  The problem was caused by a bug in the chipset; an
      OHCI controller in the Reset state would continue to drive a bus reset
      signal even after system shutdown.  The workaround was to put the
      controllers into the Suspend state instead.
      
      It turns out that later NVIDIA chipsets do not suffer from this bug.
      Instead some have the opposite bug: If a system is shut down while an
      OHCI controller is in the Suspend state, USB devices remain powered!
      On other systems, shutting down with a Suspended controller causes the
      system to reboot immediately.  Thus, working around the original bug
      on some machines exposes other bugs on other machines.
      
      The best solution seems to be to limit the workaround to OHCI
      controllers with a low-numbered PCI product ID.  I don't know exactly
      at what point NVIDIA changed their chipsets; the value used here is a
      guess.  So far it was worked out okay for all the people who have
      tested it.
      
      This fixes Bugzilla #35032.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Tested-by: NAndre "Osku" Schmidt <andre.osku.schmidt@googlemail.com>
      Tested-by: NYury Siamashka <yurand2@gmail.com>
      CC: <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      2b7aaf50
  8. 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
  9. 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
  10. 13 5月, 2011 3 次提交
  11. 12 5月, 2011 1 次提交
    • S
      xhci: Fix bug in control transfer cancellation. · 3abeca99
      Sarah Sharp 提交于
      When the xHCI driver attempts to cancel a transfer, it issues a Stop
      Endpoint command and waits for the host controller to indicate which TRB
      it was in the middle of processing.  The host will put an event TRB with
      completion code COMP_STOP on the event ring if it stops on a control
      transfer TRB (or other types of transfer TRBs).  The ring handling code
      is supposed to set ep->stopped_trb to the TRB that the host stopped on
      when this happens.
      
      Unfortunately, there is a long-standing bug in the control transfer
      completion code.  It doesn't actually check to see if COMP_STOP is set
      before attempting to process the transfer based on which part of the
      control TD completed.  So when we get an event on the data phase of the
      control TRB with COMP_STOP set, it thinks it's a normal completion of
      the transfer and doesn't set ep->stopped_td or ep->stopped_trb.
      
      When the ring handling code goes on to process the completion of the Stop
      Endpoint command, it sees that ep->stopped_trb is not a part of the TD
      it's trying to cancel.  It thinks the hardware has its enqueue pointer
      somewhere further up in the ring, and thinks it's safe to turn the control
      TRBs into no-op TRBs.  Since the hardware was in the middle of the control
      TRBs to be cancelled, the proper software behavior is to issue a Set TR
      dequeue pointer command.
      
      It turns out that the NEC host controllers can handle active TRBs being
      set to no-op TRBs after a stop endpoint command, but other host
      controllers have issues with this out-of-spec software behavior.  Fix this
      behavior.
      
      This patch should be backported to kernels as far back as 2.6.31, but it
      may be a bit challenging, since process_ctrl_td() was introduced in some
      refactoring done in 2.6.36, and some endian-safe patches added in 2.6.40
      that touch the same lines.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: stable@kernel.org
      3abeca99
  12. 11 5月, 2011 1 次提交
  13. 10 5月, 2011 7 次提交
  14. 07 5月, 2011 2 次提交