linux/drivers/usb/core/message.c, branch v3.0.62

USB: fix endpoint-disabling for failed config changes

2013-01-21T19:44:59Z

commit 36caff5d795429c572443894e8789c2150dd796b upstream. This patch (as1631) fixes a bug that shows up when a config change fails for a device under an xHCI controller. The controller needs to be told to disable the endpoints that have been enabled for the new config. The existing code does this, but before storing the information about which endpoints were enabled! As a result, any second attempt to install the new config is doomed to fail because xhci-hcd will refuse to enable an endpoint that is already enabled. The patch optimistically initializes the new endpoints' device structures before asking the device to switch to the new config. If the request fails then the endpoint information is already stored, so we can use usb_hcd_alloc_bandwidth() to disable the endpoints with no trouble. The rest of the error path is slightly more complex now; we have to disable the new interfaces and call put_device() rather than simply deallocating them. Signed-off-by: Alan Stern Reported-and-tested-by: Matthias Schniedermeyer CC: Sarah Sharp Signed-off-by: Greg Kroah-Hartman Signed-off-by: CAI Qian

USB: fix gathering of interface associations

2012-06-22T18:34:16Z

commit b3a3dd074f7053ef824ad077e5331b52220ceba1 upstream. TEAC's UD-H01 (and probably other devices) have a gap in the interface number allocation of their descriptors: Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 220 bNumInterfaces 3 [...] Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 [...] Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 2 bInterfaceCount 2 bFunctionClass 1 Audio bFunctionSubClass 0 bFunctionProtocol 32 iFunction 4 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 [...] Once a configuration is selected, usb_set_configuration() walks the known interfaces of a given configuration and calls find_iad() on each of them to set the interface association pointer the interface is included in. The problem here is that the loop variable is taken for the interface number in the comparison logic that gathers the association. Which is fine as long as the descriptors are sane. In the case above, however, the logic gets out of sync and the interface association fields of all interfaces beyond the interface number gap are wrong. Fix this by passing the interface's bInterfaceNumber to find_iad() instead. Signed-off-by: Daniel Mack Reported-by: bEN Reported-by: Ivan Perrone Tested-by: ivan perrone Signed-off-by: Greg Kroah-Hartman

USB: fix deadlock in bConfigurationValue attribute method

2012-04-27T16:51:08Z

commit 8963c487a80b4688c9e68dcc504a90074aacc145 upstream. This patch (as154) fixes a self-deadlock that occurs when userspace writes to the bConfigurationValue sysfs attribute for a hub with children. The task tries to lock the bandwidth_mutex at a time when it already owns the lock: The attribute's method calls usb_set_configuration(), which calls usb_disable_device() with the bandwidth_mutex held. usb_disable_device() unregisters the existing interfaces, which causes the hub driver to be unbound. The hub_disconnect() routine calls hub_quiesce(), which calls usb_disconnect() for each of the hub's children. usb_disconnect() attempts to acquire the bandwidth_mutex around a call to usb_disable_device(). The solution is to make usb_disable_device() acquire the mutex for itself instead of requiring the caller to hold it. Then the mutex can cover only the bandwidth deallocation operation and not the region where the interfaces are unregistered. This has the potential to change system behavior slightly when a config change races with another config or altsetting change. Some of the bandwidth released from the old config might get claimed by the other config or altsetting, make it impossible to restore the old config in case of a failure. But since we don't try to recover from config-change failures anyway, this doesn't matter. [This should be marked for stable kernels that contain the commit fccf4e86200b8f5edd9a65da26f150e32ba79808 "USB: Free bandwidth when usb_disable_device is called." That commit was marked for stable kernels as old as 2.6.32.] Signed-off-by: Alan Stern Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman

USB: don't clear urb->dev in scatter-gather library

2012-04-22T23:21:40Z

commit bcf398537630bf20b4dbe59ba855b69f404c93cf upstream. This patch (as1517b) fixes an error in the USB scatter-gather library. The library code uses urb->dev to determine whether or nor an URB is currently active; the completion handler sets urb->dev to NULL. However the core unlinking routines need to use urb->dev. Since unlinking always racing with completion, the completion handler must not clear urb->dev -- it can lead to invalid memory accesses when a transfer has to be cancelled. This patch fixes the problem by getting rid of the lines that clear urb->dev after urb has been submitted. As a result we may end up trying to unlink an URB that failed in submission or that has already completed, so an extra check is added after each unlink to avoid printing an error message when this happens. The checks are updated in both sg_complete() and sg_cancel(), and the second is updated to match the first (currently it prints out unnecessary warning messages if a device is unplugged while a transfer is in progress). Signed-off-by: Alan Stern Reported-and-tested-by: Illia Zaitsev CC: Ming Lei Signed-off-by: Greg Kroah-Hartman

USB: additional regression fix for device removal

2011-07-07T20:29:33Z

