1. 16 3月, 2018 1 次提交
  2. 09 12月, 2017 5 次提交
  3. 01 12月, 2017 1 次提交
  4. 07 11月, 2017 1 次提交
    • G
      USB: host: xhci: Remove redundant license text · 9ed64195
      Greg Kroah-Hartman 提交于
      Now that the SPDX tag is in all USB files, that identifies the license
      in a specific and legally-defined manner.  So the extra GPL text wording
      can be removed as it is no longer needed at all.
      
      This is done on a quest to remove the 700+ different ways that files in
      the kernel describe the GPL license text.  And there's unneeded stuff
      like the address (sometimes incorrect) for the FSF which is never
      needed.
      
      No copyright headers or other non-license-description text was removed.
      
      Cc: Matthias Brugger <matthias.bgg@gmail.com>
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Cc: Jonathan Hunter <jonathanh@nvidia.com>
      Acked-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9ed64195
  5. 04 11月, 2017 1 次提交
  6. 17 10月, 2017 3 次提交
  7. 05 10月, 2017 2 次提交
    • A
      xhci: allow TRACE to work with EVENT ring dequeue · 49d5b05e
      Adam Wallis 提交于
      inc_deq() currently bails earlier for EVENT rings than the common return
      point of the function, due to the fact that EVENT rings do not have
      link TRBs. The unfortunate side effect of this is that the very useful
      trace_xhci_inc_deq() function is not called/usable for EVENT ring
      debug.
      
      This patch provides a refactor by removing the multiple return exit
      points into a single return which additionally allows for all rings to
      use the trace function.
      Signed-off-by: NAdam Wallis <awallis@codeaurora.org>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      49d5b05e
    • A
      usb: xhci: reduce device initiated resume time variance. · 0914ea66
      Anshuman Gupta 提交于
      This patch will improve the variable auto-resume latency of an usb-port.
      
      The attempt to sync the start of root hub polling with resume time
      signaling finish was ruined by a later request to start immediate
      root hub polling.
      
      When xhci gets a port status change event interrupt due to PORT_PLC
      (port link state transition), linux Host controller driver drives the
      resume signalling on the bus for the amount of time defined by
      USB_REUME_TIMEOUT(40ms) macro.
      
      This 40ms delay for resume signalling is in acceptable limit, but
      it get worse when xhci goes for polling mode in order to detect other
      events on its ports and modify rh_timer timer with a variable time out of
      1ms to (HZ/4)ms.
      
      drivers/usb/core/hcd.c line 799
      mod_timer (&hcd->rh_timer, (jiffies/(HZ/4) + 1) * (HZ/4)).
      
      Due to above variable timeout usb auto-resume latency varies from
      40ms to ~300ms.
      
      Log Snippet:
      ~128ms latency
      [   53.112049] hub 1-0:1.0: state 7 ports 12 chg 0000 evt 0000
      [   53.229200] hub 1-0:1.0: state 7 ports 12 chg 0000 evt 0004
      [   53.240177] usb 1-2: usb wakeup-resume
      [   53.240195] usb 1-2: finish resume
      [   53.240357] usb usb1-port2: resume, status 0
      -----------------------------------------------------------------
      ~300ms latency
      [   59.946620] hub 1-0:1.0: state 7 ports 12 chg 0000 evt 0000
      [   59.979341] hub 1-0:1.0: state 7 ports 12 chg 0000 evt 0000
      [   60.229342] hub 1-0:1.0: state 7 ports 12 chg 0000 evt 0004
      [   60.251321] usb 1-2: usb wakeup-resume
      [   60.251335] usb 1-2: finish resume
      [   60.251539] usb usb1-port2: resume, status 0
      
      This variable resume latency can be optimized, as in case of PORT_PLC
      change event rh_timer has already been modified with USB_RESUME_TIMEOUT
      (40ms) delay,leaving the rest to GetPortStatus and started polling for
      root hub status (invoking usb_hcd_poll_rh_status).
      We can avoid polling as we have already modified rh_timer with
      delay of 40ms.
      
      This patch set the HCD_FLAG_POLL_RH to hcd->flags after modification of
      rh_timer, and avoids polling of root hub status. so rh_timer can fire
      after 40ms and usb device auto-resuem latency will be around 40ms.
      
      [topic and first two senctences of commit message changed -Mathias]
      Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0914ea66
  8. 17 8月, 2017 2 次提交
  9. 20 7月, 2017 1 次提交
  10. 16 6月, 2017 6 次提交
  11. 03 6月, 2017 4 次提交
  12. 18 5月, 2017 4 次提交
    • M
      xhci: Fix command ring stop regression in 4.11 · 604d02a2
      Mathias Nyman 提交于
      In 4.11 TRB completion codes were renamed to match spec.
      
      Completion codes for command ring stopped and endpoint stopped
      were mixed, leading to failures while handling a stopped command ring.
      
      Use the correct completion code for command ring stopped events.
      
      Fixes: 0b7c105a ("usb: host: xhci: rename completion codes to match spec")
      Cc: <stable@vger.kernel.org> # 4.11
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      604d02a2
    • A
      USB: xhci: fix lock-inversion problem · 63aea0db
      Alan Stern 提交于
      With threaded interrupts, bottom-half handlers are called with
      interrupts enabled.  Therefore they can't safely use spin_lock(); they
      have to use spin_lock_irqsave().  Lockdep warns about a violation
      occurring in xhci_irq():
      
      =========================================================
      [ INFO: possible irq lock inversion dependency detected ]
      4.11.0-rc8-dbg+ #1 Not tainted
      ---------------------------------------------------------
      swapper/7/0 just changed the state of lock:
       (&(&ehci->lock)->rlock){-.-...}, at: [<ffffffffa0130a69>]
      ehci_hrtimer_func+0x29/0xc0 [ehci_hcd]
      but this lock took another, HARDIRQ-unsafe lock in the past:
       (hcd_urb_list_lock){+.....}
      
      and interrupts could create inverse lock ordering between them.
      
      other info that might help us debug this:
       Possible interrupt unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(hcd_urb_list_lock);
                                     local_irq_disable();
                                     lock(&(&ehci->lock)->rlock);
                                     lock(hcd_urb_list_lock);
        <Interrupt>
          lock(&(&ehci->lock)->rlock);
       *** DEADLOCK ***
      
      no locks held by swapper/7/0.
      the shortest dependencies between 2nd lock and 1st lock:
       -> (hcd_urb_list_lock){+.....} ops: 252 {
          HARDIRQ-ON-W at:
                            __lock_acquire+0x602/0x1280
                            lock_acquire+0xd5/0x1c0
                            _raw_spin_lock+0x2f/0x40
                            usb_hcd_unlink_urb_from_ep+0x1b/0x60 [usbcore]
                            xhci_giveback_urb_in_irq.isra.45+0x70/0x1b0 [xhci_hcd]
                            finish_td.constprop.60+0x1d8/0x2e0 [xhci_hcd]
                            xhci_irq+0xdd6/0x1fa0 [xhci_hcd]
                            usb_hcd_irq+0x26/0x40 [usbcore]
                            irq_forced_thread_fn+0x2f/0x70
                            irq_thread+0x149/0x1d0
                            kthread+0x113/0x150
                            ret_from_fork+0x2e/0x40
      
      This patch fixes the problem.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: NBart Van Assche <bart.vanassche@sandisk.com>
      CC: <stable@vger.kernel.org>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      63aea0db
    • P
      usb: host: xhci-ring: don't need to clear interrupt pending for MSI enabled hcd · 6a29beef
      Peter Chen 提交于
      According to xHCI spec Figure 30: Interrupt Throttle Flow Diagram
      
      	If PCI Message Signaled Interrupts (MSI or MSI-X) are enabled,
             	then the assertion of the Interrupt Pending (IP) flag in Figure 30
             	generates a PCI Dword write. The IP flag is automatically cleared
             	by the completion of the PCI write.
      
      the MSI enabled HCs don't need to clear interrupt pending bit, but
      hcd->irq = 0 doesn't equal to MSI enabled HCD. At some Dual-role
      controller software designs, it sets hcd->irq as 0 to avoid HCD
      requesting interrupt, and they want to decide when to call usb_hcd_irq
      by software.
      Signed-off-by: NPeter Chen <peter.chen@nxp.com>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6a29beef
    • M
      usb: xhci: trace URB before giving it back instead of after · 7bc5d5af
      Mathias Nyman 提交于
      Don't access any members of a URB after giving it back.
      URB might be freed by then already.
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7bc5d5af
  13. 08 4月, 2017 8 次提交
  14. 29 3月, 2017 1 次提交