1. 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
  2. 05 3月, 2014 6 次提交
  3. 08 2月, 2014 2 次提交
  4. 31 1月, 2014 1 次提交
  5. 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
  6. 09 1月, 2014 1 次提交
  7. 18 12月, 2013 1 次提交
  8. 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
  9. 03 12月, 2013 6 次提交
    • 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
    • X
      xhci: replace xhci_readl() with readl() · b0ba9720
      Xenia Ragiadakou 提交于
      Function xhci_readl() is used to read 32bit 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_readl() internally simply calls readl(). This creates
      an illusion that xhci_readl() is an xhci specific function that has to be
      called in a context where a pointer to xhci_hcd is available.
      
      Remove the unnecessary xhci_readl() wrapper function and replace its calls to
      with calls to readl() to make the code more straightforward.
      Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      b0ba9720
    • X
      xhci: fix incorrect type in assignment in handle_device_notification() · 7e76ad43
      Xenia Ragiadakou 提交于
      This patch converts Event TRB's 3rd field, which has type le32, to CPU
      byteorder before using it to retrieve the Slot ID with TRB_TO_SLOT_ID macro.
      This bug was found using sparse.
      Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      7e76ad43
    • D
      usb: xhci: Link TRB must not occur within a USB payload burst · 35773dac
      David Laight 提交于
      Section 4.11.7.1 of rev 1.0 of the xhci specification states that a link TRB
      can only occur at a boundary between underlying USB frames (512 bytes for
      high speed devices).
      
      If this isn't done the USB frames aren't formatted correctly and, for example,
      the USB3 ethernet ax88179_178a card will stop sending (while still receiving)
      when running a netperf tcp transmit test with (say) and 8k buffer.
      
      This should be a candidate for stable, the ax88179_178a driver defaults to
      gso and tso enabled so it passes a lot of fragmented skb to the USB stack.
      
      Notes from Sarah:
      
      Discussion: http://marc.info/?l=linux-usb&m=138384509604981&w=2
      
      This patch fixes a long-standing xHCI driver bug that was revealed by a
      change in 3.12 in the usb-net driver.  Commit
      638c5115 "USBNET: support DMA SG" added
      support to use bulk endpoint scatter-gather (urb->sg).  Only the USB
      ethernet drivers trigger this bug, because the mass storage driver sends
      sg list entries in page-sized chunks.
      
      This patch only fixes the issue for bulk endpoint scatter-gather.  The
      problem will still occur for periodic endpoints, because hosts will
      interpret no-op transfers as a request to skip a service interval, which
      is not what we want.
      
      Luckily, the USB core isn't set up for scatter-gather on isochronous
      endpoints, and no USB drivers use scatter-gather for interrupt
      endpoints.  Document this known limitation so that developers won't try
      to use urb->sg for interrupt endpoints until this issue is fixed.  The
      more comprehensive fix would be to allow link TRBs in the middle of the
      endpoint ring and revert this patch, but that fix would touch too much
      code to be allowed in for stable.
      
      This patch should be backported to kernels as old as 3.12, that contain
      the commit 638c5115 "USBNET: support DMA
      SG".  Without this patch, the USB network device gets wedged, and stops
      sending packets.  Mark Lord confirms this patch fixes the regression:
      
      http://marc.info/?l=linux-netdev&m=138487107625966&w=2Signed-off-by: NDavid Laight <david.laight@aculab.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Tested-by: NMark Lord <mlord@pobox.com>
      Cc: stable@vger.kernel.org
      35773dac
  10. 17 10月, 2013 18 次提交
  11. 24 9月, 2013 2 次提交
    • F
      xhci: Fix race between ep halt and URB cancellation · 526867c3
      Florian Wolter 提交于
      The halted state of a endpoint cannot be cleared over CLEAR_HALT from a
      user process, because the stopped_td variable was overwritten in the
      handle_stopped_endpoint() function. So the xhci_endpoint_reset() function will
      refuse the reset and communication with device can not run over this endpoint.
      https://bugzilla.kernel.org/show_bug.cgi?id=60699Signed-off-by: NFlorian Wolter <wolly84@web.de>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      526867c3
    • 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