Commit e534c5b831c8b8e9f5edee5c8a37753c808b80dc (USB: fix regression occurring during device removal) didn't go far enough. It failed to take into account that when a driver claims multiple interfaces, it may release them all at the same time. As a result, some interfaces can get released before they are unregistered, and we deadlock trying to acquire the bandwidth_mutex that we already own. This patch (asl478) handles this case by setting the "unregistering" flag on all the interfaces before removing any of them. Signed-off-by: Alan Stern Cc: stable Tested-by: Éric Piel Signed-off-by: Greg Kroah-Hartman

USB: fix regression occurring during device removal

2011-07-01T21:20:39Z

This patch (as1476) fixes a regression introduced by fccf4e86200b8f5edd9a65da26f150e32ba79808 (USB: Free bandwidth when usb_disable_device is called). usb_disconnect() grabs the bandwidth_mutex before calling usb_disable_device(), which calls down indirectly to usb_set_interface(), which tries to acquire the bandwidth_mutex. The fix causes usb_set_interface() to return early when it is called for an interface that has already been unregistered, which is what happens in usb_disable_device(). Signed-off-by: Alan Stern Tested-by: Sarah Sharp Cc: stable Signed-off-by: Greg Kroah-Hartman

USB: Free bandwidth when usb_disable_device is called.

2011-06-15T21:05:18Z

Tanya ran into an issue when trying to switch a UAS device from the BOT configuration to the UAS configuration via the bConfigurationValue sysfs file. Before installing the UAS configuration, set_bConfigurationValue() calls usb_disable_device(). That function is supposed to remove all host controller resources associated with that device, but it leaves some state in the xHCI host controller. Commit 0791971ba8fbc44e4f476079f856335ed45e6324 usb: allow drivers to use allocated bandwidth until unbound added a call to usb_disable_device() in usb_set_configuration(), before the xHCI bandwidth functions were invoked. That commit fixed a bug, but also introduced a bug that is triggered when a configured device is switched to a new configuration. usb_disable_device() goes through all the motions of unbinding the drivers attached to active interfaces and removing the USB core structures associated with those interfaces, but it doesn't actually remove the endpoints from the internal xHCI host controller bandwidth structures. When usb_disable_device() calls usb_disable_endpoint() with reset_hardware set to true, the entries in udev->ep_out and udev->ep_in will be set to NULL. Usually, when the USB core installs a new configuration, usb_hcd_alloc_bandwidth() will drop all non-NULL endpoints in udev->ep_out and udev->ep_in before adding any new endpoints. However, when the new UAS configuration was added, all those entries were null, so none of the old endpoints in the BOT configuration were dropped. The xHCI driver blindly added the UAS configuration endpoints, and some of the endpoint addresses overlapped with the old BOT configuration endpoints. This caused the xHCI host to reject the Configure Endpoint command. Now that the xHCI driver code is cleaned up to reject a double-add of active endpoints, we need to fix the USB core to properly drop old endpoints in usb_disable_device(). If the host controller driver needs bandwidth checking support, make usb_disable_device() call usb_disable_endpoint() with reset_hardware set to false, drop the endpoints from the xHCI host controller, and then call usb_disable_endpoint() again with reset_hardware set to true. The first call to usb_disable_endpoint() will cancel any pending URBs and wait on them to be freed in usb_hcd_disable_endpoint(), but will keep the pointers in udev->ep_out and udev->ep in intact. Then usb_hcd_alloc_bandwidth() will use those pointers to know which endpoints to drop. The final call to usb_disable_endpoint() will do two things: 1. It will call usb_hcd_disable_endpoint() again, which should be harmless since the ep->urb_list should be empty after the first call to usb_disable_endpoint() returns. 2. It will set the entries in udev->ep_out and udev->ep in to NULL, and call usb_hcd_disable_endpoint(). That call will have no effect, since the xHCI driver doesn't set the endpoint_disable function pointer. Note that usb_disable_device() will now need to be called with hcd->bandwidth_mutex held. This should be backported to kernels as old as 2.6.32. Signed-off-by: Sarah Sharp Reported-by: Tanya Brokhman Cc: ablay@codeaurora.org Cc: Alan Stern Cc: stable@kernel.org

usb: Change usb_hcd->bandwidth_mutex to a pointer.

2011-03-14T01:07:14Z

Change the bandwith_mutex in struct usb_hcd to a pointer. This will allow the pointer to be shared across usb_hcds for the upcoming work to split the xHCI driver roothub into a USB 2.0/1.1 and a USB 3.0 bus. Signed-off-by: Sarah Sharp

USB: make usb_mark_last_busy use pm_runtime_mark_last_busy

2010-11-16T22:02:54Z

Since the runtime-PM core already defines a .last_busy field in device.power, this patch uses it to replace the .last_busy field defined in usb_device and uses pm_runtime_mark_last_busy to implement usb_mark_last_busy. Signed-off-by: Ming Lei Reviewed-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

USB: use the no_callbacks flag for interfaces

2010-11-16T22:02:00Z

Call pm_runtime_no_callbacks to set no_callbacks flag for USB interfaces. Since interfaces cannot be power-managed separately from their parent devices, there's no reason for the runtime-PM core to invoke any callbacks for them. Signed-off-by: Ming Lei Reviewed-by: Alan Stern Signed-off-by: Greg Kroah-Hartman