linux.git/drivers/usb/core, branch v4.7-rc2

Merge 4.6-rc7 into usb-next

2016-05-09T07:29:13+00:00

We want the USB fixes in here to resolve merge issues and make it easier
for testing.

Signed-off-by: Greg Kroah-Hartman

USB: usbfs: fix potential infoleak in devio

2016-05-03T21:32:07+00:00

The stack object “ci” has a total size of 8 bytes. Its last 3 bytes
are padding bytes which are not initialized and leaked to userland
via “copy_to_user”.

Signed-off-by: Kangjie Lu 
Signed-off-by: Greg Kroah-Hartman

USB: leave LPM alone if possible when binding/unbinding interface drivers

2016-05-03T21:32:07+00:00

When a USB driver is bound to an interface (either through probing or
by claiming it) or is unbound from an interface, the USB core always
disables Link Power Management during the transition and then
re-enables it afterward.  The reason is because the driver might want
to prevent hub-initiated link power transitions, in which case the HCD
would have to recalculate the various LPM parameters.  This
recalculation takes place when LPM is re-enabled and the new
parameters are sent to the device and its parent hub.

However, if the driver does not want to prevent hub-initiated link
power transitions then none of this work is necessary.  The parameters
don't need to be recalculated, and LPM doesn't need to be disabled and
re-enabled.

It turns out that disabling and enabling LPM can be time-consuming,
enough so that it interferes with user programs that want to claim and
release interfaces rapidly via usbfs.  Since the usbfs kernel driver
doesn't set the disable_hub_initiated_lpm flag, we can speed things up
and get the user programs to work by leaving LPM alone whenever the
flag isn't set.

And while we're improving the way disable_hub_initiated_lpm gets used,
let's also fix its kerneldoc.

Signed-off-by: Alan Stern 
Tested-by: Matthew Giassa 
CC: Mathias Nyman 
CC: 
Signed-off-by: Greg Kroah-Hartman

Revert "USB / PM: Allow USB devices to remain runtime-suspended when sleeping"

2016-05-02T15:44:31+00:00

This reverts commit e3345db85068ddb937fc0ba40dfc39c293dad977, which
broke system resume for a large class of devices.

Devices that after having been reset during resume need to be rebound
due to a missing reset_resume callback, are now left in a suspended
state. This specifically broke resume of common USB-serial devices,
which are now unusable after system suspend (until disconnected and
reconnected) when USB persist is enabled.

During resume, usb_resume_interface will set the needs_binding flag for
such interfaces, but unlike system resume, run-time resume does not
honour it.

Cc: stable 	# 4.5
Signed-off-by: Johan Hovold 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

usb: core: move root hub's device node assignment after it is added to bus

2016-04-28T19:57:49+00:00

When the root hub device is added to the bus, it tries to get pins
information from pinctrl (see pinctrl_bind_pins, at really_probe), if
the pin information is described at DT, it will show below error since
the root hub's device node is the same with controller's, but controller's
pin has already been requested when it is added to platform bus.

	imx6q-pinctrl 20e0000.iomuxc: pin MX6Q_PAD_GPIO_1 already
       	requested by 2184000.usb; cannot claim for usb1
	imx6q-pinctrl 20e0000.iomuxc: pin-137 (usb1) status -22
	imx6q-pinctrl 20e0000.iomuxc: could not request pin 137
       	(MX6Q_PAD_GPIO_1) from group usbotggrp-3 on device 20e0000.iomuxc
	usb usb1: Error applying setting, reverse things back

To fix this issue, we move the root hub's device node assignment (equals
to contrller's) after device is added to bus, we only need to know root
hub's device node information after the device under root hub is created,
so this movement will not affect current function.

Signed-off-by: Peter Chen 
Reported-by: Lars Steubesand 
Signed-off-by: Greg Kroah-Hartman

usb: core: hub: hub_port_init lock controller instead of bus

2016-04-28T19:40:46+00:00

The XHCI controller presents two USB buses to the system - one for USB2
and one for USB3. The hub init code (hub_port_init) is reentrant but
only locks one bus per thread, leading to a race condition failure when
two threads attempt to simultaneously initialise a USB2 and USB3 device:

[    8.034843] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[   13.183701] usb 3-3: device descriptor read/all, error -110

On a test system this failure occurred on 6% of all boots.

The call traces at the point of failure are:

