1. 23 7月, 2015 1 次提交
    • A
      usb: xhci: Bugfix for NULL pointer deference in xhci_endpoint_init() function · 34968106
      AMAN DEEP 提交于
      virt_dev->num_cached_rings counts on freed ring and is not updated
      correctly. In xhci_free_or_cache_endpoint_ring() function, the free ring
      is added into cache and then num_rings_cache is incremented as below:
      		virt_dev->ring_cache[rings_cached] =
      			virt_dev->eps[ep_index].ring;
      		virt_dev->num_rings_cached++;
      here, free ring pointer is added to a current index and then
      index is incremented.
      So current index always points to empty location in the ring cache.
      For getting available free ring, current index should be decremented
      first and then corresponding ring buffer value should be taken from ring
      cache.
      
      But In function xhci_endpoint_init(), the num_rings_cached index is
      accessed before decrement.
      		virt_dev->eps[ep_index].new_ring =
      			virt_dev->ring_cache[virt_dev->num_rings_cached];
      		virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL;
      		virt_dev->num_rings_cached--;
      This is bug in manipulating the index of ring cache.
      And it should be as below:
      		virt_dev->num_rings_cached--;
      		virt_dev->eps[ep_index].new_ring =
      			virt_dev->ring_cache[virt_dev->num_rings_cached];
      		virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL;
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAman Deep <aman.deep@samsung.com>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      34968106
  2. 10 1月, 2015 2 次提交
  3. 24 9月, 2014 1 次提交
  4. 12 9月, 2014 2 次提交
  5. 29 5月, 2014 1 次提交
  6. 20 5月, 2014 3 次提交
    • 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
  7. 05 3月, 2014 5 次提交
    • H
      xhci: The trb_address_map radix tree expects 1KB segment memory aligment · 84c1e40f
      Hans de Goede 提交于
      If we align segment dma pool memory to 64 bytes, then a segment can be located
      at 0x10000040 - 0x1000043f, and a segment from another ring at 0x10000440 -
      0x1000083f. The last trb in the first segment at 0x10000430 will then translate
      to the same radix tree key as the first trb of the second segment, while they
      are in different rings!
      
      This patches fixes this by changing the alignment of the dma pool to be 1KB
      rather then 64 bytes. An alternative fix would be to reduce the shift used
      to calculate the radix tree keys, but that would (slighlty) grow the radix
      trees so I believe this is the better fix.
      
      Note this patch is mostly theoretical since in practice I've not seen
      the dma_pool actually return not 1KB aligned memory.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      84c1e40f
    • H
      xhci: xhci_mem_cleanup: make sure cmd_ring_reserved_trbs really is 0 · 127329d7
      Hans de Goede 提交于
      cmd_ring_reserved_trbs gets decremented by xhci_free_stream_info(), so set it
      to 0 after freeing all rings, otherwise it wraps around to a very large value
      when rings with streams are free-ed.
      
      Before this patch the wrap-around could be triggered when xhci_resume
      calls xhci_mem_cleanup if the controller resume fails.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      127329d7
    • S
      xhci: Remove segments from radix tree on failed insert. · d5734223
      Sarah Sharp 提交于
      If we're expanding a stream ring, we want to make sure we can add those
      ring segments to the radix tree that maps segments to ring pointers.
      Try the radix tree insert after the new ring segments have been allocated
      (the last segment in the new ring chunk will point to the first newly
      allocated segment), but before the new ring segments are linked into the
      old ring.
      
      If insert fails on any one segment, remove each segment from the radix
      tree, deallocate the new segments, and return.  Otherwise, link the new
      segments into the tree.
      
      HdG: Add a check to only update stream mappings in xhci_ring_expansion when
      the ring is a stream ring.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      d5734223
    • H
      xhci: Check size rather then number of streams when allocating stream ctxs · ee4aa54b
      Hans de Goede 提交于
      Before this a device needing ie 32 stream ctxs would end up with an entry from
      the small_streams_pool which has 256 bytes entries, where as 32 stream ctxs
      need 512 bytes. Things actually keep running for a surprisingly long time
      before crashing because of this.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      ee4aa54b
    • G
      xhci: fix usb3 streams · 15341303
      Gerd Hoffmann 提交于
      xhci maintains a radix tree for each stream endpoint because it must
      be able to map a trb address to the stream ring.  Each ring segment
      must be added to the ring for this to work.  Currently xhci sticks
      only the first segment of each stream ring into the radix tree.
      
      Result is that things work initially, but as soon as the first segment
      is full xhci can't map the trb address from the completion event to the
      stream ring any more -> BOOM.  You'll find this message in the logs:
      
        ERROR Transfer event for disabled endpoint or incorrect stream ring
      
      This patch adds a helper function to update the radix tree, and a
      function to remove ring segments from the tree.  Both functions loop
      over the segment list and handles all segments instead of just the
      first.
      
      [Note: Sarah changed this patch to add radix_tree_maybe_preload() and
      radix_tree_preload_end() calls around the radix tree insert, since we
      can now insert entries in interrupt context.  There are now two helper
      functions to make the code cleaner, and those functions are moved to
      make them static.]
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      15341303
  8. 31 1月, 2014 1 次提交
  9. 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
  10. 03 12月, 2013 7 次提交
  11. 17 10月, 2013 1 次提交
    • S
      usb: Don't enable USB 2.0 Link PM by default. · de68bab4
      Sarah Sharp 提交于
      How it's supposed to work:
      --------------------------
      
      USB 2.0 Link PM is a lower power state that some newer USB 2.0 devices
      support.  USB 3.0 devices certified by the USB-IF are required to
      support it if they are plugged into a USB 2.0 only port, or a USB 2.0
      cable is used.  USB 2.0 Link PM requires both a USB device and a host
      controller that supports USB 2.0 hardware-enabled LPM.
      
      USB 2.0 Link PM is designed to be enabled once by software, and the host
      hardware handles transitions to the L1 state automatically.  The premise
      of USB 2.0 Link PM is to be able to put the device into a lower power
      link state when the bus is idle or the device NAKs USB IN transfers for
      a specified amount of time.
      
      ...but hardware is broken:
      --------------------------
      
      It turns out many USB 3.0 devices claim to support USB 2.0 Link PM (by
      setting the LPM bit in their USB 2.0 BOS descriptor), but they don't
      actually implement it correctly.  This manifests as the USB device
      refusing to respond to transfers when it is plugged into a USB 2.0 only
      port under the Haswell-ULT/Lynx Point LP xHCI host.
      
      These devices pass the xHCI driver's simple test to enable USB 2.0 Link
      PM, wait for the port to enter L1, and then bring it back into L0.  They
      only start to break when L1 entry is interleaved with transfers.
      
      Some devices then fail to respond to the next control transfer (usually
      a Set Configuration).  This results in devices never enumerating.
      
      Other mass storage devices (such as a later model Western Digital My
      Passport USB 3.0 hard drive) respond fine to going into L1 between
      control transfers.  They ACK the entry, come out of L1 when the host
      needs to send a control transfer, and respond properly to those control
      transfers.  However, when the first READ10 SCSI command is sent, the
      device NAKs the data phase while it's reading from the spinning disk.
      Eventually, the host requests to put the link into L1, and the device
      ACKs that request.  Then it never responds to the data phase of the
      READ10 command.  This results in not being able to read from the drive.
      
      Some mass storage devices (like the Corsair Survivor USB 3.0 flash
      drive) are well behaved.  They ACK the entry into L1 during control
      transfers, and when SCSI commands start coming in, they NAK the requests
      to go into L1, because they need to be at full power.
      
      Not all USB 3.0 devices advertise USB 2.0 link PM support.  My Point
      Grey USB 3.0 webcam advertises itself as a USB 2.1 device, but doesn't
      have a USB 2.0 BOS descriptor, so we don't enable USB 2.0 Link PM.  I
      suspect that means the device isn't certified.
      
      What do we do about it?
      -----------------------
      
      There's really no good way for the kernel to test these devices.
      Therefore, the kernel needs to disable USB 2.0 Link PM by default, and
      distros will have to enable it by writing 1 to the sysfs file
      /sys/bus/usb/devices/../power/usb2_hardware_lpm.  Rip out the xHCI Link
      PM test, since it's not sufficient to detect these buggy devices, and
      don't automatically enable LPM after the device is addressed.
      
      This patch should be backported to kernels as old as 3.11, that
      contain the commit a558ccdc "usb: xhci:
      add USB2 Link power management BESL support".  Without this fix, some
      USB 3.0 devices will not enumerate or work properly under USB 2.0 ports
      on Haswell-ULT systems.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      de68bab4
  12. 24 9月, 2013 1 次提交
    • S
      usb: Fix xHCI host issues on remote wakeup. · 8b3d4570
      Sarah Sharp 提交于
      When a device signals remote wakeup on a roothub, and the suspend change
      bit is set, the host controller driver must not give control back to the
      USB core until the port goes back into the active state.
      
      EHCI accomplishes this by waiting in the get port status function until
      the PORT_RESUME bit is cleared:
      
                              /* stop resume signaling */
                              temp &= ~(PORT_RWC_BITS | PORT_SUSPEND | PORT_RESUME);
                              ehci_writel(ehci, temp, status_reg);
                              clear_bit(wIndex, &ehci->resuming_ports);
                              retval = ehci_handshake(ehci, status_reg,
                                              PORT_RESUME, 0, 2000 /* 2msec */);
      
      Similarly, the xHCI host should wait until the port goes into U0, before
      passing control up to the USB core.  When the port transitions from the
      RExit state to U0, the xHCI driver will get a port status change event.
      We need to wait for that event before passing control up to the USB
      core.
      
      After the port transitions to the active state, the USB core should time
      a recovery interval before it talks to the device.  The length of that
      recovery interval is TRSMRCY, 10 ms, mentioned in the USB 2.0 spec,
      section 7.1.7.7.  The previous xHCI code (which did not wait for the
      port to go into U0) would cause the USB core to violate that recovery
      interval.
      
      This bug caused numerous USB device disconnects on remote wakeup under
      ChromeOS and a Lynx Point LP xHCI host that takes up to 20 ms to move
      from RExit to U0.  ChromeOS is very aggressive about power savings, and
      sets the autosuspend_delay to 100 ms, and disables USB persist.
      
      I attempted to replicate this bug with Ubuntu 12.04, but could not.  I
      used Ubuntu 12.04 on the same platform, with the same BIOS that the bug
      was triggered on ChromeOS with.  I also changed the USB sysfs settings
      as described above, but still could not reproduce the bug under Ubuntu.
      It may be that ChromeOS userspace triggers this bug through additional
      settings.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      8b3d4570
  13. 14 8月, 2013 4 次提交
  14. 01 8月, 2013 1 次提交
    • J
      usb: xhci: add missing dma-mapping.h includes · 008eb957
      James Hogan 提交于
      A randconfig build hit the following build errors because xhci.c and
      xhci-mem.c use dma mapping functions but don't include
      <linux/dma-mapping.h>. Add the missing includes to fix the build errors.
      
      drivers/usb/host/xhci.c In function 'xhci_gen_setup':
      drivers/usb/host/xhci.c +4872 : error: implicit declaration of function 'dma_set_mask'
      drivers/usb/host/xhci.c +4872 : error: implicit declaration of function 'DMA_BIT_MASK'
      
      drivers/usb/host/xhci-mem.c In function 'xhci_free_stream_ctx':
      drivers/usb/host/xhci-mem.c +435 : error: implicit declaration of function 'dma_free_coherent'
      drivers/usb/host/xhci-mem.c In function 'xhci_alloc_stream_ctx':
      drivers/usb/host/xhci-mem.c +463 : error: implicit declaration of function 'dma_alloc_coherent'
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: linux-usb@vger.kernel.org
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      008eb957
  15. 19 6月, 2013 1 次提交
  16. 15 6月, 2013 4 次提交
  17. 06 6月, 2013 1 次提交
  18. 25 5月, 2013 2 次提交
  19. 16 5月, 2013 1 次提交
    • A
      USB: xHCI: override bogus bulk wMaxPacketSize values · e4f47e36
      Alan Stern 提交于
      This patch shortens the logic in xhci_endpoint_init() by moving common
      calculations involving max_packet and max_burst outside the switch
      statement, rather than repeating the same code in multiple
      case-specific statements.  It also replaces two usages of max_packet
      which were clearly intended to be max_burst all along.
      
      More importantly, it compensates for a common bug in high-speed bulk
      endpoint descriptors.  In many devices there is a bulk endpoint having
      a wMaxPacketSize value smaller than 512, which is forbidden by the USB
      spec.  Some xHCI controllers can't handle this and refuse to accept
      the endpoint.  This patch changes the max_packet value to 512, which
      allows the controller to use the endpoint properly.
      
      In practice the bogus maxpacket size doesn't matter, because none of
      the transfers sent via these endpoints are longer than the maxpacket
      value anyway.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: N"Aurélien Leblond" <blablack@gmail.com>
      CC: <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e4f47e36