linux/drivers/usb/core/driver.c, branch v4.9

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

2016-05-03T21:32:07Z

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

USB: usb_driver_claim_interface: add sanity checking

2016-03-18T16:19:02Z

Attacks that trick drivers into passing a NULL pointer to usb_driver_claim_interface() using forged descriptors are known. This thwarts them by sanity checking. Signed-off-by: Oliver Neukum CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

usb: core: driver: Use kmalloc_array

2015-10-04T09:47:19Z

Use kmalloc_array instead of kmalloc to allocate memory for an array. Also, remove the dev_warn for a memory leak, making the if check more sleek. Signed-off-by: Muhammad Falak R Wani Signed-off-by: Greg Kroah-Hartman

usb: interface authorization: Control interface probing and claiming

2015-09-22T19:08:40Z

Driver probings and interface claims get rejected if an interface is not authorized. Signed-off-by: Stefan Koch Signed-off-by: Greg Kroah-Hartman

Revert "usb: interface authorization: Control interface probing and claiming"

2015-08-18T16:58:26Z

This reverts commit de7718bd9c4d3db96991a98c2a0cb38258a04e47 as the signed-off-by address is invalid. Cc: Stefan Koch Signed-off-by: Greg Kroah-Hartman

usb: interface authorization: Control interface probing and claiming

2015-08-14T23:55:54Z

Driver probings and interface claims get rejected if an interface is not authorized. Signed-off-by: Stefan Koch Signed-off-by: Greg Kroah-Hartman

usb: fix coding style issue

2015-07-22T21:55:21Z

Fixed coding style issue: newline after declaration Signed-off-by: Kris Borer Signed-off-by: Greg Kroah-Hartman

USB: add flag for HCDs that can't receive wakeup requests (isp1760-hcd)

2015-01-31T17:05:06Z

Currently the USB stack assumes that all host controller drivers are capable of receiving wakeup requests from downstream devices. However, this isn't true for the isp1760-hcd driver, which means that it isn't safe to do a runtime suspend of any device attached to a root-hub port if the device requires wakeup. This patch adds a "cant_recv_wakeups" flag to the usb_hcd structure and sets the flag in isp1760-hcd. The core is modified to prevent a direct child of the root hub from being put into runtime suspend with wakeup enabled if the flag is set. Signed-off-by: Alan Stern Tested-by: Nicolas Pitre CC: Signed-off-by: Greg Kroah-Hartman

USB: don't cancel queued resets when unbinding drivers

2015-01-25T12:54:17Z

The USB stack provides a mechanism for drivers to request an asynchronous device reset (usb_queue_reset_device()). The mechanism uses a work item (reset_ws) embedded in the usb_interface structure used by the driver, and the reset is carried out by a work queue routine. The asynchronous reset can race with driver unbinding. When this happens, we try to cancel the queued reset before unbinding the driver, on the theory that the driver won't care about any resets once it is unbound. However, thanks to the fact that lockdep now tracks work queue accesses, this can provoke a lockdep warning in situations where the device reset causes another interface's driver to be unbound; see http://marc.info/?l=linux-usb&m=141893165203776&w=2 for an example. The reason is that the work routine for reset_ws in one interface calls cancel_queued_work() for the reset_ws in another interface. Lockdep thinks this might lead to a work routine trying to cancel itself. The simplest solution is not to cancel queued resets when unbinding drivers. This means we now need to acquire a reference to the usb_interface when queuing a reset_ws work item and to drop the reference when the work routine finishes. We also need to make sure that the usb_interface structure doesn't outlive its parent usb_device; this means acquiring and dropping a reference when the interface is created and destroyed. In addition, cancelling a queued reset can fail (if the device is in the middle of an earlier reset), and this can cause usb_reset_device() to try to rebind an interface that has been deallocated (see http://marc.info/?l=linux-usb&m=142175717016628&w=2 for details). Acquiring the extra references prevents this failure. Signed-off-by: Alan Stern Reported-by: Russell King - ARM Linux Reported-by: Olivier Sobrie Tested-by: Olivier Sobrie Cc: stable # 3.19 Signed-off-by: Greg Kroah-Hartman

USB / PM: Drop CONFIG_PM_RUNTIME from the USB core

2014-12-03T23:51:54Z

After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is selected) PM_RUNTIME is always set if PM is set, so quite a few depend on CONFIG_PM (or even dropped in some cases). Replace CONFIG_PM_RUNTIME with CONFIG_PM in the USB core code and documentation. Signed-off-by: Rafael J. Wysocki Acked-by: Alan Stern Acked-by: Greg Kroah-Hartman