1. 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
  2. 03 12月, 2013 8 次提交
  3. 17 10月, 2013 5 次提交
    • D
      usb: xhci: remove the unused ->address field · a2cdc343
      Dan Williams 提交于
      Only used for debug output, so we don't need to save it.
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      a2cdc343
    • X
      xhci: correct the usage of USB_CTRL_SET_TIMEOUT · d194c031
      xiao jin 提交于
      The usage of USB_CTRL_SET_TIMEOUT in xhci is incorrect.
      The definition of USB_CTRL_SET_TIMEOUT is 5000ms. The
      input timeout to wait_for_completion_interruptible_timeout
      is jiffies. That makes the timeout be longer than what
      we want, such as 50s in some platform.
      
      The patch is to use XHCI_CMD_DEFAULT_TIMEOUT instead of
      USB_CTRL_SET_TIMEOUT as command completion event timeout.
      Signed-off-by: Nxiao jin <jin.xiao@intel.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      d194c031
    • S
      usb: Push USB2 LPM disable on disconnect into USB core. · f468f7b9
      Sarah Sharp 提交于
      The USB core currently handles enabling and disabling optional USB power
      management features during device transitions (device suspend/resume,
      driver bind/unbind, device reset, and device disconnect).  Those
      optional power features include Latency Tolerance Messaging (LTM),
      USB 3.0 Link PM, and USB 2.0 Link PM.
      
      The USB core currently enables LPM on device enumeration and disables
      USB 2.0 Link PM when the device is reset.  However, the xHCI driver
      disables LPM when the device is disconnected and the device context is
      freed.  Push the call up into the USB core, in order to be consistent
      with the core handling all power management enabling and disabling.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      f468f7b9
    • 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
    • S
      xhci: Set L1 device slot on USB2 LPM enable/disable. · 58e21f73
      Sarah Sharp 提交于
      To enable USB 2.0 Link Power Management (LPM), the xHCI host controller
      needs the device slot ID to generate the device address used in L1 entry
      tokens.  That information is set in the L1 device slot ID field of the
      USB 2.0 LPM registers.
      
      Currently, the L1 device slot ID is overwritten when the xHCI driver
      initiates the software test of USB 2.0 Link PM in
      xhci_usb2_software_lpm_test.  It is never cleared when USB 2.0 Link PM
      is disabled for the device.  That should be harmless, because the
      Hardware LPM Enable (HLE) bit is cleared when USB 2.0 Link PM is
      disabled, so the host should not pay attention to the slot ID.
      
      This patch should have no effect on host behavior, but since
      xhci_usb2_software_lpm_test is going away in an upcoming bug fix patch,
      we need to move that code to the function that enables and disables USB
      2.0 Link PM.
      
      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".  The upcoming bug fix patch is also
      marked for that stable kernel.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      58e21f73
  4. 10 10月, 2013 2 次提交
    • T
      xhci: Fix spurious wakeups after S5 on Haswell · 638298dc
      Takashi Iwai 提交于
      Haswell LynxPoint and LynxPoint-LP with the recent Intel BIOS show
      mysterious wakeups after shutdown occasionally.  After discussing with
      BIOS engineers, they explained that the new BIOS expects that the
      wakeup sources are cleared and set to D3 for all wakeup devices when
      the system is going to sleep or power off, but the current xhci driver
      doesn't do this properly (partly intentionally).
      
      This patch introduces a new quirk, XHCI_SPURIOUS_WAKEUP, for
      fixing the spurious wakeups at S5 by calling xhci_reset() in the xhci
      shutdown ops as done in xhci_stop(), and setting the device to PCI D3
      at shutdown and remove ops.
      
      The PCI D3 call is based on the initial fix patch by Oliver Neukum.
      
      [Note: Sarah changed the quirk name from XHCI_HSW_SPURIOUS_WAKEUP to
      XHCI_SPURIOUS_WAKEUP, since none of the other quirks have system names
      in them.  Sarah also fixed a collision with a quirk submitted around the
      same time, by changing the xhci->quirks bit from 17 to 18.]
      
      This patch should be backported to kernels as old as 3.0, that
      contain the commit 1c12443a "xhci: Add
      Lynx Point to list of Intel switchable hosts."
      
      Cc: Oliver Neukum <oneukum@suse.de>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      638298dc
    • O
      xhci: quirk for extra long delay for S4 · 455f5892
      Oliver Neukum 提交于
      It has been reported that this chipset really cannot
      sleep without this extraordinary delay.
      
      This patch should be backported, in order to ensure this host functions
      under stable kernels.  The last quirk for Fresco Logic hosts (commit
      bba18e33 "xhci: Extend Fresco Logic MSI
      quirk.") was backported to stable kernels as old as 2.6.36.
      Signed-off-by: NOliver Neukum <oneukum@suse.de>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      455f5892
  5. 24 9月, 2013 1 次提交
    • 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
  6. 29 8月, 2013 1 次提交
    • S
      xhci: Fix warning introduced by disabling runtime PM. · e7ecf069
      Sarah Sharp 提交于
      The 0day build server caught a new build warning that is triggered when
      CONFIG_USB_DEFAULT_PERSIST is turned on:
      
      tree:   git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git for-usb-next
      head:   0730d52a
      commit: c8476fb8 [1/3] usb: xhci: Disable runtime PM suspend for quirky controllers
      config: i386-randconfig-r6-0826 (attached as .config)
      
      All warnings:
      
         drivers/usb/host/xhci.c: In function 'xhci_free_dev':
      >> drivers/usb/host/xhci.c:3560:17: warning: unused variable 'dev' [-Wunused-variable]
           struct device *dev = hcd->self.controller;
                          ^
         drivers/usb/host/xhci.c: In function 'xhci_alloc_dev':
      >> drivers/usb/host/xhci.c:3648:17: warning: unused variable 'dev' [-Wunused-variable]
           struct device *dev = hcd->self.controller;
                          ^
      
      vim +/dev +3560 drivers/usb/host/xhci.c
      
        3554   * disabled.  Free any HC data structures associated with that device.
        3555   */
        3556  void xhci_free_dev(struct usb_hcd *hcd, struct usb_device *udev)
        3557  {
        3558          struct xhci_hcd *xhci = hcd_to_xhci(hcd);
        3559          struct xhci_virt_device *virt_dev;
      > 3560          struct device *dev = hcd->self.controller;
        3561          unsigned long flags;
        3562          u32 state;
        3563          int i, ret;
        3564
        3565  #ifndef CONFIG_USB_DEFAULT_PERSIST
        3566          /*
        3567           * We called pm_runtime_get_noresume when the device was attached.
        3568           * Decrement the counter here to allow controller to runtime suspend
        3569           * if no devices remain.
        3570           */
        3571          if (xhci->quirks & XHCI_RESET_ON_RESUME)
        3572                  pm_runtime_put_noidle(dev);
        3573  #endif
        3574
      ...
        3641  /*
        3642   * Returns 0 if the xHC ran out of device slots, the Enable Slot command
        3643   * timed out, or allocating memory failed.  Returns 1 on success.
        3644   */
        3645  int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device *udev)
        3646  {
        3647          struct xhci_hcd *xhci = hcd_to_xhci(hcd);
      > 3648          struct device *dev = hcd->self.controller;
        3649          unsigned long flags;
        3650          int timeleft;
        3651          int ret;
      
      Fix this.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Shawn Nematbakhsh <shawnn@chromium.org>
      e7ecf069
  7. 27 8月, 2013 1 次提交
    • S
      usb: xhci: Disable runtime PM suspend for quirky controllers · c8476fb8
      Shawn Nematbakhsh 提交于
      If a USB controller with XHCI_RESET_ON_RESUME goes to runtime suspend,
      a reset will be performed upon runtime resume. Any previously suspended
      devices attached to the controller will be re-enumerated at this time.
      This will cause problems, for example, if an open system call on the
      device triggered the resume (the open call will fail).
      
      Note that this change is only relevant when persist_enabled is not set
      for USB devices.
      
      This patch should be backported to kernels as old as 3.0, that
      contain the commit c877b3b2 "xhci: Add
      reset on resume quirk for asrock p67 host".
      Signed-off-by: NShawn Nematbakhsh <shawnn@chromium.org>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      c8476fb8
  8. 16 8月, 2013 1 次提交
    • S
      xhci-plat: Don't enable legacy PCI interrupts. · 52fb6125
      Sarah Sharp 提交于
      The xHCI platform driver calls into usb_add_hcd to register the irq for
      its platform device.  It does not want the xHCI generic driver to
      register an interrupt for it at all.  The original code did that by
      setting the XHCI_BROKEN_MSI quirk, which tells the xHCI driver to not
      enable MSI or MSI-X for a PCI host.
      
      Unfortunately, if CONFIG_PCI is enabled, and CONFIG_USB_DW3 is enabled,
      the xHCI generic driver will attempt to register a legacy PCI interrupt
      for the xHCI platform device in xhci_try_enable_msi().  This will result
      in a bogus irq being registered, since the underlying device is a
      platform_device, not a pci_device, and thus the pci_device->irq pointer
      will be bogus.
      
      Add a new quirk, XHCI_PLAT, so that the xHCI generic driver can
      distinguish between a PCI device that can't handle MSI or MSI-X, and a
      platform device that should not have its interrupts touched at all.
      This quirk may be useful in the future, in case other corner cases like
      this arise.
      
      This patch should be backported to kernels as old as 3.9, that
      contain the commit 00eed9c8 "USB: xhci:
      correctly enable interrupts".
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Reported-by: NYu Y Wang <yu.y.wang@intel.com>
      Tested-by: NYu Y Wang <yu.y.wang@intel.com>
      Reviewed-by: NFelipe Balbi <balbi@ti.com>
      Cc: stable@vger.kernel.org
      52fb6125
  9. 14 8月, 2013 11 次提交
    • X
      xhci: fix dma mask setup in xhci.c · c10cf118
      Xenia Ragiadakou 提交于
      The function dma_set_mask() tests internally whether the dma_mask pointer
      for the device is initialized and fails if the dma_mask pointer is NULL.
      On pci platforms, the device dma_mask pointer is initialized, when pci
      devices are enumerated, to point to the pci_dev->dma_mask which is 0xffffffff.
      However, for non-pci platforms, the dma_mask pointer may not be initialized
      and in that case dma_set_mask() will fail.
      
      This patch initializes the dma_mask and the coherent_dma_mask to 32bits
      in xhci_plat_probe(), before the call to usb_create_hcd() that sets the
      "uses_dma" flag for the usb bus and the call to usb_add_hcd() that creates
      coherent dma pools for the usb hcd.
      
      Moreover, a call to dma_set_mask() does not set the device coherent_dma_mask.
      Since the xhci-hcd driver calls dma_alloc_coherent() and dma_pool_alloc()
      to allocate consistent DMA memory blocks, the coherent DMA address mask
      has to be set explicitly.
      
      This patch sets the coherent_dma_mask to 64bits in xhci_gen_setup() when
      the xHC is capable for 64-bit DMA addressing.
      
      If dma_set_mask() succeeds, for a given bitmask, it is guaranteed that
      the given bitmask is also supported for consistent DMA mappings.
      
      Other changes introduced in this patch are:
      
      - The return value of dma_set_mask() is checked to ensure that the required
        dma bitmask conforms with the host system's addressing capabilities.
      
      - The dma_mask setup code for the non-primary hcd was removed since both
        primary and non-primary hcd refer to the same generic device whose
        dma_mask and coherent_dma_mask are already set during the setup of
        the primary hcd.
      
      - The code for reading the HCCPARAMS register to find out the addressing
        capabilities of xHC was removed since its value is already cached in
        xhci->hccparams.
      
      - hcd->self.controller was replaced with the dev variable since it is
        already available.
      Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      c10cf118
    • X
      xhci: trace debug messages related to driver initialization and unload · d195fcff
      Xenia Ragiadakou 提交于
      This patch defines a new trace event, which is called xhci_dbg_init
      and belongs to the event class xhci_log_msg, and adds tracepoints that
      trace the debug statements in the functions used to start and stop the
      xhci-hcd driver.
      
      Also, it removes an unnecessary cast of variable val to unsigned int
      in xhci_mem_init(), since val is already declared as unsigned int.
      Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      d195fcff
    • X
      xhci: trace debug statements for urb cancellation · aa50b290
      Xenia Ragiadakou 提交于
      This patch defines a new trace event, which is called xhci_dbg_cancel_urb
      and belongs to the event class xhci_log_msg, and adds tracepoints that
      trace the debug messages related to the removal of a cancelled URB from
      the endpoint's transfer ring.
      Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      aa50b290
    • X
      xhci: add xhci_address_ctx trace event · 1d27fabe
      Xenia Ragiadakou 提交于
      This patch defines a new event class, called xhci_log_ctx,
      that records in the ring buffer the context data, the
      context type (input or output), the context dma and virtual
      addresses, the context endpoint entries, the slot ID and
      whether the xHC uses 64 byte context data structures.
      
      This information can be used, later, to parse and display
      the context data fields with the appropriate plugin using
      the trace-cmd tool.
      
      Also, this patch defines a trace event, called xhci_address_ctx,
      to trace the contexts related to the Address Device command and
      adds the associated tracepoints in xhci_address_device().
      Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      1d27fabe
    • X
      xhci: add trace for debug messages related to endpoint reset · a0254324
      Xenia Ragiadakou 提交于
      This patch defines a new trace event, which is called xhci_dbg_reset_ep
      and belongs in the event class xhci_log_msg, and adds tracepoints that
      trace the debug messages associated with resetting an endpoint after
      the reception of a STALL packet.
      Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      a0254324
    • X
      xhci: add trace for debug messages related to quirks · 4bdfe4c3
      Xenia Ragiadakou 提交于
      This patch defines a new trace event, which is called xhci_dbg_quirks
      and belongs in the event class xhci_log_msg, and adds tracepoints that
      trace the debug messages associated with xHCs' quirks.
      Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      4bdfe4c3
    • X
      xhci: add trace for debug messages related to changing contexts · 3a7fa5be
      Xenia Ragiadakou 提交于
      This patch defines a new trace event, which is called xhci_dbg_context_change
      and belongs in the event class xhci_log_msg, and adds tracepoints for tracing
      the debug messages related to context updates performed with Configure Endpoint
      and Evaluate Context commands.
      Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      3a7fa5be
    • X
      xhci: add traces for debug messages in xhci_address_device() · 84a99f6f
      Xenia Ragiadakou 提交于
      This patch declares an event class for trace events that
      trace messages with variadic arguments, called xhci_log_msg,
      and defines a trace event for tracing the debug messages in
      xhci_address_device() function, called xhci_dbg_address.
      
      In order to implement this type of trace events, a wrapper function,
      called xhci_dbg_trace(), was created that records the format string
      and variadic arguments into a va_format structure which is passed as
      argument to the tracepoints of the class xhci_log_msg.
      
      All the xhci_dbg() calls in xhci_address_device() are replaced
      with calls to xhci_dbg_trace(). The functionality of xhci_dbg()
      log messages was not removed though, but it is placed inside
      xhci_dbg_trace().
      
      This trace event aims to give the ability to the user or the
      developper to isolate and trace the debug messages generated
      when an Address Device Command is issued to xHC.
      Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      84a99f6f
    • X
      xhci: remove CONFIG_USB_XHCI_HCD_DEBUGGING and unused code · b2497509
      Xenia Ragiadakou 提交于
      CONFIG_USB_XHCI_HCD_DEBUGGING option is used to enable
      verbose debugging output for the xHCI host controller
      driver.
      
      In the current version of the xhci-hcd driver, this
      option must be turned on, in order for the debugging
      log messages to be displayed, and users may need to
      recompile the linux kernel to obtain debugging
      information that will help them track down problems.
      
      This patch removes the above debug option to enable
      debugging log messages at all times.
      The aim of this is to rely on the debugfs and the
      dynamic debugging feature for fine-grained management
      of debugging messages and to not force users to set
      the debug config option and compile the linux kernel
      in order to have access in that information.
      
      This patch, also, removes the XHCI_DEBUG symbol and the
      functions dma_to_stream_ring(), xhci_test_radix_tree()
      and xhci_event_ring_work() that are not useful anymore.
      Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      b2497509
    • X
      xhci: replace printk(KERN_DEBUG ...) · 5c1127d3
      Xenia Ragiadakou 提交于
      This patch replaces the calls to printk(KERN_DEBUG ...)
      with either calls to xhci_dbg() or calls to pr_debug(),
      depending on whether the xhci_hcd structure is available
      at callsite, so that the correspoding debugging messages
      are not enabled by default when CONFIG_DYNAMIC_DEBUG option
      is set but rather can be enabled dynamically taking advantage
      of the dynamic debugging feature.
      
      Also, it adds a newline at the end of debugging messages in
      case there is not, so that messages don't appear broken
      when printed.
      Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      5c1127d3
    • X
      xhci: replace xhci_info() with xhci_dbg() · 38a532a6
      Xenia Ragiadakou 提交于
      This patch replaces the calls to xhci_info() with calls to
      xhci_dbg() and removes the unused xhci_info() definition
      from xhci-hcd.
      
      By replacing the xhci_info() with xhci_dbg(), the calls to
      dev_info() are replaced with calls to dev_dbg() so that
      their output can be dynamically controlled via the dynamic
      debugging mechanism.
      Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      38a532a6
  10. 13 8月, 2013 1 次提交
  11. 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
  12. 25 7月, 2013 3 次提交
    • G
      usb: host: xhci: Enable XHCI_SPURIOUS_SUCCESS for all controllers with xhci 1.0 · 07f3cb7c
      George Cherian 提交于
      Xhci controllers with hci_version > 0.96 gives spurious success
      events on short packet completion. During webcam capture the
      "ERROR Transfer event TRB DMA ptr not part of current TD" was observed.
      The same application works fine with synopsis controllers hci_version 0.96.
      The same issue is seen with Intel Pantherpoint xhci controller. So enabling
      this quirk in xhci_gen_setup if controller verion is greater than 0.96.
      For xhci-pci move the quirk to much generic place xhci_gen_setup.
      
      Note from Sarah:
      
      The xHCI 1.0 spec changed how hardware handles short packets.  The HW
      will notify SW of the TRB where the short packet occurred, and it will
      also give a successful status for the last TRB in a TD (the one with the
      IOC flag set).  On the second successful status, that warning will be
      triggered in the driver.
      
      Software is now supposed to not assume the TD is not completed until it
      gets that last successful status.  That means we have a slight race
      condition, although it should have little practical impact.  This patch
      papers over that issue.
      
      It's on my long-term to-do list to fix this race condition, but it is a
      much more involved patch that will probably be too big for stable.  This
      patch is needed for stable to avoid serious log spam.
      
      This patch should be backported to kernels as old as 3.0, that
      contain the commit ad808333 "Intel xhci:
      Ignore spurious successful event."
      
      The patch will have to be modified for kernels older than 3.2, since
      that kernel added the xhci_gen_setup function for xhci platform devices.
      The correct conflict resolution for kernels older than 3.2 is to set
      XHCI_SPURIOUS_SUCCESS in xhci_pci_quirks for all xHCI 1.0 hosts.
      Signed-off-by: NGeorge Cherian <george.cherian@ti.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      07f3cb7c
    • O
      usb: xhci: Mark two functions __maybe_unused · d5c82feb
      Olof Johansson 提交于
      Resolves the following build warnings:
      drivers/usb/host/xhci.c:332:13: warning: 'xhci_msix_sync_irqs' defined but not used [-Wunused-function]
      drivers/usb/host/xhci.c:3901:12: warning: 'xhci_change_max_exit_latency' defined but not used [-Wunused-function]
      
      These functions are not always used, and since they're marked static
      they will produce build warnings:
      - xhci_msix_sync_irqs is only used with CONFIG_PCI.
      - xhci_change_max_exit_latency is a little more complicated with
        dependencies on CONFIG_PM and CONFIG_PM_RUNTIME.
      
      Instead of building a bigger maze of ifdefs in this code, I've just
      marked both with __maybe_unused.
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      d5c82feb
    • S
      xhci: Avoid NULL pointer deref when host dies. · 203a8661
      Sarah Sharp 提交于
      When the host controller fails to respond to an Enable Slot command, and
      the host fails to respond to the register write to abort the command
      ring, the xHCI driver will assume the host is dead, and call
      usb_hc_died().
      
      The USB device's slot_id is still set to zero, and the pointer stored at
      xhci->devs[0] will always be NULL.  The call to xhci_check_args in
      xhci_free_dev should have caught the NULL virt_dev pointer.
      
      However, xhci_free_dev is designed to free the xhci_virt_device
      structures, even if the host is dead, so that we don't leak kernel
      memory.  xhci_free_dev checks the return value from the generic
      xhci_check_args function.  If the return value is -ENODEV, it carries on
      trying to free the virtual device.
      
      The issue is that xhci_check_args looks at the host controller state
      before it looks at the xhci_virt_device pointer.  It will return -ENIVAL
      because the host is dead, and xhci_free_dev will ignore the return
      value, and happily dereference the NULL xhci_virt_device pointer.
      
      The fix is to make sure that xhci_check_args checks the xhci_virt_device
      pointer before it checks the host state.
      
      See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1203453 for
      further details.  This patch doesn't solve the underlying issue, but
      will ensure we don't see any more NULL pointer dereferences because of
      the issue.
      
      This patch should be backported to kernels as old as 3.1, that
      contain the commit 7bd89b40 "xhci: Don't
      submit commands or URBs to halted hosts."
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Reported-by: NVincent Thiele <vincentthiele@gmail.com>
      Cc: stable@vger.kernel.org
      203a8661
  13. 24 7月, 2013 1 次提交
  14. 26 6月, 2013 1 次提交
  15. 15 6月, 2013 1 次提交
  16. 06 6月, 2013 1 次提交