1. 10 8月, 2011 2 次提交
    • S
      xhci: Remove TDs from TD lists when URBs are canceled. · 585df1d9
      Sarah Sharp 提交于
      When a driver tries to cancel an URB, and the host controller is dying,
      xhci_urb_dequeue will giveback the URB without removing the xhci_tds
      that comprise that URB from the td_list or the cancelled_td_list.  This
      can cause a race condition between the driver calling URB dequeue and
      the stop endpoint command watchdog timer.
      
      If the timer fires on a dying host, and a driver attempts to resubmit
      while the watchdog timer has dropped the xhci->lock to giveback a
      cancelled URB, URBs may be given back by the xhci_urb_dequeue() function.
      At that point, the URB's priv pointer will be freed and set to NULL, but
      the TDs will remain on the td_list.  This will cause an oops in
      xhci_giveback_urb_in_irq() when the watchdog timer attempts to loop
      through the endpoints' td_lists, giving back killed URBs.
      
      Make sure that xhci_urb_dequeue() removes TDs from the TD lists and
      canceled TD lists before it gives back the URB.
      
      This patch should be backported to kernels as old as 2.6.36.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Andiry Xu <andiry.xu@amd.com>
      Cc: stable@kernel.org
      585df1d9
    • S
      xhci: Fix memory leak during failed enqueue. · d13565c1
      Sarah Sharp 提交于
      When the isochronous transfer support was introduced, and the xHCI driver
      switched to using urb->hcpriv to store an "urb_priv" pointer, a couple of
      memory leaks were introduced into the URB enqueue function in its error
      handling paths.
      
      xhci_urb_enqueue allocates urb_priv, but it doesn't free it if changing
      the control endpoint's max packet size fails or the bulk endpoint is in
      the middle of allocating or deallocating streams.
      
      xhci_urb_enqueue also doesn't free urb_priv if any of the four endpoint
      types' enqueue functions fail.  Instead, it expects those functions to
      free urb_priv if an error occurs.  However, the bulk, control, and
      interrupt enqueue functions do not free urb_priv if the endpoint ring is
      NULL.  It will, however, get freed if prepare_transfer() fails in those
      enqueue functions.
      
      Several of the error paths in the isochronous endpoint enqueue function
      also fail to free it.  xhci_queue_isoc_tx_prepare() doesn't free urb_priv
      if prepare_ring() indicates there is not enough room for all the
      isochronous TDs in this URB.  If individual isochronous TDs fail to be
      queued (perhaps due to an endpoint state change), urb_priv is also leaked.
      
      This argues that the freeing of urb_priv should be done in the function
      that allocated it, xhci_urb_enqueue.
      
      This patch looks rather ugly, but refactoring the code will have to wait
      because this patch needs to be backported to stable kernels.
      
      This patch should be backported to kernels as old as 2.6.36.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Andiry Xu <andiry.xu@amd.com>
      Cc: stable@kernel.org
      d13565c1
  2. 02 8月, 2011 1 次提交
    • S
      xhci: Don't submit commands or URBs to halted hosts. · 7bd89b40
      Sarah Sharp 提交于
      Commit fccf4e86
      "USB: Free bandwidth when usb_disable_device is called" caused a bit of an
      issue when the xHCI host controller driver is unloaded.  It changed the
      USB core to remove all endpoints when a USB device is disabled.  When the
      driver is unloaded, it will remove the SuperSpeed split root hub, which
      will disable all devices under that roothub and then halt the host
      controller.  When the second High Speed split roothub is removed, the USB
      core will attempt to disable the endpoints, which will submit a Configure
      Endpoint command to a halted host controller.
      
      The command will eventually time out, but it makes the xHCI driver unload
      take *minutes* if there are a couple of USB 1.1/2.0 devices attached.  We
      must halt the host controller when the SuperSpeed roothub is removed,
      because we can't allow any interrupts from things like port status
      changes.
      
      Make several different functions not submit commands or URBs to the host
      controller when the host is halted, by adding a check in
      xhci_check_args().  xhci_check_args() is used by these functions:
      
      xhci.c-int xhci_urb_enqueue()
      xhci.c-int xhci_drop_endpoint()
      xhci.c-int xhci_add_endpoint()
      xhci.c-int xhci_check_bandwidth()
      xhci.c-void xhci_reset_bandwidth()
      xhci.c-static int xhci_check_streams_endpoint()
      xhci.c-int xhci_discover_or_reset_device()
      
      It's also used by xhci_free_dev().  However, we have to take special
      care in that case, because we want the device memory to be freed if the
      host controller is halted.
      
      This patch should be backported to the 2.6.39 and 3.0 kernel.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@kernel.org
      7bd89b40
  3. 18 6月, 2011 2 次提交
    • M
      xhci: Add reset on resume quirk for asrock p67 host · c877b3b2
      Maarten Lankhorst 提交于
      The asrock p67 xhci controller completely dies on resume, add a
      quirk for this, to bring the host back online after a suspend.
      
      This should be backported to stable kernels as old as 2.6.37.
      Signed-off-by: NMaarten Lankhorst <m.b.lankhorst@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@kernel.org
      c877b3b2
    • A
      xHCI 1.0: Incompatible Device Error · f6ba6fe2
      Alex He 提交于
      It is one new TRB Completion Code for the xHCI spec v1.0.
      Asserted if the xHC detects a problem with a device that does not allow it to
      be successfully accessed, e.g. due to a device compliance or compatibility
      problem. This error may be returned by any command or transfer, and is fatal
      as far as the Slot is concerned. Return -EPROTO by urb->status or frame->status
      of ISOC for transfer case. And return -ENODEV for configure endpoint command,
      evaluate context command and address device command if there is an incompatible
      Device Error. The error codes will be sent back to the USB core to decide how
      to do. It's unnecessary for other commands because after the three commands run
      successfully means that the device has been accepted.
      Signed-off-by: NAlex He <alex.he@amd.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      f6ba6fe2
  4. 16 6月, 2011 1 次提交
    • S
      xhci: Reject double add of active endpoints. · fa75ac37
      Sarah Sharp 提交于
      While trying to switch a UAS device from the BOT configuration to the UAS
      configuration via the bConfigurationValue file, Tanya ran into an issue in
      the USB core.  usb_disable_device() sets entries in udev->ep_out and
      udev->ep_out to NULL, but doesn't call into the xHCI bandwidth management
      functions to remove the BOT configuration endpoints from the xHCI host's
      internal structures.
      
      The USB core would then attempt to add endpoints for the UAS
      configuration, and some of the endpoints had the same address as endpoints
      in the BOT configuration.  The xHCI driver blindly added the endpoints
      again, but the xHCI host controller rejected the Configure Endpoint
      command because active endpoints were added without being dropped.
      
      Make the xHCI driver reject calls to xhci_add_endpoint() that attempt to
      add active endpoints without first calling xhci_drop_endpoint().
      
      This should be backported to kernels as old as 2.6.31.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Reported-by: NTanya Brokhman <tlinder@codeaurora.org>
      Cc: stable@kernel.org
      fa75ac37
  5. 03 6月, 2011 4 次提交
  6. 28 5月, 2011 1 次提交
    • 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
  7. 26 5月, 2011 1 次提交
  8. 17 5月, 2011 1 次提交
    • 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
  9. 10 5月, 2011 2 次提交
  10. 03 5月, 2011 3 次提交
    • S
      xhci: Remove sparse warning about cmd_status. · 00161f7d
      Sarah Sharp 提交于
      Sparse complains about the arguments to xhci_evaluate_context_result() and
      xhci_configure_endpoint_result():
      
        CHECK   drivers/usb/host/xhci.c
      drivers/usb/host/xhci.c:1647:53: warning: incorrect type in argument 3 (different signedness)
      drivers/usb/host/xhci.c:1647:53:    expected int *cmd_status
      drivers/usb/host/xhci.c:1647:53:    got unsigned int [usertype] *[assigned] cmd_status
      drivers/usb/host/xhci.c:1648:50: warning: incorrect type in argument 3 (different signedness)
      drivers/usb/host/xhci.c:1648:50:    expected int *cmd_status
      drivers/usb/host/xhci.c:1648:50:    got unsigned int [usertype] *[assigned] cmd_status
      
      The command status is taken from the command completion event TRB, and
      will always be a positive number.  Change the signature of
      xhci_evaluate_context_result() and xhci_configure_endpoint_result() to
      take a u32 for cmd_status.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      00161f7d
    • M
      xhci: Add an assertion to check for virt_dev=0 bug. · 7ed603ec
      Matt Evans 提交于
      During a "plug-unplug" stress test on an NEC xHCI card, a null pointer
      dereference was observed.  xhci_address_device() dereferenced a null
      virt_dev (possibly an erroneous udev->slot_id?); this patch adds a WARN_ON &
      message to aid debug if it can be recreated.
      Signed-off-by: NMatt Evans <matt@ozlabs.org>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      7ed603ec
    • M
      xhci: Make xHCI driver endian-safe · 28ccd296
      Matt Evans 提交于
      This patch changes the struct members defining access to xHCI device-visible
      memory to use __le32/__le64 where appropriate, and then adds swaps where
      required.  Checked with sparse that all accesses are correct.
      
      MMIO accesses use readl/writel so already are performed LE, but prototypes
      now reflect this with __le*.
      
      There were a couple of (debug) instances of DMA pointers being truncated to
      32bits which have been fixed too.
      Signed-off-by: NMatt Evans <matt@ozlabs.org>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      28ccd296
  11. 14 4月, 2011 3 次提交
    • A
      xHCI: Implement AMD PLL quirk · c41136b0
      Andiry Xu 提交于
      This patch disable the optional PM feature inside the Hudson3 platform under
      the following conditions:
      
      1. If an isochronous device is connected to xHCI port and is active;
      2. Optional PM feature that powers down the internal Bus PLL when the link is
         in low power state is enabled.
      
      The PM feature needs to be disabled to eliminate PLL startup delays when the
      link comes out of low power state. The performance of DMA data transfer could
      be impacted if system delay were encountered and in addition to the PLL start
      up delays. Disabling the PM would leave room for unpredictable system delays
      in order to guarantee uninterrupted data transfer to isochronous audio or
      video stream devices that require time sensitive information. If data in an
      audio/video stream was interrupted then erratic audio or video performance
      may be encountered.
      
      AMD PLL quirk is already implemented in OHCI/EHCI driver. After moving the
      quirk code to pci-quirks.c and export them, xHCI driver can call it directly
      without having the quirk implementation in itself.
      Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      c41136b0
    • S
      xhci: Tell USB core both roothubs lost power. · fedd383e
      Sarah Sharp 提交于
      On a resume, when the power is lost during hibernate, the USB core will
      call hub_reset_resume for the xHCI USB 2.0 roothub, but not for the USB
      3.0 roothub:
      
      [  164.748310] usb usb1: root hub lost power or was reset
      [  164.748353] usb usb2: root hub lost power or was reset
      [  164.748487] usb usb3: root hub lost power or was reset
      [  164.748488] xhci_hcd 0000:01:00.0: Stop HCD
      ...
      [  164.870039] hub 4-0:1.0: hub_resume
      ...
      [  164.870054] hub 3-0:1.0: hub_reset_resume
      
      This causes issues later, because the USB core assumes the USB 3.0 hub
      attached to the USB 3.0 roothub is still active.  It attempts to queue a
      control URB for the external hub, which fails because all the device
      slot contexts were released when the USB 3.0 roothub lost power:
      
      [  164.980044] hub 4-1:1.0: hub_resume
      [  164.980047] xhci_hcd 0000:01:00.0: Get port status returned 0x10101
      [  164.980049] xHCI xhci_urb_enqueue called with unaddressed device
      [  164.980053] hub 3-0:1.0: port 1: status 0101 change 0001
      [  164.980056] hub 4-1:1.0: hub_port_status failed (err = -22)
      [  164.980060] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc90008948440, 32'h202e1, 4'hf);
      [  164.980062] xHCI xhci_urb_enqueue called with unaddressed device
      [  164.980066] xhci_hcd 0000:01:00.0: clear port connect change, actual port 0 status  = 0x2e1
      [  164.980069] hub 4-1:1.0: hub_port_status failed (err = -22)
      [  164.980072] xhci_hcd 0000:01:00.0: get port status, actual port 1 status  = 0x2a0
      [  164.980074] xHCI xhci_urb_enqueue called with unaddressed device
      [  164.980077] xhci_hcd 0000:01:00.0: Get port status returned 0x100
      [  164.980079] hub 4-1:1.0: hub_port_status failed (err = -22)
      [  164.980082] xHCI xhci_urb_enqueue called with unaddressed device
      [  164.980085] hub 4-1:1.0: hub_port_status failed (err = -22)
      [  164.980088] hub 4-1:1.0: port 4: status 0000 change 0000
      [  164.980091] xHCI xhci_urb_enqueue called with unaddressed device
      [  164.980094] hub 4-1:1.0: activate --> -22
      [  164.980113] xHCI xhci_urb_enqueue called with unaddressed device
      [  164.980117] hub 4-1:1.0: hub_port_status failed (err = -22)
      [  164.980119] xHCI xhci_urb_enqueue called with unaddressed device
      [  164.980123] hub 4-1:1.0: can't resume port 4, status -22
      [  164.980126] hub 4-1:1.0: port 4 status ffff.ffff after resume, -22
      [  164.980129] usb 4-1.4: can't resume, status -22
      [  164.980131] hub 4-1:1.0: logical disconnect on port 4
      
      This causes issues when a USB 3.0 hard drive is attached to the external
      USB 3.0 hub when the system is hibernated:
      
      [ 6249.849653] sd 8:0:0:0: [sdb] Unhandled error code
      [ 6249.849659] sd 8:0:0:0: [sdb]  Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
      [ 6249.849663] sd 8:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 2a 08 00 00 02 00
      [ 6249.849671] end_request: I/O error, dev sdb, sector 10760
      
      Make sure to inform the USB core that *both* xHCI roothubs lost power.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      fedd383e
    • D
      USB: xhci - also free streams when resetting devices · 2dea75d9
      Dmitry Torokhov 提交于
      Currently, when resetting a device, xHCI driver disables all but one
      endpoints and frees their rings, but leaves alone any streams that
      might have been allocated. Later, when users try to free allocated
      streams, we oops in xhci_setup_no_streams_ep_input_ctx() because
      ep->ring is NULL.
      
      Let's free not only rings but also stream data as well, so that
      calling free_streams() on a device that was reset will be safe.
      
      This should be queued for stable trees back to 2.6.35.
      Reviewed-by: NMicah Elizabeth Scott <micah@vmware.com>
      Signed-off-by: NDmitry Torokhov <dtor@vmware.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@kernel.org
      2dea75d9
  12. 31 3月, 2011 1 次提交
  13. 14 3月, 2011 11 次提交
    • S
      xhci: Return canceled URBs immediately when host is halted. · c6cc27c7
      Sarah Sharp 提交于
      When the xHCI host controller is halted, it won't respond to commands
      placed on the command ring.  So if an URB is cancelled after the first
      roothub is deallocated, it will try to place a stop endpoint command on
      the command ring, which will fail.  The command watchdog timer will fire
      after five seconds, and the host controller will be marked as dying, and
      all URBs will be completed.
      
      Add a flag to the xHCI's internal state variable for when the host
      controller is halted.  Immediately return the canceled URB if the host
      controller is halted.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      c6cc27c7
    • S
      xhci: Fixes for suspend/resume of shared HCDs. · b3209379
      Sarah Sharp 提交于
      Make sure the HCD_FLAG_HW_ACCESSIBLE flag is mirrored by both roothubs,
      since it refers to whether the shared hardware is accessible.  Make sure
      each bus is marked as suspended by setting usb_hcd->state to
      HC_STATE_SUSPENDED when the PCI host controller is resumed.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      b3209379
    • S
      xhci: Fix re-init on power loss after resume. · 65b22f93
      Sarah Sharp 提交于
      When a host controller has lost power during a suspend, we must
      reinitialize it.  Now that the xHCI host has two roothubs, xhci_run() and
      xhci_stop() expect to be called with both usb_hcd structures.  Be sure
      that the re-initialization code in xhci_resume() mirrors the process the
      USB PCI probe function uses.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      65b22f93
    • S
      xhci: Register second xHCI roothub. · f6ff0ac8
      Sarah Sharp 提交于
      This patch changes the xHCI driver to allocate two roothubs.  This touches
      the driver initialization and shutdown paths, roothub emulation code, and
      port status change event handlers.  This is a rather large patch, but it
      can't be broken up, or it would break git-bisect.
      
      Make the xHCI driver register its own PCI probe function.  This will call
      the USB core to create the USB 2.0 roothub, and then create the USB 3.0
      roothub.  This gets the code for registering a shared roothub out of the
      USB core, and allows other HCDs later to decide if and how many shared
      roothubs they want to allocate.
      
      Make sure the xHCI's reset method marks the xHCI host controller's primary
      roothub as the USB 2.0 roothub.  This ensures that the high speed bus will
      be processed first when the PCI device is resumed, and any USB 3.0 devices
      that have migrated over to high speed will migrate back after being reset.
      This ensures that USB persist works with these odd devices.
      
      The reset method will also mark the xHCI USB2 roothub as having an
      integrated TT.  Like EHCI host controllers with a "rate matching hub" the
      xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
      It doesn't really have a TT, but we'll lie and say it has an integrated
      TT.  We need to do this because the USB core will reject LS/FS devices
      under a HS hub without a TT.
      
      Other details:
      -------------
      
      The roothub emulation code is changed to return the correct number of
      ports for the two roothubs.  For the USB 3.0 roothub, it only reports the
      USB 3.0 ports.  For the USB 2.0 roothub, it reports all the LS/FS/HS
      ports.  The code to disable a port now checks the speed of the roothub,
      and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
      
      The code for initializing a new device context must be changed to set the
      proper roothub port number.  Since we've split the xHCI host into two
      roothubs, we can't just use the port number in the ancestor hub.  Instead,
      we loop through the array of hardware port status register speeds and find
      the Nth port with a similar speed.
      
      The port status change event handler is updated to figure out whether the
      port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
      Once it figures out the port speed, it kicks the proper roothub.
      
      The function to find a slot ID based on the port index is updated to take
      into account that the two roothubs will have over-lapping port indexes.
      It checks that the virtual device with a matching port index is the same
      speed as the passed in roothub.
      
      There's also changes to the driver initialization and shutdown paths:
      
       1. Make sure that the xhci_hcd pointer is shared across the two
          usb_hcd structures.  The xhci_hcd pointer is allocated and the
          registers are mapped in when xhci_pci_setup() is called with the
          primary HCD.  When xhci_pci_setup() is called with the non-primary
          HCD, the xhci_hcd pointer is stored.
      
       2. Make sure to set the sg_tablesize for both usb_hcd structures.  Set
          the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
          DMA.  (The PCI DMA mask is set from the primary HCD further down in
          the xhci_pci_setup() function.)
      
       3. Ensure that the host controller doesn't start kicking khubd in
          response to port status changes before both usb_hcd structures are
          registered.  xhci_run() only starts the xHC running once it has been
          called with the non-primary roothub.  Similarly, the xhci_stop()
          function only halts the host controller when it is called with the
          non-primary HCD.  Then on the second call, it resets and cleans up the
          MSI-X irqs.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      f6ff0ac8
    • S
      xhci: Refactor bus suspend state into a struct. · 20b67cf5
      Sarah Sharp 提交于
      There are several variables in the xhci_hcd structure that are related to
      bus suspend and resume state.  There are a couple different port status
      arrays that are accessed by port index.  Move those variables into a
      separate structure, xhci_bus_state.  Stash that structure in xhci_hcd.
      
      When we have two roothhubs that can be suspended and resumed separately,
      we can have two xhci_bus_states, and index into the port arrays in each
      structure with the fake roothub port index (not the real hardware port
      index).
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      20b67cf5
    • S
      xhci: Always use usb_hcd in URB instead of converting xhci_hcd. · 214f76f7
      Sarah Sharp 提交于
      Make sure to call into the USB core's link, unlink, and giveback URB
      functions with the usb_hcd pointer found by using urb->dev->bus.  This
      will avoid confusion later, when the xHCI driver will deal with URBs from
      two separate buses (the USB 3.0 roothub and the faked USB 2.0 roothub).
      
      Assume xhci_urb_dequeue() will be called with the proper usb_hcd.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      214f76f7
    • S
      xhci: Remove references to HC_STATE_RUNNING. · ad73dff3
      Sarah Sharp 提交于
      The USB core will set hcd->state to HC_STATE_RUNNING before calling
      xhci_run, so there's no point in setting it twice.  The USB core also
      doesn't pay attention to HC_STATE_RUNNING on the resume path anymore; it
      uses HCD_RH_RUNNING(), which looks at hcd->flags & (1U <<
      HCD_FLAG_RH_RUNNING.  Therefore, it's safe to remove the state set in
      xhci_bus_resume().
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      ad73dff3
    • S
      xhci: Remove references to HC_STATE_HALT. · ac04e6ff
      Sarah Sharp 提交于
      The xHCI driver doesn't ever test hcd->state for HC_STATE_HALT.  The USB
      core recently stopped using it internally, so there's no point in setting
      it in the driver.  We still need to set HC_STATE_RUNNING in order to make
      it past the USB core's hcd->state check in register_roothub().
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      ac04e6ff
    • A
      xHCI: prolong host controller halt time limit · bdfca502
      Andiry Xu 提交于
      xHCI 1.0 spec specifies the xHC shall halt within 16ms after software clears
      Run/Stop bit. In xHCI 0.96 spec the time limit is 16 microframes (2ms), it's
      too short and often cause dmesg shows "Host controller not halted, aborting
      reset." message when rmmod xhci-hcd.
      
      Modify the time limit to comply with xHCI 1.0 specification and prevents the
      warning message showing when remove xhci-hcd.
      Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      bdfca502
    • A
      xHCI: Remove redundant variable in xhci_resume() · 019a35f1
      Andiry Xu 提交于
      Set hcd->state = HC_STATE_SUSPENDED if there is a power loss during system
      resume or the system is hibernated, otherwise leave it be. The variable
      old_state is redundant and made an unreachable code path, so remove it.
      Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      019a35f1
    • S
      xhci: Remove old no-op test. · 0b8ca72a
      Sarah Sharp 提交于
      The test of placing a number of command no-ops on the command ring and
      counting the number of no-op events that were generated was only used
      during the initial xHCI driver bring up.  This test is no longer used, so
      delete it.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      0b8ca72a
  14. 23 2月, 2011 1 次提交
  15. 20 2月, 2011 1 次提交
  16. 15 1月, 2011 3 次提交
    • S
      xhci: Use GFP_NOIO during device reset. · a6d940dd
      Sarah Sharp 提交于
      When xhci_discover_or_reset_device() is called after a host controller
      power loss, the virtual device may need to be reallocated.  Make sure
      xhci_alloc_dev() uses GFP_NOIO.  This avoid causing a deadlock by allowing
      the kernel to flush pending I/O while reallocating memory for a virtual
      device for a USB mass storage device that's holding the backing store for
      dirty memory buffers.
      
      This patch should be queued for the 2.6.37 stable tree.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@kernel.org
      a6d940dd
    • Z
      xhci: Do not run xhci_cleanup_msix with irq disabled · 40a9fb17
      Zhang Rui 提交于
      when unloading xhci_hcd, I got:
      [  134.856813] xhci_hcd 0000:02:00.0: remove, state 4
      [  134.858140] usb usb3: USB disconnect, address 1
      [  134.874956] xhci_hcd 0000:02:00.0: Host controller not halted, aborting reset.
      [  134.876351] BUG: sleeping function called from invalid context at kernel/mutex.c:85
      [  134.877657] in_atomic(): 0, irqs_disabled(): 1, pid: 1451, name: modprobe
      [  134.878975] Pid: 1451, comm: modprobe Not tainted 2.6.37-rc5+ #162
      [  134.880298] Call Trace:
      [  134.881602]  [<ffffffff8104156a>] __might_sleep+0xeb/0xf0
      [  134.882921]  [<ffffffff814763dc>] mutex_lock+0x24/0x50
      [  134.884229]  [<ffffffff810a745c>] free_desc+0x2e/0x5f
      [  134.885538]  [<ffffffff810a74c8>] irq_free_descs+0x3b/0x71
      [  134.886853]  [<ffffffff8102584d>] free_irq_at+0x31/0x36
      [  134.888167]  [<ffffffff8102723f>] destroy_irq+0x69/0x71
      [  134.889486]  [<ffffffff8102747a>] native_teardown_msi_irq+0xe/0x10
      [  134.890820]  [<ffffffff8124c382>] default_teardown_msi_irqs+0x57/0x80
      [  134.892158]  [<ffffffff8124be46>] free_msi_irqs+0x8b/0xe9
      [  134.893504]  [<ffffffff8124cd46>] pci_disable_msix+0x35/0x39
      [  134.894844]  [<ffffffffa01b444a>] xhci_cleanup_msix+0x31/0x51 [xhci_hcd]
      [  134.896186]  [<ffffffffa01b4b3a>] xhci_stop+0x3a/0x80 [xhci_hcd]
      [  134.897521]  [<ffffffff81341dd4>] usb_remove_hcd+0xfd/0x14a
      [  134.898859]  [<ffffffff813500ae>] usb_hcd_pci_remove+0x5c/0xc6
      [  134.900193]  [<ffffffff8123c606>] pci_device_remove+0x3f/0x91
      [  134.901535]  [<ffffffff812e7ea4>] __device_release_driver+0x83/0xd9
      [  134.902899]  [<ffffffff812e8571>] driver_detach+0x86/0xad
      [  134.904222]  [<ffffffff812e7d56>] bus_remove_driver+0xb2/0xd8
      [  134.905540]  [<ffffffff812e8633>] driver_unregister+0x6c/0x74
      [  134.906839]  [<ffffffff8123c8e4>] pci_unregister_driver+0x44/0x89
      [  134.908121]  [<ffffffffa01b940e>] xhci_unregister_pci+0x15/0x17 [xhci_hcd]
      [  134.909396]  [<ffffffffa01bd7d2>] xhci_hcd_cleanup+0xe/0x10 [xhci_hcd]
      [  134.910652]  [<ffffffff8107fcd1>] sys_delete_module+0x1ca/0x23b
      [  134.911882]  [<ffffffff81123932>] ? path_put+0x22/0x26
      [  134.913104]  [<ffffffff8109a800>] ? audit_syscall_entry+0x2c/0x148
      [  134.914333]  [<ffffffff8100ac82>] system_call_fastpath+0x16/0x1b
      [  134.915658] xhci_hcd 0000:02:00.0: USB bus 3 deregistered
      [  134.916465] xhci_hcd 0000:02:00.0: PCI INT A disabled
      
      and the same issue when xhci_suspend is invoked.  (Note from Sarah: That's
      fixed by Andiry's patch before this, by synchronizing the irqs rather than
      freeing them on suspend.)
      
      Do not run xhci_cleanup_msix with irq disabled.
      
      This patch should be queued for the 2.6.37 stable tree.
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@kernel.org
      40a9fb17
    • A
      xHCI: synchronize irq in xhci_suspend() · 0029227f
      Andiry Xu 提交于
      Synchronize the interrupts instead of free them in xhci_suspend(). This will
      prevent a double free when the host is suspended and then the card removed.
      
      Set the flag hcd->msix_enabled when using MSI-X, and check the flag in
      suspend_common(). MSI-X synchronization will be handled by xhci_suspend(),
      and MSI/INTx will be synchronized in suspend_common().
      
      This patch should be queued for the 2.6.37 stable tree.
      Reported-by: NMatthew Garrett <mjg@redhat.com>
      Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@kernel.org
      0029227f
  17. 20 11月, 2010 1 次提交
    • P
      xhci: Fix reset-device and configure-endpoint commands · 7a3783ef
      Paul Zimmerman 提交于
      We have been having problems with the USB-IF Gold Tree tests when plugging
      and unplugging devices from the tree. I have seen that the reset-device
      and configure-endpoint commands, which are invoked from
      xhci_discover_or_reset_device() and xhci_configure_endpoint(), will sometimes
      time out.
      
      After much debugging, I determined that the commands themselves do not actually
      time out, but rather their completion events do not get delivered to the right
      place.
      
      This happens when the command ring has just wrapped around, and it's enqueue
      pointer is left pointing to the link TRB. xhci_discover_or_reset_device() and
      xhci_configure_endpoint() use the enqueue pointer directly as their command
      TRB pointer, without checking whether it's pointing to the link TRB.
      
      When the completion event arrives, if the command TRB is pointing to the link
      TRB, the check against the command ring dequeue pointer in
      handle_cmd_in_cmd_wait_list() fails, so the completion inside the command does
      not get signaled.
      
      The patch below fixes the timeout problem for me.
      
      This should be queued for the 2.6.35 and 2.6.36 stable trees.
      Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@kernel.org
      7a3783ef
  18. 16 11月, 2010 1 次提交
    • S
      xhci: Fix command ring replay after resume. · 89821320
      Sarah Sharp 提交于
      Andiry's xHCI bus suspend patch introduced the possibly of a host
      controller replaying old commands on the command ring, if the host
      successfully restores the registers after a resume.
      
      After a resume from suspend, the xHCI driver must restore the registers,
      including the command ring pointer.  I had suggested that Andiry set the
      command ring pointer to the current command ring dequeue pointer, so that
      the driver wouldn't have to zero the command ring.
      
      Unfortunately, setting the command ring pointer to the current dequeue
      pointer won't work because the register assumes the pointer is 64-byte
      aligned, and TRBs on the command ring are 16-byte aligned.  The lower
      seven bits will always be masked off, leading to the written pointer being
      up to 3 TRBs behind the intended pointer.
      
      Here's a log excerpt.  On init, the xHCI driver places a vendor-specific
      command on the command ring:
      
      [  215.750958] xhci_hcd 0000:01:00.0: Vendor specific event TRB type = 48
      [  215.750960] xhci_hcd 0000:01:00.0: NEC firmware version 30.25
      [  215.750962] xhci_hcd 0000:01:00.0: Command ring deq = 0x3781e010 (DMA)
      
      When we resume, the command ring dequeue pointer to be written should have
      been 0x3781e010.  Instead, it's 0x3781e000:
      
      [  235.557846] xhci_hcd 0000:01:00.0: // Setting command ring address to 0x3781e001
      [  235.557848] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 64'hffffc900100bc038, 64'h3781e001, 4'hf);
      [  235.557850] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc900100bc020, 32'h204, 4'hf);
      [  235.557866] usb usb9: root hub lost power or was reset
      
      (I can't see the results of this bug because the xHCI restore always fails
      on this box, and the xHCI driver re-allocates everything.)
      
      The fix is to zero the command ring and put the software and hardware
      enqueue and dequeue pointer back to the beginning of the ring.  We do this
      before the system suspends, to be paranoid and prevent the BIOS from
      starting the host without clearing the command ring pointer, which might
      cause the host to muck with stale memory.  (The pointer isn't required to
      be in the suspend power well, but it could be.)  The command ring pointer
      is set again after the host resumes.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Tested-by: NAndiry Xu <andiry.xu@amd.com>
      89821320