1. 07 3月, 2015 1 次提交
    • A
      xhci: fix reporting of 0-sized URBs in control endpoint · 45ba2154
      Aleksander Morgado 提交于
      When a control transfer has a short data stage, the xHCI controller generates
      two transfer events: a COMP_SHORT_TX event that specifies the untransferred
      amount, and a COMP_SUCCESS event. But when the data stage is not short, only the
      COMP_SUCCESS event occurs. Therefore, xhci-hcd must set urb->actual_length to
      urb->transfer_buffer_length while processing the COMP_SUCCESS event, unless
      urb->actual_length was set already by a previous COMP_SHORT_TX event.
      
      The driver checks this by seeing whether urb->actual_length == 0, but this alone
      is the wrong test, as it is entirely possible for a short transfer to have an
      urb->actual_length = 0.
      
      This patch changes the xhci driver to rely on a new td->urb_length_set flag,
      which is set to true when a COMP_SHORT_TX event is received and the URB length
      updated at that stage.
      
      This fixes a bug which affected the HSO plugin, which relies on URBs with
      urb->actual_length == 0 to halt re-submitting the RX URB in the control
      endpoint.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAleksander Morgado <aleksander@aleksander.es>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      45ba2154
  2. 25 2月, 2015 1 次提交
  3. 10 1月, 2015 3 次提交
  4. 03 12月, 2014 2 次提交
  5. 22 11月, 2014 2 次提交
    • M
      USB: xhci: Reset a halted endpoint immediately when we encounter a stall. · 8e71a322
      Mathias Nyman 提交于
      If a device is halted and reuturns a STALL, then the halted endpoint
      needs to be cleared both on the host and device side. The host
      side halt is cleared by issueing a xhci reset endpoint command. The device side
      is cleared with a ClearFeature(ENDPOINT_HALT) request, which should
      be issued by the device driver if a URB reruen -EPIPE.
      
      Previously we cleared the host side halt after the device side was cleared.
      To make sure the host side halt is cleared in time we want to issue the
      reset endpoint command immedialtely when a STALL status is encountered.
      
      Otherwise we end up not following the specs and not returning -EPIPE
      several times in a row when trying to transfer data to a halted endpoint.
      
      Fixes: bcef3fd5 (USB: xhci: Handle errors that cause endpoint halts.)
      Cc: <stable@vger.kernel.org> # v2.6.33+
      Tested-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8e71a322
    • M
      USB: xhci: don't start a halted endpoint before its new dequeue is set · c3492dbf
      Mathias Nyman 提交于
      A halted endpoint ring must first be reset, then move the ring
      dequeue pointer past the problematic TRB. If we start the ring too
      early after reset, but before moving the dequeue pointer we
      will end up executing the same problematic TRB again.
      
      As we always issue a set transfer dequeue command after a reset
      endpoint command we can skip starting endpoint rings at reset endpoint
      command completion.
      
      Without this fix we end up trying to handle the same faulty TD for
      contol endpoints. causing timeout, and failing testusb ctrl_out write
      tests.
      
      Fixes: e9df17eb (USB: xhci: Correct assumptions about number of rings per endpoint.)
      Cc: <stable@vger.kernel.org> #v2.6.35
      Tested-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c3492dbf
  6. 24 9月, 2014 5 次提交
  7. 20 8月, 2014 2 次提交
  8. 02 8月, 2014 1 次提交
  9. 25 6月, 2014 2 次提交
  10. 20 5月, 2014 4 次提交
    • M
      xhci: rework command timeout and cancellation, · c311e391
      Mathias Nyman 提交于
      Use one timer to control command timeout.
      
      start/kick the timer every time a command is completed and a
      new command is waiting, or a new command is added to a empty list.
      
      If the timer runs out, then tag the current command as "aborted", and
      start the xhci command abortion process.
      
      Previously each function that submitted a command had its own timer.
      If that command timed out, a new command structure for the
      command was created and it was put on a cancel_cmd_list list,
      then a pci write to abort the command ring was issued.
      
      when the ring was aborted, it checked if the current command
      was the one to be canceled, later when the ring was stopped the
      driver got ownership of the TRBs in the command ring,
      compared then to the TRBs in the cancel_cmd_list,
      and turned them into No-ops.
      
      Now, instead, at timeout we tag the status of the command in the
      command queue to be aborted, and start the ring abortion.
      Ring abortion stops the command ring and gives control of the
      commands to us.
      All the aborted commands are now turned into No-ops.
      
      If the ring is already stopped when the command times outs its not possible
      to start the ring abortion, in this case the command is turnd to No-op
      right away.
      
      All these changes allows us to remove the entire cancel_cmd_list code.
      
      The functions waiting for a command to finish no longer have their own timeouts.
      They will wait either until the command completes normally,
      or until the whole command abortion is done.
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c311e391
    • M
      xhci: Use completion and status in global command queue · 9ea1833e
      Mathias Nyman 提交于
      Remove the per-device command list and handle_cmd_in_cmd_wait_list()
      and use the completion and status variables found in the
      command structure in the global command list.
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9ea1833e
    • M
      xhci: Add a global command queue · c9aa1a2d
      Mathias Nyman 提交于
      Create a list to store command structures, add a structure to it every time
      a command is submitted, and remove it from the list once we get a
      command completion event matching the command.
      
      Callers that wait for completion will free their command structures themselves.
      The other command structures are freed in the command completion event handler.
      
      Also add a check that prevents queuing commands if host is dying
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c9aa1a2d
    • M
      xhci: Use command structures when queuing commands on the command ring · ddba5cd0
      Mathias Nyman 提交于
      To create a global command queue we require that each command put on the
      command ring is submitted with a command structure.
      
      Functions that queue commands and wait for completion need to allocate a command
      before submitting it, and free it once completed. The following command queuing
      functions need to be modified.
      
      xhci_configure_endpoint()
      xhci_address_device()
      xhci_queue_slot_control()
      xhci_queue_stop_endpoint()
      xhci_queue_new_dequeue_state()
      xhci_queue_reset_ep()
      xhci_configure_endpoint()
      
      xhci_configure_endpoint() could already be called with a command structure,
      and only xhci_check_maxpacket and xhci_check_bandwidth did not do so. These
      are changed and a command structure is now required. This change also simplifies
      the configure endpoint command completion handling and the "goto bandwidth_change"
      handling code can be removed.
      
      In some cases the command queuing function is called in interrupt context.
      These commands needs to be allocated atomically, and they can't wait for
      completion. These commands will in this patch be freed directly after queuing,
      but freeing will be moved to the command completion event handler in a later
      patch once we get the global command queue up.(Just so that we won't leak
      memory in the middle of the patch set)
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ddba5cd0
  11. 26 4月, 2014 1 次提交
    • J
      usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb · 1f81b6d2
      Julius Werner 提交于
      We have observed a rare cycle state desync bug after Set TR Dequeue
      Pointer commands on Intel LynxPoint xHCs (resulting in an endpoint that
      doesn't fetch new TRBs and thus an unresponsive USB device). It always
      triggers when a previous Set TR Dequeue Pointer command has set the
      pointer to the final Link TRB of a segment, and then another URB gets
      enqueued and cancelled again before it can be completed. Further
      investigation showed that the xHC had returned the Link TRB in the TRB
      Pointer field of the Transfer Event (CC == Stopped -- Length Invalid),
      but when xhci_find_new_dequeue_state() later accesses the Endpoint
      Context's TR Dequeue Pointer field it is set to the first TRB of the
      next segment.
      
      The driver expects those two values to be the same in this situation,
      and uses the cycle state of the latter together with the address of the
      former. This should be fine according to the XHCI specification, since
      the endpoint ring should be stopped when returning the Transfer Event
      and thus should not advance over the Link TRB before it gets restarted.
      However, real-world XHCI implementations apparently don't really care
      that much about these details, so the driver should follow a more
      defensive approach to try to work around HC spec violations.
      
      This patch removes the stopped_trb variable that had been used to store
      the TRB Pointer from the last Transfer Event of a stopped TRB. Instead,
      xhci_find_new_dequeue_state() now relies only on the Endpoint Context,
      requiring a small amount of additional processing to find the virtual
      address corresponding to the TR Dequeue Pointer. Some other parts of the
      function were slightly rearranged to better fit into this model.
      
      This patch should be backported to kernels as old as 2.6.31 that contain
      the commit ae636747 "USB: xhci: URB
      cancellation support."
      Signed-off-by: NJulius Werner <jwerner@chromium.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f81b6d2
  12. 05 3月, 2014 6 次提交
  13. 08 2月, 2014 2 次提交
  14. 31 1月, 2014 1 次提交
  15. 30 1月, 2014 1 次提交
    • S
      Revert "xhci: replace xhci_write_64() with writeq()" · 477632df
      Sarah Sharp 提交于
      This reverts commit 7dd09a1a.
      
      Many xHCI host controllers can only handle 32-bit addresses, and writing
      64-bits at a time causes them to fail.  Rafał reports that USB devices
      simply do not enumerate, and reverting this patch helps.  Branimir
      reports that his host controller doesn't respond to an Enable Slot
      command and dies:
      
      [   75.576160] xhci_hcd 0000:03:00.0: Timeout while waiting for a slot
      [   88.991634] xhci_hcd 0000:03:00.0: Stopped the command ring failed, maybe the host is dead
      [   88.991748] xhci_hcd 0000:03:00.0: Abort command ring failed
      [   88.991845] xhci_hcd 0000:03:00.0: HC died; cleaning up
      [   93.985489] xhci_hcd 0000:03:00.0: Timeout while waiting for a slot
      [   93.985494] xhci_hcd 0000:03:00.0: Abort the command ring, but the xHCI is dead.
      [   98.982586] xhci_hcd 0000:03:00.0: Timeout while waiting for a slot
      [   98.982591] xhci_hcd 0000:03:00.0: Abort the command ring, but the xHCI is dead.
      [  103.979696] xhci_hcd 0000:03:00.0: Timeout while waiting for a slot
      [  103.979702] xhci_hcd 0000:03:00.0: Abort the command ring, but the xHCI is dead
      Signed-off-by: NSarah Sharp <sarah.a.sharp@intel.com>
      Reported-by: NRafał Miłecki <zajec5@gmail.com>
      Reported-by: NBranimir Maksimovic <branimir.maksimovic@gmail.com>
      Cc: Xenia Ragiadakou <burzalodowa@gmail.com>
      477632df
  16. 09 1月, 2014 1 次提交
  17. 18 12月, 2013 1 次提交
  18. 11 12月, 2013 1 次提交
    • D
      usb: xhci: change enumeration scheme to 'new scheme' by default · 48fc7dbd
      Dan Williams 提交于
      Change the default enumeration scheme for xhci attached non-SuperSpeed
      devices from:
      
         Reset
         SetAddress [xhci address-device BSR = 0]
         GetDescriptor(8)
         GetDescriptor(18)
      
      ...to:
      
         Reset
         [xhci address-device BSR = 1]
         GetDescriptor(64)
         Reset
         SetAddress [xhci address-device BSR = 0]
         GetDescriptor(18)
      
      ...as some devices misbehave when encountering a SetAddress command
      prior to GetDescriptor.  There are known legacy devices that require
      this scheme, but testing has found at least one USB3 device that fails
      enumeration when presented with this ordering.  For now, follow the ehci
      case and enable 'new scheme' by default for non-SuperSpeed devices.
      
      To support this enumeration scheme on xhci the AddressDevice operation
      needs to be performed twice.  The first instance of the command enables
      the HC's device and slot context info for the device, but omits sending
      the device a SetAddress command (BSR == block set address request).
      Then, after GetDescriptor completes, follow up with the full
      AddressDevice+SetAddress operation.
      
      As mentioned before, this ordering of events with USB3 devices causes an
      extra state transition to be exposed to xhci.  Previously USB3 devices
      would transition directly from 'enabled' to 'addressed' and never need
      to underrun responses to 'get descriptor'. We do see the 64-byte
      descriptor fetch the correct data, but the following 18-byte descriptor
      read after the reset gets:
      
      bLength            = 0
      bDescriptorType    = 0
      bcdUSB             = 0
      bDeviceClass       = 0
      bDeviceSubClass    = 0
      bDeviceProtocol    = 0
      bMaxPacketSize0    = 9
      
      instead of:
      
      bLength            = 12
      bDescriptorType    = 1
      bcdUSB             = 300
      bDeviceClass       = 0
      bDeviceSubClass    = 0
      bDeviceProtocol    = 0
      bMaxPacketSize0    = 9
      
      which results in the discovery process looping until falling back to
      'old scheme' enumeration.
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: NDavid Moore <david.moore@gmail.com>
      Suggested-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      48fc7dbd
  19. 03 12月, 2013 3 次提交
    • X
      xhci: replace xhci_write_64() with writeq() · 7dd09a1a
      Xenia Ragiadakou 提交于
      Function xhci_write_64() is used to write 64bit xHC registers residing in MMIO.
      On 32bit systems, xHC registers need to be written with 32bit accesses by
      writing first the lower 32bits and then the higher 32bits. The header file
      asm-generic/io-64-nonatomic-lo-hi.h ensures that on 32bit systems writeq() will
      will write 64bit registers in 32bit chunks with low-high order.
      
      Replace all calls to xhci_write_64() with calls to writeq().
      
      This is done to reduce code duplication since 64bit low-high write logic
      is already implemented and to take advantage of inherent "atomic" 64bit
      write operations on 64bit systems.
      Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      7dd09a1a
    • X
      xhci: replace xhci_read_64() with readq() · e8b37332
      Xenia Ragiadakou 提交于
      Function xhci_read_64() is used to read 64bit xHC registers residing in MMIO.
      On 32bit systems, xHC registers need to be read with 32bit accesses by
      reading first the lower 32bits and then the higher 32bits.
      
      Replace all calls to xhci_read_64() with calls to readq() and include
      asm-generic/io-64-nonatomic-lo-hi.h header file, so that if the system
      is not 64bit, readq() will read registers in 32bit chunks with low-high order.
      
      This is done to reduce code duplication since 64bit low-high read logic
      is already implemented and to take advantage of inherent "atomic" 64bit
      read operations on 64bit systems.
      Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      e8b37332
    • X
      xhci: replace xhci_writel() with writel() · 204b7793
      Xenia Ragiadakou 提交于
      Function xhci_writel() is used to write a 32bit value in xHC registers residing
      in MMIO address space. It takes as first argument a pointer to the xhci_hcd
      although it does not use it. xhci_writel() internally simply calls writel().
      This creates an illusion that xhci_writel() is an xhci specific function that
      has to be called in a context where a pointer to xhci_hcd is available.
      
      Remove xhci_writel() wrapper function and replace its calls with calls to
      writel() to make the code more straight-forward.
      Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      204b7793