aboutsummaryrefslogtreecommitdiff
path: root/drivers/usb/core
AgeCommit message (Collapse)Author
2012-07-16Merge 3.5-rc7 into usb-nextGreg Kroah-Hartman
This resolves the merge issue with the drivers/usb/host/ehci-omap.c file. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-07-14usb: feed USB device information to the /dev/random driverTheodore Ts'o
Send the USB device's serial, product, and manufacturer strings to the /dev/random driver to help seed its pools. Cc: Linus Torvalds <torvalds@linux-foundation.org> Acked-by: Greg KH <greg@kroah.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Cc: stable@vger.kernel.org
2012-07-11USB: Add a sysfs file to show LTM capabilities.Sarah Sharp
USB 3.0 devices can optionally support Latency Tolerance Messaging (LTM). Add a new sysfs file in the device directory to show whether a device is LTM capable. This file will be present for both USB 2.0 and USB 3.0 devices. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-07-11USB: Enable Latency Tolerance Messaging (LTM).Sarah Sharp
USB 3.0 devices may optionally support a new feature called Latency Tolerance Messaging. If both the xHCI host controller and the device support LTM, it should be turned on in order to give the system hardware a better clue about the latency tolerance values of its PCI devices. Once a Set Feature request to enable LTM is received, the USB 3.0 device will begin to send LTM updates as its buffers fill or empty, and it can tolerate more or less latency. The USB 3.0 spec, section C.4.2 says that LTM should be disabled just before the device is placed into suspend. Then the device will send an updated LTM notification, so that the system doesn't think it should remain in an active state in order to satisfy the latency requirements of the suspended device. The Set and Clear Feature LTM enable command can only be sent to a configured device. The device will respond with an error if that command is sent while it is in the Default or Addressed state. Make sure to check udev->actconfig in usb_enable_ltm() and usb_disable_ltm(), and don't send those commands when the device is unconfigured. LTM should be enabled once a new configuration is installed in usb_set_configuration(). If we end up sending duplicate Set Feature LTM Enable commands on a switch from one installed configuration to another configuration, that should be harmless. Make sure that LTM is disabled before the device is unconfigured in usb_disable_device(). If no drivers are bound to the device, it doesn't make sense to allow the device to control the latency tolerance of the xHCI host controller. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-07-11USB: Fix LPM disable count mismatch on driver unbind.Sarah Sharp
When a user runs `echo 0 > bConfigurationValue` for a USB 3.0 device, usb_disable_device() is called. This function disables all drivers, deallocates interfaces, and sets the device configuration value to 0 (unconfigured). With the new scheme to ensure that unconfigured devices have LPM disabled, usb_disable_device() must call usb_unlocked_disable_lpm() once it unconfigures the device. This commit should be backported to kernels as old as 3.5, that contain the commit 8306095fd2c1100e8244c09bf560f97aca5a311d "USB: Disable USB 3.0 LPM in critical sections." Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2012-07-11USB: Disable LPM while the device is unconfigured.Sarah Sharp
The USB 3.0 Set/Clear Feature U1/U2 Enable cannot be sent to a device in the Default or Addressed state. It can only be sent to a configured device. Change the USB core to initialize the LPM disable count to 1 (disabled), which reflects this limitation. Change usb_set_configuration() to ensure that if the device is unconfigured on entry, usb_lpm_disable() is not called. This avoids sending the Clear Feature U1/U2 when the device is in the Addressed state. When usb_set_configuration() exits with a successfully installed configuration, usb_lpm_enable() will be called. Once the new configuration is installed, make sure usb_set_configuration() only calls usb_enable_lpm() if the device moved to the Configured state. If we have unconfigured the device by sending it a Set Configuration for config 0, don't enable LPM. This commit should be backported to kernels as old as 3.5, that contain the commit 8306095fd2c1100e8244c09bf560f97aca5a311d "USB: Disable USB 3.0 LPM in critical sections." Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2012-07-11USB: Fix LPM disable/enable during device reset.Sarah Sharp
The USB 3.0 specification says that sending a Set Feature or Clear Feature for U1/U2 Enable is not a valid request when the device is in the Default or Addressed state. It is only valid when the device is in the Configured state. The original LPM patch attempted to disable LPM after the device had been reset by hub_port_init(), before it had the configuration reinstalled. The TI hub I tested with did not fail the Clear Feature U1/U2 Enable request that khubd sent while it was in the addressed state, which is why I didn't catch it. Move the LPM disable before the device reset, so that we can send the Clear Feature U1/U2 Enable successfully, and balance the LPM disable count. Also delete any calls to usb_enable_lpm() on error paths that lead to re-enumeration. The calls will fail because the device isn't configured, and it's not useful to balance the LPM disable count because the usb_device is about to be destroyed before re-enumeration. Fix the early exit path ("done" label) to call usb_enable_lpm() to balance the LPM disable count. Note that calling usb_reset_and_verify_device() with an unconfigured device may fail on the first call to usb_disable_lpm(). That's because the LPM disable count is initialized to 0 (LPM enabled), and usb_disable_lpm() will attempt to send a Clear Feature U1/U2 request to a device in the Addressed state. The next patch will fix that. This commit should be backported to kernels as old as 3.5, that contain the commit 8306095fd2c1100e8244c09bf560f97aca5a311d "USB: Disable USB 3.0 LPM in critical sections." Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2012-07-09usb/hcd: Ensure scatter-gather is not used for isoc transfersHans de Goede
We don't support sg for isoc transfers, enforce this. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-07-06usb: convert port_owners type from void * to struct dev_state *Lan Tianyu
This patch is to convert port_owners type from void * to struct dev_state * in order to make code more readable. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-07-06usbdevfs: Use scatter-gather lists for large bulk transfersHans de Goede
When using urb->transfer_buffer we need to allocate physical contiguous buffers for the entire transfer, which is pretty much guaranteed to fail with large transfers. Currently userspace works around this by breaking large transfers into multiple urbs. For large bulk transfers this leads to all kind of complications. This patch makes it possible for userspace to reliable submit large bulk transfers to scatter-gather capable host controllers in one go, by using a scatterlist to break the transfer up in managable chunks. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-07-06usbdevfs: Add a USBDEVFS_GET_CAPABILITIES ioctlHans de Goede
There are a few (new) usbdevfs capabilities which an application cannot discover in any other way then checking the kernel version. There are 3 problems with this: 1) It is just not very pretty. 2) Given the tendency of enterprise distros to backport stuff it is not reliable. 3) As discussed in length on the mailinglist, USBDEVFS_URB_BULK_CONTINUATION does not work as it should when combined with USBDEVFS_URB_SHORT_NOT_OK (which is its intended use) on devices attached to an XHCI controller. So the availability of these features can be host controller dependent, making depending on them based on the kernel version not a good idea. This patch besides adding the new ioctl also adds flags for the following existing capabilities: USBDEVFS_CAP_ZERO_PACKET, available since 2.6.31 USBDEVFS_CAP_BULK_CONTINUATION, available since 2.6.32, except for XHCI USBDEVFS_CAP_NO_PACKET_SIZE_LIM, available since 3.3 Note that this patch only does not advertise the USBDEVFS_URB_BULK_CONTINUATION cap for XHCI controllers, bulk transfers with this flag set will still be accepted when submitted to XHCI controllers. Returning -EINVAL for them would break existing apps, and in most cases the troublesome scenario wrt USBDEVFS_URB_SHORT_NOT_OK urbs on XHCI controllers will never get hit, so this would break working use cases. The disadvantage of not returning -EINVAL is that cases were it is causing real trouble may go undetected / the cause of the trouble may be unclear, but this is the best we can do. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-07-06usbdevfs: Correct amount of data copied to user in processcompl_compatHans de Goede
iso data buffers may have holes in them if some packets were short, so for iso urbs we should always copy the entire buffer, just like the regular processcompl does. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-07-02usb: Add support for root hub port status CASStanislaw Ledwon
The host controller port status register supports CAS (Cold Attach Status) bit. This bit could be set when USB3.0 device is connected when system is in Sx state. When the system wakes to S0 this port status with CAS bit is reported and this port can't be used by any device. When CAS bit is set the port should be reset by warm reset. This was not supported by xhci driver. The issue was found when pendrive was connected to suspended platform. The link state of "Compliance Mode" was reported together with CAS bit. This link state was also not supported by xhci and core/hub.c. The CAS bit is defined only for xhci root hub port and it is not supported on regular hubs. The link status is used to force warm reset on port. Make the USB core issue a warm reset when port is in ether the 'inactive' or 'compliance mode'. Change the xHCI driver to report 'compliance mode' when the CAS is set. This force warm reset on the root hub port. This patch should be backported to stable kernels as old as 3.2, that contain the commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When hot reset for USB3 fails, try warm reset." Signed-off-by: Stanislaw Ledwon <staszek.ledwon@linux.intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Andiry Xu <andiry.xu@amd.com> Cc: stable@vger.kernel.org
2012-06-20Merge 3.5-rc3 into usb-nextGreg Kroah-Hartman
This lets us catch the USB fixes that went into 3.5-rc3 into this branch, as we want them here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-14USB: fix gathering of interface associationsDaniel Mack
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 <zonque@gmail.com> Reported-by: bEN <ml_all@circa.be> Reported-by: Ivan Perrone <ivanperrone@hotmail.com> Tested-by: ivan perrone <ivanperrone@hotmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-13Merge tag 'for-usb-linus-2012-06-13' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus xhci: Bug fixes for 3.5 Hi Greg, Here's five bug fixes for 3.5. They fix some memory leaks in the bandwidth calculation code, fix a couple bugs in the USB3 Link PM patchset, and make system suspend and resume work on platforms with the AsMedia ASM1042 xHCI host controller. Sarah Sharp
2012-06-13USB: Checking the wrong variable in usb_disable_lpm()Dan Carpenter
We check "u1_params" instead of checking "u2_params". Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-06-13usb-core: Set intfdata to NULL if a driver's probe method failedHans de Goede
Ensure that intfdata always is NULL if no driver is bound: 1) drvdata is for a driver to store a pointer to driver specific data 2) If no driver is bound, there is no driver specific data associated with the device 3) Thus logically drvdata should be NULL if no driver is bound. We already set intfdata to NULL when a driver is unbound, to ensure that intfdata will be NULL even if the drivers disconnect method does not properly clear it. This ensures that intfdata will also be NULL after a failed probe, even if the driver's probe method left a (likely dangling) pointer in there. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-13USB: allow match on bInterfaceNumberBjørn Mork
Some composite USB devices provide multiple interfaces with different functions, all using "vendor-specific" for class/subclass/protocol. Another OS use interface numbers to match the driver and interface. It seems these devices are designed with that in mind - using static interface numbers for the different functions. This adds support for matching against the bInterfaceNumber, allowing such devices to be supported without having to resort to testing against interface number whitelists and/or blacklists in the probe. Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-13USB: rename the usb misc class from "usb" to "usbmisc"Greg Kroah-Hartman
This class was not named properly years ago, and it turns out that tools like udev can't properly see the devices in this class after booting due to the fact that there is a bus with the same name in the system. Changing this to "usbmisc" fixes this problem, and it solves the problem for the future when we want to unify classes and busses. Reported-by: Kay Sievers <kay@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-13USB: add NO_D3_DURING_SLEEP flag and revert 151b61284776be2Alan Stern
This patch (as1558) fixes a problem affecting several ASUS computers: The machine crashes or corrupts memory when going into suspend if the ehci-hcd driver is bound to any controllers. Users have been forced to unbind or unload ehci-hcd before putting their systems to sleep. After extensive testing, it was determined that the machines don't like going into suspend when any EHCI controllers are in the PCI D3 power state. Presumably this is a firmware bug, but there's nothing we can do about it except to avoid putting the controllers in D3 during system sleep. The patch adds a new flag to indicate whether the problem is present, and avoids changing the controller's power state if the flag is set. Runtime suspend is unaffected; this matters only for system suspend. However as a side effect, the controller will not respond to remote wakeup requests while the system is asleep. Hence USB wakeup is not functional -- but of course, this is already true in the current state of affairs. A similar patch has already been applied as commit 151b61284776be2d6f02d48c23c3625678960b97 (USB: EHCI: fix crash during suspend on ASUS computers). The patch supersedes that one and reverts it. There are two differences: The old patch added the flag at the USB level; this patch adds it at the PCI level. The old patch applied to all chipsets with the same vendor, subsystem vendor, and product IDs; this patch makes an exception for a known-good system (based on DMI information). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Dâniel Fraga <fragabr@gmail.com> Tested-by: Andrey Rahmatullin <wrar@wrar.name> Tested-by: Steven Rostedt <rostedt@goodmis.org> Cc: stable <stable@vger.kernel.org> Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-22Merge tag 'driver-core-3.5-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core updates from Greg Kroah-Hartman: "Here's the driver core, and other driver subsystems, pull request for the 3.5-rc1 merge window. Outside of a few minor driver core changes, we ended up with the following different subsystem and core changes as well, due to interdependancies on the driver core: - hyperv driver updates - drivers/memory being created and some drivers moved into it - extcon driver subsystem created out of the old Android staging switch driver code - dynamic debug updates - printk rework, and /dev/kmsg changes All of this has been tested in the linux-next releases for a few weeks with no reported problems. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>" Fix up conflicts in drivers/extcon/extcon-max8997.c where git noticed that a patch to the deleted drivers/misc/max8997-muic.c driver needs to be applied to this one. * tag 'driver-core-3.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (90 commits) uio_pdrv_genirq: get irq through platform resource if not set otherwise memory: tegra{20,30}-mc: Remove empty *_remove() printk() - isolate KERN_CONT users from ordinary complete lines sysfs: get rid of some lockdep false positives Drivers: hv: util: Properly handle version negotiations. Drivers: hv: Get rid of an unnecessary check in vmbus_prep_negotiate_resp() memory: tegra{20,30}-mc: Use dev_err_ratelimited() driver core: Add dev_*_ratelimited() family Driver Core: don't oops with unregistered driver in driver_find_device() printk() - restore prefix/timestamp printing for multi-newline strings printk: add stub for prepend_timestamp() ARM: tegra30: Make MC optional in Kconfig ARM: tegra20: Make MC optional in Kconfig ARM: tegra30: MC: Remove unnecessary BUG*() ARM: tegra20: MC: Remove unnecessary BUG*() printk: correctly align __log_buf ARM: tegra30: Add Tegra Memory Controller(MC) driver ARM: tegra20: Add Tegra Memory Controller(MC) driver printk() - restore timestamp printing at console output printk() - do not merge continuation lines of different threads ...
2012-05-21USB: Fix core compile with CONFIG_USB_SUSPEND=nSarah Sharp
When CONFIG_PM=n, make sure that the usb_[unlocked_][en/dis]able_lpm declarations are visible in include/linux/usb.h, and exported from drivers/usb/core/hub.c. Before this patch, if CONFIG_USB_SUSPEND was turned off, it would cause build errors: drivers/usb/core/hub.c: In function 'usb_disable_lpm': drivers/usb/core/hub.c:3394:2: error: implicit declaration of function 'usb_enable_lpm' [-Werror=implicit-function-declaration] drivers/usb/core/hub.c: At top level: drivers/usb/core/hub.c:3424:6: warning: conflicting types for 'usb_enable_lpm' [enabled by default] drivers/usb/core/hub.c:3394:2: note: previous implicit declaration of 'usb_enable_lpm' was here drivers/usb/core/driver.c: In function 'usb_probe_interface': drivers/usb/core/driver.c:339:2: error: implicit declaration of function 'usb_unlocked_disable_lpm' [-Werror=implicit-function-declaration] drivers/usb/core/driver.c:364:3: error: implicit declaration of function 'usb_unlocked_enable_lpm' [-Werror=implicit-function-declaration] drivers/usb/core/message.c: In function 'usb_set_interface': drivers/usb/core/message.c:1314:2: error: implicit declaration of function 'usb_disable_lpm' [-Werror=implicit-function-declaration] drivers/usb/core/message.c:1323:3: error: implicit declaration of function 'usb_enable_lpm' [-Werror=implicit-function-declaration] drivers/usb/core/message.c:1368:2: error: implicit declaration of function 'usb_unlocked_enable_lpm' [-Werror=implicit-function-declaration] Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reported-by: Chen Peter-B29397 <B29397@freescale.com>
2012-05-18USB: Remove races in devio.cHuajun Li
There exist races in devio.c, below is one case, and there are similar races in destroy_async() and proc_unlinkurb(). Remove these races. cancel_bulk_urbs() async_completed() ------------------- ----------------------- spin_unlock(&ps->lock); list_move_tail(&as->asynclist, &ps->async_completed); wake_up(&ps->wait); Lead to free_async() be triggered, then urb and 'as' will be freed. usb_unlink_urb(as->urb); ===> refer to the freed 'as' Signed-off-by: Huajun Li <huajun.li.lee@gmail.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Oncaphillis <oncaphillis@snafu.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-18USB: Disable USB 3.0 LPM in critical sections.Sarah Sharp
There are several places where the USB core needs to disable USB 3.0 Link PM: - usb_bind_interface - usb_unbind_interface - usb_driver_claim_interface - usb_port_suspend/usb_port_resume - usb_reset_and_verify_device - usb_set_interface - usb_reset_configuration - usb_set_configuration Use the new LPM disable/enable functions to temporarily disable LPM around these critical sections. We need to protect the critical section around binding and unbinding USB interface drivers. USB drivers may want to disable hub-initiated USB 3.0 LPM, which will change the value of the U1/U2 timeouts that the xHCI driver will install. We need to disable LPM completely until the driver is bound to the interface, and the driver has a chance to enable whatever alternate interface setting it needs in its probe routine. Then re-enable USB3 LPM, and recalculate the U1/U2 timeout values. We also need to disable LPM in usb_driver_claim_interface, because drivers like usbfs can bind to an interface through that function. Note, there is no way currently for userspace drivers to disable hub-initiated USB 3.0 LPM. Revisit this later. When a driver is unbound, the U1/U2 timeouts may change because we are unbinding the last driver that needed hub-initiated USB 3.0 LPM to be disabled. USB LPM must be disabled when a USB device is going to be suspended. The USB 3.0 spec does not define a state transition from U1 or U2 into U3, so we need to bring the device into U0 by disabling LPM before we can place it into U3. Therefore, call usb_unlocked_disable_lpm() in usb_port_suspend(), and call usb_unlocked_enable_lpm() in usb_port_resume(). If the port suspend fails, make sure to re-enable LPM by calling usb_unlocked_enable_lpm(), since usb_port_resume() will not be called on a failed port suspend. USB 3.0 devices lose their USB 3.0 LPM settings (including whether USB device-initiated LPM is enabled) across device suspend. Therefore, disable LPM before the device will be reset in usb_reset_and_verify_device(), and re-enable LPM after the reset is complete and the configuration/alt settings are re-installed. The calculated U1/U2 timeout values are heavily dependent on what USB device endpoints are currently enabled. When any of the enabled endpoints on the device might change, due to a new configuration, or new alternate interface setting, we need to first disable USB 3.0 LPM, add or delete endpoints from the xHCI schedule, install the new interfaces and alt settings, and then re-enable LPM. Do this in usb_set_interface, usb_reset_configuration, and usb_set_configuration. Basically, there is a call to disable and then enable LPM in all functions that lock the bandwidth_mutex. One exception is usb_disable_device, because the device is disconnecting or otherwise going away, and we should not care about whether USB 3.0 LPM is enabled. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-18USB: Add support to enable/disable USB3 link states.Sarah Sharp
There are various functions within the USB core that will need to disable USB 3.0 link power states. For example, when a USB device driver is being bound to an interface, we need to disable USB 3.0 LPM until we know if the driver will allow hub-initiated LPM transitions. Another example is when the USB core is switching alternate interface settings. The USB 3.0 timeout values are dependent on what endpoints are enabled, so we want to ensure that LPM is disabled until the new alt setting is fully installed. Multiple functions need to disable LPM, and those functions can even be nested. For example, usb_bind_interface() could disable LPM, and then call into the driver probe function, which may attempt to switch to a different alt setting. Therefore, we need to keep a count of the number of functions that require LPM to be disabled at any point in time. Introduce two new USB core API calls, usb_disable_lpm() and usb_enable_lpm(). These functions increment and decrement a new variable in the usb_device, lpm_disable_count. If usb_disable_lpm() fails, it will call usb_enable_lpm() in order to balance the lpm_disable_count. These two new functions must be called with the bandwidth_mutex locked. If the bandwidth_mutex is not already held by the caller, it should instead call usb_unlocked_disable_lpm() and usb_enable_lpm(), which take the bandwidth_mutex before calling usb_disable_lpm() and usb_enable_lpm(), respectively. Introduce a new variable (timeout) in the usb3_lpm_params structure to keep track of the currently enabled U1/U2 timeout values. When usb_disable_lpm() is called, and the USB device has the U1 or U2 timeouts set to a non-zero value (meaning either device-initiated or hub-initiated LPM is enabled), attempt to disable LPM, regardless of the state of the lpm_disable_count. We want to ensure that all callers can be guaranteed that LPM is disabled if usb_disable_lpm() returns zero. Otherwise the following scenario could occur: 1. Driver A is being bound to interface 1. usb_probe_interface() disables LPM. Driver A doesn't care if hub-initiated LPM is enabled, so even though usb_disable_lpm() fails, the probe of the driver continues, and the bandwidth mutex is dropped. 2. Meanwhile, Driver B is being bound to interface 2. usb_probe_interface() grabs the bandwidth mutex and calls usb_disable_lpm(). That call should attempt to disable LPM, even though the lpm_disable_count is set to 1 by Driver A. For usb_enable_lpm(), we attempt to enable LPM only when the lpm_disable_count is zero. If some step in enabling LPM fails, it will only have a minimal impact on power consumption, and all USB device drivers should still work properly. Therefore don't bother to return any error codes. Don't enable device-initiated LPM if the device is unconfigured. The USB device will only accept the U1/U2_ENABLE control transfers in the configured state. Do enable hub-initiated LPM in that case, since devices are allowed to accept the LGO_Ux link commands in any state. Don't enable or disable LPM if the device is marked as not being LPM capable. This can happen if: - the USB device doesn't have a SS BOS descriptor, - the device's parent hub has a zeroed bHeaderDecodeLatency value, or - the xHCI host doesn't support LPM. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Andiry Xu <andiry.xu@amd.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-18USB: Calculate USB 3.0 exit latencies for LPM.Sarah Sharp
There are several different exit latencies associated with coming out of the U1 or U2 lower power link state. Device Exit Latency (DEL) is the maximum time it takes for the USB device to bring its upstream link into U0. That can be found in the SuperSpeed Extended Capabilities BOS descriptor for the device. The time it takes for a particular link in the tree to exit to U0 is the maximum of either the parent hub's U1/U2 DEL, or the child's U1/U2 DEL. Hubs introduce a further delay that effects how long it takes a child device to transition to U0. When a USB 3.0 hub receives a header packet, it takes some time to decode that header and figure out which downstream port the packet was destined for. If the port is not in U0, this hub header decode latency will cause an additional delay for bringing the child device to U0. This Hub Header Decode Latency is found in the USB 3.0 hub descriptor. We can use DEL and the header decode latency, along with additional latencies imposed by each additional hub tier, to figure out the exit latencies for both host-initiated and device-initiated exit to U0. The Max Exit Latency (MEL) is the worst-case time it will take for a host-initiated exit to U0, based on whether U1 or U2 link states are enabled. The ping or packet must traverse the path to the device, and each hub along the way incurs the hub header decode latency in order to figure out which device the transfer was bound for. We say worst-case, because some hubs may not be in the lowest link state that is enabled. See the examples in section C.2.2.1. Note that "HSD" is a "host specific delay" that the power appendix architect has not been able to tell me how to calculate. There's no way to get HSD from the xHCI registers either, so I'm simply ignoring it. The Path Exit Latency (PEL) is the worst-case time it will take for a device-initiate exit to U0 to place all the links from the device to the host into U0. The System Exit Latency (SEL) is another device-initiated exit latency. SEL is useful for USB 3.0 devices that need to send data to the host at specific intervals. The device may send an NRDY to indicate it isn't ready to send data, then put its link into a lower power state. If it needs to have that data transmitted at a specific time, it can use SEL to back calculate when it will need to bring the link back into U0 to meet its deadlines. SEL is the worst-case time from the device-initiated exit to U0, to when the device will receive a packet from the host controller. It includes PEL, the time it takes for an ERDY to get to the host, a host-specific delay for the host to process that ERDY, and the time it takes for the packet to traverse the path to the device. See Figure C-2 in the USB 3.0 bus specification. Note: I have not been able to get good answers about what the host-specific delay to process the ERDY should be. The Intel HW developers say it will be specific to the platform the xHCI host is integrated into, and they say it's negligible. Ignore this too. Separate from these four exit latencies are the U1/U2 timeout values we program into the parent hubs. These timeouts tell the hub to attempt to place the device into a lower power link state after the link has been idle for that amount of time. Create two arrays (one for U1 and one for U2) to store mel, pel, sel, and the timeout values. Store the exit latency values in nanosecond units, since that's the smallest units used (DEL is in us, but the Hub Header Decode Latency is in ns). If a USB 3.0 device doesn't have a SuperSpeed Extended Capabilities BOS descriptor, it's highly unlikely it will be able to handle LPM requests properly. So it's best to disable LPM for devices that don't have this descriptor, and any children beneath it, if it's a USB 3.0 hub. Warn users when that happens, since it means they have a non-compliant USB 3.0 device or hub. This patch assumes a simplified design where links deep in the tree will not have U1 or U2 enabled unless all their parent links have the corresponding LPM state enabled. Eventually, we might want to allow a different policy, and we can revisit this patch when that happens. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Alan Stern <stern@rowland.harvard.edu>
2012-05-18USB: Refactor code to set LPM support flag.Sarah Sharp
Refactor the code that sets the usb_device flag to indicate the device support link power management (lpm_capable). The current code sets lpm_capable unconditionally if the USB devices have a USB 2.0 Extended Capabilities Descriptor. USB 3.0 devices can also have that descriptor, but the xHCI driver code that uses lpm_capable will not run the USB 2.0 LPM test for devices under the USB 3.0 roothub. Therefore, it's fine only set lpm_capable for high speed devices in this refactoring. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-18USB: Make sure to fetch the BOS desc for roothubs.Sarah Sharp
The BOS descriptor is normally fetched and stored in the usb_device->bos during enumeration. USB 3.0 roothubs don't undergo enumeration, but we need them to have a BOS descriptor, since each xHCI host has a different U1 and U2 exit latency. Make sure to fetch the BOS descriptor for USB 3.0 roothubs. It will be freed when the roothub usb_device is released. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Andiry Xu <andiry.xu@amd.com>
2012-05-17usbcore: enable USB2 LPM if port suspend failsAndiry Xu
USB2 LPM is disabled when device begin to suspend and enabled after device is resumed. That's because USB spec does not define the transition from U1/U2 state to U3 state. If usb_port_suspend() fails, usb_port_resume() is never called, and USB2 LPM is disabled in this situation. Enable USB2 LPM if port suspend fails. This patch should be backported to kernels as old as 3.2, that contain the commit 65580b4321eb36f16ae8b5987bfa1bb948fc5112 "xHCI: set USB2 hardware LPM". Signed-off-by: Andiry Xu <andiry.xu@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2012-05-16usb: fix breakage on systems without ACPISasha Levin
Commit da0af6e ("usb: Bind devices to ACPI devices when possible") really tries to force-bind devices even when impossible, unlike what it says in the subject. CONFIG_ACPI is not an indication that ACPI tables are actually present, nor is an indication that any USB relevant information is present in them. There is no reason to fail the creation of a USB bus if it can't bind it to ACPI device during initialization. On systems with CONFIG_ACPI set but without ACPI tables it would cause a boot panic. Signed-off-by: Sasha Levin <levinsasha928@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-14sysfs: get rid of some lockdep false positivesAlan Stern
This patch (as1554) fixes a lockdep false-positive report. The problem arises because lockdep is unable to deal with the tree-structured locks created by the device core and sysfs. This particular problem involves a sysfs attribute method that unregisters itself, not from the device it was called for, but from a descendant device. Lockdep doesn't understand the distinction and reports a possible deadlock, even though the operation is safe. This is the sort of thing that would normally be handled by using a nested lock annotation; unfortunately it's not feasible to do that here. There's no sensible way to tell sysfs when attribute removal occurs in the context of a parent attribute method. As a workaround, the patch adds a new flag to struct attribute telling sysfs not to inform lockdep when it acquires a readlock on a sysfs_dirent instance for the attribute. The readlock is still acquired, but lockdep doesn't know about it and hence does not complain about impossible deadlock scenarios. Also added are macros for static initialization of attribute structures with the ignore_lockdep flag set. The three offending attributes in the USB subsystem are converted to use the new macros. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Tejun Heo <tj@kernel.org> CC: Eric W. Biederman <ebiederm@xmission.com> CC: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-14USB: add read support to usb-serial/../new_idBjørn Mork
Keep the usb-serial support for dynamic IDs in sync with the usb support. This enables readout of dynamic device IDs for usb-serial drivers. Common code is exported from the usb core system and reused by the usb-serial bus driver. Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-14USB: let both new_id and remove_id show dynamic id listBjørn Mork
This enables the current list of dynamic IDs to be read out through either new_id or remove_id. Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-14Revert "usb: add struct usb_hub_port to store port related members."Greg Kroah-Hartman
This reverts commit f397d7c4c5e8a1eb93f2ed15808a509318ccf1dd. This series isn't quite ready for 3.5 just yet, so revert it and give the author more time to get it correct. Cc: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-14Revert "usb: move struct usb_device->children to struct usb_hub_port->child"Greg Kroah-Hartman
This reverts commit bebc56d58dc780539777d2b1ca80df5566e2ad87. The call here is fragile and not well thought out, so revert it, it's not fully baked yet and I don't want this to go into 3.5. Cc: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-14usb: Kconfig: remove unneeded default valueDavid Herrmann
If no default value is specified, then 'n' is used so the default value used here is not needed. Furthermore, we should never change default values depending on EXPERT mode. EXPERT mode should only make options visible, not change them. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-11usb: move struct usb_device->children to struct usb_hub_port->childLan Tianyu
Move child's pointer to the struct usb_hub_port since the child device is directly associated with the port. Provide usb_get_hub_child_device() to get child's pointer. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-11usb: add struct usb_hub_port to store port related members.Lan Tianyu
Add struct usb_hub_port pointer port_data in the struct usb_hub and allocate struct usb_hub_port perspectively for each ports to store private data. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-11usb: Set device removable state based on ACPI USB dataMatthew Garrett
ACPI offers two methods that allow us to infer whether or not a USB port is removable. The _PLD method gives us information on whether the port is "user visible" or not. If that's not present then we can fall back to the _UPC method which tells us whether or not a port is connectable. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-11usb: Bind devices to ACPI devices when possibleMatthew Garrett
Built-in USB devices will typically have a representation in the system ACPI tables. Add support for binding the two together so the USB code can make use of the associated methods. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-07USB: make vendor id of root hubs greppablePaul Bolle
It took me surprisingly long to find the location where the Linux Foundation vendor id (0x1d6b) is set for the root hubs. A minor update to three comments makes those locations (trivially) greppable. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-07Merge 3.4-rc6 into usb-nextGreg Kroah-Hartman
This resolves the conflict with: drivers/usb/host/ehci-tegra.c Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-01USB: file.c: remove dbg() usageGreg Kroah-Hartman
dbg() was a very old USB-specific macro that should no longer be used. This patch removes it from being used in the driver and uses dev_dbg() instead. CC: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-01usbhid: prevent deadlock during timeoutOliver Neukum
On some HCDs usb_unlink_urb() can directly call the completion handler. That limits the spinlocks that can be taken in the handler to locks not held while calling usb_unlink_urb() To prevent a race with resubmission, this patch exposes usbcore's infrastructure for blocking submission, uses it and so drops the lock without causing a race in usbhid. Signed-off-by: Oliver Neukum <oneukum@suse.de> Acked-by: Jiri Kosina <jkosina@suse.cz> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-30usb: add USB_QUIRK_RESET_RESUME for M-Audio 88esSteffen Müller
Tested-by: Steffen Müller <steffen.mueller@radio-frei.de> Signed-off-by: Steffen Müller <steffen.mueller@radio-frei.de> Signed-off-by: Stefan Seyfried <seife+kernel@b1-systems.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-29USB: remove CONFIG_USB_DEVICE_CLASSGreg Kroah-Hartman
This option has been deprecated for many years now, and no userspace tools use it anymore, so it should be safe to finally remove it. Reported-by: Kay Sievers <kay@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-29USB: remove CONFIG_USB_DEVICEFSGreg Kroah-Hartman
This option has been deprecated for many years now, and no userspace tools use it anymore, so it should be safe to finally remove it. Reported-by: Kay Sievers <kay@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-24USB: EHCI: fix crash during suspend on ASUS computersAlan Stern
This patch (as1545) fixes a problem affecting several ASUS computers: The machine crashes or corrupts memory when going into suspend if the ehci-hcd driver is bound to any controllers. Users have been forced to unbind or unload ehci-hcd before putting their systems to sleep. After extensive testing, it was determined that the machines don't like going into suspend when any EHCI controllers are in the PCI D3 power state. Presumably this is a firmware bug, but there's nothing we can do about it except to avoid putting the controllers in D3 during system sleep. The patch adds a new flag to indicate whether the problem is present, and avoids changing the controller's power state if the flag is set. Runtime suspend is unaffected; this matters only for system suspend. However as a side effect, the controller will not respond to remote wakeup requests while the system is asleep. Hence USB wakeup is not functional -- but of course, this is already true in the current state of affairs. This fixes Bugzilla #42728. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Steven Rostedt <rostedt@goodmis.org> Tested-by: Andrey Rahmatullin <wrar@wrar.name> Tested-by: Oleksij Rempel (fishor) <bug-track@fisher-privat.net> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-17USB: fix deadlock in bConfigurationValue attribute methodAlan Stern
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 <stern@rowland.harvard.edu> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>