Skip to content

L
linux
Switch branch/tag
  1. 20 May, 2010 3 commits
    • Sarah Sharp's avatar
      USB: xhci: Fix check for room on the ring. · 44ebd037
      Sarah Sharp authored 
      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: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      44ebd037
    • Sarah Sharp's avatar
      USB: xhci: Limit bus sg_tablesize to 62 TRBs. · bc88d2eb
      Sarah Sharp authored 
      When a scatter-gather list is enqueued to the xHCI driver, it translates
each entry into a transfer request block (TRB).  Only 63 TRBs can be
used per ring segment, and there must be one additional TRB reserved to
make sure the hardware does not think the ring is empty (so the enqueue
pointer doesn't equal the dequeue pointer).  Limit the bus sg_tablesize
to 62 TRBs.
Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      bc88d2eb
    • Sarah Sharp's avatar
      USB: xhci: Fix issue with set interface after stall. · 1624ae1c
      Sarah Sharp authored 
      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: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      1624ae1c
  3. 16 May, 2010 6 commits
  5. 15 May, 2010 17 commits
  7. 14 May, 2010 14 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7