1. 16 3月, 2018 2 次提交
  2. 10 3月, 2018 8 次提交
  3. 22 2月, 2018 1 次提交
  4. 16 2月, 2018 11 次提交
    • J
      usb: Move USB_UHCI_BIG_ENDIAN_* out of USB_SUPPORT · ec897569
      James Hogan 提交于
      Move the Kconfig symbols USB_UHCI_BIG_ENDIAN_MMIO and
      USB_UHCI_BIG_ENDIAN_DESC out of drivers/usb/host/Kconfig, which is
      conditional upon USB && USB_SUPPORT, so that it can be freely selected
      by platform Kconfig symbols in architecture code.
      
      For example once the MIPS_GENERIC platform selects are fixed in commit
      2e6522c5 ("MIPS: Fix typo BIG_ENDIAN to CPU_BIG_ENDIAN"), the MIPS
      32r6_defconfig warns like so:
      
      warning: (MIPS_GENERIC) selects USB_UHCI_BIG_ENDIAN_MMIO which has unmet direct dependencies (USB_SUPPORT && USB)
      warning: (MIPS_GENERIC) selects USB_UHCI_BIG_ENDIAN_DESC which has unmet direct dependencies (USB_SUPPORT && USB)
      
      Fixes: 2e6522c5 ("MIPS: Fix typo BIG_ENDIAN to CPU_BIG_ENDIAN")
      Signed-off-by: NJames Hogan <jhogan@kernel.org>
      Cc: Corentin Labbe <clabbe.montjoie@gmail.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: linux-usb@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Patchwork: https://patchwork.linux-mips.org/patch/18559/
      ec897569
    • A
      usb: ohci: Proper handling of ed_rm_list to handle race condition between... · 46408ea5
      AMAN DEEP 提交于
      usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()
      
      There is a race condition between finish_unlinks->finish_urb() function
      and usb_kill_urb() in ohci controller case. The finish_urb calls
      spin_unlock(&ohci->lock) before usb_hcd_giveback_urb() function call,
      then if during this time, usb_kill_urb is called for another endpoint,
      then new ed will be added to ed_rm_list at beginning for unlink, and
      ed_rm_list will point to newly added.
      
      When finish_urb() is completed in finish_unlinks() and ed->td_list
      becomes empty as in below code (in finish_unlinks() function):
      
              if (list_empty(&ed->td_list)) {
                      *last = ed->ed_next;
                      ed->ed_next = NULL;
              } else if (ohci->rh_state == OHCI_RH_RUNNING) {
                      *last = ed->ed_next;
                      ed->ed_next = NULL;
                      ed_schedule(ohci, ed);
              }
      
      The *last = ed->ed_next will make ed_rm_list to point to ed->ed_next
      and previously added ed by usb_kill_urb will be left unreferenced by
      ed_rm_list. This causes usb_kill_urb() hang forever waiting for
      finish_unlink to remove added ed from ed_rm_list.
      
      The main reason for hang in this race condtion is addition and removal
      of ed from ed_rm_list in the beginning during usb_kill_urb and later
      last* is modified in finish_unlinks().
      
      As suggested by Alan Stern, the solution for proper handling of
      ohci->ed_rm_list is to remove ed from the ed_rm_list before finishing
      any URBs. Then at the end, we can add ed back to the list if necessary.
      
      This properly handle the updated ohci->ed_rm_list in usb_kill_urb().
      
      Fixes: 977dcfdc ("USB: OHCI: don't lose track of EDs when a controller dies")
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: <stable@vger.kernel.org>
      Signed-off-by: NAman Deep <aman.deep@samsung.com>
      Signed-off-by: NJeffy Chen <jeffy.chen@rock-chips.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      46408ea5
    • P
      usb: host: ehci: always enable interrupt for qtd completion at test mode · 91b11935
      Peter Chen 提交于
      At former code, the SETUP stage does not enable interrupt
      for qtd completion, it relies on IAA watchdog to complete
      interrupt, then the transcation would be considered timeout
      if the flag need_io_watchdog is cleared by platform code.
      
      In this commit, we always add enable interrupt for qtd completion,
      then the qtd completion can be notified by hardware interrupt.
      Signed-off-by: NPeter Chen <peter.chen@nxp.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      91b11935
    • P
      usb: host: ehci: use correct device pointer for dma ops · 02a10f06
      Peter Chen 提交于
      commit a8c06e40 ("usb: separate out sysdev pointer from usb_bus")
      converted to use hcd->self.sysdev for DMA operations instead of
      hcd->self.controller, but forgot to do it for hcd test mode. Replace
      the correct one in this commit.
      
      Fixes: a8c06e40 ("usb: separate out sysdev pointer from usb_bus")
      Signed-off-by: NPeter Chen <peter.chen@nxp.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      02a10f06
    • S
      ohci-hcd: Fix race condition caused by ohci_urb_enqueue() and io_watchdog_func() · b2685bda
      Shigeru Yoshida 提交于
      Running io_watchdog_func() while ohci_urb_enqueue() is running can
      cause a race condition where ohci->prev_frame_no is corrupted and the
      watchdog can mis-detect following error:
      
        ohci-platform 664a0800.usb: frame counter not updating; disabled
        ohci-platform 664a0800.usb: HC died; cleaning up
      
      Specifically, following scenario causes a race condition:
      
        1. ohci_urb_enqueue() calls spin_lock_irqsave(&ohci->lock, flags)
           and enters the critical section
        2. ohci_urb_enqueue() calls timer_pending(&ohci->io_watchdog) and it
           returns false
        3. ohci_urb_enqueue() sets ohci->prev_frame_no to a frame number
           read by ohci_frame_no(ohci)
        4. ohci_urb_enqueue() schedules io_watchdog_func() with mod_timer()
        5. ohci_urb_enqueue() calls spin_unlock_irqrestore(&ohci->lock,
           flags) and exits the critical section
        6. Later, ohci_urb_enqueue() is called
        7. ohci_urb_enqueue() calls spin_lock_irqsave(&ohci->lock, flags)
           and enters the critical section
        8. The timer scheduled on step 4 expires and io_watchdog_func() runs
        9. io_watchdog_func() calls spin_lock_irqsave(&ohci->lock, flags)
           and waits on it because ohci_urb_enqueue() is already in the
           critical section on step 7
       10. ohci_urb_enqueue() calls timer_pending(&ohci->io_watchdog) and it
           returns false
       11. ohci_urb_enqueue() sets ohci->prev_frame_no to new frame number
           read by ohci_frame_no(ohci) because the frame number proceeded
           between step 3 and 6
       12. ohci_urb_enqueue() schedules io_watchdog_func() with mod_timer()
       13. ohci_urb_enqueue() calls spin_unlock_irqrestore(&ohci->lock,
           flags) and exits the critical section, then wake up
           io_watchdog_func() which is waiting on step 9
       14. io_watchdog_func() enters the critical section
       15. io_watchdog_func() calls ohci_frame_no(ohci) and set frame_no
           variable to the frame number
       16. io_watchdog_func() compares frame_no and ohci->prev_frame_no
      
      On step 16, because this calling of io_watchdog_func() is scheduled on
      step 4, the frame number set in ohci->prev_frame_no is expected to the
      number set on step 3.  However, ohci->prev_frame_no is overwritten on
      step 11.  Because step 16 is executed soon after step 11, the frame
      number might not proceed, so ohci->prev_frame_no must equals to
      frame_no.
      
      To address above scenario, this patch introduces a special sentinel
      value IO_WATCHDOG_OFF and set this value to ohci->prev_frame_no when
      the watchdog is not pending or running.  When ohci_urb_enqueue()
      schedules the watchdog (step 4 and 12 above), it compares
      ohci->prev_frame_no to IO_WATCHDOG_OFF so that ohci->prev_frame_no is
      not overwritten while io_watchdog_func() is running.
      Signed-off-by: NShigeru Yoshida <Shigeru.Yoshida@windriver.com>
      Signed-off-by: NHaiqing Bai <Haiqing.Bai@windriver.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2685bda
    • Z
      xhci: fix xhci debugfs errors in xhci_stop · 11cd764d
      Zhengjun Xing 提交于
      In function xhci_stop, xhci_debugfs_exit called before xhci_mem_cleanup.
      xhci_debugfs_exit removed the xhci debugfs root nodes, xhci_mem_cleanup
      called function xhci_free_virt_devices_depth_first which in turn called
      function xhci_debugfs_remove_slot.
      Function xhci_debugfs_remove_slot removed the nodes for devices, the nodes
      folders are sub folder of xhci debugfs.
      
      It is unreasonable to remove xhci debugfs root folder before
      xhci debugfs sub folder. Function xhci_mem_cleanup should be called
      before function xhci_debugfs_exit.
      
      Fixes: 02b6fdc2 ("usb: xhci: Add debugfs interface for xHCI driver")
      Cc: <stable@vger.kernel.org> # v4.15
      Signed-off-by: NZhengjun Xing <zhengjun.xing@linux.intel.com>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      11cd764d
    • Z
      xhci: xhci debugfs device nodes weren't removed after device plugged out · 8c5a93eb
      Zhengjun Xing 提交于
      There is a bug after plugged out USB device, the device and its ep00
      nodes are still kept, we need to remove the nodes in xhci_free_dev when
      USB device is plugged out.
      
      Fixes: 052f71e2 ("xhci: Fix xhci debugfs NULL pointer dereference in resume from hibernate")
      Cc: <stable@vger.kernel.org> # v4.15
      Signed-off-by: NZhengjun Xing <zhengjun.xing@linux.intel.com>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8c5a93eb
    • Z
      xhci: Fix xhci debugfs devices node disappearance after hibernation · d9167671
      Zhengjun Xing 提交于
      During system resume from hibernation, xhci host is reset, all the
      nodes in devices folder are removed in xhci_mem_cleanup function.
      Later nodes in /sys/kernel/debug/usb/xhci/* are created again in
      function xhci_run, but the nodes already exist, so the nodes still
      keep the old ones, finally device nodes in xhci debugfs folder
      /sys/kernel/debug/usb/xhci/*/devices/* are disappeared.
      
      This fix removed xhci debugfs nodes before the nodes are re-created,
      so all the nodes in xhci debugfs can be re-created successfully.
      
      Fixes: 02b6fdc2 ("usb: xhci: Add debugfs interface for xHCI driver")
      Cc: <stable@vger.kernel.org> # v4.15
      Signed-off-by: NZhengjun Xing <zhengjun.xing@linux.intel.com>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d9167671
    • Z
      xhci: Fix NULL pointer in xhci debugfs · fa2dfd0e
      Zhengjun Xing 提交于
      Commit dde63405 ("xhci: Fix use-after-free in xhci debugfs") causes a
      null pointer dereference while fixing xhci-debugfs usage of ring pointers
      that were freed during hibernate.
      
      The fix passed addresses to ring pointers instead, but forgot to do this
      change for the xhci_ring_trb_show function.
      
      The address of the ring pointer passed to xhci-debugfs was of a temporary
      ring pointer "new_ring" instead of the actual ring "ring" pointer. The
      temporary new_ring pointer will be set to NULL later causing the NULL
      pointer dereference.
      
      This issue was seen when reading xhci related files in debugfs:
      
      cat /sys/kernel/debug/usb/xhci/*/devices/*/ep*/trbs
      
      [  184.604861] BUG: unable to handle kernel NULL pointer dereference at (null)
      [  184.613776] IP: xhci_ring_trb_show+0x3a/0x890
      [  184.618733] PGD 264193067 P4D 264193067 PUD 263238067 PMD 0
      [  184.625184] Oops: 0000 [#1] SMP
      [  184.726410] RIP: 0010:xhci_ring_trb_show+0x3a/0x890
      [  184.731944] RSP: 0018:ffffba8243c0fd90 EFLAGS: 00010246
      [  184.737880] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000000295d6
      [  184.746020] RDX: 00000000000295d5 RSI: 0000000000000001 RDI: ffff971a6418d400
      [  184.754121] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
      [  184.762222] R10: ffff971a64c98a80 R11: ffff971a62a00e40 R12: ffff971a62a85500
      [  184.770325] R13: 0000000000020000 R14: ffff971a6418d400 R15: ffff971a6418d400
      [  184.778448] FS:  00007fe725a79700(0000) GS:ffff971a6ec00000(0000) knlGS:0000000000000000
      [  184.787644] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  184.794168] CR2: 0000000000000000 CR3: 000000025f365005 CR4: 00000000003606f0
      [  184.802318] Call Trace:
      [  184.805094]  ? seq_read+0x281/0x3b0
      [  184.809068]  seq_read+0xeb/0x3b0
      [  184.812735]  full_proxy_read+0x4d/0x70
      [  184.817007]  __vfs_read+0x23/0x120
      [  184.820870]  vfs_read+0x91/0x130
      [  184.824538]  SyS_read+0x42/0x90
      [  184.828106]  entry_SYSCALL_64_fastpath+0x1a/0x7d
      
      Fixes: dde63405 ("xhci: Fix use-after-free in xhci debugfs")
      Cc: <stable@vger.kernel.org> # v4.15
      Signed-off-by: NZhengjun Xing <zhengjun.xing@linux.intel.com>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fa2dfd0e
    • M
      xhci: Don't print a warning when setting link state for disabled ports · 1208d8a8
      Mathias Nyman 提交于
      When disabling a USB3 port the hub driver will set the port link state to
      U3 to prevent "ejected" or "safely removed" devices that are still
      physically connected from immediately re-enumerating.
      
      If the device was really unplugged, then error messages were printed
      as the hub tries to set the U3 link state for a port that is no longer
      enabled.
      
      xhci-hcd ee000000.usb: Cannot set link state.
      usb usb8-port1: cannot disable (err = -32)
      
      Don't print error message in xhci-hub if hub tries to set port link state
      for a disabled port. Return -ENODEV instead which also silences hub driver.
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Tested-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1208d8a8
    • J
      xhci: workaround for AMD Promontory disabled ports wakeup · bde0716d
      Joe Lee 提交于
      For AMD Promontory xHCI host, although you can disable USB ports in
      BIOS settings, those ports will be enabled anyway after you remove a
      device on that port and re-plug it in again. It's a known limitation of
      the chip. As a workaround we can clear the PORT_WAKE_BITS.
      
      [commit and code comment rephrasing -Mathias]
      Signed-off-by: NJoe Lee <asmt.swfae@gmail.com>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bde0716d
  5. 06 2月, 2018 1 次提交
  6. 24 1月, 2018 1 次提交
  7. 22 1月, 2018 1 次提交
  8. 17 1月, 2018 1 次提交
  9. 16 1月, 2018 1 次提交
  10. 09 1月, 2018 2 次提交
  11. 05 1月, 2018 1 次提交
  12. 27 12月, 2017 3 次提交
  13. 12 12月, 2017 3 次提交
  14. 09 12月, 2017 4 次提交