Call Trace:
 [] schedule+0x37/0x90
 [] usb_kill_urb+0x8d/0xd0
 [] ? wake_up_atomic_t+0x30/0x30
 [] usb_start_wait_urb+0xbe/0x150
 [] usb_control_msg+0xbc/0xf0
 [] hub_port_init+0x51e/0xb70
 [] hub_event+0x817/0x1570
 [] process_one_work+0x1ff/0x620
 [] ? process_one_work+0x15f/0x620
 [] worker_thread+0x64/0x4b0
 [] ? rescuer_thread+0x390/0x390
 [] kthread+0x105/0x120
 [] ? kthread_create_on_node+0x200/0x200
 [] ret_from_fork+0x3f/0x70
 [] ? kthread_create_on_node+0x200/0x200

Call Trace:
 [] xhci_setup_device+0x53d/0xa40
 [] xhci_address_device+0xe/0x10
 [] hub_port_init+0x1bf/0xb70
 [] ? trace_hardirqs_on+0xd/0x10
 [] hub_event+0x817/0x1570
 [] process_one_work+0x1ff/0x620
 [] ? process_one_work+0x15f/0x620
 [] worker_thread+0x64/0x4b0
 [] ? rescuer_thread+0x390/0x390
 [] kthread+0x105/0x120
 [] ? kthread_create_on_node+0x200/0x200
 [] ret_from_fork+0x3f/0x70
 [] ? kthread_create_on_node+0x200/0x200

Which results from the two call chains:

hub_port_init
 usb_get_device_descriptor
  usb_get_descriptor
   usb_control_msg
    usb_internal_control_msg
     usb_start_wait_urb
      usb_submit_urb / wait_for_completion_timeout / usb_kill_urb

hub_port_init
 hub_set_address
  xhci_address_device
   xhci_setup_device

Mathias Nyman explains the current behaviour violates the XHCI spec:

 hub_port_reset() will end up moving the corresponding xhci device slot
 to default state.

 As hub_port_reset() is called several times in hub_port_init() it
 sounds reasonable that we could end up with two threads having their
 xhci device slots in default state at the same time, which according to
 xhci 4.5.3 specs still is a big no no:

 "Note: Software shall not transition more than one Device Slot to the
  Default State at a time"

 So both threads fail at their next task after this.
 One fails to read the descriptor, and the other fails addressing the
 device.

Fix this in hub_port_init by locking the USB controller (instead of an
individual bus) to prevent simultaneous initialisation of both buses.

Fixes: 638139eb95d2 ("usb: hub: allow to process more usb hub events in parallel")
Link: https://lkml.org/lkml/2016/2/8/312
Link: https://lkml.org/lkml/2016/2/4/748
Signed-off-by: Chris Bainbridge 
Cc: stable 
Acked-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

usb: devio: declare usbdev_vm_ops as static

2016-04-28T19:35:36+00:00

usbdev_vm_ops is used in devio.c only, so declare it as static

Signed-off-by: Michele Curti 
Signed-off-by: Greg Kroah-Hartman

usb: core: buffer: avoid NULL pointer dereferrence

2016-04-28T19:35:36+00:00

NULL pointer dereferrence will happen when class driver
wants to allocate zero length buffer and pool_max[0]
can't be used, so simply returns NULL in the case.

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

drivers: usb: core: Minimize irq disabling in usb_sg_cancel()

2016-04-26T22:21:41+00:00

Restructure usb_sg_cancel() so we don't have to disable interrupts
while cancelling the URBs.

Suggested-by: Alan Stern 
Signed-off-by: David Mosberger 
Signed-off-by: Greg Kroah-Hartman

drivers: usb: core: Don't disable irqs in usb_sg_wait() during URB submit.

2016-04-26T22:21:41+00:00

usb_submit_urb() may take quite long to execute.  For example, a
single sg list may have 30 or more entries, possibly leading to that
many calls to DMA-map pages.  This can cause interrupt latency of
several hundred micro-seconds.

Avoid the problem by releasing the io->lock spinlock and re-enabling
interrupts before calling usb_submit_urb().  This opens races with
usb_sg_cancel() and sg_complete().  Handle those races by using
usb_block_urb() to stop URBs from being submitted after
usb_sg_cancel() or sg_complete() with error.

Note that usb_unlink_urb() is guaranteed to return -ENODEV if
!io->urbs[i]->dev and since the -ENODEV case is already handled,
we don't have to check for !io->urbs[i]->dev explicitly.

Before this change, reading 512MB from an ext3 filesystem on a USB
memory stick showed a throughput of 12 MB/s with about 500 missed
deadlines.

With this change, reading the same file gave the same throughput but
only one or two missed deadlines.

Signed-off-by: David Mosberger 
Signed-off-by: Greg Kroah-Hartman