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

xhci: Prevent U1/U2 link pm states if exit latency is too long

2018-12-13T08:16:20+00:00

commit 0472bf06c6fd33c1a18aaead4c8f91e5a03d8d7b upstream.

Don't allow USB3 U1 or U2 if the latency to wake up from the U-state
reaches the service interval for a periodic endpoint.

This is according to xhci 1.1 specification section 4.23.5.2 extra note:

"Software shall ensure that a device is prevented from entering a U-state
 where its worst case exit latency approaches the ESIT."

Allowing too long exit latencies for periodic endpoint confuses xHC
internal scheduling, and new devices may fail to enumerate with a
"Not enough bandwidth for new device state" error from the host.

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

xhci: workaround CSS timeout on AMD SNPS 3.0 xHC

2018-12-13T08:16:20+00:00

commit a7d57abcc8a5bdeb53bbf8e87558e8e0a2c2a29d upstream.

Occasionally AMD SNPS 3.0 xHC does not respond to
CSS when set, also it does not flag anything on SRE and HCE
to point the internal xHC errors on USBSTS register. This stalls
the entire system wide suspend and there is no point in stalling
just because of xHC CSS is not responding.

To work around this problem, if the xHC does not flag
anything on SRE and HCE, we can skip the CSS
timeout and allow the system to continue the suspend. Once the
system resume happens we can internally reset the controller
using XHCI_RESET_ON_RESUME quirk

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

USB: serial: console: fix reported terminal settings

2018-12-13T08:16:15+00:00

commit f51ccf46217c28758b1f3b5bc0ccfc00eca658b2 upstream.

The USB-serial console implementation has never reported the actual
terminal settings used. Despite storing the corresponding cflags in its
struct console, these were never honoured on later tty open() where the
tty termios would be left initialised to the driver defaults.

Unlike the serial console implementation, the USB-serial code calls
subdriver open() already at console setup. While calling set_termios()
and write() before open() looks like it could work for some USB-serial
drivers, others definitely do not expect this, so modelling this after
serial core is going to be intrusive, if at all possible.

Instead, use a (renamed) tty helper to save the termios data used at
console setup so that the tty termios reflects the actual terminal
settings after a subsequent tty open().

Note that the calls to tty_init_termios() (tty_driver_install()) and
tty_save_termios() are serialised using the disconnect mutex.

This specifically fixes a regression that was triggered by a recent
change adding software flow control to the pl2303 driver: a getty trying
to disable flow control while leaving the baud rate unchanged would now
also set the baud rate to the driver default (prior to the flow-control
change this had been a noop).

Fixes: 7041d9c3f01b ("USB: serial: pl2303: add support for tx xon/xoff flow control")
Cc: stable 	# 4.18
Cc: Florian Zumbiehl 
Reported-by: Jarkko Nikula 
Tested-by: Jarkko Nikula 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

USB: check usb_get_extra_descriptor for proper size

2018-12-13T08:16:15+00:00

commit 704620afc70cf47abb9d6a1a57f3825d2bca49cf upstream.

When reading an extra descriptor, we need to properly check the minimum
and maximum size allowed, to prevent from invalid data being sent by a
device.

Reported-by: Hui Peng 
Reported-by: Mathias Payer 
Co-developed-by: Linus Torvalds 
Signed-off-by: Hui Peng 
Signed-off-by: Mathias Payer 
Signed-off-by: Linus Torvalds 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

usb: appledisplay: Add 27" Apple Cinema Display

2018-12-13T08:16:15+00:00

commit d7859905301880ad3e16272399d26900af3ac496 upstream.

Add another Apple Cinema Display to the list of supported displays.

Signed-off-by: Alexander Theissen 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

usb: quirk: add no-LPM quirk on SanDisk Ultra Flair device

2018-12-13T08:16:15+00:00

commit 2f2dde6ba89b1ef1fe23c1138131b315d9aa4019 upstream.

Some lower volume SanDisk Ultra Flair in 16GB, which the VID:PID is
in 0781:5591, will aggressively request LPM of U1/U2 during runtime,
when using this thumb drive as the OS installation key we found the
device will generate failure during U1 exit path making it dropped
from the USB bus, this causes a corrupted installation in system at
the end.

i.e.,
[  166.918296] hub 2-0:1.0: state 7 ports 7 chg 0000 evt 0004
[  166.918327] usb usb2-port2: link state change
[  166.918337] usb usb2-port2: do warm reset
[  166.970039] usb usb2-port2: not warm reset yet, waiting 50ms
[  167.022040] usb usb2-port2: not warm reset yet, waiting 200ms
[  167.276043] usb usb2-port2: status 02c0, change 0041, 5.0 Gb/s
[  167.276050] usb 2-2: USB disconnect, device number 2
[  167.276058] usb 2-2: unregistering device
[  167.276060] usb 2-2: unregistering interface 2-2:1.0
[  167.276170] xhci_hcd 0000:00:15.0: shutdown urb ffffa3c7cc695cc0 ep1in-bulk
[  167.284055] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[  167.284064] sd 0:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 33 04 90 00 01 00 00
...

Analyzed the USB trace in the link layer we realized it is because
of the 6-ms timer of tRecoveryConfigurationTimeout which documented
on the USB 3.2 Revision 1.0, the section 7.5.10.4.2 of "Exit from
Recovery.Configuration"; device initiates U1 exit -> Recovery.Active
-> Recovery.Configuration, then the host timer timeout makes the link
transits to eSS.Inactive -> Rx.Detect follows by a Warm Reset.

Interestingly, the other higher volume of SanDisk Ultra Flair sharing
the same VID:PID, such as 64GB, would not request LPM during runtime,
it sticks at U0 always, thus disabling LPM does not affect those thumb
drives at all.

The same odd occures in SanDisk Ultra Fit 16GB, VID:PID in 0781:5583.

Signed-off-by: Harry Pan 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

Revert "usb: gadget: ffs: Fix BUG when userland exits with submitted AIO transfers"

2018-12-13T08:16:11+00:00

[ Upstream commit a9c859033f6ec772f8e3228c343bb1321584ae0e ]

This reverts commit b4194da3f9087dd38d91b40f9bec42d59ce589a8
since it causes list corruption followed by kernel panic:

Workqueue: adb ffs_aio_cancel_worker
RIP: 0010:__list_add_valid+0x4d/0x70
Call Trace:
insert_work+0x47/0xb0
__queue_work+0xf6/0x400
queue_work_on+0x65/0x70
dwc3_gadget_giveback+0x44/0x50 [dwc3]
dwc3_gadget_ep_dequeue+0x83/0x2d0 [dwc3]
? finish_wait+0x80/0x80
usb_ep_dequeue+0x1e/0x90
process_one_work+0x18c/0x3b0
worker_thread+0x3c/0x390
? process_one_work+0x3b0/0x3b0
kthread+0x11e/0x140
? kthread_create_worker_on_cpu+0x70/0x70
ret_from_fork+0x3a/0x50

This issue is seen with warm reboot stability testing.

Signed-off-by: Shen Jing 
Signed-off-by: Saranya Gopal 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin

usb: dwc2: pci: Fix an error code in probe

2018-12-13T08:16:11+00:00

[ Upstream commit 3c135e8900199e3b9375c1eff808cceba2ee37de ]

We added some error handling to this function but forgot to set the
error code on this path.

Fixes: ecd29dabb2ba ("usb: dwc2: pci: Handle error cleanup in probe")
Acked-by: Minas Harutyunyan 
Signed-off-by: Dan Carpenter 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin

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