1. 11 8月, 2010 17 次提交
  2. 27 7月, 2010 1 次提交
    • S
      USB: xHCI: Fix another bug in link TRB activation change. · d1dc908a
      Sarah Sharp 提交于
      Commit 6c12db90 also seems to have
      introduced a bug that is triggered when the command ring is about to wrap.
      The inc_enq() function will not have moved the enqueue pointer past the
      link TRB.  It is supposed to be moved past the link TRB in prepare_ring(),
      which should be called before a TD is enqueued.  However, the
      queue_command() function never calls the prepare_ring() function because
      prepare_ring() is only supposed to be used for endpoint rings.  That means
      the enqueue pointer will not be moved past the link TRB, and will get
      overwritten.
      
      The fix is to make queue_command() call prepare_ring() with a fake
      endpoint status (set to running).  Then the enqueue pointer will get moved
      past the link TRB.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      d1dc908a
  3. 30 6月, 2010 1 次提交
    • S
      USB: xHCI: Fix bug in link TRB activation change. · 6cc30d85
      Sarah Sharp 提交于
      Commit 6c12db90 introduced a bug for
      control transfers.  The patch was supposed to change when the link TRBs at
      the end of each ring segment were given to the hardware.  If a transfer
      descriptor (TD) ended just before the link TRB, the code wouldn't give
      back the link TRB to the hardware; instead it would be given back in
      prepare_ring() just before the next TD was enqueued at the top of the
      ring.
      
      Unfortunately, the code relied on checking the chain bit of the TRB to
      determine whether the TD ended just before the link TRB.  It assumed that
      the ring enqueuing code would call prepare_ring() before enqueuing the
      next TD.  However, control transfers are made of multiple TDs, and
      prepare_ring() is only called once before enqueuing two or three TDs.
      
      If the first or second TD of the control transfer ended just before the
      link TRB, then the code in inc_enq() would not move the enqueue pointer
      past the link TRB, and the link TRB would get overwritten.  This would
      cause the xHCI driver to start writing to memory past the ring segment,
      and eventually the system would crash or hang.
      
      The fix is to add a flag to inc_enq() that says whether the caller will
      enqueue more TDs before calling prepare_ring().  If the chain bit is
      cleared (meaning this is the last TRB in a TD), and the caller will not
      enqueue more TDs, then we defer giving back the link TRB.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6cc30d85
  4. 05 6月, 2010 1 次提交
    • S
      USB: xhci: Print NEC firmware version. · 0238634d
      Sarah Sharp 提交于
      The NEC xHCI host controller firmware version can be found by putting a
      vendor-specific command on the command ring and extracting the BCD
      encoded-version out of the vendor-specific event TRB.
      
      The firmware version debug line in dmesg will look like:
      
      xhci_hcd 0000:05:00.0: NEC firmware version 30.21
      
      (NEC merged with Renesas Technologies and became Renesas Electronics on
      April 1, 2010.  I have their OK to merge this vendor-specific code.)
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Satoshi Otani <satoshi.otani.xm@renesas.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      0238634d
  5. 21 5月, 2010 11 次提交
    • G
      USB: xhci: fix compiler warning. · c3443a6d
      Greg Kroah-Hartman 提交于
      Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c3443a6d
    • A
      USB: xHCI: Fix wrong usage of macro TRB_TYPE · 54b5acf3
      Andiry Xu 提交于
      Macro TRB_TYPE is misused in some places. Fix the wrong usage.
      Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      54b5acf3
    • J
      USB: xhci: Transfer ring link TRB activation change. · 6c12db90
      John Youn 提交于
      Change transfer ring behavior to not follow/activate link TRBs
      until active TRBs are queued after it.  This change affects
      the behavior when a TD ends just before a link TRB.
      Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6c12db90
    • S
      USB: xhci: Set stream ID to 0 after cleaning up stalls. · 5e5cf6fc
      Sarah Sharp 提交于
      After using state stored in xhci_virt_ep to clean up a stalled endpoint,
      be sure to set the stalled stream ID back to 0.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      5e5cf6fc
    • M
      USB: Change the scatterlist type in struct urb · 910f8d0c
      Matthew Wilcox 提交于
      Change the type of the URB's 'sg' pointer from a usb_sg_request to
      a scatterlist.  This allows drivers to submit scatter-gather lists
      without using the usb_sg_wait() interface.  It has the added benefit
      of removing the typecasts that were added as part of patch as1368 (and
      slightly decreasing the number of pointer dereferences).
      Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
      Reviewed-by: NAlan Stern <stern@rowland.harvard.edu>
      Tested-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      910f8d0c
    • R
      USB: clean up some host controller sparse warnings · 326b4810
      Randy Dunlap 提交于
      Fix usb sparse warnings:
      
      drivers/usb/host/isp1362-hcd.c:2220:50: warning: Using plain integer as NULL pointer
      drivers/usb/host/xhci-mem.c:43:24: warning: Using plain integer as NULL pointer
      drivers/usb/host/xhci-mem.c:49:24: warning: Using plain integer as NULL pointer
      drivers/usb/host/xhci-mem.c:161:24: warning: Using plain integer as NULL pointer
      drivers/usb/host/xhci-mem.c:198:16: warning: Using plain integer as NULL pointer
      drivers/usb/host/xhci-mem.c:319:31: warning: Using plain integer as NULL pointer
      drivers/usb/host/xhci-mem.c:1231:33: warning: Using plain integer as NULL pointer
      drivers/usb/host/xhci-pci.c:177:23: warning: non-ANSI function declaration of function 'xhci_register_pci'
      drivers/usb/host/xhci-pci.c:182:26: warning: non-ANSI function declaration of function 'xhci_unregister_pci'
      drivers/usb/host/xhci-ring.c:342:32: warning: Using plain integer as NULL pointer
      drivers/usb/host/xhci-ring.c:525:34: warning: Using plain integer as NULL pointer
      drivers/usb/host/xhci-ring.c:1009:32: warning: Using plain integer as NULL pointer
      drivers/usb/host/xhci-ring.c:1031:32: warning: Using plain integer as NULL pointer
      drivers/usb/host/xhci-ring.c:1041:16: warning: Using plain integer as NULL pointer
      drivers/usb/host/xhci-ring.c:1096:30: warning: Using plain integer as NULL pointer
      drivers/usb/host/xhci-ring.c:1100:27: warning: Using plain integer as NULL pointer
      drivers/usb/host/xhci-mem.c:224:27: warning: symbol 'xhci_alloc_container_ctx' was not declared. Should it be static?
      drivers/usb/host/xhci-mem.c:242:6: warning: symbol 'xhci_free_container_ctx' was not declared. Should it be static?
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Cc: Lothar Wassmann <LW@KARO-electronics.de>
      Signed-off By: Sarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      326b4810
    • S
      USB: xhci: Correct assumptions about number of rings per endpoint. · e9df17eb
      Sarah Sharp 提交于
      Much of the xHCI driver code assumes that endpoints only have one ring.
      Now an endpoint can have one ring per enabled stream ID, so correct that
      assumption.  Use functions that translate the stream_id field in the URB
      or the DMA address of a TRB into the correct stream ring.
      
      Correct the polling loop to print out all enabled stream rings.  Make the
      URB cancellation routine find the correct stream ring if the URB has
      stream_id set.  Make sure the URB enqueueing routine does the same.  Also
      correct the code that handles stalled/halted endpoints.
      
      Check that commands and registers that can take stream IDs handle them
      properly.  That includes ringing an endpoint doorbell, resetting a
      stalled/halted endpoint, and setting a transfer ring dequeue pointer
      (since that command can set the dequeue pointer in a stream context or an
      endpoint context).
      
      Correct the transfer event handler to translate a TRB DMA address into the
      stream ring it was enqueued to.  Make the code to allocate and prepare TD
      structures adds the TD to the right td_list for the stream ring.  Make
      sure the code to give the first TRB in a TD to the hardware manipulates
      the correct stream ring.
      
      When an endpoint stalls, store the stream ID of the stream ring that
      stalled in the xhci_virt_ep structure.  Use that instead of the stream ID
      in the URB, since an URB may be re-used after it is given back after a
      non-control endpoint stall.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      e9df17eb
    • S
      USB: xhci: Add memory allocation for USB3 bulk streams. · 8df75f42
      Sarah Sharp 提交于
      Add support for allocating streams for USB 3.0 bulk endpoints.  See
      Documentation/usb/bulk-streams.txt for more information about how and why
      you would use streams.
      
      When an endpoint has streams enabled, instead of having one ring where all
      transfers are enqueued to the hardware, it has several rings.  The ring
      dequeue pointer in the endpoint context is changed to point to a "Stream
      Context Array".  This is basically an array of pointers to transfer rings,
      one for each stream ID that the driver wants to use.
      
      The Stream Context Array size must be a power of two, and host controllers
      can place a limit on the size of the array (4 to 2^16 entries).  These
      two facts make calculating the size of the Stream Context Array and the
      number of entries actually used by the driver a bit tricky.
      
      Besides the Stream Context Array and rings for all the stream IDs, we need
      one more data structure.  The xHCI hardware will not tell us which stream
      ID a transfer event was for, but it will give us the slot ID, endpoint
      index, and physical address for the TRB that caused the event.  For every
      endpoint on a device, add a radix tree to map physical TRB addresses to
      virtual segments within a stream ring.
      
      Keep track of whether an endpoint is transitioning to using streams, and
      don't enqueue any URBs while that's taking place.  Refuse to transition an
      endpoint to streams if there are already URBs enqueued for that endpoint.
      
      We need to make sure that freeing streams does not fail, since a driver's
      disconnect() function may attempt to do this, and it cannot fail.
      Pre-allocate the command structure used to issue the Configure Endpoint
      command, and reserve space on the command ring for each stream endpoint.
      This may be a bit overkill, but it is permissible for the driver to
      allocate all streams in one call and free them in multiple calls.  (It is
      not advised, however, since it is a waste of resources and time.)
      
      Even with the memory and ring room pre-allocated, freeing streams can
      still fail because the xHC rejects the configure endpoint command.  It is
      valid (by the xHCI 0.96 spec) to return a "Bandwidth Error" or a "Resource
      Error" for a configure endpoint command.  We should never see a Bandwidth
      Error, since bulk endpoints do not effect the reserved bandwidth.  The
      host controller can still return a Resource Error, but it's improbable
      since the xHC would be going from a more resource-intensive configuration
      (streams) to a less resource-intensive configuration (no streams).
      
      If the xHC returns a Resource Error, the endpoint will be stuck with
      streams and will be unusable for drivers.  It's an unavoidable consequence
      of broken host controller hardware.
      
      Includes bug fixes from the original patch, contributed by
      John Youn <John.Youn@synopsys.com> and Andy Green <AGreen@PLXTech.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8df75f42
    • A
      USB: fix usbmon and DMA mapping for scatter-gather URBs · ff9c895f
      Alan Stern 提交于
      This patch (as1368) fixes a rather obscure bug in usbmon: When tracing
      URBs sent by the scatter-gather library, it accesses the data buffers
      while they are still mapped for DMA.
      
      The solution is to move the mapping and unmapping out of the s-g
      library and into the usual place in hcd.c.  This requires the addition
      of new URB flag bits to describe the kind of mapping needed, since we
      have to call dma_map_sg() if the HCD supports native scatter-gather
      operation and dma_map_page() if it doesn't.  The nice thing about
      having the new flags is that they simplify the testing for unmapping.
      
      The patch removes the only caller of usb_buffer_[un]map_sg(), so those
      functions are #if'ed out.  A later patch will remove them entirely.
      
      As a result of this change, urb->sg will be set in situations where
      it wasn't set previously.  Hence the xhci and whci drivers are
      adjusted to test urb->num_sgs instead, which retains its original
      meaning and is nonzero only when the HCD has to handle a scatterlist.
      
      Finally, even when a submission error occurs we don't want to hand
      URBs to usbmon before they are unmapped.  The submission path is
      rearranged so that map_urb_for_dma() is called only for non-root-hub
      URBs and unmap_urb_for_dma() is called immediately after a submission
      error.  This simplifies the error handling.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      ff9c895f
    • S
      USB: xhci: Fix check for room on the ring. · 44ebd037
      Sarah Sharp 提交于
      The length of the scatter gather list a driver can enqueue is limited by
      the bus' sg_tablesize to 62 entries.  Each entry will be described by at
      least one transfer request block (TRB).  If the entry's buffer crosses a
      64KB boundary, then that entry will have to be described by two or more
      TRBs.  So even if the USB device driver respects sg_tablesize, the whole
      scatter list may take more than 62 TRBs to describe, and won't fit on
      the ring.
      
      Don't assume that an empty ring means there is enough room on the
      transfer ring.  The old code would unconditionally queue this too-large
      transfer, and over write the beginning of the transfer.  This would mean
      the cycle bit was unchanged in those overwritten transfers, causing the
      hardware to think it didn't own the TRBs, and the host would seem to
      hang.
      
      Now drivers may see submit_urb() fail with -ENOMEM if the transfers are
      too big to fit on the ring.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      44ebd037
    • S
      USB: xhci: Fix issue with set interface after stall. · 1624ae1c
      Sarah Sharp 提交于
      When the USB core installs a new interface, it unconditionally clears the
      halts on all the endpoints on the new interface.  Usually the xHCI host
      needs to know when an endpoint is reset, so it can change its internal
      endpoint state.  In this case, it doesn't care, because the endpoints were
      never halted in the first place.
      
      To avoid issuing a redundant Reset Endpoint command, the xHCI driver looks
      at xhci_virt_ep->stopped_td to determine if the endpoint was actually
      halted.  However, the functions that handle the stall never set that
      variable to NULL after it dealt with the stall.  So if an endpoint stalled
      and a Reset Endpoint command completed, and then the class driver tried to
      install a new alternate setting, the xHCI driver would access the old
      xhci_virt_ep->stopped_td pointer.  A similar problem occurs if the
      endpoint has been stopped to cancel a transfer.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      1624ae1c
  6. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  7. 03 3月, 2010 2 次提交
    • S
      USB: xhci: Notify the xHC when a device is reset. · 2a8f82c4
      Sarah Sharp 提交于
      When a USB device is reset, the xHCI hardware must know, in order to match
      the device state and disable all endpoints except control endpoint 0.
      Issue a Reset Device command after a USB device is successfully reset.
      Wait on the command to finish, and then cache or free the disabled
      endpoint rings.
      
      There are four different USB device states that the xHCI hardware tracks:
       - disabled/enabled - device connection has just been detected,
       - default - the device has been reset and has an address of 0,
       - addressed - the device has a non-zero address but no configuration has
         been set,
       - configured - a set configuration succeeded.
      
      The USB core may issue a port reset when a device is in any state, but the
      Reset Device command will fail for a 0.96 xHC if the device is not in the
      addressed or configured state.  Don't consider this failure as an error,
      but don't free any endpoint rings if this command fails.
      
      A storage driver may request that the USB device be reset during error
      handling, so use GPF_NOIO instead of GPF_KERNEL while allocating memory
      for the Reset Device command.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      2a8f82c4
    • S
      USB: xhci: Refactor test for vendor-specific completion codes. · b45b5069
      Sarah Sharp 提交于
      All commands that can be issued to the xHCI hardware can come back with
      vendor-specific "informational" completion codes.  These are to be treated
      like a successful completion code.  Refactor out the code to test for the
      range of these codes and print debugging messages.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b45b5069
  8. 12 12月, 2009 6 次提交
    • S
      USB: xhci: Fix command completion after a drop endpoint. · 06df5729
      Sarah Sharp 提交于
      The xHCI driver issues a Configure Endpoint command for two reasons:
       - a new configuration or alternate interface setting is selected
       - a quirky Fresco Logic prototype requires the command after a Reset
         Endpoint command.
      The xHCI driver only waits on the command in the first case.
      
      When a configure endpoint command completes, the driver needs to know why
      the command was generated.  When the driver only supported selecting an
      initial configuration, the check was simple.  Unfortunately that check
      doesn't work now that the driver supports alternate interfaces.  If an
      endpoint must be dropped (because it's not in the new alternate setting)
      and no new endpoints are added, the math involving
      xhci_last_valid_endpoint() will assign -1 to an unsigned integer and cause
      an out-of-bounds array access.
      
      Move the check for the quirky hardware sooner and avoid the bad array
      access.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      06df5729
    • S
      USB: xhci: Handle errors that cause endpoint halts. · bcef3fd5
      Sarah Sharp 提交于
      The xHCI 0.95 and 0.96 specification defines several transfer buffer
      request completion codes that indicate a USB transaction error occurred.
      When a stall, babble, transaction, or split transaction error completion code
      is set, the xHCI has halted that endpoint ring.  Software must issue a
      Reset Endpoint command and a Set Transfer Ring Dequeue Pointer command
      to clean up the halted ring.
      
      The USB device driver is supposed to call into usb_reset_endpoint() when
      an endpoint stalls.  That calls into the xHCI driver to issue the proper
      commands.  However, drivers don't call that function for the other
      errors that cause the xHC to halt the endpoint ring.  If a babble,
      transaction, or split transaction error occurs, check if the endpoint
      context reports a halted condition, and clean up the endpoint ring if it
      does.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      bcef3fd5
    • S
      USB: xhci: Return success for vendor-specific info codes. · 5ad6a529
      Sarah Sharp 提交于
      An xHCI host controller manufacturer can choose to implement several
      vendor-specific informational completion codes.  These are all to be
      treated like a successful transfer completion.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      5ad6a529
    • S
      USB: xhci: Return -EPROTO on a split transaction error. · ec74e403
      Sarah Sharp 提交于
      When the xHCI hardware says a transfer completed with a split
      transaction error, set the URB status to -EPROTO.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ec74e403
    • S
      USB: xhci: Set transfer descriptor size field correctly. · 04dd950d
      Sarah Sharp 提交于
      The transfer descriptor (TD) is a series of transfer request buffers
      (TRBs) that describe the buffer pointer, length, and other
      characteristics.  The xHCI controllers want to know an estimate of how
      long the TD is, for caching reasons.  In each TRB, there is a "TD size"
      field that provides a rough estimate of the remaining buffers to be
      transmitted, including the buffer pointed to by that TRB.
      
      The TD size is 5 bits long, and contains the remaining size in bytes,
      right shifted by 10 bits.  So a remaining TD size less than 1024 would get
      a zero in the TD size field, and a remaining size greater than 32767 would
      get 31 in the field.
      
      This patches fixes a bug in the TD_REMAINDER macro that is triggered when
      the URB has a scatter gather list with a size bigger than 32767 bytes.
      Not all host controllers pay attention to the TD size field, so the bug
      will not appear on all USB 3.0 hosts.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      04dd950d
    • S
      USB: xhci: Add tests for TRB address translation. · 6648f29d
      Sarah Sharp 提交于
      It's not surprising that the transfer request buffer (TRB) physical to
      virtual address translation function has bugs in it, since I wrote most of
      it at 4am last October.  Add a test suite to check the TRB math.  This
      runs at memory initialization time, and causes the driver to fail to load
      if the TRB math fails.
      
      Please excuse the excessively long lines in the test vectors; they can't
      really be made shorter and still be readable.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6648f29d