Searched +hist:9 +hist:b790915 (Results 1 - 3 of 3) sorted by relevance
/linux-master/drivers/usb/host/ | ||
H A D | ehci-hub.c | diff 9d4b8270 Mon Nov 28 22:45:38 MST 2016 Changming Huang <jerry.huang@nxp.com> fsl/usb: Workarourd for USB erratum-A005697 The EHCI specification states the following in the SUSP bit description: In the Suspend state, the port is sensitive to resume detection. Note that the bit status does not change until the port is suspended and that there may be a delay in suspending a port if there is a transaction currently in progress on the USB. However, in NXP USBDR controller, the PORTSCx[SUSP] bit changes immediately when the application sets it and not when the port is actually suspended. So the application must wait for at least 10 milliseconds after a port indicates that it is suspended, to make sure this port has entered suspended state before initiating this port resume using the Force Port Resume bit. This bit is for NXP controller, not EHCI compatible. Signed-off-by: Changming Huang <jerry.huang@nxp.com> Signed-off-by: Ramneek Mehresh <ramneek.mehresh@nxp.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 9b790915 Fri May 17 01:08:51 MDT 2013 Julius Werner <jwerner@chromium.org> usb: ehci: Only sleep for post-resume handover if devices use persist The current EHCI code sleeps a flat 110ms in the resume path if there was a USB 1.1 device connected to its companion controller during suspend, waiting for the device to reappear and reset so that it can be handed back to the companion. This is necessary if the device uses persist, so that the companion controller can actually see it during its own resume path. However, if the device doesn't use persist, this is entirely unnecessary. We might just as well ignore it and have the normal device detection/reset/handoff code handle it asynchronously when it eventually shows up. As USB 1.1 devices are almost exclusively HIDs these days (for which persist has no value), this can allow distros to shave another tenth of a second off their resume time. In order to enable this optimization, the patch also adds a new usb_for_each_dev() iterator that is exported by the USB core and wraps bus_for_each_dev() with the logic to differentiate between struct usb_device and struct usb_interface on the usb_bus_type bus. Signed-off-by: Julius Werner <jwerner@chromium.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 9b790915 Fri May 17 01:08:51 MDT 2013 Julius Werner <jwerner@chromium.org> usb: ehci: Only sleep for post-resume handover if devices use persist The current EHCI code sleeps a flat 110ms in the resume path if there was a USB 1.1 device connected to its companion controller during suspend, waiting for the device to reappear and reset so that it can be handed back to the companion. This is necessary if the device uses persist, so that the companion controller can actually see it during its own resume path. However, if the device doesn't use persist, this is entirely unnecessary. We might just as well ignore it and have the normal device detection/reset/handoff code handle it asynchronously when it eventually shows up. As USB 1.1 devices are almost exclusively HIDs these days (for which persist has no value), this can allow distros to shave another tenth of a second off their resume time. In order to enable this optimization, the patch also adds a new usb_for_each_dev() iterator that is exported by the USB core and wraps bus_for_each_dev() with the logic to differentiate between struct usb_device and struct usb_interface on the usb_bus_type bus. Signed-off-by: Julius Werner <jwerner@chromium.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 9fa5780b Mon Sep 17 17:23:02 MDT 2012 Jan Beulich <JBeulich@suse.com> USB EHCI/Xen: propagate controller reset information to hypervisor Just like for the in-tree early console debug port driver, the hypervisor - when using a debug port based console - also needs to be told about controller resets, so it can suppress using and then re-initialize the debug port accordingly. Other than the in-tree driver, the hypervisor driver actually cares about doing this only for the device where the debug is port actually in use, i.e. it needs to be told the coordinates of the device being reset (quite obviously, leveraging the addition done for that would likely benefit the in-tree driver too). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 9d938747 Wed Jul 11 09:22:44 MDT 2012 Alan Stern <stern@rowland.harvard.edu> USB: EHCI: use hrtimer for the IAA watchdog This patch (as1581) replaces the iaa_watchdog kernel timer used by ehci-hcd with an hrtimer event, in keeping with the general conversion to high-res timers. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff df202255 Wed Jul 11 09:22:26 MDT 2012 Alan Stern <stern@rowland.harvard.edu> USB: EHCI: use hrtimer for interrupt QH unlink This patch (as1577) adds hrtimer support for unlinking interrupt QHs in ehci-hcd. The current code relies on a fixed delay of either 2 or 55 us, which is not always adequate and in any case is totally bogus. Thanks to internal caching, the EHCI hardware may continue to access an interrupt QH for more than a millisecond after it has been unlinked. In fact, the EHCI spec doesn't say how long to wait before using an unlinked interrupt QH. The patch sets the delay to 9 microframes minimum, which ought to be adequate. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
/linux-master/drivers/usb/core/ | ||
H A D | usb.c | diff 5198c0ee Fri Aug 11 09:47:15 MDT 2023 Alan Stern <stern@rowland.harvard.edu> USB: core: Fix unused variable warning in usb_alloc_dev() The kernel test robot reported that a recent commit caused a "variable set but not used" warning. As a result of that commit, the variable no longer serves any purpose; it should be removed. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202308092350.HR4PVHUt-lkp@intel.com/ Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Fixes: 1e4c574225cc ("USB: Remove remnants of Wireless USB and UWB") Link: https://lore.kernel.org/r/7223cc66-f006-42ae-9f30-a6c546bf97a7@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 9c174b57 Tue Feb 16 03:14:32 MST 2021 Greg Kroah-Hartman <gregkh@linuxfoundation.org> USB: core: no need to save usb_devices_root There is no need to save the usb_devices debugfs file as we only need it when removing it, so have the debugfs code look it up when it is needed instead, saving the storage. Link: https://lore.kernel.org/r/YCubCA/trHAF7PtF@kroah.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 9be427ef Mon May 02 07:35:57 MDT 2016 Johan Hovold <johan@kernel.org> Revert "USB / PM: Allow USB devices to remain runtime-suspended when sleeping" 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 <stable@vger.kernel.org> # 4.5 Signed-off-by: Johan Hovold <johan@kernel.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 9b790915 Fri May 17 01:08:51 MDT 2013 Julius Werner <jwerner@chromium.org> usb: ehci: Only sleep for post-resume handover if devices use persist The current EHCI code sleeps a flat 110ms in the resume path if there was a USB 1.1 device connected to its companion controller during suspend, waiting for the device to reappear and reset so that it can be handed back to the companion. This is necessary if the device uses persist, so that the companion controller can actually see it during its own resume path. However, if the device doesn't use persist, this is entirely unnecessary. We might just as well ignore it and have the normal device detection/reset/handoff code handle it asynchronously when it eventually shows up. As USB 1.1 devices are almost exclusively HIDs these days (for which persist has no value), this can allow distros to shave another tenth of a second off their resume time. In order to enable this optimization, the patch also adds a new usb_for_each_dev() iterator that is exported by the USB core and wraps bus_for_each_dev() with the logic to differentiate between struct usb_device and struct usb_interface on the usb_bus_type bus. Signed-off-by: Julius Werner <jwerner@chromium.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 9b790915 Fri May 17 01:08:51 MDT 2013 Julius Werner <jwerner@chromium.org> usb: ehci: Only sleep for post-resume handover if devices use persist The current EHCI code sleeps a flat 110ms in the resume path if there was a USB 1.1 device connected to its companion controller during suspend, waiting for the device to reappear and reset so that it can be handed back to the companion. This is necessary if the device uses persist, so that the companion controller can actually see it during its own resume path. However, if the device doesn't use persist, this is entirely unnecessary. We might just as well ignore it and have the normal device detection/reset/handoff code handle it asynchronously when it eventually shows up. As USB 1.1 devices are almost exclusively HIDs these days (for which persist has no value), this can allow distros to shave another tenth of a second off their resume time. In order to enable this optimization, the patch also adds a new usb_for_each_dev() iterator that is exported by the USB core and wraps bus_for_each_dev() with the logic to differentiate between struct usb_device and struct usb_interface on the usb_bus_type bus. Signed-off-by: Julius Werner <jwerner@chromium.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 9cf65991 Wed Jul 04 00:22:38 MDT 2012 Sarah Sharp <sarah.a.sharp@linux.intel.com> USB: Disable LPM while the device is unconfigured. 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 diff 9bbdf1e0 Thu Jan 07 22:57:28 MST 2010 Alan Stern <stern@rowland.harvard.edu> USB: convert to the runtime PM framework This patch (as1329) converts the USB stack over to the PM core's runtime PM framework. This involves numerous changes throughout usbcore, especially to hub.c and driver.c. Perhaps the most notable change is that CONFIG_USB_SUSPEND now depends on CONFIG_PM_RUNTIME instead of CONFIG_PM. Several fields in the usb_device and usb_interface structures are no longer needed. Some code which used to depend on CONFIG_USB_PM now depends on CONFIG_USB_SUSPEND (requiring some rearrangement of header files). The only visible change in behavior should be that following a system sleep (resume from RAM or resume from hibernation), autosuspended USB devices will be resumed just like everything else. They won't remain suspended. But if they aren't in use then they will naturally autosuspend again in a few seconds. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> diff 7206b001 Mon Apr 27 20:54:49 MDT 2009 Sarah Sharp <sarah.a.sharp@linux.intel.com> USB: Add route string to struct usb_device. This patch adds a hex route string to each USB device. The route string is used by the USB 3.0 host controller to send packets through the device tree. USB 3.0 hubs use this string to route packets to the correct port. This is fundamental bus change from USB 2.0, where all packets were broadcast across the bus. Devices (including hubs) under a root port receive the route string 0x0. Every four bits in the route string represent a port on a hub. This length works because USB 3.0 hubs are limited to 15 ports, and USB 2.0 hubs (with potentially more ports) will never see packets with a route string. A port number of 0 means the packet is destined for that hub. For example, a peripheral device might have a route string of 0x00097. This means the device is connected to port 9 of the hub at depth 1. The hub at depth 1 is connected to port 7 of a hub at depth 0. The hub at depth 0 is connected to a root port. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> diff 9b8e7ba6 Wed May 27 19:10:44 MDT 2009 FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> USB: replace dma_sync_single and dma_sync_sg with dma_sync_single_for_cpu and dma_sync_sg_for_cpu This replaces dma_sync_single() and dma_sync_sg() with dma_sync_single_for_cpu() and dma_sync_sg_for_cpu() respectively because they is an obsolete API; include/linux/dma-mapping.h says: /* Backwards compat, remove in 2.7.x */ #define dma_sync_single dma_sync_single_for_cpu #define dma_sync_sg dma_sync_sg_for_cpu Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> diff 9ac39f28 Wed Nov 12 14:19:49 MST 2008 Alan Stern <stern@rowland.harvard.edu> USB: add asynchronous autosuspend/autoresume support This patch (as1160b) adds support routines for asynchronous autosuspend and autoresume, with accompanying documentation updates. There already are several potential users of this interface, and others are likely to arise as autosuspend support becomes more widespread. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> |
/linux-master/include/linux/ | ||
H A D | usb.h | diff 130eac41 Tue Mar 28 07:10:43 MDT 2023 Arnd Bergmann <arnd@arndb.de> xhci: use pm_ptr() instead of #ifdef for CONFIG_PM conditionals A recent patch caused an unused-function warning in builds with CONFIG_PM disabled, after the function became marked 'static': drivers/usb/host/xhci-pci.c:91:13: error: 'xhci_msix_sync_irqs' defined but not used [-Werror=unused-function] 91 | static void xhci_msix_sync_irqs(struct xhci_hcd *xhci) | ^~~~~~~~~~~~~~~~~~~ This could be solved by adding another #ifdef, but as there is a trend towards removing CONFIG_PM checks in favor of helper macros, do the same conversion here and use pm_ptr() to get either a function pointer or NULL but avoid the warning. As the hidden functions reference some other symbols, make sure those are visible at compile time, at the minimal cost of a few extra bytes for 'struct usb_device'. Fixes: 9abe15d55dcc ("xhci: Move xhci MSI sync function to to xhci-pci") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20230328131114.1296430-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 9c6d7788 Fri Aug 26 13:31:32 MDT 2022 Alan Stern <stern@rowland.harvard.edu> USB: core: Prevent nested device-reset calls Automatic kernel fuzzing revealed a recursive locking violation in usb-storage: ============================================ WARNING: possible recursive locking detected 5.18.0 #3 Not tainted -------------------------------------------- kworker/1:3/1205 is trying to acquire lock: ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at: usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 but task is already holding lock: ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at: usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 ... stack backtrace: CPU: 1 PID: 1205 Comm: kworker/1:3 Not tainted 5.18.0 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Workqueue: usb_hub_wq hub_event Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_deadlock_bug kernel/locking/lockdep.c:2988 [inline] check_deadlock kernel/locking/lockdep.c:3031 [inline] validate_chain kernel/locking/lockdep.c:3816 [inline] __lock_acquire.cold+0x152/0x3ca kernel/locking/lockdep.c:5053 lock_acquire kernel/locking/lockdep.c:5665 [inline] lock_acquire+0x1ab/0x520 kernel/locking/lockdep.c:5630 __mutex_lock_common kernel/locking/mutex.c:603 [inline] __mutex_lock+0x14f/0x1610 kernel/locking/mutex.c:747 usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 usb_reset_device+0x37d/0x9a0 drivers/usb/core/hub.c:6109 r871xu_dev_remove+0x21a/0x270 drivers/staging/rtl8712/usb_intf.c:622 usb_unbind_interface+0x1bd/0x890 drivers/usb/core/driver.c:458 device_remove drivers/base/dd.c:545 [inline] device_remove+0x11f/0x170 drivers/base/dd.c:537 __device_release_driver drivers/base/dd.c:1222 [inline] device_release_driver_internal+0x1a7/0x2f0 drivers/base/dd.c:1248 usb_driver_release_interface+0x102/0x180 drivers/usb/core/driver.c:627 usb_forced_unbind_intf+0x4d/0xa0 drivers/usb/core/driver.c:1118 usb_reset_device+0x39b/0x9a0 drivers/usb/core/hub.c:6114 This turned out not to be an error in usb-storage but rather a nested device reset attempt. That is, as the rtl8712 driver was being unbound from a composite device in preparation for an unrelated USB reset (that driver does not have pre_reset or post_reset callbacks), its ->remove routine called usb_reset_device() -- thus nesting one reset call within another. Performing a reset as part of disconnect processing is a questionable practice at best. However, the bug report points out that the USB core does not have any protection against nested resets. Adding a reset_in_progress flag and testing it will prevent such errors in the future. Link: https://lore.kernel.org/all/CAB7eexKUpvX-JNiLzhXBDWgfg2T9e9_0Tw4HQ6keN==voRbP0g@mail.gmail.com/ Cc: stable@vger.kernel.org Reported-and-tested-by: Rondreis <linhaoguo86@gmail.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/YwkflDxvg0KWqyZK@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff e146caf3 Fri May 06 10:18:07 MDT 2022 Mathias Nyman <mathias.nyman@linux.intel.com> usb: Avoid extra usb SET_SEL requests when enabling link power management The host needs to tell the device the exit latencies using the SET_SEL request before device initiated link powermanagement can be enabled. The exit latency values do not change after enumeration, it's enough to set them once. So do like Windows 10 and issue the SET_SEL request once just before setting the configuration. This is also the sequence described in USB 3.2 specs "9.1.2 Bus enumeration". SET_SEL is issued once before the Set Configuration request, and won't be cleared by the Set Configuration, Set Interface or ClearFeature (STALL) requests. Only warm reset, hot reset, set Address 0 clears the exit latencies. See USB 3.2 section 9.4.14 Table 9-10 Device parameters and events Add udev->lpm_devinit_allow, and set it if SET_SEL was successful. If not set, then don't try to enable device initiated LPM We used to issue a SET_SEL request every time lpm is enabled for either U1 or U2 link states, meaning a SET_SEL was issued twice after every Set Configuration and Set Interface requests, easily accumulating to over 15 SET_SEL requets during a USB3 webcam enumeration. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20220506161807.3369439-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 2ddf7617 Wed Mar 16 09:55:13 MDT 2022 Vincent Mailhol <mailhol.vincent@wanadoo.fr> usb: remove third argument of usb_maxpacket() Now that all users of usb_maxpacket() have been migrated to only use two arguments, remove the third variadic argument which was introduced for the transition. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/20220317035514.6378-9-mailhol.vincent@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff ddd1198e Wed Sep 23 07:43:42 MDT 2020 Oliver Neukum <oneukum@suse.com> USB: correct API of usb_control_msg_send/recv They need to specify how memory is to be allocated, as control messages need to work in contexts that require GFP_NOIO. Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20200923134348.23862-9-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 9b6f0c4b Mon Mar 10 02:36:40 MDT 2014 Valentina Manea <valentina.manea.m@gmail.com> usbcore: rename struct dev_state to struct usb_dev_state Since it is needed outside usbcore and exposed in include/linux/usb.h, it conflicts with enum dev_state in rt2x00 wireless driver. Mark it as usb specific to avoid conflicts in the future. Signed-off-by: Valentina Manea <valentina.manea.m@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 9ef73dbd Wed Oct 09 09:01:40 MDT 2013 Hans de Goede <hdegoede@redhat.com> usb-anchor: Ensure poisened gets initialized to 0 And do so in a way which ensures that any fields added in the future will also get properly zero-ed. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Oliver Neukum <oliver@neukum.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 9b790915 Fri May 17 01:08:51 MDT 2013 Julius Werner <jwerner@chromium.org> usb: ehci: Only sleep for post-resume handover if devices use persist The current EHCI code sleeps a flat 110ms in the resume path if there was a USB 1.1 device connected to its companion controller during suspend, waiting for the device to reappear and reset so that it can be handed back to the companion. This is necessary if the device uses persist, so that the companion controller can actually see it during its own resume path. However, if the device doesn't use persist, this is entirely unnecessary. We might just as well ignore it and have the normal device detection/reset/handoff code handle it asynchronously when it eventually shows up. As USB 1.1 devices are almost exclusively HIDs these days (for which persist has no value), this can allow distros to shave another tenth of a second off their resume time. In order to enable this optimization, the patch also adds a new usb_for_each_dev() iterator that is exported by the USB core and wraps bus_for_each_dev() with the logic to differentiate between struct usb_device and struct usb_interface on the usb_bus_type bus. Signed-off-by: Julius Werner <jwerner@chromium.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 9b790915 Fri May 17 01:08:51 MDT 2013 Julius Werner <jwerner@chromium.org> usb: ehci: Only sleep for post-resume handover if devices use persist The current EHCI code sleeps a flat 110ms in the resume path if there was a USB 1.1 device connected to its companion controller during suspend, waiting for the device to reappear and reset so that it can be handed back to the companion. This is necessary if the device uses persist, so that the companion controller can actually see it during its own resume path. However, if the device doesn't use persist, this is entirely unnecessary. We might just as well ignore it and have the normal device detection/reset/handoff code handle it asynchronously when it eventually shows up. As USB 1.1 devices are almost exclusively HIDs these days (for which persist has no value), this can allow distros to shave another tenth of a second off their resume time. In order to enable this optimization, the patch also adds a new usb_for_each_dev() iterator that is exported by the USB core and wraps bus_for_each_dev() with the logic to differentiate between struct usb_device and struct usb_interface on the usb_bus_type bus. Signed-off-by: Julius Werner <jwerner@chromium.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 9e18c821 Fri Apr 02 11:22:09 MDT 2010 Alan Stern <stern@rowland.harvard.edu> USB: use PM core routines to enable/disable autosuspend This patch (as1366) replaces the private routines usb_enable_autosuspend() and usb_disable_autosuspend() with calls to the standard pm_runtime_allow() and pm_runtime_forbid() functions in the runtime PM framework. They do the same thing. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> |
Completed in 326 milliseconds