linux-stable.git/drivers/usb, branch v4.19.7

Revert "usb: dwc3: gadget: skip Set/Clear Halt when invalid"

2018-12-05T18:32:13+00:00

commit 38317f5c0f2faae5110854f36edad810f841d62f upstream.

This reverts commit ffb80fc672c3a7b6afd0cefcb1524fb99917b2f3.

Turns out that commit is wrong. Host controllers are allowed to use
Clear Feature HALT as means to sync data toggle between host and
periperal.

Cc: 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

usb: core: quirks: add RESET_RESUME quirk for Cherry G230 Stream series

2018-12-05T18:32:13+00:00

commit effd14f66cc1ef6701a19c5a56e39c35f4d395a5 upstream.

Cherry G230 Stream 2.0 (G85-231) and 3.0 (G85-232) need this quirk to
function correctly. This fixes a but where double pressing numlock locks
up the device completely with need to replug the keyboard.

Signed-off-by: Michael Niewöhner 
Tested-by: Michael Niewöhner 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

USB: usb-storage: Add new IDs to ums-realtek

2018-12-05T18:32:13+00:00

commit a84a1bcc992f0545a51d2e120b8ca2ef20e2ea97 upstream.

There are two new Realtek card readers require ums-realtek to work
correctly.

Add the new IDs to support them.

Signed-off-by: Kai-Heng Feng 
Acked-by: Alan Stern 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

usb: xhci: Prevent bus suspend if a port connect change or polling state is detected

2018-12-01T08:37:25+00:00

commit 2f31a67f01a8beb22cae754c53522cb61a005750 upstream.

USB3 roothub might autosuspend before a plugged USB3 device is detected,
causing USB3 device enumeration failure.

USB3 devices don't show up as connected and enabled until USB3 link trainig
completes. On a fast booting platform with a slow USB3 link training the
link might reach the connected enabled state just as the bus is suspending.

If this device is discovered first time by the xhci_bus_suspend() routine
it will be put to U3 suspended state like the other ports which failed to
suspend earlier.

The hub thread will notice the connect change and resume the bus,
moving the port back to U0

This U0 -> U3 -> U0 transition right after being connected seems to be
too much for some devices, causing them to first go to SS.Inactive state,
and finally end up stuck in a polling state with reset asserted

Fix this by failing the bus suspend if a port has a connect change or is
in a polling state in xhci_bus_suspend().

Don't do any port changes until all ports are checked, buffer all port
changes and only write them in the end if suspend can proceed

Cc: stable@vger.kernel.org
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

xhci: Add quirk to workaround the errata seen on Cavium Thunder-X2 Soc

2018-12-01T08:37:25+00:00

commit 11644a7659529730eaf2f166efaabe7c3dc7af8c upstream.

Implement workaround for ThunderX2 Errata-129 (documented in
CN99XX Known Issues" available at Cavium support site).
As per ThunderX2errata-129, USB 2 device may come up as USB 1
if a connection to a USB 1 device is followed by another connection to
a USB 2 device, the link will come up as USB 1 for the USB 2 device.

Resolution: Reset the PHY after the USB 1 device is disconnected.
The PHY reset sequence is done using private registers in XHCI register
space. After the PHY is reset we check for the PLL lock status and retry
the operation if it fails. From our tests, retrying 4 times is sufficient.

Add a new quirk flag XHCI_RESET_PLL_ON_DISCONNECT to invoke the workaround
in handle_xhci_port_status().

Cc: stable@vger.kernel.org
Signed-off-by: George Cherian 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

usb: xhci: fix timeout for transition from RExit to U0

2018-12-01T08:37:25+00:00

commit a5baeaeabcca3244782a9b6382ebab6f8a58f583 upstream.

This definition is used by msecs_to_jiffies in milliseconds.
According to the comments, max rexit timeout should be 20ms.
Align with the comments to properly calculate the delay.

Verified on Sunrise Point-LP and Cannon Lake.

Cc: stable@vger.kernel.org
Signed-off-by: Aaron Ma 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

usb: xhci: fix uninitialized completion when USB3 port got wrong status

2018-12-01T08:37:25+00:00

commit 958c0bd86075d4ef1c936998deefe1947e539240 upstream.

Realtek USB3.0 Card Reader [0bda:0328] reports wrong port status on
Cannon lake PCH USB3.1 xHCI [8086:a36d] after resume from S3,
after clear port reset it works fine.

Since this device is registered on USB3 roothub at boot,
when port status reports not superspeed, xhci_get_port_status will call
an uninitialized completion in bus_state[0].
Kernel will hang because of NULL pointer.

Restrict the USB2 resume status check in USB2 roothub to fix hang issue.

Cc: stable@vger.kernel.org
Signed-off-by: Aaron Ma 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

xhci: Add check for invalid byte size error when UAS devices are connected.

2018-12-01T08:37:25+00:00

commit d9193efba84fe4c4aa22a569fade5e6ca971f8af upstream.

Observed "TRB completion code (27)" error which corresponds to Stopped -
Length Invalid error(xhci spec section 4.17.4) while connecting USB to
SATA bridge.

Looks like this case was not considered when the following patch[1] was
committed. Hence adding this new check which can prevent
the invalid byte size error.

[1] ade2e3a xhci: handle transfer events without TRB pointer

Cc: 
Signed-off-by: Sandeep Singh 
cc: Nehal Shah 
cc: Shyam Sundar S K 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

xhci: handle port status events for removed USB3 hcd

2018-12-01T08:37:25+00:00

commit 1245374e9b8340fc255fd51b2015173a83050d03 upstream.

At xhci removal the USB3 hcd (shared_hcd) is removed before the primary
USB2 hcd. Interrupts for port status changes may still occur for USB3
ports after the shared_hcd is freed, causing  NULL pointer dereference.

Check if xhci->shared_hcd is still valid before handing USB3 port events

Cc: 
Reported-by: Peter Chen 
Tested-by: Jack Pham 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

xhci: Fix leaking USB3 shared_hcd at xhci removal

2018-12-01T08:37:25+00:00

commit f068090426ea8d72c408ebd42953a82a88e2282c upstream.

Ensure that the shared_hcd pointer is valid when calling usb_put_hcd()

The shared_hcd is removed and freed in xhci by first calling
usb_remove_hcd(xhci->shared_hcd), and later
usb_put_hcd(xhci->shared_hcd)

Afer commit fe190ed0d602 ("xhci: Do not halt the host until both HCD have
disconnected their devices.") the shared_hcd was never properly put as
xhci->shared_hcd was set to NULL before usb_put_hcd(xhci->shared_hcd) was
called.

shared_hcd (USB3) is removed before primary hcd (USB2).
While removing the primary hcd we might need to handle xhci interrupts
to cleanly remove last USB2 devices, therefore we need to set
xhci->shared_hcd to NULL before removing the primary hcd to let xhci
interrupt handler know shared_hcd is no longer available.

xhci-plat.c, xhci-histb.c and xhci-mtk first create both their hcd's before
adding them. so to keep the correct reverse removal order use a temporary
shared_hcd variable for them.
For more details see commit 4ac53087d6d4 ("usb: xhci: plat: Create both
HCDs before adding them")

Fixes: fe190ed0d602 ("xhci: Do not halt the host until both HCD have disconnected their devices.")
Cc: Joel Stanley 
Cc: Chunfeng Yun 
Cc: Thierry Reding 
Cc: Jianguo Sun 
Cc: 
Reported-by: Jack Pham 
Tested-by: Jack Pham 
Tested-by: Peter Chen 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman