1. 08 2月, 2014 1 次提交
  2. 31 1月, 2014 1 次提交
  3. 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
  4. 09 1月, 2014 1 次提交
  5. 18 12月, 2013 1 次提交
  6. 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
  7. 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
  8. 17 10月, 2013 18 次提交
  9. 24 9月, 2013 4 次提交
    • 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
    • M
      xhci: Ensure a command structure points to the correct trb on the command ring · ec7e43e2
      Mathias Nyman 提交于
      If a command on the command ring needs to be cancelled before it is handled
      it can be turned to a no-op operation when the ring is stopped.
      We want to store the command ring enqueue pointer in the command structure
      when the command in enqueued for the cancellation case.
      
      Some commands used to store the command ring dequeue pointers instead of enqueue
      (these often worked because enqueue happends to equal dequeue quite often)
      
      Other commands correctly used the enqueue pointer but did not check if it pointed
      to a valid trb or a link trb, this caused for example stop endpoint command to timeout in
      xhci_stop_device() in about 2% of suspend/resume cases.
      
      This should also solve some weird behavior happening in command cancellation cases.
      
      This patch is based on a patch submitted by Sarah Sharp to linux-usb, but
      then forgotten:
          http://marc.info/?l=linux-usb&m=136269803207465&w=2
      
      This patch should be backported to kernels as old as 3.7, that contain
      the commit b92cc66c "xHCI: add aborting
      command ring function"
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      ec7e43e2
    • M
      xhci: Fix oops happening after address device timeout · 284d2055
      Mathias Nyman 提交于
      When a command times out, the command ring is first aborted,
      and then stopped. If the command ring is empty when it is stopped
      the stop event will point to next command which is not yet set.
      xHCI tries to handle this next event often causing an oops.
      
      Don't handle command completion events on stopped cmd ring if ring is
      empty.
      
      This patch should be backported to kernels as old as 3.7, that contain
      the commit b92cc66c "xHCI: add aborting
      command ring function"
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Reported-by: NGiovanni <giovanni.nervi@yahoo.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      284d2055
  10. 27 8月, 2013 1 次提交
  11. 14 8月, 2013 5 次提交