linux-toradex.git/drivers/usb/host, branch v4.9.75

usb: xhci: Add XHCI_TRUST_TX_LENGTH for Renesas uPD720201

2018-01-02T19:35:16+00:00

commit da99706689481717998d1d48edd389f339eea979 upstream.

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).

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

xhci: plat: Register shutdown for xhci_plat

2017-12-25T13:23:42+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 
Signed-off-by: Greg Kroah-Hartman

usb: xhci-mtk: check hcc_params after adding primary hcd

2017-12-20T09:07:18+00:00

[ Upstream commit 94a631d91ad341b3b4bdac72d1104d9f090e0ca9 ]

hcc_params is set in xhci_gen_setup() called from usb_add_hcd(),
so checks the Maximum Primary Stream Array Size in the hcc_params
register after adding primary hcd.

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

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

2017-12-20T09:07:17+00:00

commit 5d9b70f7d52eb14bb37861c663bae44de9521c35 upstream.

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."

Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

usb: xhci: fix TDS for MTK xHCI1.1

2017-12-20T09:07:16+00:00

commit 72b663a99c074a8d073e7ecdae446cfb024ef551 upstream.

For MTK's xHCI 1.0 or latter, TD size is the number of max
packet sized packets remaining in the TD, not including
this TRB (following spec).

For MTK's xHCI 0.96 and older, TD size is the number of max
packet sized packets remaining in the TD, including this TRB
(not following spec).

Signed-off-by: Chunfeng Yun 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

usb: host: fix incorrect updating of offset

2017-12-09T21:01:57+00:00

commit 1d5a31582ef046d3b233f0da1a68ae26519b2f0a upstream.

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")
Signed-off-by: Colin Ian King 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

usb: xhci: fix panic in xhci_free_virt_devices_depth_first

2017-12-09T21:01:56+00:00

commit 80e457699a8dbdd70f2d26911e46f538645c55fc upstream.

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 
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

usb: xhci: Handle error condition in xhci_stop_device()

2017-11-02T08:49:13+00:00

commit b3207c65dfafae27e7c492cb9188c0dc0eeaf3fd upstream.

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,")
Signed-off-by: Mayank Rana 
Signed-off-by: Jack Pham 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

xhci: Identify USB 3.1 capable hosts by their port protocol capability

2017-10-27T08:38:06+00:00

commit ea7d0d69426cab6747ed311c53f4142eb48b9454 upstream.

Many USB 3.1 capable hosts never updated the Serial Bus Release Number
(SBRN) register to USB 3.1 from USB 3.0

xhci driver identified USB 3.1 capable hosts based on this SBRN register,
which according to specs "contains the release of the Universal Serial
Bus Specification with which this Universal Serial Bus Host Controller
module is compliant." but still in october 2017 gives USB 3.0 as
the only possible option.

Make an additional check for USB 3.1 support and enable it if the xHCI
supported protocol capablity lists USB 3.1 capable ports.

Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

Revert "xhci: Limit USB2 port wake support for AMD Promontory hosts"

2017-10-12T09:51:18+00:00

commit bcd6a7aa13800afc1418e6b29d944d882214939a upstream.

This reverts commit dec08194ffeccfa1cf085906b53d301930eae18f.

Commit dec08194ffec ("xhci: Limit USB2 port wake support for AMD Promontory
hosts") makes all high speed USB ports on ASUS PRIME B350M-A cease to
function after enabling runtime PM.

All boards with this chipsets will be affected, so revert the commit.

The original patch was added to stable 4.9, 4.11 and 4.12 and needs
to reverted from there as well

Signed-off-by: Kai-Heng Feng 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman