1. 23 5月, 2019 1 次提交
  2. 22 5月, 2019 5 次提交
    • A
      xhci: Convert xhci_handshake() to use readl_poll_timeout_atomic() · f7fac17c
      Andrey Smirnov 提交于
      Xhci_handshake() implements the algorithm already captured by
      readl_poll_timeout_atomic(). Convert the former to use the latter to
      avoid repetition.
      
      Turned out this patch also fixes a bug on the AMD Stoneyridge platform
      where usleep(1) sometimes takes over 10ms.
      This means a 5 second timeout can easily take over 15 seconds which will
      trigger the watchdog and reboot the system.
      
      [Add info about patch fixing a bug to commit message -Mathias]
      Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
      Tested-by: NRaul E Rangel <rrangel@chromium.org>
      Reviewed-by: NRaul E Rangel <rrangel@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>
      f7fac17c
    • M
      xhci: Fix immediate data transfer if buffer is already DMA mapped · 13b82b74
      Mathias Nyman 提交于
      xhci immediate data transfer (IDT) support in 5.2-rc1 caused regression
      on various Samsung Exynos boards with ASIX USB 2.0 ethernet dongle.
      
      If the transfer buffer in the URB is already DMA mapped then IDT should
      not be used. urb->transfer_dma will already contain a valid dma address,
      and there is no guarantee the data in urb->transfer_buffer is valid.
      
      The IDT support patch used urb->transfer_dma as a temporary storage,
      copying data from urb->transfer_buffer into it.
      
      Issue was solved by preventing IDT if transfer buffer is already dma
      mapped, and by not using urb->transfer_dma as temporary storage.
      
      Fixes: 33e39350 ("usb: xhci: add Immediate Data Transfer support")
      Reported-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      CC: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      13b82b74
    • C
      usb: xhci: avoid null pointer deref when bos field is NULL · 7aa1bb2f
      Carsten Schmid 提交于
      With defective USB sticks we see the following error happen:
      usb 1-3: new high-speed USB device number 6 using xhci_hcd
      usb 1-3: device descriptor read/64, error -71
      usb 1-3: device descriptor read/64, error -71
      usb 1-3: new high-speed USB device number 7 using xhci_hcd
      usb 1-3: device descriptor read/64, error -71
      usb 1-3: unable to get BOS descriptor set
      usb 1-3: New USB device found, idVendor=0781, idProduct=5581
      usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
      ...
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
      
      This comes from the following place:
      [ 1660.215380] IP: xhci_set_usb2_hardware_lpm+0xdf/0x3d0 [xhci_hcd]
      [ 1660.222092] PGD 0 P4D 0
      [ 1660.224918] Oops: 0000 [#1] PREEMPT SMP NOPTI
      [ 1660.425520] CPU: 1 PID: 38 Comm: kworker/1:1 Tainted: P     U  W  O    4.14.67-apl #1
      [ 1660.434277] Workqueue: usb_hub_wq hub_event [usbcore]
      [ 1660.439918] task: ffffa295b6ae4c80 task.stack: ffffad4580150000
      [ 1660.446532] RIP: 0010:xhci_set_usb2_hardware_lpm+0xdf/0x3d0 [xhci_hcd]
      [ 1660.453821] RSP: 0018:ffffad4580153c70 EFLAGS: 00010046
      [ 1660.459655] RAX: 0000000000000000 RBX: ffffa295b4d7c000 RCX: 0000000000000002
      [ 1660.467625] RDX: 0000000000000002 RSI: ffffffff984a55b2 RDI: ffffffff984a55b2
      [ 1660.475586] RBP: ffffad4580153cc8 R08: 0000000000d6520a R09: 0000000000000001
      [ 1660.483556] R10: ffffad4580a004a0 R11: 0000000000000286 R12: ffffa295b4d7c000
      [ 1660.491525] R13: 0000000000010648 R14: ffffa295a84e1800 R15: 0000000000000000
      [ 1660.499494] FS:  0000000000000000(0000) GS:ffffa295bfc80000(0000) knlGS:0000000000000000
      [ 1660.508530] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 1660.514947] CR2: 0000000000000008 CR3: 000000025a114000 CR4: 00000000003406a0
      [ 1660.522917] Call Trace:
      [ 1660.525657]  usb_set_usb2_hardware_lpm+0x3d/0x70 [usbcore]
      [ 1660.531792]  usb_disable_device+0x242/0x260 [usbcore]
      [ 1660.537439]  usb_disconnect+0xc1/0x2b0 [usbcore]
      [ 1660.542600]  hub_event+0x596/0x18f0 [usbcore]
      [ 1660.547467]  ? trace_preempt_on+0xdf/0x100
      [ 1660.552040]  ? process_one_work+0x1c1/0x410
      [ 1660.556708]  process_one_work+0x1d2/0x410
      [ 1660.561184]  ? preempt_count_add.part.3+0x21/0x60
      [ 1660.566436]  worker_thread+0x2d/0x3f0
      [ 1660.570522]  kthread+0x122/0x140
      [ 1660.574123]  ? process_one_work+0x410/0x410
      [ 1660.578792]  ? kthread_create_on_node+0x60/0x60
      [ 1660.583849]  ret_from_fork+0x3a/0x50
      [ 1660.587839] Code: 00 49 89 c3 49 8b 84 24 50 16 00 00 8d 4a ff 48 8d 04 c8 48 89 ca 4c 8b 10 45 8b 6a 04 48 8b 00 48 89 45 c0 49 8b 86 80 03 00 00 <48> 8b 40 08 8b 40 03 0f 1f 44 00 00 45 85 ff 0f 84 81 01 00 00
      [ 1660.608980] RIP: xhci_set_usb2_hardware_lpm+0xdf/0x3d0 [xhci_hcd] RSP: ffffad4580153c70
      [ 1660.617921] CR2: 0000000000000008
      
      Tracking this down shows that udev->bos is NULL in the following code:
      (xhci.c, in xhci_set_usb2_hardware_lpm)
      	field = le32_to_cpu(udev->bos->ext_cap->bmAttributes);  <<<<<<< here
      
      	xhci_dbg(xhci, "%s port %d USB2 hardware LPM\n",
      			enable ? "enable" : "disable", port_num + 1);
      
      	if (enable) {
      		/* Host supports BESL timeout instead of HIRD */
      		if (udev->usb2_hw_lpm_besl_capable) {
      			/* if device doesn't have a preferred BESL value use a
      			 * default one which works with mixed HIRD and BESL
      			 * systems. See XHCI_DEFAULT_BESL definition in xhci.h
      			 */
      			if ((field & USB_BESL_SUPPORT) &&
      			    (field & USB_BESL_BASELINE_VALID))
      				hird = USB_GET_BESL_BASELINE(field);
      			else
      				hird = udev->l1_params.besl;
      
      The failing case is when disabling LPM. So it is sufficient to avoid
      access to udev->bos by moving the instruction into the "enable" clause.
      
      Cc: Stable <stable@vger.kernel.org>
      Signed-off-by: NCarsten Schmid <carsten_schmid@mentor.com>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7aa1bb2f
    • J
      usb: xhci: Fix a potential null pointer dereference in xhci_debugfs_create_endpoint() · 5bce256f
      Jia-Ju Bai 提交于
      In xhci_debugfs_create_slot(), kzalloc() can fail and
      dev->debugfs_private will be NULL.
      In xhci_debugfs_create_endpoint(), dev->debugfs_private is used without
      any null-pointer check, and can cause a null pointer dereference.
      
      To fix this bug, a null-pointer check is added in
      xhci_debugfs_create_endpoint().
      
      This bug is found by a runtime fuzzing tool named FIZZER written by us.
      
      [subjet line change change, add potential -Mathais]
      Signed-off-by: NJia-Ju Bai <baijiaju1990@gmail.com>
      Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5bce256f
    • H
      xhci: update bounce buffer with correct sg num · 597c56e3
      Henry Lin 提交于
      This change fixes a data corruption issue occurred on USB hard disk for
      the case that bounce buffer is used during transferring data.
      
      While updating data between sg list and bounce buffer, current
      implementation passes mapped sg number (urb->num_mapped_sgs) to
      sg_pcopy_from_buffer() and sg_pcopy_to_buffer(). This causes data
      not get copied if target buffer is located in the elements after
      mapped sg elements. This change passes sg number for full list to
      fix issue.
      
      Besides, for copying data from bounce buffer, calling dma_unmap_single()
      on the bounce buffer before copying data to sg list can avoid cache issue.
      
      Fixes: f9c589e1 ("xhci: TD-fragment, align the unsplittable case with a bounce buffer")
      Cc: <stable@vger.kernel.org> # v4.8+
      Signed-off-by: NHenry Lin <henryl@nvidia.com>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      597c56e3
  3. 27 4月, 2019 4 次提交
  4. 19 4月, 2019 3 次提交
  5. 16 4月, 2019 2 次提交
  6. 12 4月, 2019 3 次提交
  7. 08 4月, 2019 1 次提交
    • W
      drivers: Remove explicit invocations of mmiowb() · fb24ea52
      Will Deacon 提交于
      mmiowb() is now implied by spin_unlock() on architectures that require
      it, so there is no reason to call it from driver code. This patch was
      generated using coccinelle:
      
      	@mmiowb@
      	@@
      	- mmiowb();
      
      and invoked as:
      
      $ for d in drivers include/linux/qed sound; do \
      spatch --include-headers --sp-file mmiowb.cocci --dir $d --in-place; done
      
      NOTE: mmiowb() has only ever guaranteed ordering in conjunction with
      spin_unlock(). However, pairing each mmiowb() removal in this patch with
      the corresponding call to spin_unlock() is not at all trivial, so there
      is a small chance that this change may regress any drivers incorrectly
      relying on mmiowb() to order MMIO writes between CPUs using lock-free
      synchronisation. If you've ended up bisecting to this commit, you can
      reintroduce the mmiowb() calls using wmb() instead, which should restore
      the old behaviour on all architectures other than some esoteric ia64
      systems.
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      fb24ea52
  8. 27 3月, 2019 1 次提交
  9. 26 3月, 2019 1 次提交
  10. 23 3月, 2019 3 次提交
  11. 19 3月, 2019 1 次提交
  12. 21 2月, 2019 5 次提交
  13. 20 2月, 2019 1 次提交
  14. 19 2月, 2019 1 次提交
  15. 12 2月, 2019 4 次提交
  16. 30 1月, 2019 3 次提交
  17. 22 1月, 2019 1 次提交