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

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

USB: shutdown all URBs after controller death

2014-07-17T23:59:27Z

When a host controller dies, we don't need to wait for a driver to time out. We can shut down its URBs immediately. Without this change, we can end up waiting 30 seconds for a mass-storage transfer to time out. Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

USB: Avoid runtime suspend loops for HCDs that can't handle suspend/resume

2014-05-23T19:06:00Z

Not all host controller drivers have bus-suspend and bus-resume methods. When one doesn't, it will cause problems if runtime PM is enabled in the kernel. The PM core will attempt to suspend the controller's root hub, the suspend will fail because there is no bus-suspend routine, and a -EBUSY error code will be returned to the PM core. This will cause the suspend attempt to be repeated shortly thereafter, in a never-ending loop. Part of the problem is that the original error code -ENOENT gets changed to -EBUSY in usb_runtime_suspend(), on the grounds that the PM core will interpret -ENOENT as meaning that the root hub has gotten into a runtime-PM error state. While this change is appropriate for real USB devices, it's not such a good idea for a root hub. In fact, considering the root hub to be in a runtime-PM error state would not be far from the truth. Therefore this patch updates usb_runtime_suspend() so that it adjusts error codes only for non-root-hub devices. Furthermore, the patch attempts to prevent the problem from occurring in the first place by not enabling runtime PM by default for root hubs whose host controller driver doesn't have bus_suspend and bus_resume methods. Signed-off-by: Alan Stern Reported-by: Will Deacon Tested-by: Will Deacon CC: Signed-off-by: Greg Kroah-Hartman