linux-stable.git/drivers/usb/host, branch linux-4.1.y

Revert "xhci: plat: Register shutdown for xhci_plat"

2018-05-23T01:36:31+00:00

[ Upstream commit c20f53c58261b121d0989e147368803b9773b413 ]

This reverts commit b07c12517f2aed0add8ce18146bb426b14099392

It is incomplete and causes hangs on devices when shutting down.  It
needs a much more "complete" fix in order to work properly.  As that fix
has not been merged, revert this patch for now before it causes any more
problems.

Cc: Greg Hackmann 
Cc: Adam Wallis 
Cc: Mathias Nyman 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()

2018-03-04T15:28:34+00:00

[ Upstream commit 46408ea558df13b110e0866b99624384a33bdeba ]

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: 977dcfdc6031 ("USB: OHCI: don't lose track of EDs when a controller dies")
Acked-by: Alan Stern 
CC: 
Signed-off-by: Aman Deep 
Signed-off-by: Jeffy Chen 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: xhci: Add XHCI_TRUST_TX_LENGTH for Renesas uPD720201

2018-03-01T00:32:19+00:00

[ Upstream commit da99706689481717998d1d48edd389f339eea979 ]

When plugging in a USB webcam I see the following message:
xhci_hcd 0000:04:00.0: WARN Successful completion on short TX: needs
XHCI_TRUST_TX_LENGTH quirk?
handle_tx_event: 913 callbacks suppressed

All is quiet again with this patch (and I've done a fair but of soak
testing with the camera since).

Cc: 
Signed-off-by: Daniel Thompson 
Acked-by: Ard Biesheuvel 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

xhci: plat: Register shutdown for xhci_plat

2018-03-01T00:32:14+00:00

[ Upstream commit b07c12517f2aed0add8ce18146bb426b14099392 ]

Shutdown should be called for xhci_plat devices especially for
situations where kexec might be used by stopping DMA
transactions.

Signed-off-by: Adam Wallis 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

xhci: Don't add a virt_dev to the devs array before it's fully allocated

2018-01-17T17:55:31+00:00

[ Upstream commit 5d9b70f7d52eb14bb37861c663bae44de9521c35 ]

Avoid null pointer dereference if some function is walking through the
devs array accessing members of a new virt_dev that is mid allocation.

Add the virt_dev to xhci->devs[i] _after_ the virt_device and all its
members are properly allocated.

issue found by KASAN: null-ptr-deref in xhci_find_slot_id_by_port

"Quick analysis suggests that xhci_alloc_virt_device() is not mutex
protected. If so, there is a time frame where xhci->devs[slot_id] is set
but not fully initialized. Specifically, xhci->devs[i]->udev can be NULL."

Cc: stable 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: host: fix incorrect updating of offset

2018-01-17T17:55:21+00:00

[ Upstream commit 1d5a31582ef046d3b233f0da1a68ae26519b2f0a ]

The variable temp is incorrectly being updated, instead it should
be offset otherwise the loop just reads the same capability value
and loops forever.  Thanks to Alan Stern for pointing out the
correct fix to my original fix.  Fix also cleans up clang warning:

drivers/usb/host/ehci-dbg.c:840:4: warning: Value stored to 'temp'
is never read

Fixes: d49d43174400 ("USB: misc ehci updates")
Cc: stable 
Signed-off-by: Colin Ian King 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: xhci: fix panic in xhci_free_virt_devices_depth_first

2018-01-17T17:55:20+00:00

[ Upstream commit 80e457699a8dbdd70f2d26911e46f538645c55fc ]

Check vdev->real_port 0 to avoid panic
[    9.261347] [] xhci_free_virt_devices_depth_first+0x58/0x108
[    9.261352] [] xhci_mem_cleanup+0x1bc/0x570
[    9.261355] [] xhci_stop+0x140/0x1c8
[    9.261365] [] usb_remove_hcd+0xfc/0x1d0
[    9.261369] [] xhci_plat_remove+0x6c/0xa8
[    9.261377] [] platform_drv_remove+0x2c/0x70
[    9.261384] [] __device_release_driver+0x80/0x108
[    9.261387] [] device_release_driver+0x2c/0x40
[    9.261392] [] bus_remove_device+0xe0/0x120
[    9.261396] [] device_del+0x114/0x210
[    9.261399] [] platform_device_del+0x30/0xa0
[    9.261403] [] dwc3_otg_work+0x204/0x488
[    9.261407] [] event_work+0x304/0x5b8
[    9.261414] [] process_one_work+0x148/0x490
[    9.261417] [] worker_thread+0x50/0x4a0
[    9.261421] [] kthread+0xe8/0x100
[    9.261427] [] ret_from_fork+0x10/0x50

The problem can occur if xhci_plat_remove() is called shortly after
xhci_plat_probe(). While xhci_free_virt_devices_depth_first been
called before the device has been setup and get real_port initialized.
The problem occurred on Hikey960 and was reproduced by Guenter Roeck
on Kevin with chromeos-4.4.

Fixes: ee8665e28e8d ("xhci: free xhci virtual devices with leaf nodes first")
Cc: Guenter Roeck 
Cc:  # v4.10+
Reviewed-by: Guenter Roeck 
Tested-by: Guenter Roeck 
Signed-off-by: Fan Ning 
Signed-off-by: Li Rui 
Signed-off-by: yangdi 
Signed-off-by: Yu Chen 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: xhci: Handle error condition in xhci_stop_device()

2017-11-06T04:54:37+00:00

[ Upstream commit b3207c65dfafae27e7c492cb9188c0dc0eeaf3fd ]

xhci_stop_device() calls xhci_queue_stop_endpoint() multiple times
without checking the return value. xhci_queue_stop_endpoint() can
return error if the HC is already halted or unable to queue commands.
This can cause a deadlock condition as xhci_stop_device() would
end up waiting indefinitely for a completion for the command that
didn't get queued. Fix this by checking the return value and bailing
out of xhci_stop_device() in case of error. This patch happens to fix
potential memory leaks of the allocated command structures as well.

Fixes: c311e391a7ef ("xhci: rework command timeout and cancellation,")
Cc: 
Signed-off-by: Mayank Rana 
Signed-off-by: Jack Pham 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

xhci: fix finding correct bus_state structure for USB 3.1 hosts

2017-11-06T04:54:21+00:00

[ Upstream commit 5a838a13c9b4e5dd188b7a6eaeb894e9358ead0c ]

xhci driver keeps a bus_state structure for each hcd (usb2 and usb3)

The structure is picked based on hcd speed, but driver only compared
for HCD_USB3 speed, returning the wrong bus_state for HCD_USB31 hosts.

This caused null pointer dereference errors in bus_resume function.

Cc: 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: pci-quirks.c: Corrected timeout values used in handshake

2017-11-06T04:54:19+00:00

[ Upstream commit 114ec3a6f9096d211a4aff4277793ba969a62c73 ]

Servers were emitting failed handoff messages but were not
waiting the full 1 second as designated in section 4.22.1 of
the eXtensible Host Controller Interface specifications. The
handshake was using wrong units so calls were made with milliseconds
not microseconds. Comments referenced 5 seconds not 1 second as
in specs.

The wrong units were also corrected in a second handshake call.

Cc: 
Signed-off-by: Jim Dickerson 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin