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

xhci: Show what USB release number the xHC supports from protocol capablity

2018-05-25T14:17:42+00:00

[ Upstream commit 0ee78c101425aae681c631ba59c6ac7f44b1d83a ]

xhci driver displays the supported xHC USB revision in a message during
driver load:

"Host supports USB 3.1 Enhanced SuperSpeed"

Get the USB minor revision number from the xhci protocol capability.
This will show the correct supported revisions for new USB 3.2 and later
hosts

Don't rely on the SBRN (serial bus revision number) register, it's often
showing 0x30 (USB3.0) for hosts that support USB 3.1

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

usb: gadget: composite: fix incorrect handling of OS desc requests

2018-05-25T14:17:41+00:00

[ Upstream commit 5d6ae4f0da8a64a185074dabb1b2f8c148efa741 ]

When handling an OS descriptor request, one of the first operations is
to zero out the request buffer using the wLength from the setup packet.
There is no bounds checking, so a wLength > 4096 would clobber memory
adjacent to the request buffer. Fix this by taking the min of wLength
and the request buffer length prior to the memset. While at it, define
the buffer length in a header file so that magic numbers don't appear
throughout the code.

When returning data to the host, the data length should be the min of
the wLength and the valid data we have to return. Currently we are
returning wLength, thus requests for a wLength greater than the amount
of data in the OS descriptor buffer would return invalid (albeit zero'd)
data following the valid descriptor data. Fix this by counting the
number of bytes when constructing the data and using this when
determining the length of the request.

Signed-off-by: Chris Dickens 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

usb: gadget: udc: change comparison to bitshift when dealing with a mask

2018-05-25T14:17:41+00:00

[ Upstream commit ac87e560f7c0f91b62012e9a159c0681a373b922 ]

Due to a typo, the mask was destroyed by a comparison instead of a bit
shift.

Reported-by: Geert Uytterhoeven 
Signed-off-by: Wolfram Sang 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

usbip: Correct maximum value of CONFIG_USBIP_VHCI_HC_PORTS

2018-05-25T14:17:41+00:00

[ Upstream commit 351a8d4837ae0d61744e64262c3a80ab92ff3e42 ]

Now that usbip supports USB3, the maximum number of ports allowed
on a hub is 15 (USB_SS_MAXPORTS), not 31 (USB_MAXCHILDREN).

Reported-by: Gianluigi Tiesi 
Reported-by: Borissh1983 
References: https://bugs.debian.org/878866
Fixes: 1c9de5bf4286 ("usbip: vhci-hcd: Add USB3 SuperSpeed support")
Signed-off-by: Ben Hutchings 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

usb: gadget: ffs: Execute copy_to_user() with USER_DS set

2018-05-25T14:17:41+00:00

[ Upstream commit 4058ebf33cb0be88ca516f968eda24ab7b6b93e4 ]

When using a AIO read() operation on the function FS gadget driver a URB is
submitted asynchronously and on URB completion the received data is copied
to the userspace buffer associated with the read operation.

This is done from a kernel worker thread invoking copy_to_user() (through
copy_to_iter()). And while the user space process memory is made available
to the kernel thread using use_mm(), some architecture require in addition
to this that the operation runs with USER_DS set. Otherwise the userspace
memory access will fail.

For example on ARM64 with Privileged Access Never (PAN) and User Access
Override (UAO) enabled the following crash occurs.

	Internal error: Accessing user space memory with fs=KERNEL_DS: 9600004f [#1] SMP
	Modules linked in:
	CPU: 2 PID: 1636 Comm: kworker/2:1 Not tainted 4.9.0-04081-g8ab2dfb-dirty #487
	Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
	Workqueue: events ffs_user_copy_worker
	task: ffffffc87afc8080 task.stack: ffffffc87a00c000
	PC is at __arch_copy_to_user+0x190/0x220
	LR is at copy_to_iter+0x78/0x3c8
	[...]
	[] __arch_copy_to_user+0x190/0x220
	[] ffs_user_copy_worker+0x70/0x130
	[] process_one_work+0x1dc/0x460
	[] worker_thread+0x50/0x4b0
	[] kthread+0xd8/0xf0
	[] ret_from_fork+0x10/0x50

Address this by placing a set_fs(USER_DS) before of the copy operation
and revert it again once the copy operation has finished.

This patch is analogous to commit d7ffde35e31a ("vhost: use USER_DS in
vhost_worker thread") which addresses the same underlying issue.

Signed-off-by: Lars-Peter Clausen 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

usb: gadget: ffs: Let setup() return USB_GADGET_DELAYED_STATUS

2018-05-25T14:17:41+00:00

[ Upstream commit 946ef68ad4e45aa048a5fb41ce8823ed29da866a ]

Some UDC drivers (like the DWC3) expect that the response to a setup()
request is queued from within the setup function itself so that it is
available as soon as setup() has completed.

Upon receiving a setup request the function fs driver creates an event that
is made available to userspace. And only once userspace has acknowledged
that event the response to the setup request is queued.

So it violates the requirement of those UDC drivers and random failures can
be observed. This is basically a race condition and if userspace is able to
read the event and queue the response fast enough all is good. But if it is
not, for example because other processes are currently scheduled to run,
the USB host that sent the setup request will observe an error.

To avoid this the gadget framework provides the USB_GADGET_DELAYED_STATUS
return code. If a setup() callback returns this value the UDC driver is
aware that response is not yet available and can uses the appropriate
methods to handle this case.

Since in the case of function fs the response will never be available when
the setup() function returns make sure that this status code is used.

This fixed random occasional failures that were previously observed on a
DWC3 based system under high system load.

Signed-off-by: Lars-Peter Clausen 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

usb: dwc2: host: Fix transaction errors in host mode

2018-05-25T14:17:40+00:00

[ Upstream commit 92a8dd26464e1f21f1d869ec53717bd2c1200d63 ]

Added missing GUSBCFG programming in host mode, which fixes
transaction errors issue on HiKey and Altera Cyclone V boards.

These field even if was programmed in device mode (in function
dwc2_hsotg_core_init_disconnected()) will be resetting to POR values
after core soft reset applied.
So, each time when switching to host mode required to set this field
to correct value.

Acked-by: John Youn 
Signed-off-by: Minas Harutyunyan 
Signed-off-by: Grigor Tovmasyan 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

usb: dwc2: hcd: Fix host channel halt flow

2018-05-25T14:17:40+00:00

[ Upstream commit a82c7abdf8fc3b09c4a0ed2eee6d43ecef2ccdb0 ]

According databook in Buffer and External DMA mode
non-split periodic channels can't be halted.

Acked-by: John Youn 
Signed-off-by: Minas Harutyunyan 
Signed-off-by: Grigor Tovmasyan 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

usb: dwc2: Fix interval type issue

2018-05-25T14:17:40+00:00

[ Upstream commit 12814a3f8f9b247531d7863170cc82b3fe4218fd ]

The maximum value that unsigned char can hold is 255, meanwhile
the maximum value of interval is  2^(bIntervalMax-1)=2^15.

Signed-off-by: Grigor Tovmasyan 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

xhci: zero usb device slot_id member when disabling and freeing a xhci slot

2018-05-25T14:17:40+00:00

[ Upstream commit a400efe455f7b61ac9a801ac8d0d01f8c8d82dd5 ]

set udev->slot_id to zero when disabling and freeing the xhci slot.
Prevents usb core from calling xhci with a stale slot id.

xHC controller may be reset during resume to recover from some error.
All slots are unusable as they are disabled and freed.
xhci driver starts slot enumeration again from 1 in the order they are
enabled. In the worst case a stale udev->slot_id for one device matches
a newly enabled slot_id for a different device, causing us to
perform a action on the wrong device.

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