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

USB: Increment wakeup count on remote wakeup.

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

[ Upstream commit 83a62c51ba7b3c0bf45150c4eac7aefc6c785e94 ]

On chromebooks we depend on wakeup count to identify the wakeup source.
But currently USB devices do not increment the wakeup count when they
trigger the remote wake. This patch addresses the same.

Resume condition is reported differently on USB 2.0 and USB 3.0 devices.

On USB 2.0 devices, a wake capable device, if wake enabled, drives
resume signal to indicate a remote wake (USB 2.0 spec section 7.1.7.7).
The upstream facing port then sets C_PORT_SUSPEND bit and reports a
port change event (USB 2.0 spec section 11.24.2.7.2.3). Thus if a port
has resumed before driving the resume signal from the host and
C_PORT_SUSPEND is set, then the device attached to the given port might
be the reason for the last system wakeup. Increment the wakeup count for
the same.

On USB 3.0 devices, a function may signal that it wants to exit from device
suspend by sending a Function Wake Device Notification to the host (USB3.0
spec section 8.5.6.4) Thus on receiving the Function Wake, increment the
wakeup count.

Signed-off-by: Ravi Chandra Sadineni 
Acked-by: Alan Stern 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: core: Add quirk for HP v222w 16GB Mini

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

[ Upstream commit 3180dabe08e3653bf0a838553905d88f3773f29c ]

Add DELAY_INIT quirk to fix the following problem with HP
v222w 16GB Mini:

usb 1-3: unable to read config index 0 descriptor/start: -110
usb 1-3: can't read configurations, error -110
usb 1-3: can't set config #1, error -110

Signed-off-by: Kamil Lulko 
Signed-off-by: Kuppuswamy Sathyanarayanan 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

USB:fix USB3 devices behind USB3 hubs not resuming at hibernate thaw

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

[ Upstream commit 64627388b50158fd24d6ad88132525b95a5ef573 ]

USB3 hubs don't support global suspend.

USB3 specification 10.10, Enhanced SuperSpeed hubs only support selective
suspend and resume, they do not support global suspend/resume where the
hub downstream facing ports states are not affected.

When system enters hibernation it first enters freeze process where only
the root hub enters suspend, usb_port_suspend() is not called for other
devices, and suspend status flags are not set for them. Other devices are
expected to suspend globally. Some external USB3 hubs will suspend the
downstream facing port at global suspend. These devices won't be resumed
at thaw as the suspend status flag is not set.

A USB3 removable hard disk connected through a USB3 hub that won't resume
at thaw will fail to synchronize SCSI cache, return “cmd cmplt err -71”
error, and needs a 60 seconds timeout which causing system hang for 60s
before the USB host reset the port for the USB3 removable hard disk to
recover.

Fix this by always calling usb_port_suspend() during freeze for USB3
devices.

Signed-off-by: Zhengjun Xing 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: quirks: add control message delay for 1b1c:1b20

2018-03-21T03:49:54+00:00

[ Upstream commit cb88a0588717ba6c756cb5972d75766b273a6817 ]

Corsair Strafe RGB keyboard does not respond to usb control messages
sometimes and hence generates timeouts.

Commit de3af5bf259d ("usb: quirks: add delay init quirk for Corsair
Strafe RGB keyboard") tried to fix those timeouts by adding
USB_QUIRK_DELAY_INIT.

Unfortunately, even with this quirk timeouts of usb_control_msg()
can still be seen, but with a lower frequency (approx. 1 out of 15):

[   29.103520] usb 1-8: string descriptor 0 read error: -110
[   34.363097] usb 1-8: can't set config #1, error -110

Adding further delays to different locations where usb control
messages are issued just moves the timeouts to other locations,
e.g.:

[   35.400533] usbhid 1-8:1.0: can't add hid device: -110
[   35.401014] usbhid: probe of 1-8:1.0 failed with error -110

The only way to reliably avoid those issues is having a pause after
each usb control message. In approx. 200 boot cycles no more timeouts
were seen.

Addionaly, keep USB_QUIRK_DELAY_INIT as it turned out to be necessary
to have the delay in hub_port_connect() after hub_port_init().

The overall boot time seems not to be influenced by these additional
delays, even on fast machines and lightweight distributions.

Fixes: de3af5bf259d ("usb: quirks: add delay init quirk for Corsair Strafe RGB keyboard")
Cc: stable@vger.kernel.org
Signed-off-by: Danilo Krummrich 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

Add delay-init quirk for Corsair K70 RGB keyboards

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

[ Upstream commit 7a1646d922577b5b48c0d222e03831141664bb59 ]

Following on from this patch: https://lkml.org/lkml/2017/11/3/516,
Corsair K70 RGB keyboards also require the DELAY_INIT quirk to
start correctly at boot.

Device ids found here:
usb 3-3: New USB device found, idVendor=1b1c, idProduct=1b13
usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-3: Product: Corsair K70 RGB Gaming Keyboard

Signed-off-by: Jack Stocker 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: add RESET_RESUME for ELSA MicroLink 56K

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

[ Upstream commit b9096d9f15c142574ebebe8fbb137012bb9d99c2 ]

This modem needs this quirk to operate. It produces timeouts when
resumed without reset.

Signed-off-by: Oliver Neukum 
CC: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: Add device quirk for Logitech HD Pro Webcam C925e

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

[ Upstream commit 7f038d256c723dd390d2fca942919573995f4cfd ]

Commit e0429362ab15
("usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e")
introduced quirk to workaround an issue with some Logitech webcams.

There is one more model that has the same issue - C925e, so applying
the same quirk as well.

See aforementioned commit message for detailed explanation of the problem.

Signed-off-by: Dmitry Fleytman 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

USB: core: prevent malicious bNumInterfaces overflow

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

[ Upstream commit 48a4ff1c7bb5a32d2e396b03132d20d552c0eca7 ]

A malicious USB device with crafted descriptors can cause the kernel
to access unallocated memory by setting the bNumInterfaces value too
high in a configuration descriptor.  Although the value is adjusted
during parsing, this adjustment is skipped in one of the error return
paths.

This patch prevents the problem by setting bNumInterfaces to 0
initially.  The existing code already sets it to the proper value
after parsing is complete.

Signed-off-by: Alan Stern 
Reported-by: Andrey Konovalov 
CC: 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

USB: usbfs: Filter flags passed in from user space

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

[ Upstream commit 446f666da9f019ce2ffd03800995487e79a91462 ]

USBDEVFS_URB_ISO_ASAP must be accepted only for ISO endpoints.
Improve sanity checking.

Reported-by: Andrey Konovalov 
Signed-off-by: Oliver Neukum 
Cc: stable 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

USB: devio: Prevent integer overflow in proc_do_submiturb()

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

[ Upstream commit 57999d1107c1e60c2ca7088f2ac0f819e2f554b3 ]

There used to be an integer overflow check in proc_do_submiturb() but
we removed it.  It turns out that it's still required.  The
uurb->buffer_length variable is a signed integer and it's controlled by
the user.  It can lead to an integer overflow when we do:

	num_sgs = DIV_ROUND_UP(uurb->buffer_length, USB_SG_SIZE);

If we strip away the macro then that line looks like this:

	num_sgs = (uurb->buffer_length + USB_SG_SIZE - 1) / USB_SG_SIZE;
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
It's the first addition which can overflow.

Fixes: 1129d270cbfb ("USB: Increase usbfs transfer limit")
Cc: stable 
Signed-off-by: Dan Carpenter 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin