kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-15 19:56:03 +00:00
Code Issues Releases Packages Activity
linux/drivers/usb/core/hub.c

6474 lines
184 KiB
Raw Normal View History

USB: core: move existing SPDX tags to top of the file To match the rest of the kernel, the SPDX tags for the drivers/usb/core/ files are moved to the first line of the file. This makes it more obvious the tag is present as well as making it match the other 12k files in the tree with this location. It also uses // to match the "expected style" as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-03 09:18:41 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: core: add missing license information to some files Some of the USB core files were missing explicit license information. As all files in the kernel tree are implicitly licensed under the GPLv2-only, be explicit in case someone get confused looking at individual files by using the SPDX nomenclature. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-28 17:16:36 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
sched/headers: Prepare to move the memalloc_noio_*() APIs to <linux/sched/mm.h> Update the .c files that depend on these APIs. Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-02-02 20:43:54 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: Use str_enable_disable-like helpers Replace ternary (condition ? "enable" : "disable") syntax with helpers from string_choices.h because: 1. Simple function call with one argument is easier to read. Ternary operator has three arguments and with wrapping might lead to quite long code. 2. Is slightly shorter thus also easier to read. 3. It brings uniformity in the text - same string. 4. Allows deduping by the linker, which results in a smaller binary file. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250114-str-enable-disable-usb-v1-6-c8405df47c19@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-14 21:05:39 +01:00
usb, kcov: collect coverage from hub_event Add kcov_remote_start()/kcov_remote_stop() annotations to the hub_event() function, which is responsible for processing events on USB buses, in particular events that happen during USB device enumeration. Since hub_event() is run in a global background kernel thread (see Documentation/dev-tools/kcov.rst for details), each USB bus gets a unique global handle from the USB subsystem kcov handle range. As the result kcov can now be used to collect coverage from events that happen on a particular USB bus. [akpm@linux-foundation.org: avoid patch conflicts to make life easier for Andrew] Link: http://lkml.kernel.org/r/de4fe1c219db2d002d905dc1736e2a3bfa1db997.1572366574.git.andreyknvl@google.com Signed-off-by: Andrey Konovalov <andreyknvl@google.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Alexander Potapenko <glider@google.com> Cc: Anders Roxell <anders.roxell@linaro.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: David Windsor <dwindsor@gmail.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Elena Reshetova <elena.reshetova@intel.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Marco Elver <elver@google.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-12-04 16:52:47 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: make hcd.h public (drivers dependency) The usbcore headers: hcd.h and hub.h are shared between usbcore, HCDs and a couple of other drivers (e.g. USBIP modules). So, it makes sense to move them into a more public location and to cleanup dependency of those modules on kernel internal headers. This patch moves hcd.h from drivers/usb/core into include/linux/usb/ Signed-of-by: Eric Lescouet <eric@lescouet.org> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-24 23:21:52 +02:00
usb: misc: onboard_hub: rename to onboard_dev This patch prepares onboad_hub to support non-hub devices by renaming the driver files and their content, the headers and their references. The comments and descriptions have been slightly modified to keep coherence and account for the specific cases that only affect onboard hubs (e.g. peer-hub). The "hub" variables in functions where "dev" (and similar names) variables already exist have been renamed to onboard_dev for clarity, which adds a few lines in cases where more than 80 characters are used. No new functionality has been added. Acked-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net> Link: https://lore.kernel.org/r/20240325-onboard_xvf3500-v8-2-29e3f9222922@wolfvision.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-25 10:15:12 +01:00
USB: notify phy when root hub port connect change Phy may need to change settings when port connect change. Signed-off-by: Richard Zhao <richard.zhao@freescale.com> Tested-by: Subodh Nijsure <snijsure@grid-net.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-07-11 11:09:28 +08:00
USB delay init quirk for logitech Harmony 700-series devices The Logitech Harmony 700 series needs an extra delay during initialization. This patch adds a USB quirk which enables such a delay and adds the device to the quirks list. Signed-off-by: Phil Dibowitz <phil@ipom.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-07-22 00:05:01 +02:00
usb: hub: convert khubd into workqueue There is no need to have separate kthread for handling USB hub events. It is more elegant to use the workqueue framework. The workqueue is allocated as freezable because the original thread was freezable as well. Also it is allocated as ordered because the code is not ready for parallel processing of hub events, see choose_devnum(). struct usb_hub is passed via the work item. Therefore we do not need hub_event_list. Also hub_thread() is not longer needed. It would call only hub_event(). The rest of the code did manipulate the kthread and it is handled by the workqueue framework now. kick_khubd is renamed to kick_hub_wq() to make the function clear. And the protection against races is done another way, see below. hub_event_lock has been removed. It cannot longer be used to protect struct usb_hub between hub_event() and hub_disconnect(). Instead we need to get hub->kref already in kick_hub_wq(). The lock is not really needed for the other scenarios as well. queue_work() returns whether it succeeded. We could revert the needed operations accordingly. This is enough to avoid duplicity and inconsistencies. Yes, the removed lock causes that there is not longer such a strong synchronization between scheduling the work and manipulating hub->disconnected. But kick_hub_wq() must never be called together with hub_disconnect() otherwise even the original code would have failed. Any callers are responsible for this. Therefore the only problem is that hub_disconnect() could be called in parallel with hub_event(). But this was possible even in the past. struct usb_hub is still guarded by hub->kref and released in hub_events() when needed. Note that the source file is still full of the obsolete "khubd" strings. Let's remove them in a follow up patch. This patch already is complex enough. Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to allocate the workqueue. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:21 +02:00
[PATCH] USB: convert a bunch of USB semaphores to mutexes the patch below converts a bunch of semaphores-used-as-mutex in the USB code to mutexes Signed-off-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-11 15:55:29 +01:00
usb: feed USB device information to the /dev/random driver 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-04 11:22:20 -04:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
usb: core: added uevent for over-current After commit 1cbd53c8cd85 ("usb: core: introduce per-port over-current counters") usb ports expose a sysfs value 'over_current_count' to user space. This value on its own is not very useful as it requires manual polling. As a solution, fire a udev event from the usb hub device that specifies the values 'OVER_CURRENT_PORT' and 'OVER_CURRENT_COUNT' that indicate the path of the usb port where the over-current event occurred and the value of 'over_current_count' in sysfs. Additionally, call sysfs_notify() so the sysfs value supports poll(). Signed-off-by: Jon Flatley <jflat@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-20 10:17:54 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: Track SuperSpeed Plus GenXxY Introduce ssp_rate field to usb_device structure to capture the connected SuperSpeed Plus signaling rate generation and lane count with the corresponding usb_ssp_rate enum. Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/b7805d121e5ae4ad5ae144bd860b6ac04ee47436.1615432770.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-10 19:42:44 -08:00
Replace <asm/uaccess.h> with <linux/uaccess.h> globally This was entirely automated, using the script by Al: PATT='^[[:blank:]]*#[[:blank:]]*include[[:blank:]]*<asm/uaccess.h>' sed -i -e "s!$PATT!#include <linux/uaccess.h>!" \ $(git grep -l "$PATT"|grep -v ^include/linux/uaccess.h) to do the replacement at the end of the merge window. Requested-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-12-24 11:46:01 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: Add driver/usb/core/(port.c,hub.h) files This patch is to create driver/usb/core/(port.c,hub.h) files and move usb port related code into port.c. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-11 20:10:38 +08:00
usb: core: add phy notify connect and disconnect In Realtek SoC, the parameter of usb phy is designed to can dynamic tuning base on port status. Therefore, add a notify callback of generic phy driver when usb device connect and disconnect change. The Realtek phy driver is designed to dynamically adjust disconnection level and calibrate phy parameters. When the device connected bit changes and when the disconnected bit changes, do connection change notification: Check if portstatus is USB_PORT_STAT_CONNECTION and portchange is USB_PORT_STAT_C_CONNECTION. 1. The device is connected, the driver lowers the disconnection level and calibrates the phy parameters. 2. The device disconnects, the driver increases the disconnect level and calibrates the phy parameters. Generic phy driver in usb core framework does not support device connect and disconnect notifications. Therefore, we add an api to notify phy the connection changes. Additionally, the generic phy only specifies primary_hcd in the original design. Added specific "usb2-phy" on primary_hcd and "usb3-phy" on shared_hcd. Signed-off-by: Stanley Chang <stanley_chang@realtek.com> Link: https://lore.kernel.org/r/20231213031203.4911-4-stanley_chang@realtek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-13 11:10:09 +08:00
USB: OTG: rename product list of devices Rename the list of specific devices that an OTG device could support to make it more obvious as to what this list is for and what it is doing. Also rename the configuration option to make it more obvious as well. Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Paul Burton <paulburton@kernel.org> Cc: "Diego Elio Pettenò" <flameeyes@flameeyes.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: Jiaxun Yang <jiaxun.yang@flygoat.com> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: "Philippe Mathieu-Daudé" <f4bug@amsat.org> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Eugeniu Rosca <erosca@de.adit-jv.com> Cc: Qi Zhou <atmgnd@outlook.com> Cc: Andrey Konovalov <andreyknvl@google.com> Cc: Hardik Gajjar <hgajjar@de.adit-jv.com> Cc: Harry Pan <harry.pan@intel.com> Cc: David Heinzelmann <heinzelmann.david@gmail.com> Cc: Nishad Kamdar <nishadkamdar@gmail.com> Link: https://lore.kernel.org/r/20200618094300.1887727-9-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-18 11:43:00 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: check port changes before hub runtime suspend for some bug device The hub status endpoint has a long 'bInterval', which is 255ms for FS/LS device and 256ms for HS device according to USB 2.0 spec, so the device connection change may be reported later more than 255ms via status pipe. The connection change in hub may have been happened already on the downstream ports, but no status URB completes when it is killed in hub_suspend(auto), so the connection change may be missed by some buggy hub devices, which won't generate remote wakeup signal after their remote wakeup is enabled and they are put into suspend state. The problem can be observed at least on the below Genesys Logic, Inc. hub devices: 0x05e3,0x0606 0x05e3,0x0608 In theory, there is no way to fix the problem completely, but we can make it less likely to occur by this patch. This patch introduces one quirk of HUB_QUIRK_CHECK_PORTS_AUTOSUSPEND to check ports' change during hub_suspend(auto) for the buggy devices. If ports' change is found, terminate the auto suspend and return to working state. So for the buggy hubs, if the connection change happend before the ports' check, it can be handled correctly. If it happens between the ports' check and enabling remote wakeup/entering suspend, it will be missed. Considered the interval is quite short, it is very less likely to happen during the window. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-24 11:59:24 +08:00
USB: hub: Fix the broken detection of USB3 device in SMSC hub Renesas R-Car H3ULCB + Kingfisher Infotainment Board is either not able to detect the USB3.0 mass storage devices or is detecting those as USB2.0 high speed devices. The explanation given by Renesas is that, due to a HW issue, the XHCI driver does not wake up after going to sleep on connecting a USB3.0 device. In order to mitigate that, disable the auto-suspend feature specifically for SMSC hubs from hub_probe() function, as a quirk. Renesas Kingfisher Infotainment Board has two USB3.0 ports (CN2) which are connected via USB5534B 4-port SuperSpeed/Hi-Speed, low-power, configurable hub controller. [1] SanDisk USB 3.0 device detected as USB-2.0 before the patch [ 74.036390] usb 5-1.1: new high-speed USB device number 4 using xhci-hcd [ 74.061598] usb 5-1.1: New USB device found, idVendor=0781, idProduct=5581, bcdDevice= 1.00 [ 74.069976] usb 5-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 74.077303] usb 5-1.1: Product: Ultra [ 74.080980] usb 5-1.1: Manufacturer: SanDisk [ 74.085263] usb 5-1.1: SerialNumber: 4C530001110208116550 [2] SanDisk USB 3.0 device detected as USB-3.0 after the patch [ 34.565078] usb 6-1.1: new SuperSpeed Gen 1 USB device number 3 using xhci-hcd [ 34.588719] usb 6-1.1: New USB device found, idVendor=0781, idProduct=5581, bcdDevice= 1.00 [ 34.597098] usb 6-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 34.604430] usb 6-1.1: Product: Ultra [ 34.608110] usb 6-1.1: Manufacturer: SanDisk [ 34.612397] usb 6-1.1: SerialNumber: 4C530001110208116550 Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Eugeniu Rosca <erosca@de.adit-jv.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/1580989763-32291-1-git-send-email-hgajjar@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-06 12:49:23 +01:00
usb: core: hub: limit HUB_QUIRK_DISABLE_AUTOSUSPEND to USB5534B On Tue, May 12, 2020 at 09:36:07PM +0800, Kai-Heng Feng wrote [1]: > This patch prevents my Raven Ridge xHCI from getting runtime suspend. The problem described in v5.6 commit 1208f9e1d758c9 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub") applies solely to the USB5534B hub [2] present on the Kingfisher Infotainment Carrier Board, manufactured by Shimafuji Electric Inc [3]. Despite that, the aforementioned commit applied the quirk to _all_ hubs carrying vendor ID 0x424 (i.e. SMSC), of which there are more [4] than initially expected. Consequently, the quirk is now enabled on platforms carrying SMSC/Microchip hub models which potentially don't exhibit the original issue. To avoid reports like [1], further limit the quirk's scope to USB5534B [2], by employing both Vendor and Product ID checks. Tested on H3ULCB + Kingfisher rev. M05. [1] https://lore.kernel.org/linux-renesas-soc/73933975-6F0E-40F5-9584-D2B8F615C0F3@canonical.com/ [2] https://www.microchip.com/wwwproducts/en/USB5534B [3] http://www.shimafuji.co.jp/wp/wp-content/uploads/2018/08/SBEV-RCAR-KF-M06Board_HWSpecificationEN_Rev130.pdf [4] https://devicehunt.com/search/type/usb/vendor/0424/device/any Fixes: 1208f9e1d758c9 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub") Cc: stable@vger.kernel.org # v4.14+ Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Hardik Gajjar <hgajjar@de.adit-jv.com> Cc: linux-renesas-soc@vger.kernel.org Cc: linux-usb@vger.kernel.org Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Link: https://lore.kernel.org/r/20200514220246.13290-1-erosca@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-15 00:02:46 +02:00
usb: core: hub: Disable autosuspend for Cypress CY7C65632 The Cypress CY7C65632 appears to have an issue with auto suspend and detecting devices, not too dissimilar to the SMSC 5534B hub. It is easiest to reproduce by connecting multiple mass storage devices to the hub at the same time. On a Lenovo Yoga, around 1 in 3 attempts result in the devices not being detected. It is however possible to make them appear using lsusb -v. Disabling autosuspend for this hub resolves the issue. Fixes: 1208f9e1d758 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub") Cc: stable@vger.kernel.org Signed-off-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20210614155524.2228800-1-andrew@lunn.ch Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-14 17:55:23 +02:00
usb: core: hub: disable autosuspend for TI TUSB8041 The Texas Instruments TUSB8041 has an autosuspend problem at high temperature. If there is not USB traffic, after a couple of ms, the device enters in autosuspend mode. In this condition the external clock stops working, to save energy. When the USB activity turns on, ther hub exits the autosuspend state, the clock starts running again and all works fine. At ambient temperature all works correctly, but at high temperature, when the USB activity turns on, the external clock doesn't restart and the hub disappears from the USB bus. Disabling the autosuspend mode for this hub solves the issue. Signed-off-by: Flavio Suligoi <f.suligoi@asem.it> Cc: stable <stable@kernel.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20221219124759.3207032-1-f.suligoi@asem.it Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-19 13:47:59 +01:00
usb: hub: Add quirk to decrease IN-ep poll interval for Microchip USB491x hub There is a potential delay in notifying Linux USB drivers of downstream USB bus activity when connecting a high-speed or superSpeed device via the Microchip USB491x hub. This delay is due to the fixed bInterval value of 12 in the silicon of the Microchip USB491x hub. Microchip requested to ignore the device descriptor and decrease that value to 9 as it was too late to modify that in silicon. This patch speeds up the USB enummeration process that helps to pass Apple Carplay certifications and improve the User experience when utilizing the USB device via Microchip Multihost USB491x Hub. A new hub quirk HUB_QUIRK_REDUCE_FRAME_INTR_BINTERVAL speeds up the notification process for Microchip USB491x hub by limiting the maximum bInterval value to 9. Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20231205181829.127353-2-hgajjar@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-05 19:18:29 +01:00
usb: hub: Replace hardcoded quirk value with BIT() macro This patch replaces the hardcoded quirk value in the macro with BIT(). Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20231205181829.127353-1-hgajjar@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-05 19:18:28 +01:00
usb: hub: Add quirk to decrease IN-ep poll interval for Microchip USB491x hub There is a potential delay in notifying Linux USB drivers of downstream USB bus activity when connecting a high-speed or superSpeed device via the Microchip USB491x hub. This delay is due to the fixed bInterval value of 12 in the silicon of the Microchip USB491x hub. Microchip requested to ignore the device descriptor and decrease that value to 9 as it was too late to modify that in silicon. This patch speeds up the USB enummeration process that helps to pass Apple Carplay certifications and improve the User experience when utilizing the USB device via Microchip Multihost USB491x Hub. A new hub quirk HUB_QUIRK_REDUCE_FRAME_INTR_BINTERVAL speeds up the notification process for Microchip USB491x hub by limiting the maximum bInterval value to 9. Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20231205181829.127353-2-hgajjar@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-05 19:18:29 +01:00
USB: check port changes before hub runtime suspend for some bug device The hub status endpoint has a long 'bInterval', which is 255ms for FS/LS device and 256ms for HS device according to USB 2.0 spec, so the device connection change may be reported later more than 255ms via status pipe. The connection change in hub may have been happened already on the downstream ports, but no status URB completes when it is killed in hub_suspend(auto), so the connection change may be missed by some buggy hub devices, which won't generate remote wakeup signal after their remote wakeup is enabled and they are put into suspend state. The problem can be observed at least on the below Genesys Logic, Inc. hub devices: 0x05e3,0x0606 0x05e3,0x0608 In theory, there is no way to fix the problem completely, but we can make it less likely to occur by this patch. This patch introduces one quirk of HUB_QUIRK_CHECK_PORTS_AUTOSUSPEND to check ports' change during hub_suspend(auto) for the buggy devices. If ports' change is found, terminate the auto suspend and return to working state. So for the buggy hubs, if the connection change happend before the ports' check, it can be handled correctly. If it happens between the ports' check and enabling remote wakeup/entering suspend, it will be missed. Considered the interval is quite short, it is very less likely to happen during the window. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-24 11:59:24 +08:00
usb: core: add support for USB_REQ_SET_ISOCH_DELAY USB SS and SSP hubs provide wHubDelay values on their hub descriptor which we should inform the USB Device about. The USB Specification 3.0 explains, on section 9.4.11, how to calculate the value and how to issue the request. Note that a USB_REQ_SET_ISOCH_DELAY is valid on all device states (Default, Address, Configured), we just *chose* to issue it from Address state right after successfully fetching the USB Device Descriptor. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-14 09:50:39 +02:00
usb: hub: Fix link power management max exit latency (MEL) calculations Maximum Exit Latency (MEL) value is used by host to know how much in advance it needs to start waking up a U1/U2 suspended link in order to service a periodic transfer in time. Current MEL calculation only includes the time to wake up the path from U1/U2 to U0. This is called tMEL1 in USB 3.1 section C 1.5.2 Total MEL = tMEL1 + tMEL2 +tMEL3 + tMEL4 which should additinally include: - tMEL2 which is the time it takes for PING message to reach device - tMEL3 time for device to process the PING and submit a PING_RESPONSE - tMEL4 time for PING_RESPONSE to traverse back upstream to host. Add the missing tMEL2, tMEL3 and tMEL4 to MEL calculation. Cc: <stable@kernel.org> # v3.5 Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210715150122.1995966-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-15 18:01:21 +03:00
usb: hub: Add quirk to decrease IN-ep poll interval for Microchip USB491x hub There is a potential delay in notifying Linux USB drivers of downstream USB bus activity when connecting a high-speed or superSpeed device via the Microchip USB491x hub. This delay is due to the fixed bInterval value of 12 in the silicon of the Microchip USB491x hub. Microchip requested to ignore the device descriptor and decrease that value to 9 as it was too late to modify that in silicon. This patch speeds up the USB enummeration process that helps to pass Apple Carplay certifications and improve the User experience when utilizing the USB device via Microchip Multihost USB491x Hub. A new hub quirk HUB_QUIRK_REDUCE_FRAME_INTR_BINTERVAL speeds up the notification process for Microchip USB491x hub by limiting the maximum bInterval value to 9. Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20231205181829.127353-2-hgajjar@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-05 19:18:29 +01:00
usb: core: add support for USB_REQ_SET_ISOCH_DELAY USB SS and SSP hubs provide wHubDelay values on their hub descriptor which we should inform the USB Device about. The USB Specification 3.0 explains, on section 9.4.11, how to calculate the value and how to issue the request. Note that a USB_REQ_SET_ISOCH_DELAY is valid on all device states (Default, Address, Configured), we just *chose* to issue it from Address state right after successfully fetching the USB Device Descriptor. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-14 09:50:39 +02:00
usb: new quirk to reduce the SET_ADDRESS request timeout This patch introduces a new USB quirk, USB_QUIRK_SHORT_SET_ADDRESS_REQ_TIMEOUT, which modifies the timeout value for the SET_ADDRESS request. The standard timeout for USB request/command is 5000 ms, as recommended in the USB 3.2 specification (section 9.2.6.1). However, certain scenarios, such as connecting devices through an APTIV hub, can lead to timeout errors when the device enumerates as full speed initially and later switches to high speed during chirp negotiation. In such cases, USB analyzer logs reveal that the bus suspends for 5 seconds due to incorrect chirp parsing and resumes only after two consecutive timeout errors trigger a hub driver reset. Packet(54) Dir(?) Full Speed J(997.100 us) Idle( 2.850 us) _______| Time Stamp(28 . 105 910 682) _______|_____________________________________________________________Ch0 Packet(55) Dir(?) Full Speed J(997.118 us) Idle( 2.850 us) _______| Time Stamp(28 . 106 910 632) _______|_____________________________________________________________Ch0 Packet(56) Dir(?) Full Speed J(399.650 us) Idle(222.582 us) _______| Time Stamp(28 . 107 910 600) _______|_____________________________________________________________Ch0 Packet(57) Dir Chirp J( 23.955 ms) Idle(115.169 ms) _______| Time Stamp(28 . 108 532 832) _______|_____________________________________________________________Ch0 Packet(58) Dir(?) Full Speed J (Suspend)( 5.347 sec) Idle( 5.366 us) _______| Time Stamp(28 . 247 657 600) _______|_____________________________________________________________Ch0 This 5-second delay in device enumeration is undesirable, particularly in automotive applications where quick enumeration is crucial (ideally within 3 seconds). The newly introduced quirks provide the flexibility to align with a 3-second time limit, as required in specific contexts like automotive applications. By reducing the SET_ADDRESS request timeout to 500 ms, the system can respond more swiftly to errors, initiate rapid recovery, and ensure efficient device enumeration. This change is vital for scenarios where rapid smartphone enumeration and screen projection are essential. To use the quirk, please write "vendor_id:product_id:p" to /sys/bus/usb/drivers/hub/module/parameter/quirks For example, echo "0x2c48:0x0132:p" > /sys/bus/usb/drivers/hub/module/parameters/quirks" Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20231027152029.104363-2-hgajjar@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-27 17:20:29 +02:00
Revert "usb: move struct usb_device->children to struct usb_hub_port->child" 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-14 09:20:37 -07:00
[PATCH] USB: Remove USB private semaphore This patch (as605) removes the private udev->serialize semaphore, relying instead on the locking provided by the embedded struct device's semaphore. The changes are confined to the core, except that the usb_trylock_device routine now uses the return convention of down_trylock rather than down_read_trylock (they return opposite values for no good reason). A couple of other associated changes are included as well: Now that we aren't concerned about HCDs that avoid using the hcd glue layer, usb_disconnect no longer needs to acquire the usb_bus_lock -- that can be done by usb_remove_hcd where it belongs. Devices aren't locked over the same scope of code in usb_new_device and hub_port_connect_change as they used to be. This shouldn't cause any trouble. Along with the preceding driver core patch, this needs a lot of testing. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-17 17:10:32 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: convert khubd into workqueue There is no need to have separate kthread for handling USB hub events. It is more elegant to use the workqueue framework. The workqueue is allocated as freezable because the original thread was freezable as well. Also it is allocated as ordered because the code is not ready for parallel processing of hub events, see choose_devnum(). struct usb_hub is passed via the work item. Therefore we do not need hub_event_list. Also hub_thread() is not longer needed. It would call only hub_event(). The rest of the code did manipulate the kthread and it is handled by the workqueue framework now. kick_khubd is renamed to kick_hub_wq() to make the function clear. And the protection against races is done another way, see below. hub_event_lock has been removed. It cannot longer be used to protect struct usb_hub between hub_event() and hub_disconnect(). Instead we need to get hub->kref already in kick_hub_wq(). The lock is not really needed for the other scenarios as well. queue_work() returns whether it succeeded. We could revert the needed operations accordingly. This is enough to avoid duplicity and inconsistencies. Yes, the removed lock causes that there is not longer such a strong synchronization between scheduling the work and manipulating hub->disconnected. But kick_hub_wq() must never be called together with hub_disconnect() otherwise even the original code would have failed. Any callers are responsible for this. Therefore the only problem is that hub_disconnect() could be called in parallel with hub_event(). But this was possible even in the past. struct usb_hub is still guarded by hub->kref and released in hub_events() when needed. Note that the source file is still full of the obsolete "khubd" strings. Let's remove them in a follow up patch. This patch already is complex enough. Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to allocate the workqueue. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:21 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: assign default peer ports for root hubs Assume that the peer of a superspeed port is the port with the same id on the shared_hcd root hub. This identification scheme is required of external hubs by the USB3 spec [1]. However, for root hubs, tier mismatch may be in effect [2]. Tier mismatch can only be enumerated via platform firmware. For now, simply perform the nominal association. A new lock 'usb_port_peer_mutex' is introduced to synchronize port device add/remove with peer lookups. It protects peering against changes to hcd->shared_hcd, hcd->self.root_hub, hdev->maxchild, and port_dev->child pointers. [1]: usb 3.1 section 10.3.3 [2]: xhci 1.1 appendix D Cc: Alan Stern <stern@rowland.harvard.edu> [alan: usb_port_peer_mutex locking scheme] Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:28 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
drivers: usb: removed assignment of 0 to static variables fixing the error reported by script checkpatch.pl static variables blinkenlights and old_scheme_first were initialised to 0, correcting it. Signed-off-by: Saurabh Sengar <saurabh.truth@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-10-26 09:25:36 +05:30
usb: core: hub.c: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-08 01:03:34 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: hub.c: Add initial_descriptor_timeout module parameter for usbcore This patch adds initial_descriptor_timeout module parameter for usbcore.ko to allow modify initial 64-byte USB_REQ_GET_DESCRIPTOR timeout for non-standard devices. For example, the SATA8000 device from DATAST0R Technology Corp requires about 10 seconds to send reply (probably it waits until inserted disk is ready for operation). Also, this patch adds missing usbcore parameters to Documentation/kernel-parameters.txt. Signed-off-by: Jaroslav Kysela <perex@perex.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-10-10 16:24:45 +02:00
USB: make printk messages more searchable USB: make printk messages more searchable Make USB printk messages long and straightforward. One of these decorated USB error messages cost me non-trivial efforts to locate. Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-15 15:32:01 +08:00
USB: hub.c: Add initial_descriptor_timeout module parameter for usbcore This patch adds initial_descriptor_timeout module parameter for usbcore.ko to allow modify initial 64-byte USB_REQ_GET_DESCRIPTOR timeout for non-standard devices. For example, the SATA8000 device from DATAST0R Technology Corp requires about 10 seconds to send reply (probably it waits until inserted disk is ready for operation). Also, this patch adds missing usbcore parameters to Documentation/kernel-parameters.txt. Signed-off-by: Jaroslav Kysela <perex@perex.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-10-10 16:24:45 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
drivers: usb: removed assignment of 0 to static variables fixing the error reported by script checkpatch.pl static variables blinkenlights and old_scheme_first were initialised to 0, correcting it. Signed-off-by: Saurabh Sengar <saurabh.truth@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-10-26 09:25:36 +05:30
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: hub: use true,false for bool variable Fix the following coccicheck warning: drivers/usb/core/hub.c:95:12-28: WARNING: Assignment of 0/1 to bool variable Signed-off-by: Jason Yan <yanaijie@huawei.com> Link: https://lore.kernel.org/r/20200426094147.23467-1-yanaijie@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-26 17:41:47 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: mutual exclusion for EHCI init and port resets This patch (as999) fixes a problem that sometimes shows up when host controller driver modules are loaded in the wrong order. If ehci-hcd happens to initialize an EHCI controller while the companion OHCI or UHCI controller is in the middle of a port reset, the reset can fail and the companion may get very confused. The patch adds an rw-semaphore and uses it to keep EHCI initialization and port resets mutually exclusive. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: David Brownell <david-b@pacbell.net> Cc: David Miller <davem@davemloft.net> Cc: Dely L Sy <dely.l.sy@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-10-10 16:27:07 -04:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
USB: optimize port debouncing during hub activation This patch (as1082) makes a small optimization to the way the hub driver carries out port debouncing immediately after a hub is activated (i.e., initialized, reset, or resumed). If any port-change statuses are observed, the code will delay for a minimal debounce period -- thereby making a good start at debouncing all the ports at once. If this wasn't sufficient then khubd will debounce any port that still requires attention. But in most cases it should suffice; it's rare for a device to need more than a minimal debounce delay. (In the cases of hub initialization or reset even that is most likely not needed, since any devices plugged in at such times have probably been attached for a while.) Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:07 -04:00
USB: fix usb_reset_device and usb_reset_composite_device(take 3) This patch renames the existing usb_reset_device in hub.c to usb_reset_and_verify_device and renames the existing usb_reset_composite_device to usb_reset_device. Also the new usb_reset_and_verify_device does't need to be EXPORTED . The idea of the patch is that external interface driver should warn the other interfaces' driver of the same device before and after reseting the usb device. One interface driver shoud call _old_ usb_reset_composite_device instead of _old_ usb_reset_device since it can't assume the device contains only one interface. The _old_ usb_reset_composite_device is safe for single interface device also. we rename the two functions to make the change easily. This patch is under guideline from Alan Stern. Signed-off-by: Ming Lei <tom.leiming@gmail.com>
2008-06-18 22:00:29 +08:00
usb: hub: Move hub_port_disable() to fix warning if PM is disabled If CONFIG_PM=n: drivers/usb/core/hub.c:107: warning: ‘hub_usb3_port_prepare_disable’ declared inline after being called drivers/usb/core/hub.c:107: warning: previous declaration of ‘hub_usb3_port_prepare_disable’ was here To fix this, move hub_port_disable() after hub_usb3_port_prepare_disable(), and adjust forward declarations. Fixes: 37be66767e3cae4f ("usb: hub: Fix auto-remount of safely removed or ejected USB-3 devices") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-12-14 15:37:30 +01:00
usb: handle warm-reset port requests on hub resume On plug-in of my USB-C device, its USB_SS_PORT_LS_SS_INACTIVE link state bit is set. Greping all the kernel for this bit shows that the port status requests a warm-reset this way. This just happens, if its the only device on the root hub, the hub therefore resumes and the HCDs status_urb isn't yet available. If a warm-reset request is detected, this sets the hubs event_bits, which will prevent any auto-suspend and allows the hubs workqueue to warm-reset the port later in port_event. Signed-off-by: Jan-Marek Glogowski <glogow@fbihome.de> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-01 13:52:31 +01:00
USB: fix usb_reset_device and usb_reset_composite_device(take 3) This patch renames the existing usb_reset_device in hub.c to usb_reset_and_verify_device and renames the existing usb_reset_composite_device to usb_reset_device. Also the new usb_reset_and_verify_device does't need to be EXPORTED . The idea of the patch is that external interface driver should warn the other interfaces' driver of the same device before and after reseting the usb device. One interface driver shoud call _old_ usb_reset_composite_device instead of _old_ usb_reset_device since it can't assume the device contains only one interface. The _old_ usb_reset_composite_device is safe for single interface device also. we rename the two functions to make the change easily. This patch is under guideline from Alan Stern. Signed-off-by: Ming Lei <tom.leiming@gmail.com>
2008-06-18 22:00:29 +08:00
USB: Remove bogus USB_PORT_STAT_SUPER_SPEED symbol. USB_PORT_STAT_SUPER_SPEED is a made up symbol that the USB core used to track whether USB ports had a SuperSpeed device attached. This is a linux-internal symbol that was used when SuperSpeed and non-SuperSpeed devices would show up under the same xHCI roothub. This particular port status is never returned by external USB 3.0 hubs. (Instead they have a USB_PORT_STAT_SPEED_5GBPS that uses a completely different speed mask.) Now that the xHCI driver registers two roothubs, USB 3.0 devices will only show up under USB 3.0 hubs. Rip out USB_PORT_STAT_SUPER_SPEED and replace it with calls to hub_is_superspeed(). Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-06 21:00:19 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
hub: admit devices are SS+ If a port can do 10 Gb/s the kernel should say so. The corresponding check needs to be added. Signed-off.by: Oliver Neukum <ONeukum@suse.com>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-04-20 16:28:09 +02:00
USB: Remove bogus USB_PORT_STAT_SUPER_SPEED symbol. USB_PORT_STAT_SUPER_SPEED is a made up symbol that the USB core used to track whether USB ports had a SuperSpeed device attached. This is a linux-internal symbol that was used when SuperSpeed and non-SuperSpeed devices would show up under the same xHCI roothub. This particular port status is never returned by external USB 3.0 hubs. (Instead they have a USB_PORT_STAT_SPEED_5GBPS that uses a completely different speed mask.) Now that the xHCI driver registers two roothubs, USB 3.0 devices will only show up under USB 3.0 hubs. Rip out USB_PORT_STAT_SUPER_SPEED and replace it with calls to hub_is_superspeed(). Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-06 21:00:19 -08:00
USB: remove bogus USB_PORT_FEAT_*_SPEED symbols This patch (as1348) removes the bogus USB_PORT_FEAT_{HIGHSPEED,SUPERSPEED} symbols from ch11.h. No such features are defined by the USB spec. (There is a PORT_LOWSPEED feature, but the spec doesn't mention it except to say that host software should never use it.) The speed indicators are port statuses, not port features. As a temporary workaround for the xhci-hcd driver, a fictional USB_PORT_STAT_SUPER_SPEED symbol is added. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-03-04 11:32:30 -05:00
drivers: usb: core: {file,hub,sysfs,usb}.c: Whitespace fixes including: - removing of trailing whitespace - removing spaces before array indexing (foo [] to foo[]) - reindention of a switch-case block - spaces to tabs Signed-off-by: Matthias Beyer <mail@beyermatthias.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-10 23:41:27 +02:00
USB: remove bogus USB_PORT_FEAT_*_SPEED symbols This patch (as1348) removes the bogus USB_PORT_FEAT_{HIGHSPEED,SUPERSPEED} symbols from ch11.h. No such features are defined by the USB spec. (There is a PORT_LOWSPEED feature, but the spec doesn't mention it except to say that host software should never use it.) The speed indicators are port statuses, not port features. As a temporary workaround for the xhci-hcd driver, a fictional USB_PORT_STAT_SUPER_SPEED symbol is added. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-03-04 11:32:30 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: move children to struct usb_port The usb_device structure contains an array of usb_device "children". This array is only valid if the usb_device is a hub, so it makes no sense to store it there. Instead, store the usb_device child in its parent usb_port structure. Since usb_port is an internal USB core structure, add a new function to get the USB device child, usb_hub_find_child(). Add a new macro, usb_hub_get_each_child(), to iterate over all the children attached to a particular USB hub. Remove the printing the USB children array pointer from the usb-ip driver, since it's really not necessary. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-05 13:44:32 +08:00
USB: check for hub driver not bound to root hub device This patch (as1267) changes usb_kick_khubd() and hdev_to_hub() to make them more resilient against situations where a hub device isn't bound to the hub driver. The code assumes that if a root hub was successfully registered then it must be bound to the hub driver. But this assumption can fail if the user manually unbinds the hub driver, or more importantly, if the host controller dies causing usb_set_configuration to fail. To protect against these possibilities, make hdev_to_hub() check that the hub device is configured before dereferencing the active configuration, and make usb_kick_khubd() check that the pointer to the hub's private data structure isn't NULL. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-22 14:41:18 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: lpm: set lpm_capable for root hub device Commit 25cd2882e2fc ("usb/xhci: Change how we indicate a host supports Link PM.") removed the code to set lpm_capable for USB 3.0 super-speed root hub. The intention of that change was to avoid touching usb core internal field, a.k.a. lpm_capable, and let usb core to set it by checking U1 and U2 exit latency values in the descriptor. Usb core checks and sets lpm_capable in hub_port_init(). Unfortunately, root hub is a special usb device as it has no parent. Hub_port_init() will never be called for a root hub device. That means lpm_capable will by no means be set for the root hub. As the result, lpm isn't functional at all in Linux kernel. This patch add the code to check and set lpm_capable when registering a root hub device. It could be back-ported to kernels as old as v3.15, that contains the Commit 25cd2882e2fc ("usb/xhci: Change how we indicate a host supports Link PM."). Cc: stable@vger.kernel.org # 3.15 Reported-by: Kevin Strasser <kevin.strasser@linux.intel.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-06-16 09:08:26 +08:00
USB: Refactor code to set LPM support flag. 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-02-20 08:31:26 -08:00
USB: add quirk for devices with broken LPM Some USB device / host controller combinations seem to have problems with Link Power Management. For example, Steinar found that his xHCI controller wouldn't handle bandwidth calculations correctly for two video cards simultaneously when LPM was enabled, even though the bus had plenty of bandwidth available. This patch introduces a new quirk flag for devices that should remain disabled for LPM, and creates quirk entries for Steinar's devices. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Steinar H. Gunderson <sgunderson@bigfoot.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-10 15:27:21 -05:00
usb: hub: Guard against accesses to uninitialized BOS descriptors Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h access fields inside udev->bos without checking if it was allocated and initialized. If usb_get_bos_descriptor() fails for whatever reason, udev->bos will be NULL and those accesses will result in a crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1> Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:hub_port_reset+0x193/0x788 Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9 RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310 RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840 RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0 Call Trace: hub_event+0x73f/0x156e ? hub_activate+0x5b7/0x68f process_one_work+0x1a2/0x487 worker_thread+0x11a/0x288 kthread+0x13a/0x152 ? process_one_work+0x487/0x487 ? kthread_associate_blkcg+0x70/0x70 ret_from_fork+0x1f/0x30 Fall back to a default behavior if the BOS descriptor isn't accessible and skip all the functionalities that depend on it: LPM support checks, Super Speed capabilitiy checks, U1/U2 states setup. Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20230830100418.1952143-1-ricardo.canuelo@collabora.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-30 12:04:18 +02:00
USB: Refactor code to set LPM support flag. 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-02-20 08:31:26 -08:00
usb: Enable LPM for USB 2.01+ full-speed devices USB 2.01+ full-speed devices can have extended descriptor as well and can support LPM. Signed-off-by: Rupesh Tatiya <rtatiya@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-14 16:36:55 +05:30
USB: Refactor code to set LPM support flag. 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-02-20 08:31:26 -08:00
USB: Calculate USB 3.0 exit latencies for LPM. 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-02-20 12:02:19 -08:00
usb/xhci: Change how we indicate a host supports Link PM. The xHCI driver currently uses a USB core internal field, udev->lpm_capable, to indicate the xHCI driver knows how to calculate the LPM timeout values. If this value is set for the host controller udev, it means Link PM can be enabled for child devices under that host. Change the code so the xHCI driver isn't mucking with USB core internal fields. Instead, indicate the xHCI driver doesn't support Link PM on this host by clearing the U1 and U2 exit latencies in the roothub SuperSpeed Extended Capabilities BOS descriptor. The code to check for the roothub setting U1 and U2 exit latencies to zero will also disable LPM for external devices that do that same. This was already effectively done with commit ae8963adb4ad8c5f2a89ca1d99fb7bb721e7599f "usb: Don't enable LPM if the exit latency is zero." Leave that code in place, so that if a device sets one exit latency value to zero, but the other is set to a valid value, LPM is only enabled for the U1 or U2 state that had the valid value. This is the same behavior the code had before. Also, change messages about missing Link PM information from warning level to info level. Only print a warning about the first device that doesn't support LPM, to avoid log spam. Further, cleanup some unnecessary line breaks to help people to grep for the error messages. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Alan Stern <stern@rowland.harvard.edu>
2014-01-17 14:15:44 -08:00
USB: Calculate USB 3.0 exit latencies for LPM. 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-02-20 12:02:19 -08:00
usb/xhci: Change how we indicate a host supports Link PM. The xHCI driver currently uses a USB core internal field, udev->lpm_capable, to indicate the xHCI driver knows how to calculate the LPM timeout values. If this value is set for the host controller udev, it means Link PM can be enabled for child devices under that host. Change the code so the xHCI driver isn't mucking with USB core internal fields. Instead, indicate the xHCI driver doesn't support Link PM on this host by clearing the U1 and U2 exit latencies in the roothub SuperSpeed Extended Capabilities BOS descriptor. The code to check for the roothub setting U1 and U2 exit latencies to zero will also disable LPM for external devices that do that same. This was already effectively done with commit ae8963adb4ad8c5f2a89ca1d99fb7bb721e7599f "usb: Don't enable LPM if the exit latency is zero." Leave that code in place, so that if a device sets one exit latency value to zero, but the other is set to a valid value, LPM is only enabled for the U1 or U2 state that had the valid value. This is the same behavior the code had before. Also, change messages about missing Link PM information from warning level to info level. Only print a warning about the first device that doesn't support LPM, to avoid log spam. Further, cleanup some unnecessary line breaks to help people to grep for the error messages. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Alan Stern <stern@rowland.harvard.edu>
2014-01-17 14:15:44 -08:00
USB: Calculate USB 3.0 exit latencies for LPM. 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-02-20 12:02:19 -08:00
usb/xhci: Change how we indicate a host supports Link PM. The xHCI driver currently uses a USB core internal field, udev->lpm_capable, to indicate the xHCI driver knows how to calculate the LPM timeout values. If this value is set for the host controller udev, it means Link PM can be enabled for child devices under that host. Change the code so the xHCI driver isn't mucking with USB core internal fields. Instead, indicate the xHCI driver doesn't support Link PM on this host by clearing the U1 and U2 exit latencies in the roothub SuperSpeed Extended Capabilities BOS descriptor. The code to check for the roothub setting U1 and U2 exit latencies to zero will also disable LPM for external devices that do that same. This was already effectively done with commit ae8963adb4ad8c5f2a89ca1d99fb7bb721e7599f "usb: Don't enable LPM if the exit latency is zero." Leave that code in place, so that if a device sets one exit latency value to zero, but the other is set to a valid value, LPM is only enabled for the U1 or U2 state that had the valid value. This is the same behavior the code had before. Also, change messages about missing Link PM information from warning level to info level. Only print a warning about the first device that doesn't support LPM, to avoid log spam. Further, cleanup some unnecessary line breaks to help people to grep for the error messages. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Alan Stern <stern@rowland.harvard.edu>
2014-01-17 14:15:44 -08:00
USB: Refactor code to set LPM support flag. 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-02-20 08:31:26 -08:00
USB: Calculate USB 3.0 exit latencies for LPM. 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-02-20 12:02:19 -08:00
usb: hub: Fix link power management max exit latency (MEL) calculations Maximum Exit Latency (MEL) value is used by host to know how much in advance it needs to start waking up a U1/U2 suspended link in order to service a periodic transfer in time. Current MEL calculation only includes the time to wake up the path from U1/U2 to U0. This is called tMEL1 in USB 3.1 section C 1.5.2 Total MEL = tMEL1 + tMEL2 +tMEL3 + tMEL4 which should additinally include: - tMEL2 which is the time it takes for PING message to reach device - tMEL3 time for device to process the PING and submit a PING_RESPONSE - tMEL4 time for PING_RESPONSE to traverse back upstream to host. Add the missing tMEL2, tMEL3 and tMEL4 to MEL calculation. Cc: <stable@kernel.org> # v3.5 Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210715150122.1995966-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-15 18:01:21 +03:00
USB: Calculate USB 3.0 exit latencies for LPM. 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-02-20 12:02:19 -08:00
usb: hub: Fix link power management max exit latency (MEL) calculations Maximum Exit Latency (MEL) value is used by host to know how much in advance it needs to start waking up a U1/U2 suspended link in order to service a periodic transfer in time. Current MEL calculation only includes the time to wake up the path from U1/U2 to U0. This is called tMEL1 in USB 3.1 section C 1.5.2 Total MEL = tMEL1 + tMEL2 +tMEL3 + tMEL4 which should additinally include: - tMEL2 which is the time it takes for PING message to reach device - tMEL3 time for device to process the PING and submit a PING_RESPONSE - tMEL4 time for PING_RESPONSE to traverse back upstream to host. Add the missing tMEL2, tMEL3 and tMEL4 to MEL calculation. Cc: <stable@kernel.org> # v3.5 Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210715150122.1995966-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-15 18:01:21 +03:00
USB: Calculate USB 3.0 exit latencies for LPM. 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-02-20 12:02:19 -08:00
usb: hub: Fix link power management max exit latency (MEL) calculations Maximum Exit Latency (MEL) value is used by host to know how much in advance it needs to start waking up a U1/U2 suspended link in order to service a periodic transfer in time. Current MEL calculation only includes the time to wake up the path from U1/U2 to U0. This is called tMEL1 in USB 3.1 section C 1.5.2 Total MEL = tMEL1 + tMEL2 +tMEL3 + tMEL4 which should additinally include: - tMEL2 which is the time it takes for PING message to reach device - tMEL3 time for device to process the PING and submit a PING_RESPONSE - tMEL4 time for PING_RESPONSE to traverse back upstream to host. Add the missing tMEL2, tMEL3 and tMEL4 to MEL calculation. Cc: <stable@kernel.org> # v3.5 Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210715150122.1995966-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-15 18:01:21 +03:00
USB: Calculate USB 3.0 exit latencies for LPM. 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-02-20 12:02:19 -08:00
usb: hub: Fix link power management max exit latency (MEL) calculations Maximum Exit Latency (MEL) value is used by host to know how much in advance it needs to start waking up a U1/U2 suspended link in order to service a periodic transfer in time. Current MEL calculation only includes the time to wake up the path from U1/U2 to U0. This is called tMEL1 in USB 3.1 section C 1.5.2 Total MEL = tMEL1 + tMEL2 +tMEL3 + tMEL4 which should additinally include: - tMEL2 which is the time it takes for PING message to reach device - tMEL3 time for device to process the PING and submit a PING_RESPONSE - tMEL4 time for PING_RESPONSE to traverse back upstream to host. Add the missing tMEL2, tMEL3 and tMEL4 to MEL calculation. Cc: <stable@kernel.org> # v3.5 Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210715150122.1995966-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-15 18:01:21 +03:00
USB: Calculate USB 3.0 exit latencies for LPM. 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-02-20 12:02:19 -08:00
usb: hub: Fix link power management max exit latency (MEL) calculations Maximum Exit Latency (MEL) value is used by host to know how much in advance it needs to start waking up a U1/U2 suspended link in order to service a periodic transfer in time. Current MEL calculation only includes the time to wake up the path from U1/U2 to U0. This is called tMEL1 in USB 3.1 section C 1.5.2 Total MEL = tMEL1 + tMEL2 +tMEL3 + tMEL4 which should additinally include: - tMEL2 which is the time it takes for PING message to reach device - tMEL3 time for device to process the PING and submit a PING_RESPONSE - tMEL4 time for PING_RESPONSE to traverse back upstream to host. Add the missing tMEL2, tMEL3 and tMEL4 to MEL calculation. Cc: <stable@kernel.org> # v3.5 Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210715150122.1995966-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-15 18:01:21 +03:00
USB: Calculate USB 3.0 exit latencies for LPM. 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-02-20 12:02:19 -08:00
usb: define USB_SPEED_SUPER_PLUS speed for SuperSpeedPlus USB3.1 devices Add a new USB_SPEED_SUPER_PLUS device speed, and make sure usb core can handle the new speed. In most cases the behaviour is the same as with USB_SPEED_SUPER SuperSpeed devices. In a few places we add a "Plus" string to inform the user of the new speed. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-10 09:59:25 +02:00
USB: Calculate USB 3.0 exit latencies for LPM. 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-02-20 12:02:19 -08:00
usb: hub: Guard against accesses to uninitialized BOS descriptors Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h access fields inside udev->bos without checking if it was allocated and initialized. If usb_get_bos_descriptor() fails for whatever reason, udev->bos will be NULL and those accesses will result in a crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1> Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:hub_port_reset+0x193/0x788 Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9 RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310 RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840 RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0 Call Trace: hub_event+0x73f/0x156e ? hub_activate+0x5b7/0x68f process_one_work+0x1a2/0x487 worker_thread+0x11a/0x288 kthread+0x13a/0x152 ? process_one_work+0x487/0x487 ? kthread_associate_blkcg+0x70/0x70 ret_from_fork+0x1f/0x30 Fall back to a default behavior if the BOS descriptor isn't accessible and skip all the functionalities that depend on it: LPM support checks, Super Speed capabilitiy checks, U1/U2 states setup. Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20230830100418.1952143-1-ricardo.canuelo@collabora.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-30 12:04:18 +02:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
USB: Calculate USB 3.0 exit latencies for LPM. 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-02-20 12:02:19 -08:00
usbcore: fix incorrect type in assignment in usb_set_lpm_parameters() In the bos usb_ss_cap_descriptor structure, bU2DevExitLat is of type __le16. This value is used as it is, without being first converted to the CPU byteorder, for the setup of usb device's usb3_lpm_parameters. This patch fixes that by converting bU2DevExitLat field to the CPU byteorder before the assignmenment to [udev/hub]_u2_del variables. Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com> Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-31 18:09:13 +03:00
USB: Calculate USB 3.0 exit latencies for LPM. 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-02-20 12:02:19 -08:00
usbcore: fix incorrect type in assignment in usb_set_lpm_parameters() In the bos usb_ss_cap_descriptor structure, bU2DevExitLat is of type __le16. This value is used as it is, without being first converted to the CPU byteorder, for the setup of usb device's usb3_lpm_parameters. This patch fixes that by converting bU2DevExitLat field to the CPU byteorder before the assignmenment to [udev/hub]_u2_del variables. Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com> Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-31 18:09:13 +03:00
USB: Calculate USB 3.0 exit latencies for LPM. 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-02-20 12:02:19 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: hub: fix non-SS hub-descriptor handling Add missing sanity check on the non-SuperSpeed hub-descriptor length in order to avoid parsing and leaking two bytes of uninitialised slab data through sysfs removable-attributes (or a compound-device debug statement). Note that we only make sure that the DeviceRemovable field is always present (and specifically ignore the unused PortPwrCtrlMask field) in order to continue support any hubs with non-compliant descriptors. As a further safeguard, the descriptor buffer is also cleared. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable <stable@vger.kernel.org> # 2.6.12 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>
2017-05-10 18:18:28 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB 3.0 Hub Changes Update the USB core to deal with USB 3.0 hubs. These hubs have a slightly different hub descriptor than USB 2.0 hubs, with a fixed (rather than variable length) size. Change the USB core's hub descriptor to have a union for the last fields that differ. Change the host controller drivers that access those last fields (DeviceRemovable and PortPowerCtrlMask) to use the union. Translate the new version of the hub port status field into the old version that khubd understands. (Note: we need to fix it to translate the roothub's port status once we stop converting it to USB 2.0 hub status internally.) Add new code to handle link state change status. Send out new control messages that are needed for USB 3.0 hubs, like Set Hub Depth. This patch is a modified version of the original patch submitted by John Youn. It's updated to reflect the removal of the "bitmap" #define, and change the hub descriptor accesses of a couple new host controller drivers. Signed-off-by: John Youn <johnyoun@synopsys.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com> Cc: Tony Olech <tony.olech@elandigitalsystems.com> Cc: "Robert P. J. Day" <rpjday@crashcourse.ca> Cc: Max Vozeler <mvz@vozeler.com> Cc: Tejun Heo <tj@kernel.org> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Cc: Rodolfo Giometti <giometti@linux.it> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Anton Vorontsov <avorontsov@mvista.com> Cc: Sebastian Siewior <bigeasy@linutronix.de> Cc: Lothar Wassmann <LW@KARO-electronics.de> Cc: Olav Kongas <ok@artecdesign.ee> Cc: Martin Fuzzey <mfuzzey@gmail.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: David Brownell <dbrownell@users.sourceforge.net>
2001-09-17 00:00:00 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: hub: fix non-SS hub-descriptor handling Add missing sanity check on the non-SuperSpeed hub-descriptor length in order to avoid parsing and leaking two bytes of uninitialised slab data through sysfs removable-attributes (or a compound-device debug statement). Note that we only make sure that the DeviceRemovable field is always present (and specifically ignore the unused PortPwrCtrlMask field) in order to continue support any hubs with non-compliant descriptors. As a further safeguard, the descriptor buffer is also cleared. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable <stable@vger.kernel.org> # 2.6.12 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>
2017-05-10 18:18:28 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: hub: fix SS hub-descriptor handling A SuperSpeed hub descriptor does not have any variable-length fields so bail out when reading a short descriptor. This avoids parsing and leaking two bytes of uninitialised slab data through sysfs removable-attributes. Fixes: dbe79bbe9dcb ("USB 3.0 Hub Changes") Cc: stable <stable@vger.kernel.org> # 2.6.39 Cc: John Youn <John.Youn@synopsys.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-05-10 18:18:27 +02:00
USB: hub: fix non-SS hub-descriptor handling Add missing sanity check on the non-SuperSpeed hub-descriptor length in order to avoid parsing and leaking two bytes of uninitialised slab data through sysfs removable-attributes (or a compound-device debug statement). Note that we only make sure that the DeviceRemovable field is always present (and specifically ignore the unused PortPwrCtrlMask field) in order to continue support any hubs with non-compliant descriptors. As a further safeguard, the descriptor buffer is also cleared. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable <stable@vger.kernel.org> # 2.6.12 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>
2017-05-10 18:18:28 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: hub: fix SS hub-descriptor handling A SuperSpeed hub descriptor does not have any variable-length fields so bail out when reading a short descriptor. This avoids parsing and leaking two bytes of uninitialised slab data through sysfs removable-attributes. Fixes: dbe79bbe9dcb ("USB 3.0 Hub Changes") Cc: stable <stable@vger.kernel.org> # 2.6.39 Cc: John Youn <John.Youn@synopsys.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-05-10 18:18:27 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
Revert "USB: core: hub.c: use usb_control_msg_send() in a few places" This reverts commit d6a499249543356002a1efbb26254c7272e62f4c. Control messages are needed in contexts when memory allocations are restricted, such as handling device resets and runtime PM. For this reason the control message API internally uses GFP_NOIO. This is a band aid introduced because when we recognized the issue, the call chains were highly convoluted. Continuing this trend is not a good idea. So I am shooting the whole kennel here. Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20200923134348.23862-2-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-23 15:43:35 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
Revert "USB: core: hub.c: use usb_control_msg_send() in a few places" This reverts commit d6a499249543356002a1efbb26254c7272e62f4c. Control messages are needed in contexts when memory allocations are restricted, such as handling device resets and runtime PM. For this reason the control message API internally uses GFP_NOIO. This is a band aid introduced because when we recognized the issue, the call chains were highly convoluted. Continuing this trend is not a good idea. So I am shooting the whole kennel here. Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20200923134348.23862-2-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-23 15:43:35 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
Revert "USB: core: hub.c: use usb_control_msg_send() in a few places" This reverts commit d6a499249543356002a1efbb26254c7272e62f4c. Control messages are needed in contexts when memory allocations are restricted, such as handling device resets and runtime PM. For this reason the control message API internally uses GFP_NOIO. This is a band aid introduced because when we recognized the issue, the call chains were highly convoluted. Continuing this trend is not a good idea. So I am shooting the whole kennel here. Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20200923134348.23862-2-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-23 15:43:35 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: hub.c: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-08 01:03:34 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
WorkStruct: make allyesconfig Fix up for make allyesconfig. Signed-Off-By: David Howells <dhowells@redhat.com>
2006-11-22 14:57:56 +00:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: don't use bNbrPorts after initialization After successful initialization hub->descriptor->bNbrPorts and hub->hdev->maxchild are equal, but using hub->hdev->maxchild is preferred because that value is explicitly used for initialization of hub->ports[]. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-22 14:49:40 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: don't use bNbrPorts after initialization After successful initialization hub->descriptor->bNbrPorts and hub->hdev->maxchild are equal, but using hub->hdev->maxchild is preferred because that value is explicitly used for initialization of hub->ports[]. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-22 14:49:40 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: move hub init and LED blink work to power efficient workqueue Allow the scheduler to select the best CPU to handle hub initalization and LED blinking work. This extends idle residency times on idle CPUs and conserves power. This functionality is enabled when CONFIG_WQ_POWER_EFFICIENT is selected. [zoran.markovic@linaro.org: Rebased to latest kernel. Added commit message. Changed reference from system to power efficient workqueue for LEDs in check_highspeed() and hub_port_connect_change().] Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Xenia Ragiadakou <burzalodowa@gmail.com> Cc: Julius Werner <jwerner@chromium.org> Cc: Krzysztof Mazur <krzysiek@podlesie.net> Cc: Matthias Beyer <mail@beyermatthias.de> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Mathias Nyman <mathias.nyman@linux.intel.com> Cc: Thomas Pugliese <thomas.pugliese@gmail.com> Signed-off-by: Shaibal Dutta <shaibal.dutta@broadcom.com> Signed-off-by: Zoran Markovic <zoran.markovic@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-01 19:16:46 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: core: Tolerate protocol stall during hub and port status read Protocol stall should not be fatal while reading port or hub status as it is transient state. Currently hub EP0 STALL during port status read results in failed device enumeration. This has been observed with ST-Ericsson (formerly Philips) USB 2.0 Hub (04cc:1521) after connecting keyboard. Signed-off-by: Libor Pechacek <lpechacek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-20 14:53:25 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: Support USB 3.1 extended port status request usb 3.1 extend the hub get-port-status request by adding different request types. the new request types return 4 additional bytes called extended port status, these bytes are returned after the regular portstatus and portchange values. The extended port status contains a speed ID for the currently used sublink speed. A table of supported Speed IDs with details about the link is provided by the hub in the device descriptor BOS SuperSpeedPlus device capability Sublink Speed Attributes. Support this new request. Ask for the extended port status after port reset if hub supports USB 3.1. If link is running at SuperSpeedPlus set the device speed to USB_SPEED_SUPER_PLUS Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-10 09:59:29 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: Support USB 3.1 extended port status request usb 3.1 extend the hub get-port-status request by adding different request types. the new request types return 4 additional bytes called extended port status, these bytes are returned after the regular portstatus and portchange values. The extended port status contains a speed ID for the currently used sublink speed. A table of supported Speed IDs with details about the link is provided by the hub in the device descriptor BOS SuperSpeedPlus device capability Sublink Speed Attributes. Support this new request. Ask for the extended port status after port reset if hub supports USB 3.1. If link is running at SuperSpeedPlus set the device speed to USB_SPEED_SUPER_PLUS Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-10 09:59:29 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: core: Tolerate protocol stall during hub and port status read Protocol stall should not be fatal while reading port or hub status as it is transient state. Currently hub EP0 STALL during port status read results in failed device enumeration. This has been observed with ST-Ericsson (formerly Philips) USB 2.0 Hub (04cc:1521) after connecting keyboard. Signed-off-by: Libor Pechacek <lpechacek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-20 14:53:25 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: Support USB 3.1 extended port status request usb 3.1 extend the hub get-port-status request by adding different request types. the new request types return 4 additional bytes called extended port status, these bytes are returned after the regular portstatus and portchange values. The extended port status contains a speed ID for the currently used sublink speed. A table of supported Speed IDs with details about the link is provided by the hub in the device descriptor BOS SuperSpeedPlus device capability Sublink Speed Attributes. Support this new request. Ask for the extended port status after port reset if hub supports USB 3.1. If link is running at SuperSpeedPlus set the device speed to USB_SPEED_SUPER_PLUS Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-10 09:59:29 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: Support USB 3.1 extended port status request usb 3.1 extend the hub get-port-status request by adding different request types. the new request types return 4 additional bytes called extended port status, these bytes are returned after the regular portstatus and portchange values. The extended port status contains a speed ID for the currently used sublink speed. A table of supported Speed IDs with details about the link is provided by the hub in the device descriptor BOS SuperSpeedPlus device capability Sublink Speed Attributes. Support this new request. Ask for the extended port status after port reset if hub supports USB 3.1. If link is running at SuperSpeedPlus set the device speed to USB_SPEED_SUPER_PLUS Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-10 09:59:29 +02:00
USB: reorganize code in hub.c This patch (as1045) reorganizes some code in the hub driver. hub_port_status() is moved earlier in the file, and a new hub_stop() routine is created to do the work currently in hub_preset() (i.e., disconnect all child devices and quiesce the hub). There are no functional changes. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-03 15:15:43 -05:00
usb: Support USB 3.1 extended port status request usb 3.1 extend the hub get-port-status request by adding different request types. the new request types return 4 additional bytes called extended port status, these bytes are returned after the regular portstatus and portchange values. The extended port status contains a speed ID for the currently used sublink speed. A table of supported Speed IDs with details about the link is provided by the hub in the device descriptor BOS SuperSpeedPlus device capability Sublink Speed Attributes. Support this new request. Ask for the extended port status after port reset if hub supports USB 3.1. If link is running at SuperSpeedPlus set the device speed to USB_SPEED_SUPER_PLUS Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-10 09:59:29 +02:00
USB: reorganize code in hub.c This patch (as1045) reorganizes some code in the hub driver. hub_port_status() is moved earlier in the file, and a new hub_stop() routine is created to do the work currently in hub_preset() (i.e., disconnect all child devices and quiesce the hub). There are no functional changes. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-03 15:15:43 -05:00
usb: Support USB 3.1 extended port status request usb 3.1 extend the hub get-port-status request by adding different request types. the new request types return 4 additional bytes called extended port status, these bytes are returned after the regular portstatus and portchange values. The extended port status contains a speed ID for the currently used sublink speed. A table of supported Speed IDs with details about the link is provided by the hub in the device descriptor BOS SuperSpeedPlus device capability Sublink Speed Attributes. Support this new request. Ask for the extended port status after port reset if hub supports USB 3.1. If link is running at SuperSpeedPlus set the device speed to USB_SPEED_SUPER_PLUS Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-10 09:59:29 +02:00
USB: avoid error messages when a device is disconnected This patch (as1673) reduces the amount of log spew from the hub driver by removing a bunch of error messages in the case where the device in question is already known to have been disconnected. Since the disconnect event itself appears in the log, there's no need for other error messages. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Jenya Y <jy.gerstmaier@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-27 16:14:01 -04:00
USB: reorganize code in hub.c This patch (as1045) reorganizes some code in the hub driver. hub_port_status() is moved earlier in the file, and a new hub_stop() routine is created to do the work currently in hub_preset() (i.e., disconnect all child devices and quiesce the hub). There are no functional changes. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-03 15:15:43 -05:00
usb: Support USB 3.1 extended port status request usb 3.1 extend the hub get-port-status request by adding different request types. the new request types return 4 additional bytes called extended port status, these bytes are returned after the regular portstatus and portchange values. The extended port status contains a speed ID for the currently used sublink speed. A table of supported Speed IDs with details about the link is provided by the hub in the device descriptor BOS SuperSpeedPlus device capability Sublink Speed Attributes. Support this new request. Ask for the extended port status after port reset if hub supports USB 3.1. If link is running at SuperSpeedPlus set the device speed to USB_SPEED_SUPER_PLUS Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-10 09:59:29 +02:00
USB: reorganize code in hub.c This patch (as1045) reorganizes some code in the hub driver. hub_port_status() is moved earlier in the file, and a new hub_stop() routine is created to do the work currently in hub_preset() (i.e., disconnect all child devices and quiesce the hub). There are no functional changes. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-03 15:15:43 -05:00
usb: core: add phy notify connect and disconnect In Realtek SoC, the parameter of usb phy is designed to can dynamic tuning base on port status. Therefore, add a notify callback of generic phy driver when usb device connect and disconnect change. The Realtek phy driver is designed to dynamically adjust disconnection level and calibrate phy parameters. When the device connected bit changes and when the disconnected bit changes, do connection change notification: Check if portstatus is USB_PORT_STAT_CONNECTION and portchange is USB_PORT_STAT_C_CONNECTION. 1. The device is connected, the driver lowers the disconnection level and calibrates the phy parameters. 2. The device disconnects, the driver increases the disconnect level and calibrates the phy parameters. Generic phy driver in usb core framework does not support device connect and disconnect notifications. Therefore, we add an api to notify phy the connection changes. Additionally, the generic phy only specifies primary_hcd in the original design. Added specific "usb2-phy" on primary_hcd and "usb3-phy" on shared_hcd. Signed-off-by: Stanley Chang <stanley_chang@realtek.com> Link: https://lore.kernel.org/r/20231213031203.4911-4-stanley_chang@realtek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-13 11:10:09 +08:00
USB: reorganize code in hub.c This patch (as1045) reorganizes some code in the hub driver. hub_port_status() is moved earlier in the file, and a new hub_stop() routine is created to do the work currently in hub_preset() (i.e., disconnect all child devices and quiesce the hub). There are no functional changes. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-03 15:15:43 -05:00
usb: hub: port: add sysfs entry to switch port power In some cases the port of an hub needs to be disabled or switched off and on again. E.g. when the connected device needs to be re-enumerated. Or it needs to be explicitly disabled while the rest of the usb tree stays working. For this purpose this patch adds an sysfs switch to enable/disable the port on any hub. In the case the hub is supporting power switching, the power line will be disabled to the connected device. When the port gets disabled, the associated device gets disconnected and removed from the logical usb tree. No further device will be enumerated on that port until the port gets enabled again. Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220607114522.3359148-1-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-07 13:45:22 +02:00
usb: Support USB 3.1 extended port status request usb 3.1 extend the hub get-port-status request by adding different request types. the new request types return 4 additional bytes called extended port status, these bytes are returned after the regular portstatus and portchange values. The extended port status contains a speed ID for the currently used sublink speed. A table of supported Speed IDs with details about the link is provided by the hub in the device descriptor BOS SuperSpeedPlus device capability Sublink Speed Attributes. Support this new request. Ask for the extended port status after port reset if hub supports USB 3.1. If link is running at SuperSpeedPlus set the device speed to USB_SPEED_SUPER_PLUS Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-10 09:59:29 +02:00
usb: hub: add retry routine after intr URB submit error The hub sends hot-plug events to the host trough it's interrupt URB. The driver takes care of completing the URB and re-submitting it. Completion errors are handled in the hub_event() work, yet submission errors are ignored, rendering the device unresponsive. All further events are lost. It is fairly hard to find this issue in the wild, since you have to time the USB hot-plug event with the URB submission failure. For instance it could be the system running out of memory or some malfunction in the USB controller driver. Nevertheless, it's pretty reasonable to think it'll happen sometime. One can trigger this issue using eBPF's function override feature (see BCC's inject.py script). This patch adds a retry routine to the event of a submission error. The HUB driver will try to re-submit the URB once every second until it's successful or the HUB is disconnected. As some USB subsystems already take care of this issue, the implementation was inspired from usbhid/hid_core.c's. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Oliver Neukum <oneukum@suse.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-08 16:45:22 +01:00
usb: hub: convert khubd into workqueue There is no need to have separate kthread for handling USB hub events. It is more elegant to use the workqueue framework. The workqueue is allocated as freezable because the original thread was freezable as well. Also it is allocated as ordered because the code is not ready for parallel processing of hub events, see choose_devnum(). struct usb_hub is passed via the work item. Therefore we do not need hub_event_list. Also hub_thread() is not longer needed. It would call only hub_event(). The rest of the code did manipulate the kthread and it is handled by the workqueue framework now. kick_khubd is renamed to kick_hub_wq() to make the function clear. And the protection against races is done another way, see below. hub_event_lock has been removed. It cannot longer be used to protect struct usb_hub between hub_event() and hub_disconnect(). Instead we need to get hub->kref already in kick_hub_wq(). The lock is not really needed for the other scenarios as well. queue_work() returns whether it succeeded. We could revert the needed operations accordingly. This is enough to avoid duplicity and inconsistencies. Yes, the removed lock causes that there is not longer such a strong synchronization between scheduling the work and manipulating hub->disconnected. But kick_hub_wq() must never be called together with hub_disconnect() otherwise even the original code would have failed. Any callers are responsible for this. Therefore the only problem is that hub_disconnect() could be called in parallel with hub_event(). But this was possible even in the past. struct usb_hub is still guarded by hub->kref and released in hub_events() when needed. Note that the source file is still full of the obsolete "khubd" strings. Let's remove them in a follow up patch. This patch already is complex enough. Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to allocate the workqueue. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:21 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: convert khubd into workqueue There is no need to have separate kthread for handling USB hub events. It is more elegant to use the workqueue framework. The workqueue is allocated as freezable because the original thread was freezable as well. Also it is allocated as ordered because the code is not ready for parallel processing of hub events, see choose_devnum(). struct usb_hub is passed via the work item. Therefore we do not need hub_event_list. Also hub_thread() is not longer needed. It would call only hub_event(). The rest of the code did manipulate the kthread and it is handled by the workqueue framework now. kick_khubd is renamed to kick_hub_wq() to make the function clear. And the protection against races is done another way, see below. hub_event_lock has been removed. It cannot longer be used to protect struct usb_hub between hub_event() and hub_disconnect(). Instead we need to get hub->kref already in kick_hub_wq(). The lock is not really needed for the other scenarios as well. queue_work() returns whether it succeeded. We could revert the needed operations accordingly. This is enough to avoid duplicity and inconsistencies. Yes, the removed lock causes that there is not longer such a strong synchronization between scheduling the work and manipulating hub->disconnected. But kick_hub_wq() must never be called together with hub_disconnect() otherwise even the original code would have failed. Any callers are responsible for this. Therefore the only problem is that hub_disconnect() could be called in parallel with hub_event(). But this was possible even in the past. struct usb_hub is still guarded by hub->kref and released in hub_events() when needed. Note that the source file is still full of the obsolete "khubd" strings. Let's remove them in a follow up patch. This patch already is complex enough. Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to allocate the workqueue. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:21 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: convert khubd into workqueue There is no need to have separate kthread for handling USB hub events. It is more elegant to use the workqueue framework. The workqueue is allocated as freezable because the original thread was freezable as well. Also it is allocated as ordered because the code is not ready for parallel processing of hub events, see choose_devnum(). struct usb_hub is passed via the work item. Therefore we do not need hub_event_list. Also hub_thread() is not longer needed. It would call only hub_event(). The rest of the code did manipulate the kthread and it is handled by the workqueue framework now. kick_khubd is renamed to kick_hub_wq() to make the function clear. And the protection against races is done another way, see below. hub_event_lock has been removed. It cannot longer be used to protect struct usb_hub between hub_event() and hub_disconnect(). Instead we need to get hub->kref already in kick_hub_wq(). The lock is not really needed for the other scenarios as well. queue_work() returns whether it succeeded. We could revert the needed operations accordingly. This is enough to avoid duplicity and inconsistencies. Yes, the removed lock causes that there is not longer such a strong synchronization between scheduling the work and manipulating hub->disconnected. But kick_hub_wq() must never be called together with hub_disconnect() otherwise even the original code would have failed. Any callers are responsible for this. Therefore the only problem is that hub_disconnect() could be called in parallel with hub_event(). But this was possible even in the past. struct usb_hub is still guarded by hub->kref and released in hub_events() when needed. Note that the source file is still full of the obsolete "khubd" strings. Let's remove them in a follow up patch. This patch already is complex enough. Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to allocate the workqueue. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:21 +02:00
USB: prepare for changover to Runtime PM framework This patch (as1303) revises the USB Power Management infrastructure to make it compatible with the new driver-model Runtime PM framework: Drivers are no longer allowed to access intf->pm_usage_cnt directly; the PM framework manages its own usage counters. usb_autopm_set_interface() is eliminated, because it directly sets intf->pm_usage_cnt. usb_autopm_enable() and usb_autopm_disable() are eliminated, because they call usb_autopm_set_interface(). usb_autopm_get_interface_no_resume() and usb_autopm_put_interface_no_suspend() are added. They correspond to pm_runtime_get_noresume() and pm_runtime_put_noidle() in the PM framework. The power/level attribute no longer accepts "suspend", only "on" and "auto". The PM framework doesn't allow devices to be forced into a suspended mode. The hub driver contains the only code that violates the new guidelines. It is updated to use the new interface routines instead. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-07 13:01:37 -05:00
usb: hub: convert khubd into workqueue There is no need to have separate kthread for handling USB hub events. It is more elegant to use the workqueue framework. The workqueue is allocated as freezable because the original thread was freezable as well. Also it is allocated as ordered because the code is not ready for parallel processing of hub events, see choose_devnum(). struct usb_hub is passed via the work item. Therefore we do not need hub_event_list. Also hub_thread() is not longer needed. It would call only hub_event(). The rest of the code did manipulate the kthread and it is handled by the workqueue framework now. kick_khubd is renamed to kick_hub_wq() to make the function clear. And the protection against races is done another way, see below. hub_event_lock has been removed. It cannot longer be used to protect struct usb_hub between hub_event() and hub_disconnect(). Instead we need to get hub->kref already in kick_hub_wq(). The lock is not really needed for the other scenarios as well. queue_work() returns whether it succeeded. We could revert the needed operations accordingly. This is enough to avoid duplicity and inconsistencies. Yes, the removed lock causes that there is not longer such a strong synchronization between scheduling the work and manipulating hub->disconnected. But kick_hub_wq() must never be called together with hub_disconnect() otherwise even the original code would have failed. Any callers are responsible for this. Therefore the only problem is that hub_disconnect() could be called in parallel with hub_event(). But this was possible even in the past. struct usb_hub is still guarded by hub->kref and released in hub_events() when needed. Note that the source file is still full of the obsolete "khubd" strings. Let's remove them in a follow up patch. This patch already is complex enough. Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to allocate the workqueue. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:21 +02:00
USB: core: Add hub_get() and hub_put() routines Create hub_get() and hub_put() routines to encapsulate the kref_get() and kref_put() calls in hub.c. The new routines will be used by the next patch in this series. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/604da420-ae8a-4a9e-91a4-2d511ff404fb@rowland.harvard.edu Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-15 13:04:50 -04:00
usb: hub: convert khubd into workqueue There is no need to have separate kthread for handling USB hub events. It is more elegant to use the workqueue framework. The workqueue is allocated as freezable because the original thread was freezable as well. Also it is allocated as ordered because the code is not ready for parallel processing of hub events, see choose_devnum(). struct usb_hub is passed via the work item. Therefore we do not need hub_event_list. Also hub_thread() is not longer needed. It would call only hub_event(). The rest of the code did manipulate the kthread and it is handled by the workqueue framework now. kick_khubd is renamed to kick_hub_wq() to make the function clear. And the protection against races is done another way, see below. hub_event_lock has been removed. It cannot longer be used to protect struct usb_hub between hub_event() and hub_disconnect(). Instead we need to get hub->kref already in kick_hub_wq(). The lock is not really needed for the other scenarios as well. queue_work() returns whether it succeeded. We could revert the needed operations accordingly. This is enough to avoid duplicity and inconsistencies. Yes, the removed lock causes that there is not longer such a strong synchronization between scheduling the work and manipulating hub->disconnected. But kick_hub_wq() must never be called together with hub_disconnect() otherwise even the original code would have failed. Any callers are responsible for this. Therefore the only problem is that hub_disconnect() could be called in parallel with hub_event(). But this was possible even in the past. struct usb_hub is still guarded by hub->kref and released in hub_events() when needed. Note that the source file is still full of the obsolete "khubd" strings. Let's remove them in a follow up patch. This patch already is complex enough. Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to allocate the workqueue. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:21 +02:00
USB: core: Add hub_get() and hub_put() routines Create hub_get() and hub_put() routines to encapsulate the kref_get() and kref_put() calls in hub.c. The new routines will be used by the next patch in this series. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/604da420-ae8a-4a9e-91a4-2d511ff404fb@rowland.harvard.edu Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-15 13:04:50 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: rename usb_kick_khubd() to usb_kick_hub_wq() USB hub started to use a workqueue instead of kthread. Let's make it clear from the function names. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:22 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
USB: check for hub driver not bound to root hub device This patch (as1267) changes usb_kick_khubd() and hdev_to_hub() to make them more resilient against situations where a hub device isn't bound to the hub driver. The code assumes that if a root hub was successfully registered then it must be bound to the hub driver. But this assumption can fail if the user manually unbinds the hub driver, or more importantly, if the host controller dies causing usb_set_configuration to fail. To protect against these possibilities, make hdev_to_hub() check that the hub device is configured before dereferencing the active configuration, and make usb_kick_khubd() check that the pointer to the hub's private data structure isn't NULL. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-22 14:41:18 -04:00
usb: hub: convert khubd into workqueue There is no need to have separate kthread for handling USB hub events. It is more elegant to use the workqueue framework. The workqueue is allocated as freezable because the original thread was freezable as well. Also it is allocated as ordered because the code is not ready for parallel processing of hub events, see choose_devnum(). struct usb_hub is passed via the work item. Therefore we do not need hub_event_list. Also hub_thread() is not longer needed. It would call only hub_event(). The rest of the code did manipulate the kthread and it is handled by the workqueue framework now. kick_khubd is renamed to kick_hub_wq() to make the function clear. And the protection against races is done another way, see below. hub_event_lock has been removed. It cannot longer be used to protect struct usb_hub between hub_event() and hub_disconnect(). Instead we need to get hub->kref already in kick_hub_wq(). The lock is not really needed for the other scenarios as well. queue_work() returns whether it succeeded. We could revert the needed operations accordingly. This is enough to avoid duplicity and inconsistencies. Yes, the removed lock causes that there is not longer such a strong synchronization between scheduling the work and manipulating hub->disconnected. But kick_hub_wq() must never be called together with hub_disconnect() otherwise even the original code would have failed. Any callers are responsible for this. Therefore the only problem is that hub_disconnect() could be called in parallel with hub_event(). But this was possible even in the past. struct usb_hub is still guarded by hub->kref and released in hub_events() when needed. Note that the source file is still full of the obsolete "khubd" strings. Let's remove them in a follow up patch. This patch already is complex enough. Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to allocate the workqueue. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:21 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB/xHCI: Support device-initiated USB 3.0 resume. USB 3.0 hubs don't have a port suspend change bit (that bit is now reserved). Instead, when a host-initiated resume finishes, the hub sets the port link state change bit. When a USB 3.0 device initiates remote wakeup, the parent hubs with their upstream links in U3 will pass the LFPS up the chain. The first hub that has an upstream link in U0 (which may be the roothub) will reflect that LFPS back down the path to the device. However, the parent hubs in the resumed path will not set their link state change bit. Instead, the device that initiated the resume has to send an asynchronous "Function Wake" Device Notification up to the host controller. Therefore, we need a way to notify the USB core of a device resume without going through the normal hub URB completion method. First, make the xHCI roothub act like an external USB 3.0 hub and not pass up the port link state change bit when a device-initiated resume finishes. Introduce a new xHCI bit field, port_remote_wakeup, so that we can tell the difference between a port coming out of the U3Exit state (host-initiated resume) and the RExit state (ending state of device-initiated resume). Since the USB core can't tell whether a port on a hub has resumed by looking at the Hub Status buffer, we need to introduce a bitfield, wakeup_bits, that indicates which ports have resumed. When the xHCI driver notices a port finishing a device-initiated resume, we call into a new USB core function, usb_wakeup_notification(), that will set the right bit in wakeup_bits, and kick khubd for that hub. We also call usb_wakeup_notification() when the Function Wake Device Notification is received by the xHCI driver. This covers the case where the link between the roothub and the first-tier hub is in U0, and the hub reflects the resume signaling back to the device without giving any indication it has done so until the device sends the Function Wake notification. Change the code in khubd that handles the remote wakeup to look at the state the USB core thinks the device is in, and handle the remote wakeup if the port's wakeup bit is set. This patch only takes care of the case where the device is attached directly to the roothub, or the USB 3.0 hub that is attached to the root hub is the device sending the Function Wake Device Notification (e.g. because a new USB device was attached). The other cases will be covered in a second patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-11-14 18:00:01 -08:00
USB: Increment wakeup count on remote wakeup. On chromebooks we depend on wakeup count to identify the wakeup source. But currently USB devices do not increment the wakeup count when they trigger the remote wake. This patch addresses the same. Resume condition is reported differently on USB 2.0 and USB 3.0 devices. On USB 2.0 devices, a wake capable device, if wake enabled, drives resume signal to indicate a remote wake (USB 2.0 spec section 7.1.7.7). The upstream facing port then sets C_PORT_SUSPEND bit and reports a port change event (USB 2.0 spec section 11.24.2.7.2.3). Thus if a port has resumed before driving the resume signal from the host and C_PORT_SUSPEND is set, then the device attached to the given port might be the reason for the last system wakeup. Increment the wakeup count for the same. On USB 3.0 devices, a function may signal that it wants to exit from device suspend by sending a Function Wake Device Notification to the host (USB3.0 spec section 8.5.6.4) Thus on receiving the Function Wake, increment the wakeup count. Signed-off-by: Ravi Chandra Sadineni <ravisadineni@chromium.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-04-20 11:08:21 -07:00
USB/xHCI: Support device-initiated USB 3.0 resume. USB 3.0 hubs don't have a port suspend change bit (that bit is now reserved). Instead, when a host-initiated resume finishes, the hub sets the port link state change bit. When a USB 3.0 device initiates remote wakeup, the parent hubs with their upstream links in U3 will pass the LFPS up the chain. The first hub that has an upstream link in U0 (which may be the roothub) will reflect that LFPS back down the path to the device. However, the parent hubs in the resumed path will not set their link state change bit. Instead, the device that initiated the resume has to send an asynchronous "Function Wake" Device Notification up to the host controller. Therefore, we need a way to notify the USB core of a device resume without going through the normal hub URB completion method. First, make the xHCI roothub act like an external USB 3.0 hub and not pass up the port link state change bit when a device-initiated resume finishes. Introduce a new xHCI bit field, port_remote_wakeup, so that we can tell the difference between a port coming out of the U3Exit state (host-initiated resume) and the RExit state (ending state of device-initiated resume). Since the USB core can't tell whether a port on a hub has resumed by looking at the Hub Status buffer, we need to introduce a bitfield, wakeup_bits, that indicates which ports have resumed. When the xHCI driver notices a port finishing a device-initiated resume, we call into a new USB core function, usb_wakeup_notification(), that will set the right bit in wakeup_bits, and kick khubd for that hub. We also call usb_wakeup_notification() when the Function Wake Device Notification is received by the xHCI driver. This covers the case where the link between the roothub and the first-tier hub is in U0, and the hub reflects the resume signaling back to the device without giving any indication it has done so until the device sends the Function Wake notification. Change the code in khubd that handles the remote wakeup to look at the state the USB core thinks the device is in, and handle the remote wakeup if the port's wakeup bit is set. This patch only takes care of the case where the device is attached directly to the roothub, or the USB 3.0 hub that is attached to the root hub is the device sending the Function Wake Device Notification (e.g. because a new USB device was attached). The other cases will be covered in a second patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-11-14 18:00:01 -08:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
USB/xHCI: Support device-initiated USB 3.0 resume. USB 3.0 hubs don't have a port suspend change bit (that bit is now reserved). Instead, when a host-initiated resume finishes, the hub sets the port link state change bit. When a USB 3.0 device initiates remote wakeup, the parent hubs with their upstream links in U3 will pass the LFPS up the chain. The first hub that has an upstream link in U0 (which may be the roothub) will reflect that LFPS back down the path to the device. However, the parent hubs in the resumed path will not set their link state change bit. Instead, the device that initiated the resume has to send an asynchronous "Function Wake" Device Notification up to the host controller. Therefore, we need a way to notify the USB core of a device resume without going through the normal hub URB completion method. First, make the xHCI roothub act like an external USB 3.0 hub and not pass up the port link state change bit when a device-initiated resume finishes. Introduce a new xHCI bit field, port_remote_wakeup, so that we can tell the difference between a port coming out of the U3Exit state (host-initiated resume) and the RExit state (ending state of device-initiated resume). Since the USB core can't tell whether a port on a hub has resumed by looking at the Hub Status buffer, we need to introduce a bitfield, wakeup_bits, that indicates which ports have resumed. When the xHCI driver notices a port finishing a device-initiated resume, we call into a new USB core function, usb_wakeup_notification(), that will set the right bit in wakeup_bits, and kick khubd for that hub. We also call usb_wakeup_notification() when the Function Wake Device Notification is received by the xHCI driver. This covers the case where the link between the roothub and the first-tier hub is in U0, and the hub reflects the resume signaling back to the device without giving any indication it has done so until the device sends the Function Wake notification. Change the code in khubd that handles the remote wakeup to look at the state the USB core thinks the device is in, and handle the remote wakeup if the port's wakeup bit is set. This patch only takes care of the case where the device is attached directly to the roothub, or the USB 3.0 hub that is attached to the root hub is the device sending the Function Wake Device Notification (e.g. because a new USB device was attached). The other cases will be covered in a second patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-11-14 18:00:01 -08:00
USB: Increment wakeup count on remote wakeup. On chromebooks we depend on wakeup count to identify the wakeup source. But currently USB devices do not increment the wakeup count when they trigger the remote wake. This patch addresses the same. Resume condition is reported differently on USB 2.0 and USB 3.0 devices. On USB 2.0 devices, a wake capable device, if wake enabled, drives resume signal to indicate a remote wake (USB 2.0 spec section 7.1.7.7). The upstream facing port then sets C_PORT_SUSPEND bit and reports a port change event (USB 2.0 spec section 11.24.2.7.2.3). Thus if a port has resumed before driving the resume signal from the host and C_PORT_SUSPEND is set, then the device attached to the given port might be the reason for the last system wakeup. Increment the wakeup count for the same. On USB 3.0 devices, a function may signal that it wants to exit from device suspend by sending a Function Wake Device Notification to the host (USB3.0 spec section 8.5.6.4) Thus on receiving the Function Wake, increment the wakeup count. Signed-off-by: Ravi Chandra Sadineni <ravisadineni@chromium.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-04-20 11:08:21 -07:00
USB/xHCI: Support device-initiated USB 3.0 resume. USB 3.0 hubs don't have a port suspend change bit (that bit is now reserved). Instead, when a host-initiated resume finishes, the hub sets the port link state change bit. When a USB 3.0 device initiates remote wakeup, the parent hubs with their upstream links in U3 will pass the LFPS up the chain. The first hub that has an upstream link in U0 (which may be the roothub) will reflect that LFPS back down the path to the device. However, the parent hubs in the resumed path will not set their link state change bit. Instead, the device that initiated the resume has to send an asynchronous "Function Wake" Device Notification up to the host controller. Therefore, we need a way to notify the USB core of a device resume without going through the normal hub URB completion method. First, make the xHCI roothub act like an external USB 3.0 hub and not pass up the port link state change bit when a device-initiated resume finishes. Introduce a new xHCI bit field, port_remote_wakeup, so that we can tell the difference between a port coming out of the U3Exit state (host-initiated resume) and the RExit state (ending state of device-initiated resume). Since the USB core can't tell whether a port on a hub has resumed by looking at the Hub Status buffer, we need to introduce a bitfield, wakeup_bits, that indicates which ports have resumed. When the xHCI driver notices a port finishing a device-initiated resume, we call into a new USB core function, usb_wakeup_notification(), that will set the right bit in wakeup_bits, and kick khubd for that hub. We also call usb_wakeup_notification() when the Function Wake Device Notification is received by the xHCI driver. This covers the case where the link between the roothub and the first-tier hub is in U0, and the hub reflects the resume signaling back to the device without giving any indication it has done so until the device sends the Function Wake notification. Change the code in khubd that handles the remote wakeup to look at the state the USB core thinks the device is in, and handle the remote wakeup if the port's wakeup bit is set. This patch only takes care of the case where the device is attached directly to the roothub, or the USB 3.0 hub that is attached to the root hub is the device sending the Function Wake Device Notification (e.g. because a new USB device was attached). The other cases will be covered in a second patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-11-14 18:00:01 -08:00
usb: hub: convert khubd into workqueue There is no need to have separate kthread for handling USB hub events. It is more elegant to use the workqueue framework. The workqueue is allocated as freezable because the original thread was freezable as well. Also it is allocated as ordered because the code is not ready for parallel processing of hub events, see choose_devnum(). struct usb_hub is passed via the work item. Therefore we do not need hub_event_list. Also hub_thread() is not longer needed. It would call only hub_event(). The rest of the code did manipulate the kthread and it is handled by the workqueue framework now. kick_khubd is renamed to kick_hub_wq() to make the function clear. And the protection against races is done another way, see below. hub_event_lock has been removed. It cannot longer be used to protect struct usb_hub between hub_event() and hub_disconnect(). Instead we need to get hub->kref already in kick_hub_wq(). The lock is not really needed for the other scenarios as well. queue_work() returns whether it succeeded. We could revert the needed operations accordingly. This is enough to avoid duplicity and inconsistencies. Yes, the removed lock causes that there is not longer such a strong synchronization between scheduling the work and manipulating hub->disconnected. But kick_hub_wq() must never be called together with hub_disconnect() otherwise even the original code would have failed. Any callers are responsible for this. Therefore the only problem is that hub_disconnect() could be called in parallel with hub_event(). But this was possible even in the past. struct usb_hub is still guarded by hub->kref and released in hub_events() when needed. Note that the source file is still full of the obsolete "khubd" strings. Let's remove them in a follow up patch. This patch already is complex enough. Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to allocate the workqueue. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:21 +02:00
USB/xHCI: Support device-initiated USB 3.0 resume. USB 3.0 hubs don't have a port suspend change bit (that bit is now reserved). Instead, when a host-initiated resume finishes, the hub sets the port link state change bit. When a USB 3.0 device initiates remote wakeup, the parent hubs with their upstream links in U3 will pass the LFPS up the chain. The first hub that has an upstream link in U0 (which may be the roothub) will reflect that LFPS back down the path to the device. However, the parent hubs in the resumed path will not set their link state change bit. Instead, the device that initiated the resume has to send an asynchronous "Function Wake" Device Notification up to the host controller. Therefore, we need a way to notify the USB core of a device resume without going through the normal hub URB completion method. First, make the xHCI roothub act like an external USB 3.0 hub and not pass up the port link state change bit when a device-initiated resume finishes. Introduce a new xHCI bit field, port_remote_wakeup, so that we can tell the difference between a port coming out of the U3Exit state (host-initiated resume) and the RExit state (ending state of device-initiated resume). Since the USB core can't tell whether a port on a hub has resumed by looking at the Hub Status buffer, we need to introduce a bitfield, wakeup_bits, that indicates which ports have resumed. When the xHCI driver notices a port finishing a device-initiated resume, we call into a new USB core function, usb_wakeup_notification(), that will set the right bit in wakeup_bits, and kick khubd for that hub. We also call usb_wakeup_notification() when the Function Wake Device Notification is received by the xHCI driver. This covers the case where the link between the roothub and the first-tier hub is in U0, and the hub reflects the resume signaling back to the device without giving any indication it has done so until the device sends the Function Wake notification. Change the code in khubd that handles the remote wakeup to look at the state the USB core thinks the device is in, and handle the remote wakeup if the port's wakeup bit is set. This patch only takes care of the case where the device is attached directly to the roothub, or the USB 3.0 hub that is attached to the root hub is the device sending the Function Wake Device Notification (e.g. because a new USB device was attached). The other cases will be covered in a second patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-11-14 18:00:01 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
IRQ: Maintain regs pointer globally rather than passing to IRQ handlers Maintain a per-CPU global "struct pt_regs *" variable which can be used instead of passing regs around manually through all ~1800 interrupt handlers in the Linux kernel. The regs pointer is used in few places, but it potentially costs both stack space and code to pass it around. On the FRV arch, removing the regs parameter from all the genirq function results in a 20% speed up of the IRQ exit path (ie: from leaving timer_interrupt() to leaving do_IRQ()). Where appropriate, an arch may override the generic storage facility and do something different with the variable. On FRV, for instance, the address is maintained in GR28 at all times inside the kernel as part of general exception handling. Having looked over the code, it appears that the parameter may be handed down through up to twenty or so layers of functions. Consider a USB character device attached to a USB hub, attached to a USB controller that posts its interrupts through a cascaded auxiliary interrupt controller. A character device driver may want to pass regs to the sysrq handler through the input layer which adds another few layers of parameter passing. I've build this code with allyesconfig for x86_64 and i386. I've runtested the main part of the code on FRV and i386, though I can't test most of the drivers. I've also done partial conversion for powerpc and MIPS - these at least compile with minimal configurations. This will affect all archs. Mostly the changes should be relatively easy. Take do_IRQ(), store the regs pointer at the beginning, saving the old one: struct pt_regs *old_regs = set_irq_regs(regs); And put the old one back at the end: set_irq_regs(old_regs); Don't pass regs through to generic_handle_irq() or __do_IRQ(). In timer_interrupt(), this sort of change will be necessary: - update_process_times(user_mode(regs)); - profile_tick(CPU_PROFILING, regs); + update_process_times(user_mode(get_irq_regs())); + profile_tick(CPU_PROFILING); I'd like to move update_process_times()'s use of get_irq_regs() into itself, except that i386, alone of the archs, uses something other than user_mode(). Some notes on the interrupt handling in the drivers: (*) input_dev() is now gone entirely. The regs pointer is no longer stored in the input_dev struct. (*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking. It does something different depending on whether it's been supplied with a regs pointer or not. (*) Various IRQ handler function pointers have been moved to type irq_handler_t. Signed-Off-By: David Howells <dhowells@redhat.com> (cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
2006-10-05 14:55:46 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: Remove unneeded void * casts in core files The patch removes unneeded casts for the following (void *) pointers: - struct file: private - struct urb: context - struct usb_bus: hcpriv - return value of kmalloc() The patch also contains some whitespace cleanup in the relevant areas. Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-09-13 21:38:41 +02:00
USB: remove traces of urb->status from usbcore This patch (as981) removes the remaining nontrivial usages of urb->status from usbcore. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-08-24 15:42:52 -04:00
USB: more u32 conversion after transfer_buffer_length and actual_length transfer_buffer_length and actual_length have become unsigned, therefore some additional conversion of local variables, function arguments and print specifications is desired. A test for a negative urb->transfer_buffer_length became obsolete; instead we ensure that it does not exceed INT_MAX. Also, urb->actual_length is always less than urb->transfer_buffer_length. rh_string() does no longer return -EPIPE in the case of an unsupported ID. Instead its only caller, rh_call_control() does the check. Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-13 12:19:18 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: remove traces of urb->status from usbcore This patch (as981) removes the remaining nontrivial usages of urb->status from usbcore. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-08-24 15:42:52 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: hub.c: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-08 01:03:34 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: remove traces of urb->status from usbcore This patch (as981) removes the remaining nontrivial usages of urb->status from usbcore. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-08-24 15:42:52 -04:00
treewide: Use fallthrough pseudo-keyword Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
2020-08-23 17:36:59 -05:00
USB: Remove unneeded void * casts in core files The patch removes unneeded casts for the following (void *) pointers: - struct file: private - struct urb: context - struct usb_bus: hcpriv - return value of kmalloc() The patch also contains some whitespace cleanup in the relevant areas. Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-09-13 21:38:41 +02:00
usb: hub: rename khubd to hub_wq in documentation and comments USB hub has started to use a workqueue instead of kthread. Let's update the documentation and comments here and there. This patch mostly just replaces "khubd" with "hub_wq". There are only few exceptions where the whole sentence was updated. These more complicated changes can be found in the following files: Documentation/usb/hotplug.txt drivers/net/usb/usbnet.c drivers/usb/core/hcd.c drivers/usb/host/ohci-hcd.c drivers/usb/host/xhci.c Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:23 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: rename khubd to hub_wq in documentation and comments USB hub has started to use a workqueue instead of kthread. Let's update the documentation and comments here and there. This patch mostly just replaces "khubd" with "hub_wq". There are only few exceptions where the whole sentence was updated. These more complicated changes can be found in the following files: Documentation/usb/hotplug.txt drivers/net/usb/usbnet.c drivers/usb/core/hcd.c drivers/usb/host/ohci-hcd.c drivers/usb/host/xhci.c Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:23 +02:00
usb: hub: convert khubd into workqueue There is no need to have separate kthread for handling USB hub events. It is more elegant to use the workqueue framework. The workqueue is allocated as freezable because the original thread was freezable as well. Also it is allocated as ordered because the code is not ready for parallel processing of hub events, see choose_devnum(). struct usb_hub is passed via the work item. Therefore we do not need hub_event_list. Also hub_thread() is not longer needed. It would call only hub_event(). The rest of the code did manipulate the kthread and it is handled by the workqueue framework now. kick_khubd is renamed to kick_hub_wq() to make the function clear. And the protection against races is done another way, see below. hub_event_lock has been removed. It cannot longer be used to protect struct usb_hub between hub_event() and hub_disconnect(). Instead we need to get hub->kref already in kick_hub_wq(). The lock is not really needed for the other scenarios as well. queue_work() returns whether it succeeded. We could revert the needed operations accordingly. This is enough to avoid duplicity and inconsistencies. Yes, the removed lock causes that there is not longer such a strong synchronization between scheduling the work and manipulating hub->disconnected. But kick_hub_wq() must never be called together with hub_disconnect() otherwise even the original code would have failed. Any callers are responsible for this. Therefore the only problem is that hub_disconnect() could be called in parallel with hub_event(). But this was possible even in the past. struct usb_hub is still guarded by hub->kref and released in hub_events() when needed. Note that the source file is still full of the obsolete "khubd" strings. Let's remove them in a follow up patch. This patch already is complex enough. Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to allocate the workqueue. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:21 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: add retry routine after intr URB submit error The hub sends hot-plug events to the host trough it's interrupt URB. The driver takes care of completing the URB and re-submitting it. Completion errors are handled in the hub_event() work, yet submission errors are ignored, rendering the device unresponsive. All further events are lost. It is fairly hard to find this issue in the wild, since you have to time the USB hot-plug event with the URB submission failure. For instance it could be the system running out of memory or some malfunction in the USB controller driver. Nevertheless, it's pretty reasonable to think it'll happen sometime. One can trigger this issue using eBPF's function override feature (see BCC's inject.py script). This patch adds a retry routine to the event of a submission error. The HUB driver will try to re-submit the URB once every second until it's successful or the HUB is disconnected. As some USB subsystems already take care of this issue, the implementation was inspired from usbhid/hid_core.c's. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Oliver Neukum <oneukum@suse.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-08 16:45:22 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: hub.c: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-08 01:03:34 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: Clear both buffers when clearing a control transfer TT buffer. Control transfers have both IN and OUT (or SETUP) packets, so when clearing TT buffers for a control transfer it's necessary to send two HUB_CLEAR_TT_BUFFER requests to the hub. Signed-off-by: William Gulland <wgulland@google.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27 16:10:20 -07:00
Revert "USB: core: hub.c: use usb_control_msg_send() in a few places" This reverts commit d6a499249543356002a1efbb26254c7272e62f4c. Control messages are needed in contexts when memory allocations are restricted, such as handling device resets and runtime PM. For this reason the control message API internally uses GFP_NOIO. This is a band aid introduced because when we recognized the issue, the call chains were highly convoluted. Continuing this trend is not a good idea. So I am shooting the whole kennel here. Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20200923134348.23862-2-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-23 15:43:35 +02:00
usb: Clear both buffers when clearing a control transfer TT buffer. Control transfers have both IN and OUT (or SETUP) packets, so when clearing TT buffers for a control transfer it's necessary to send two HUB_CLEAR_TT_BUFFER requests to the hub. Signed-off-by: William Gulland <wgulland@google.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-27 16:10:20 -07:00
Revert "USB: core: hub.c: use usb_control_msg_send() in a few places" This reverts commit d6a499249543356002a1efbb26254c7272e62f4c. Control messages are needed in contexts when memory allocations are restricted, such as handling device resets and runtime PM. For this reason the control message API internally uses GFP_NOIO. This is a band aid introduced because when we recognized the issue, the call chains were highly convoluted. Continuing this trend is not a good idea. So I am shooting the whole kennel here. Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20200923134348.23862-2-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-23 15:43:35 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: rename khubd to hub_wq in documentation and comments USB hub has started to use a workqueue instead of kthread. Let's update the documentation and comments here and there. This patch mostly just replaces "khubd" with "hub_wq". There are only few exceptions where the whole sentence was updated. These more complicated changes can be found in the following files: Documentation/usb/hotplug.txt drivers/net/usb/usbnet.c drivers/usb/core/hcd.c drivers/usb/host/ohci-hcd.c drivers/usb/host/xhci.c Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:23 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: fix the clear_tt_buffer interface This patch (as1255) updates the interface for calling usb_hub_clear_tt_buffer(). Even the name of the function is changed! When an async URB (i.e., Control or Bulk) going through a high-speed hub to a non-high-speed device is cancelled or fails, the hub's Transaction Translator buffer may be left busy still trying to complete the transaction. The buffer has to be cleared; that's what usb_hub_clear_tt_buffer() does. It isn't safe to send any more URBs to the same endpoint until the TT buffer is fully clear. Therefore the HCD needs to be told when the Clear-TT-Buffer request has finished. This patch adds a callback method to struct hc_driver for that purpose, and makes the hub driver invoke the callback at the proper time. The patch also changes a couple of names; "hub_tt_kevent" and "tt.kevent" now look rather antiquated. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:43:32 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
WorkStruct: make allyesconfig Fix up for make allyesconfig. Signed-Off-By: David Howells <dhowells@redhat.com>
2006-11-22 14:57:56 +00:00
USB: fix the clear_tt_buffer interface This patch (as1255) updates the interface for calling usb_hub_clear_tt_buffer(). Even the name of the function is changed! When an async URB (i.e., Control or Bulk) going through a high-speed hub to a non-high-speed device is cancelled or fails, the hub's Transaction Translator buffer may be left busy still trying to complete the transaction. The buffer has to be cleared; that's what usb_hub_clear_tt_buffer() does. It isn't safe to send any more URBs to the same endpoint until the TT buffer is fully clear. Therefore the HCD needs to be told when the Clear-TT-Buffer request has finished. This patch adds a callback method to struct hc_driver for that purpose, and makes the hub driver invoke the callback at the proper time. The patch also changes a couple of names; "hub_tt_kevent" and "tt.kevent" now look rather antiquated. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:43:32 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: hub.c: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-08 01:03:34 -07:00
usb hub: send clear_tt_buffer_complete events when canceling TT clear work There is a race condition in the USB hub code with regard to handling TT clear requests that can get the HCD driver in a deadlock. Usually when an TT clear request is scheduled it will be executed immediately: <7>[ 6.077583] usb 2-1.3: unlink qh1-0e01/f4d4db00 start 0 [1/2 us] <3>[ 6.078041] usb 2-1: clear tt buffer port 3, a3 ep2 t04048d82 <7>[ 6.078299] hub_tt_work:731 <7>[ 9.309089] usb 2-1.5: link qh1-0e01/f4d506c0 start 0 [1/2 us] <7>[ 9.324526] ehci_hcd 0000:00:1d.0: reused qh f4d4db00 schedule <7>[ 9.324539] usb 2-1.3: link qh1-0e01/f4d4db00 start 0 [1/2 us] <7>[ 9.341530] usb 1-1.1: link qh4-0e01/f397aec0 start 2 [1/2 us] <7>[ 10.116159] usb 2-1.3: unlink qh1-0e01/f4d4db00 start 0 [1/2 us] <3>[ 10.116459] usb 2-1: clear tt buffer port 3, a3 ep2 t04048d82 <7>[ 10.116537] hub_tt_work:731 However, if a suspend operation is triggered before hub_tt_work is scheduled, hub_quiesce will cancel the work without notifying the HCD driver: <3>[ 35.033941] usb 2-1: clear tt buffer port 3, a3 ep2 t04048d80 <5>[ 35.034022] sd 0:0:0:0: [sda] Stopping disk <7>[ 35.034039] hub 2-1:1.0: hub_suspend <7>[ 35.034067] usb 2-1: unlink qh256-0001/f3b1ab00 start 1 [1/0 us] <7>[ 35.035085] hub 1-0:1.0: hub_suspend <7>[ 35.035102] usb usb1: bus suspend, wakeup 0 <7>[ 35.035106] ehci_hcd 0000:00:1a.0: suspend root hub <7>[ 35.035298] hub 2-0:1.0: hub_suspend <7>[ 35.035313] usb usb2: bus suspend, wakeup 0 <7>[ 35.035315] ehci_hcd 0000:00:1d.0: suspend root hub <6>[ 35.250017] PM: suspend of devices complete after 216.979 msecs <6>[ 35.250822] PM: late suspend of devices complete after 0.799 msecs <7>[ 35.252343] ehci_hcd 0000:00:1d.0: wakeup: 1 <7>[ 35.262923] ehci_hcd 0000:00:1d.0: --> PCI D3hot <7>[ 35.263302] ehci_hcd 0000:00:1a.0: wakeup: 1 <7>[ 35.273912] ehci_hcd 0000:00:1a.0: --> PCI D3hot <6>[ 35.274254] PM: noirq suspend of devices complete after 23.442 msecs <6>[ 35.274975] ACPI: Preparing to enter system sleep state S3 <6>[ 35.292666] PM: Saving platform NVS memory <7>[ 35.295030] Disabling non-boot CPUs ... <6>[ 35.297351] CPU 1 is now offline <6>[ 35.300345] CPU 2 is now offline <6>[ 35.303929] CPU 3 is now offline <7>[ 35.303931] lockdep: fixing up alternatives. <6>[ 35.304825] Extended CMOS year: 2000 When the device will resume the EHCI driver will get stuck in ehci_endpoint_disable waiting for the tt_clearing flag to reset: <0>[ 47.610967] usb 2-1.3: **** DPM device timeout **** <7>[ 47.610972] f2f11c60 00000092 f2f11c0c c10624a5 00000003 f4c6e880 c1c8a4c0 c1c8a4c0 <7>[ 47.610983] 15c55698 0000000b f56b34c0 f2a45b70 f4c6e880 00000082 f2a4602c f2f11c30 <7>[ 47.610993] c10787f8 f4cac000 f2a45b70 00000000 f4cac010 f2f11c58 00000046 00000001 <7>[ 47.611004] Call Trace: <7>[ 47.611006] [<c10624a5>] ? sched_clock_cpu+0xf5/0x160 <7>[ 47.611019] [<c10787f8>] ? lock_release_holdtime.part.22+0x88/0xf0 <7>[ 47.611026] [<c103ed46>] ? lock_timer_base.isra.35+0x26/0x50 <7>[ 47.611034] [<c17592d3>] ? schedule_timeout+0x133/0x290 <7>[ 47.611044] [<c175b43e>] schedule+0x1e/0x50 <7>[ 47.611051] [<c17592d8>] schedule_timeout+0x138/0x290 <7>[ 47.611057] [<c10624a5>] ? sched_clock_cpu+0xf5/0x160 <7>[ 47.611063] [<c103e560>] ? usleep_range+0x40/0x40 <7>[ 47.611070] [<c1759445>] schedule_timeout_uninterruptible+0x15/0x20 <7>[ 47.611077] [<c14935f4>] ehci_endpoint_disable+0x64/0x160 <7>[ 47.611084] [<c147d1ee>] ? usb_hcd_flush_endpoint+0x10e/0x1d0 <7>[ 47.611092] [<c1165663>] ? sysfs_add_file+0x13/0x20 <7>[ 47.611100] [<c147d5a9>] usb_hcd_disable_endpoint+0x29/0x40 <7>[ 47.611107] [<c147fafc>] usb_disable_endpoint+0x5c/0x80 <7>[ 47.611111] [<c147fb57>] usb_disable_interface+0x37/0x50 <7>[ 47.611116] [<c1477650>] usb_reset_and_verify_device+0x4b0/0x640 <7>[ 47.611122] [<c1474665>] ? hub_port_status+0xb5/0x100 <7>[ 47.611129] [<c147a975>] usb_port_resume+0xd5/0x220 <7>[ 47.611136] [<c148877f>] generic_resume+0xf/0x30 <7>[ 47.611142] [<c14821a3>] usb_resume+0x133/0x180 <7>[ 47.611147] [<c1473b10>] ? usb_dev_thaw+0x10/0x10 <7>[ 47.611152] [<c1473b1d>] usb_dev_resume+0xd/0x10 <7>[ 47.611157] [<c13baa60>] dpm_run_callback+0x40/0xb0 <7>[ 47.611164] [<c13bdb03>] ? pm_runtime_enable+0x43/0x70 <7>[ 47.611171] [<c13bafc6>] device_resume+0x1a6/0x2c0 <7>[ 47.611177] [<c13ba940>] ? dpm_show_time+0xe0/0xe0 <7>[ 47.611183] [<c13bb0f9>] async_resume+0x19/0x40 <7>[ 47.611189] [<c10580c4>] async_run_entry_fn+0x64/0x160 <7>[ 47.611196] [<c104a244>] ? process_one_work+0x104/0x480 <7>[ 47.611203] [<c104a24c>] ? process_one_work+0x10c/0x480 <7>[ 47.611209] [<c104a2c0>] process_one_work+0x180/0x480 <7>[ 47.611215] [<c104a244>] ? process_one_work+0x104/0x480 <7>[ 47.611220] [<c1058060>] ? async_schedule+0x10/0x10 <7>[ 47.611226] [<c104c15c>] worker_thread+0x11c/0x2f0 <7>[ 47.611233] [<c104c040>] ? manage_workers.isra.27+0x1f0/0x1f0 <7>[ 47.611239] [<c10507f8>] kthread+0x78/0x80 <7>[ 47.611244] [<c1750000>] ? timer_cpu_notify+0xd6/0x20d <7>[ 47.611253] [<c1050780>] ? __init_kthread_worker+0x60/0x60 <7>[ 47.611258] [<c176357e>] kernel_thread_helper+0x6/0xd <7>[ 47.611283] ------------[ cut here ]------------ This patch changes hub_quiesce behavior to flush the TT clear work instead of canceling it, to make sure that no TT clear request remains uncompleted before suspend. Signed-off-by: Octavian Purdila <octavian.purdila@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-01 22:21:12 +03:00
USB: hub.c: fix sparse warnings Fix sparse warning in drivers/usb/core/hub.c. The following sparse warning is seen when building on ARM due do the macro raw_local_irq_save(): warning: symbol 'temp' shadows an earlier one Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-22 16:03:05 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: fix the clear_tt_buffer interface This patch (as1255) updates the interface for calling usb_hub_clear_tt_buffer(). Even the name of the function is changed! When an async URB (i.e., Control or Bulk) going through a high-speed hub to a non-high-speed device is cancelled or fails, the hub's Transaction Translator buffer may be left busy still trying to complete the transaction. The buffer has to be cleared; that's what usb_hub_clear_tt_buffer() does. It isn't safe to send any more URBs to the same endpoint until the TT buffer is fully clear. Therefore the HCD needs to be told when the Clear-TT-Buffer request has finished. This patch adds a callback method to struct hc_driver for that purpose, and makes the hub driver invoke the callback at the proper time. The patch also changes a couple of names; "hub_tt_kevent" and "tt.kevent" now look rather antiquated. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:43:32 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: hub.c: fix sparse warnings Fix sparse warning in drivers/usb/core/hub.c. The following sparse warning is seen when building on ARM due do the macro raw_local_irq_save(): warning: symbol 'temp' shadows an earlier one Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-22 16:03:05 -04:00
usb: core: hub.c: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-08 01:03:34 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: hub.c: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-08 01:03:34 -07:00
USB: avoid error messages when a device is disconnected This patch (as1673) reduces the amount of log spew from the hub driver by removing a bunch of error messages in the case where the device in question is already known to have been disconnected. Since the disconnect event itself appears in the log, there's no need for other error messages. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Jenya Y <jy.gerstmaier@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-27 16:14:01 -04:00
usb: core: hub.c: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-08 01:03:34 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: fix the clear_tt_buffer interface This patch (as1255) updates the interface for calling usb_hub_clear_tt_buffer(). Even the name of the function is changed! When an async URB (i.e., Control or Bulk) going through a high-speed hub to a non-high-speed device is cancelled or fails, the hub's Transaction Translator buffer may be left busy still trying to complete the transaction. The buffer has to be cleared; that's what usb_hub_clear_tt_buffer() does. It isn't safe to send any more URBs to the same endpoint until the TT buffer is fully clear. Therefore the HCD needs to be told when the Clear-TT-Buffer request has finished. This patch adds a callback method to struct hc_driver for that purpose, and makes the hub driver invoke the callback at the proper time. The patch also changes a couple of names; "hub_tt_kevent" and "tt.kevent" now look rather antiquated. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:43:32 -04:00
[PATCH] USB: kfree cleanup for drivers/usb/* - no need to check for NULL Get rid of a bunch of redundant NULL pointer checks in drivers/usb/*, there's no need to check a pointer for NULL before calling kfree() on it. Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Index: gregkh-2.6/drivers/usb/class/audio.c ===================================================================
2005-04-18 17:39:34 -07:00
USB: fix the clear_tt_buffer interface This patch (as1255) updates the interface for calling usb_hub_clear_tt_buffer(). Even the name of the function is changed! When an async URB (i.e., Control or Bulk) going through a high-speed hub to a non-high-speed device is cancelled or fails, the hub's Transaction Translator buffer may be left busy still trying to complete the transaction. The buffer has to be cleared; that's what usb_hub_clear_tt_buffer() does. It isn't safe to send any more URBs to the same endpoint until the TT buffer is fully clear. Therefore the HCD needs to be told when the Clear-TT-Buffer request has finished. This patch adds a callback method to struct hc_driver for that purpose, and makes the hub driver invoke the callback at the proper time. The patch also changes a couple of names; "hub_tt_kevent" and "tt.kevent" now look rather antiquated. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:43:32 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: hub.c: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-08 01:03:34 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: add runtime pm support for usb port device This patch is to add runtime pm callback for usb port device. Set/clear PORT_POWER feature in the resume/suspend callback. Add portnum for struct usb_port to record port number. Do pm_rumtime_get_sync/put(portdev) when a device is plugged/unplugged to prevent it from being powered off when it is active. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:29 +08:00
usb: check usb_hub_to_struct_hub() return value usb_hub_to_struct_hub() can return NULL in some unlikely cases. Add checks where appropriate, or pass the hub pointer as an additional argument if it's known to be valid. The places it makes sense to check usb_hub_to_struct_hub() are picked based on feedback from Alan Stern. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-18 17:28:48 +03:00
usb: add runtime pm support for usb port device This patch is to add runtime pm callback for usb port device. Set/clear PORT_POWER feature in the resume/suspend callback. Add portnum for struct usb_port to record port number. Do pm_rumtime_get_sync/put(portdev) when a device is plugged/unplugged to prevent it from being powered off when it is active. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:29 +08:00
usb: fix some scripts/kernel-doc warnings When building the htmldocs (in verbose mode), scripts/kernel-doc reports the following type of warnings: Warning(drivers/usb/core/usb.c:76): No description found for return value of 'usb_find_alt_setting' Fix them by: - adding some missing descriptions of return values - using "Return" sections for those descriptions Signed-off-by: Yacine Belkadi <yacine.belkadi.1@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-02 20:10:04 +02:00
usb: add runtime pm support for usb port device This patch is to add runtime pm callback for usb port device. Set/clear PORT_POWER feature in the resume/suspend callback. Add portnum for struct usb_port to record port number. Do pm_rumtime_get_sync/put(portdev) when a device is plugged/unplugged to prevent it from being powered off when it is active. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:29 +08:00
usb: check usb_hub_to_struct_hub() return value usb_hub_to_struct_hub() can return NULL in some unlikely cases. Add checks where appropriate, or pass the hub pointer as an additional argument if it's known to be valid. The places it makes sense to check usb_hub_to_struct_hub() are picked based on feedback from Alan Stern. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-18 17:28:48 +03:00
usb: add runtime pm support for usb port device This patch is to add runtime pm callback for usb port device. Set/clear PORT_POWER feature in the resume/suspend callback. Add portnum for struct usb_port to record port number. Do pm_rumtime_get_sync/put(portdev) when a device is plugged/unplugged to prevent it from being powered off when it is active. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:29 +08:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
usb: make usb_port flags atomic, rename did_runtime_put to child_usage We want to manipulate ->did_runtime_put in usb_port_runtime_resume(), but we don't want that to collide with other updates. Move usb_port flags to new port-bitmap fields in usb_hub. "did_runtime_put" is renamed "child_usage_bits" to reflect that it is strictly standing in for the fact that usb_devices are not the device_model children of their parent port. Signed-off-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:52 -07:00
usb: add runtime pm support for usb port device This patch is to add runtime pm callback for usb port device. Set/clear PORT_POWER feature in the resume/suspend callback. Add portnum for struct usb_port to record port number. Do pm_rumtime_get_sync/put(portdev) when a device is plugged/unplugged to prevent it from being powered off when it is active. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:29 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: fix the clear_tt_buffer interface This patch (as1255) updates the interface for calling usb_hub_clear_tt_buffer(). Even the name of the function is changed! When an async URB (i.e., Control or Bulk) going through a high-speed hub to a non-high-speed device is cancelled or fails, the hub's Transaction Translator buffer may be left busy still trying to complete the transaction. The buffer has to be cleared; that's what usb_hub_clear_tt_buffer() does. It isn't safe to send any more URBs to the same endpoint until the TT buffer is fully clear. Therefore the HCD needs to be told when the Clear-TT-Buffer request has finished. This patch adds a callback method to struct hc_driver for that purpose, and makes the hub driver invoke the callback at the proper time. The patch also changes a couple of names; "hub_tt_kevent" and "tt.kevent" now look rather antiquated. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:43:32 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: fix some scripts/kernel-doc warnings When building the htmldocs (in verbose mode), scripts/kernel-doc reports the following type of warnings: Warning(drivers/usb/core/usb.c:76): No description found for return value of 'usb_find_alt_setting' Fix them by: - adding some missing descriptions of return values - using "Return" sections for those descriptions Signed-off-by: Yacine Belkadi <yacine.belkadi.1@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-02 20:10:04 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: fix the clear_tt_buffer interface This patch (as1255) updates the interface for calling usb_hub_clear_tt_buffer(). Even the name of the function is changed! When an async URB (i.e., Control or Bulk) going through a high-speed hub to a non-high-speed device is cancelled or fails, the hub's Transaction Translator buffer may be left busy still trying to complete the transaction. The buffer has to be cleared; that's what usb_hub_clear_tt_buffer() does. It isn't safe to send any more URBs to the same endpoint until the TT buffer is fully clear. Therefore the HCD needs to be told when the Clear-TT-Buffer request has finished. This patch adds a callback method to struct hc_driver for that purpose, and makes the hub driver invoke the callback at the proper time. The patch also changes a couple of names; "hub_tt_kevent" and "tt.kevent" now look rather antiquated. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:43:32 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: fix the clear_tt_buffer interface This patch (as1255) updates the interface for calling usb_hub_clear_tt_buffer(). Even the name of the function is changed! When an async URB (i.e., Control or Bulk) going through a high-speed hub to a non-high-speed device is cancelled or fails, the hub's Transaction Translator buffer may be left busy still trying to complete the transaction. The buffer has to be cleared; that's what usb_hub_clear_tt_buffer() does. It isn't safe to send any more URBs to the same endpoint until the TT buffer is fully clear. Therefore the HCD needs to be told when the Clear-TT-Buffer request has finished. This patch adds a callback method to struct hc_driver for that purpose, and makes the hub driver invoke the callback at the proper time. The patch also changes a couple of names; "hub_tt_kevent" and "tt.kevent" now look rather antiquated. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:43:32 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: hub.c: move assignment out of if () block We should not be doing assignments within an if () block so fix up the code to not do this. change was created using Coccinelle. Acked-by: Alan Stern <stern@rowland.harvard.edu> CC: Dan Williams <dan.j.williams@intel.com> CC: Petr Mladek <pmladek@suse.cz> CC: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Felipe Balbi <balbi@ti.com>
2015-04-30 11:32:53 +02:00
usb: core: hub.c: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-08 01:03:34 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: fix the clear_tt_buffer interface This patch (as1255) updates the interface for calling usb_hub_clear_tt_buffer(). Even the name of the function is changed! When an async URB (i.e., Control or Bulk) going through a high-speed hub to a non-high-speed device is cancelled or fails, the hub's Transaction Translator buffer may be left busy still trying to complete the transaction. The buffer has to be cleared; that's what usb_hub_clear_tt_buffer() does. It isn't safe to send any more URBs to the same endpoint until the TT buffer is fully clear. Therefore the HCD needs to be told when the Clear-TT-Buffer request has finished. This patch adds a callback method to struct hc_driver for that purpose, and makes the hub driver invoke the callback at the proper time. The patch also changes a couple of names; "hub_tt_kevent" and "tt.kevent" now look rather antiquated. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:43:32 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: Add devaddr in struct usb_device The Clear_TT_Buffer request sent to the hub includes the address of the LS/FS child device in wValue field. usb_hub_clear_tt_buffer() uses udev->devnum to set the address wValue. This won't work for devices connected to xHC. For other host controllers udev->devnum is the same as the address of the usb device, chosen and set by usb core. With xHC the controller hardware assigns the address, and won't be the same as devnum. Here we add devaddr in "struct usb_device" for usb_hub_clear_tt_buffer() to use. Signed-off-by: Jim Lin <jilin@nvidia.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-03 18:53:43 +08:00
usb: core: hub.c: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-08 01:03:34 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: hub.c: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-08 01:03:34 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: fix the clear_tt_buffer interface This patch (as1255) updates the interface for calling usb_hub_clear_tt_buffer(). Even the name of the function is changed! When an async URB (i.e., Control or Bulk) going through a high-speed hub to a non-high-speed device is cancelled or fails, the hub's Transaction Translator buffer may be left busy still trying to complete the transaction. The buffer has to be cleared; that's what usb_hub_clear_tt_buffer() does. It isn't safe to send any more URBs to the same endpoint until the TT buffer is fully clear. Therefore the HCD needs to be told when the Clear-TT-Buffer request has finished. This patch adds a callback method to struct hc_driver for that purpose, and makes the hub driver invoke the callback at the proper time. The patch also changes a couple of names; "hub_tt_kevent" and "tt.kevent" now look rather antiquated. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:43:32 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: hub.c: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-08 01:03:34 -07:00
USB: fix the clear_tt_buffer interface This patch (as1255) updates the interface for calling usb_hub_clear_tt_buffer(). Even the name of the function is changed! When an async URB (i.e., Control or Bulk) going through a high-speed hub to a non-high-speed device is cancelled or fails, the hub's Transaction Translator buffer may be left busy still trying to complete the transaction. The buffer has to be cleared; that's what usb_hub_clear_tt_buffer() does. It isn't safe to send any more URBs to the same endpoint until the TT buffer is fully clear. Therefore the HCD needs to be told when the Clear-TT-Buffer request has finished. This patch adds a callback method to struct hc_driver for that purpose, and makes the hub driver invoke the callback at the proper time. The patch also changes a couple of names; "hub_tt_kevent" and "tt.kevent" now look rather antiquated. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:43:32 -04:00
usb: core: hub.c: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-08 01:03:34 -07:00
USB: fix the clear_tt_buffer interface This patch (as1255) updates the interface for calling usb_hub_clear_tt_buffer(). Even the name of the function is changed! When an async URB (i.e., Control or Bulk) going through a high-speed hub to a non-high-speed device is cancelled or fails, the hub's Transaction Translator buffer may be left busy still trying to complete the transaction. The buffer has to be cleared; that's what usb_hub_clear_tt_buffer() does. It isn't safe to send any more URBs to the same endpoint until the TT buffer is fully clear. Therefore the HCD needs to be told when the Clear-TT-Buffer request has finished. This patch adds a callback method to struct hc_driver for that purpose, and makes the hub driver invoke the callback at the proper time. The patch also changes a couple of names; "hub_tt_kevent" and "tt.kevent" now look rather antiquated. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:43:32 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: fix the clear_tt_buffer interface This patch (as1255) updates the interface for calling usb_hub_clear_tt_buffer(). Even the name of the function is changed! When an async URB (i.e., Control or Bulk) going through a high-speed hub to a non-high-speed device is cancelled or fails, the hub's Transaction Translator buffer may be left busy still trying to complete the transaction. The buffer has to be cleared; that's what usb_hub_clear_tt_buffer() does. It isn't safe to send any more URBs to the same endpoint until the TT buffer is fully clear. Therefore the HCD needs to be told when the Clear-TT-Buffer request has finished. This patch adds a callback method to struct hc_driver for that purpose, and makes the hub driver invoke the callback at the proper time. The patch also changes a couple of names; "hub_tt_kevent" and "tt.kevent" now look rather antiquated. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:43:32 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: block suspension of superspeed port while hispeed peer is active ClearPortFeature(PORT_POWER) on a usb3 port places the port in either a DSPORT.Powered-off-detect / DSPORT.Powered-off-reset loop, or the DSPORT.Powered-off state. There is no way to ensure that RX terminations will persist in this state, so it is possible a device will degrade to its usb2 connection. Prevent this by blocking power-off of a usb3 port while its usb2 peer is active, and powering on a usb3 port before its usb2 peer. By default the latency between peer power-on events is 0. In order for the device to not see usb2 active while usb3 is still powering up inject the hub recommended power_on_good delay. In support of satisfying the power_on_good delay outside of hub_power_on() refactor the places where the delay is consumed to call a new hub_power_on_good_delay() helper. Finally, because this introduces several new checks for whether a port is_superspeed, cache that disctinction at port creation so that we don't need to keep looking up the parent hub device. Acked-by: Alan Stern <stern@rowland.harvard.edu> [alan]: add a 'superspeed' flag to the port Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:57 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] USB: usbcore: always turn on hub port power Some hubs claim not to support port-power switching, and right now the hub driver believes them and does not enable power to their ports. However it turns out that even though they don't actually switch power, they do ignore all events on a port until told to turn on the power! This problem has been reported by several users. This revised patch (as672b) makes the hub driver always try to turn on port power to all hubs, regardless of what the hub descriptor says. It also adds a comment explaining the need for this. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-04-27 15:54:22 -04:00
usb: disable port power control if not supported in wHubCharacteristics A hub indicates whether it supports per-port power control via the wHubCharacteristics field in its descriptor. If it is not supported a hub will still emulate ClearPortPower(PORT_POWER) requests by stopping the link state machine. However, since this does not save power do not bother suspending. This also consolidates support checks into a hub_is_port_power_switchable() helper. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:12 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] USB: usbcore: always turn on hub port power Some hubs claim not to support port-power switching, and right now the hub driver believes them and does not enable power to their ports. However it turns out that even though they don't actually switch power, they do ignore all events on a port until told to turn on the power! This problem has been reported by several users. This revised patch (as672b) makes the hub driver always try to turn on port power to all hubs, regardless of what the hub descriptor says. It also adds a comment explaining the need for this. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-04-27 15:54:22 -04:00
usb: don't use bNbrPorts after initialization After successful initialization hub->descriptor->bNbrPorts and hub->hdev->maxchild are equal, but using hub->hdev->maxchild is preferred because that value is explicitly used for initialization of hub->ports[]. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-22 14:49:40 +02:00
usb: make usb_port flags atomic, rename did_runtime_put to child_usage We want to manipulate ->did_runtime_put in usb_port_runtime_resume(), but we don't want that to collide with other updates. Move usb_port flags to new port-bitmap fields in usb_hub. "did_runtime_put" is renamed "child_usage_bits" to reflect that it is strictly standing in for the fact that usb_devices are not the device_model children of their parent port. Signed-off-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:52 -07:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
USB: change hub initialization sleeps to delayed_work This patch (as1137) changes the hub_activate() routine, replacing the power-power-up and debounce delays with delayed_work calls. The idea is that on systems where the USB stack is compiled into the kernel rather than built as modules, these delays will no longer block the boot thread. At least 100 ms is saved for each root hub, which can add up to a significant savings in total boot time. Arjan van de Ven was very pleased to see that this shaved 700 ms off his computer's boot time. Since his total boot time is on the order of two seconds, the improvement is considerable. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-22 14:44:26 -04:00
usb: block suspension of superspeed port while hispeed peer is active ClearPortFeature(PORT_POWER) on a usb3 port places the port in either a DSPORT.Powered-off-detect / DSPORT.Powered-off-reset loop, or the DSPORT.Powered-off state. There is no way to ensure that RX terminations will persist in this state, so it is possible a device will degrade to its usb2 connection. Prevent this by blocking power-off of a usb3 port while its usb2 peer is active, and powering on a usb3 port before its usb2 peer. By default the latency between peer power-on events is 0. In order for the device to not see usb2 active while usb3 is still powering up inject the hub recommended power_on_good delay. In support of satisfying the power_on_good delay outside of hub_power_on() refactor the places where the delay is consumed to call a new hub_power_on_good_delay() helper. Finally, because this introduces several new checks for whether a port is_superspeed, cache that disctinction at port creation so that we don't need to keep looking up the parent hub device. Acked-by: Alan Stern <stern@rowland.harvard.edu> [alan]: add a 'superspeed' flag to the port Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:57 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: fix concurrent buffer access in the hub driver This patch (as849) fixes a bug in the USB hub driver. A single pre-allocated buffer is used for all port status reads, but nothing guarantees exclusive use of the buffer. A mutex is added to provide this guarantee. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-02-05 09:56:15 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: avoid error messages when a device is disconnected This patch (as1673) reduces the amount of log spew from the hub driver by removing a bunch of error messages in the case where the device in question is already known to have been disconnected. Since the disconnect event itself appears in the log, there's no need for other error messages. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Jenya Y <jy.gerstmaier@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-27 16:14:01 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
drivers: usb: core: {file,hub,sysfs,usb}.c: Whitespace fixes including: - removing of trailing whitespace - removing spaces before array indexing (foo [] to foo[]) - reindention of a switch-case block - spaces to tabs Signed-off-by: Matthias Beyer <mail@beyermatthias.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-10 23:41:27 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: fix concurrent buffer access in the hub driver This patch (as849) fixes a bug in the USB hub driver. A single pre-allocated buffer is used for all port status reads, but nothing guarantees exclusive use of the buffer. A mutex is added to provide this guarantee. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-02-05 09:56:15 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: Allow USB 3.0 ports to be disabled. If hot and warm reset fails, or a port remains in the Compliance Mode, the USB core needs to be able to disable a USB 3.0 port. Unlike USB 2.0 ports, once the port is placed into the Disabled link state, it will not report any new device connects. To get device connect notifications, we need to put the link into the Disabled state, and then the RxDetect state. The xHCI driver needs to atomically clear all change bits on USB 3.0 port disable, so that we get Port Status Change Events for future port changes. We could technically do this in the USB core instead of in the xHCI roothub code, since the port state machine can't advance out of the disabled state until we set the link state to RxDetect. However, external USB 3.0 hubs don't need this code. They are level-triggered, not edge-triggered like xHCI, so they will continue to send interrupt events when any change bit is set. Therefore it doesn't make sense to put this code in the USB core. This patch is part of a series to fix several reports of infinite loops on device enumeration failure. This includes John, when he boots with a USB 3.0 device (Roseweil eusb3 enclosure) attached to his NEC 0.96 host controller. The fix requires warm reset support, so it does not make sense to backport this patch to stable kernels without warm reset support. This patch should be backported to kernels as old as 3.2, contain the commit ID 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm reset logic" Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: John Covici <covici@ccs.covici.com> Cc: stable@vger.kernel.org
2012-11-14 16:42:32 -08:00
USB: add USB-Persist facility This patch (as886) adds the controversial USB-persist facility, allowing USB devices to persist across a power loss during system suspend. The facility is controlled by a new Kconfig option (with appropriate warnings about the potential dangers); when the option is off the behavior will remain the same as it is now. But when the option is on, people will be able to use suspend-to-disk and keep their USB filesystems intact -- something particularly valuable for small machines where the root filesystem is on a USB device! Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-04 11:52:20 -04:00
usb: core: hub.c Remove one to many n's in a word. The Patch below removes one to many "n's" in a word.. Signed-off-by: Justin P. Mattock <justinmattock@gmail.com> CC: Alan Stern <stern@rowland.harvard.edu> CC: linux-usb@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-26 20:33:56 -08:00
usb: hub: rename khubd to hub_wq in documentation and comments USB hub has started to use a workqueue instead of kthread. Let's update the documentation and comments here and there. This patch mostly just replaces "khubd" with "hub_wq". There are only few exceptions where the whole sentence was updated. These more complicated changes can be found in the following files: Documentation/usb/hotplug.txt drivers/net/usb/usbnet.c drivers/usb/core/hcd.c drivers/usb/host/ohci-hcd.c drivers/usb/host/xhci.c Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:23 +02:00
USB: add USB-Persist facility This patch (as886) adds the controversial USB-persist facility, allowing USB devices to persist across a power loss during system suspend. The facility is controlled by a new Kconfig option (with appropriate warnings about the potential dangers); when the option is off the behavior will remain the same as it is now. But when the option is on, people will be able to use suspend-to-disk and keep their USB filesystems intact -- something particularly valuable for small machines where the root filesystem is on a USB device! Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-04 11:52:20 -04:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
USB: add USB-Persist facility This patch (as886) adds the controversial USB-persist facility, allowing USB devices to persist across a power loss during system suspend. The facility is controlled by a new Kconfig option (with appropriate warnings about the potential dangers); when the option is off the behavior will remain the same as it is now. But when the option is on, people will be able to use suspend-to-disk and keep their USB filesystems intact -- something particularly valuable for small machines where the root filesystem is on a USB device! Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-04 11:52:20 -04:00
usb: hub: rename khubd to hub_wq in documentation and comments USB hub has started to use a workqueue instead of kthread. Let's update the documentation and comments here and there. This patch mostly just replaces "khubd" with "hub_wq". There are only few exceptions where the whole sentence was updated. These more complicated changes can be found in the following files: Documentation/usb/hotplug.txt drivers/net/usb/usbnet.c drivers/usb/core/hcd.c drivers/usb/host/ohci-hcd.c drivers/usb/host/xhci.c Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:23 +02:00
USB: add USB-Persist facility This patch (as886) adds the controversial USB-persist facility, allowing USB devices to persist across a power loss during system suspend. The facility is controlled by a new Kconfig option (with appropriate warnings about the potential dangers); when the option is off the behavior will remain the same as it is now. But when the option is on, people will be able to use suspend-to-disk and keep their USB filesystems intact -- something particularly valuable for small machines where the root filesystem is on a USB device! Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-04 11:52:20 -04:00
usb: hub: convert khubd into workqueue There is no need to have separate kthread for handling USB hub events. It is more elegant to use the workqueue framework. The workqueue is allocated as freezable because the original thread was freezable as well. Also it is allocated as ordered because the code is not ready for parallel processing of hub events, see choose_devnum(). struct usb_hub is passed via the work item. Therefore we do not need hub_event_list. Also hub_thread() is not longer needed. It would call only hub_event(). The rest of the code did manipulate the kthread and it is handled by the workqueue framework now. kick_khubd is renamed to kick_hub_wq() to make the function clear. And the protection against races is done another way, see below. hub_event_lock has been removed. It cannot longer be used to protect struct usb_hub between hub_event() and hub_disconnect(). Instead we need to get hub->kref already in kick_hub_wq(). The lock is not really needed for the other scenarios as well. queue_work() returns whether it succeeded. We could revert the needed operations accordingly. This is enough to avoid duplicity and inconsistencies. Yes, the removed lock causes that there is not longer such a strong synchronization between scheduling the work and manipulating hub->disconnected. But kick_hub_wq() must never be called together with hub_disconnect() otherwise even the original code would have failed. Any callers are responsible for this. Therefore the only problem is that hub_disconnect() could be called in parallel with hub_event(). But this was possible even in the past. struct usb_hub is still guarded by hub->kref and released in hub_events() when needed. Note that the source file is still full of the obsolete "khubd" strings. Let's remove them in a follow up patch. This patch already is complex enough. Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to allocate the workqueue. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:21 +02:00
USB: add USB-Persist facility This patch (as886) adds the controversial USB-persist facility, allowing USB devices to persist across a power loss during system suspend. The facility is controlled by a new Kconfig option (with appropriate warnings about the potential dangers); when the option is off the behavior will remain the same as it is now. But when the option is on, people will be able to use suspend-to-disk and keep their USB filesystems intact -- something particularly valuable for small machines where the root filesystem is on a USB device! Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-04 11:52:20 -04:00
USB: add a "remove hardware" sysfs attribute This patch (as1297) adds a "remove" attribute to each USB device's directory in sysfs. Writing to this attribute causes the device to be deconfigured (the same as writing 0 to the "bConfigurationValue" attribute) and then tells the hub driver to disable the device's upstream port. The device remains locked during these activities so there is no possibility of it getting reconfigured in between. The port will remain disabled until after the device is unplugged. The purpose of this is to provide a means for user programs to imitate the "Safely remove hardware" applet in Windows. Some devices do expect their ports to be disabled before they are unplugged, and they provide visual feedback to users indicating when they can safely be unplugged. The security implications are minimal. Writing to the "remove" attribute is no more dangerous than writing to the "bConfigurationValue" attribute. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: David Zeuthen <davidz@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 15:20:13 -04:00
usb: hub: rename khubd to hub_wq in documentation and comments USB hub has started to use a workqueue instead of kthread. Let's update the documentation and comments here and there. This patch mostly just replaces "khubd" with "hub_wq". There are only few exceptions where the whole sentence was updated. These more complicated changes can be found in the following files: Documentation/usb/hotplug.txt drivers/net/usb/usbnet.c drivers/usb/core/hcd.c drivers/usb/host/ohci-hcd.c drivers/usb/host/xhci.c Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:23 +02:00
USB: add a "remove hardware" sysfs attribute This patch (as1297) adds a "remove" attribute to each USB device's directory in sysfs. Writing to this attribute causes the device to be deconfigured (the same as writing 0 to the "bConfigurationValue" attribute) and then tells the hub driver to disable the device's upstream port. The device remains locked during these activities so there is no possibility of it getting reconfigured in between. The port will remain disabled until after the device is unplugged. The purpose of this is to provide a means for user programs to imitate the "Safely remove hardware" applet in Windows. Some devices do expect their ports to be disabled before they are unplugged, and they provide visual feedback to users indicating when they can safely be unplugged. The security implications are minimal. Writing to the "remove" attribute is no more dangerous than writing to the "bConfigurationValue" attribute. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: David Zeuthen <davidz@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 15:20:13 -04:00
usb: fix some scripts/kernel-doc warnings When building the htmldocs (in verbose mode), scripts/kernel-doc reports the following type of warnings: Warning(drivers/usb/core/usb.c:76): No description found for return value of 'usb_find_alt_setting' Fix them by: - adding some missing descriptions of return values - using "Return" sections for those descriptions Signed-off-by: Yacine Belkadi <yacine.belkadi.1@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-02 20:10:04 +02:00
USB: add a "remove hardware" sysfs attribute This patch (as1297) adds a "remove" attribute to each USB device's directory in sysfs. Writing to this attribute causes the device to be deconfigured (the same as writing 0 to the "bConfigurationValue" attribute) and then tells the hub driver to disable the device's upstream port. The device remains locked during these activities so there is no possibility of it getting reconfigured in between. The port will remain disabled until after the device is unplugged. The purpose of this is to provide a means for user programs to imitate the "Safely remove hardware" applet in Windows. Some devices do expect their ports to be disabled before they are unplugged, and they provide visual feedback to users indicating when they can safely be unplugged. The security implications are minimal. Writing to the "remove" attribute is no more dangerous than writing to the "bConfigurationValue" attribute. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: David Zeuthen <davidz@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 15:20:13 -04:00
usb: core: hub: do error out if usb_autopm_get_interface() fails Reviewing a fresh portion of coverity defects in USB core (specifically CID 1458999), Alan Stern noted below in [1]: On Tue, Feb 25, 2020 at 02:39:23PM -0500, Alan Stern wrote: > A revised search finds line 997 in drivers/usb/core/hub.c and lines > 216, 269 in drivers/usb/core/port.c. (I didn't try looking in any > other directories.) AFAICT all three of these should check the > return value, although a error message in the kernel log probably > isn't needed. Factor out the usb_remove_device() change into a standalone patch to allow conflict-free integration on top of the earliest stable branches. [1] https://lore.kernel.org/lkml/Pine.LNX.4.44L0.2002251419120.1485-100000@iolanthe.rowland.org Fixes: 253e05724f9230 ("USB: add a "remove hardware" sysfs attribute") Cc: stable@vger.kernel.org # v2.6.33+ Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200226175036.14946-2-erosca@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-26 18:50:35 +01:00
USB: add a "remove hardware" sysfs attribute This patch (as1297) adds a "remove" attribute to each USB device's directory in sysfs. Writing to this attribute causes the device to be deconfigured (the same as writing 0 to the "bConfigurationValue" attribute) and then tells the hub driver to disable the device's upstream port. The device remains locked during these activities so there is no possibility of it getting reconfigured in between. The port will remain disabled until after the device is unplugged. The purpose of this is to provide a means for user programs to imitate the "Safely remove hardware" applet in Windows. Some devices do expect their ports to be disabled before they are unplugged, and they provide visual feedback to users indicating when they can safely be unplugged. The security implications are minimal. Writing to the "remove" attribute is no more dangerous than writing to the "bConfigurationValue" attribute. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: David Zeuthen <davidz@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 15:20:13 -04:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
USB: add a "remove hardware" sysfs attribute This patch (as1297) adds a "remove" attribute to each USB device's directory in sysfs. Writing to this attribute causes the device to be deconfigured (the same as writing 0 to the "bConfigurationValue" attribute) and then tells the hub driver to disable the device's upstream port. The device remains locked during these activities so there is no possibility of it getting reconfigured in between. The port will remain disabled until after the device is unplugged. The purpose of this is to provide a means for user programs to imitate the "Safely remove hardware" applet in Windows. Some devices do expect their ports to be disabled before they are unplugged, and they provide visual feedback to users indicating when they can safely be unplugged. The security implications are minimal. Writing to the "remove" attribute is no more dangerous than writing to the "bConfigurationValue" attribute. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: David Zeuthen <davidz@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 15:20:13 -04:00
usb: core: hub: do error out if usb_autopm_get_interface() fails Reviewing a fresh portion of coverity defects in USB core (specifically CID 1458999), Alan Stern noted below in [1]: On Tue, Feb 25, 2020 at 02:39:23PM -0500, Alan Stern wrote: > A revised search finds line 997 in drivers/usb/core/hub.c and lines > 216, 269 in drivers/usb/core/port.c. (I didn't try looking in any > other directories.) AFAICT all three of these should check the > return value, although a error message in the kernel log probably > isn't needed. Factor out the usb_remove_device() change into a standalone patch to allow conflict-free integration on top of the earliest stable branches. [1] https://lore.kernel.org/lkml/Pine.LNX.4.44L0.2002251419120.1485-100000@iolanthe.rowland.org Fixes: 253e05724f9230 ("USB: add a "remove hardware" sysfs attribute") Cc: stable@vger.kernel.org # v2.6.33+ Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200226175036.14946-2-erosca@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-26 18:50:35 +01:00
USB: add a "remove hardware" sysfs attribute This patch (as1297) adds a "remove" attribute to each USB device's directory in sysfs. Writing to this attribute causes the device to be deconfigured (the same as writing 0 to the "bConfigurationValue" attribute) and then tells the hub driver to disable the device's upstream port. The device remains locked during these activities so there is no possibility of it getting reconfigured in between. The port will remain disabled until after the device is unplugged. The purpose of this is to provide a means for user programs to imitate the "Safely remove hardware" applet in Windows. Some devices do expect their ports to be disabled before they are unplugged, and they provide visual feedback to users indicating when they can safely be unplugged. The security implications are minimal. Writing to the "remove" attribute is no more dangerous than writing to the "bConfigurationValue" attribute. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: David Zeuthen <davidz@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 15:20:13 -04:00
USB: simplify hub_restart() logic This patch (as1081) straightens out the logic of the hub_restart() routine. Each port of the hub is scanned and the driver makes sure that ports which are supposed to be disabled really _are_ disabled. Any ports with a significant change in status are flagged in hub->change_bits, so that khubd can focus on them without the need to scan all the ports a second time -- which means the hub->activating flag is no longer needed. Also, it is now recognized explicitly that the only reason for resuming a port which was not suspended is to carry out a reset-resume operation, which happens only in a non-CONFIG_USB_SUSPEND setting. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:42 -04:00
USB: prepare for changover to Runtime PM framework This patch (as1303) revises the USB Power Management infrastructure to make it compatible with the new driver-model Runtime PM framework: Drivers are no longer allowed to access intf->pm_usage_cnt directly; the PM framework manages its own usage counters. usb_autopm_set_interface() is eliminated, because it directly sets intf->pm_usage_cnt. usb_autopm_enable() and usb_autopm_disable() are eliminated, because they call usb_autopm_set_interface(). usb_autopm_get_interface_no_resume() and usb_autopm_put_interface_no_suspend() are added. They correspond to pm_runtime_get_noresume() and pm_runtime_put_noidle() in the PM framework. The power/level attribute no longer accepts "suspend", only "on" and "auto". The PM framework doesn't allow devices to be forced into a suspended mode. The hub driver contains the only code that violates the new guidelines. It is updated to use the new interface routines instead. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-07 13:01:37 -05:00
USB: change hub initialization sleeps to delayed_work This patch (as1137) changes the hub_activate() routine, replacing the power-power-up and debounce delays with delayed_work calls. The idea is that on systems where the USB stack is compiled into the kernel rather than built as modules, these delays will no longer block the boot thread. At least 100 ms is saved for each root hub, which can add up to a significant savings in total boot time. Arjan van de Ven was very pleased to see that this shaved 700 ms off his computer's boot time. Since his total boot time is on the order of two seconds, the improvement is considerable. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-22 14:44:26 -04:00
USB: simplify hub_restart() logic This patch (as1081) straightens out the logic of the hub_restart() routine. Each port of the hub is scanned and the driver makes sure that ports which are supposed to be disabled really _are_ disabled. Any ports with a significant change in status are flagged in hub->change_bits, so that khubd can focus on them without the need to scan all the ports a second time -- which means the hub->activating flag is no longer needed. Also, it is now recognized explicitly that the only reason for resuming a port which was not suspended is to carry out a reset-resume operation, which happens only in a non-CONFIG_USB_SUSPEND setting. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:42 -04:00
USB: make USB-PERSIST work after every system sleep This patch (as1046) makes USB-PERSIST work more in accordance with the documentation. Currently it takes effect only in cases where the root hub has lost power or been reset, but it is supposed to operate whenever a power session was dropped during a system sleep. A new hub_restart() routine carries out the duties required during a reset or a reset-resume. It checks to see whether occupied ports are still enabled, and if they aren't then it clears the enable-change and connect-change features (to prevent interference by khubd) and sets the child device's reset_resume flag. It also checks ports that are supposed to be unoccupied to verify that the firmware hasn't left the port in an enabled state. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-03 15:15:51 -05:00
USB: change hub initialization sleeps to delayed_work This patch (as1137) changes the hub_activate() routine, replacing the power-power-up and debounce delays with delayed_work calls. The idea is that on systems where the USB stack is compiled into the kernel rather than built as modules, these delays will no longer block the boot thread. At least 100 ms is saved for each root hub, which can add up to a significant savings in total boot time. Arjan van de Ven was very pleased to see that this shaved 700 ms off his computer's boot time. Since his total boot time is on the order of two seconds, the improvement is considerable. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-22 14:44:26 -04:00
USB: combine hub_activate and hub_restart This patch (as1071) combines hub_activate() and hub_restart() into a single routine. There's no point keeping them separate, since they are always called together. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:17 -04:00
USB: make USB-PERSIST work after every system sleep This patch (as1046) makes USB-PERSIST work more in accordance with the documentation. Currently it takes effect only in cases where the root hub has lost power or been reset, but it is supposed to operate whenever a power session was dropped during a system sleep. A new hub_restart() routine carries out the duties required during a reset or a reset-resume. It checks to see whether occupied ports are still enabled, and if they aren't then it clears the enable-change and connect-change features (to prevent interference by khubd) and sets the child device's reset_resume flag. It also checks ports that are supposed to be unoccupied to verify that the firmware hasn't left the port in an enabled state. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-03 15:15:51 -05:00
usb: Realloc xHCI structures after a hub is verified. When there's an xHCI host power loss after a suspend from memory, the USB core attempts to reset and verify the USB devices that are attached to the system. The xHCI driver has to reallocate those devices, since the hardware lost all knowledge of them during the power loss. When a hub is plugged in, and the host loses power, the xHCI hardware structures are not updated to say the device is a hub. This is usually done in hub_configure() when the USB hub is detected. That function is skipped during a reset and verify by the USB core, since the core restores the old configuration and alternate settings, and the hub driver has no idea this happened. This bug makes the xHCI host controller reject the enumeration of low speed devices under the resumed hub. Therefore, make the USB core re-setup the internal xHCI hub device information by calling update_hub_device() when hub_activate() is called for a hub reset resume. After a host power loss, all devices under the roothub get a reset-resume or a disconnect. This patch should be queued for the 2.6.37 stable tree. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@kernel.org
2010-12-23 11:12:42 -08:00
USB: make USB-PERSIST work after every system sleep This patch (as1046) makes USB-PERSIST work more in accordance with the documentation. Currently it takes effect only in cases where the root hub has lost power or been reset, but it is supposed to operate whenever a power session was dropped during a system sleep. A new hub_restart() routine carries out the duties required during a reset or a reset-resume. It checks to see whether occupied ports are still enabled, and if they aren't then it clears the enable-change and connect-change features (to prevent interference by khubd) and sets the child device's reset_resume flag. It also checks ports that are supposed to be unoccupied to verify that the firmware hasn't left the port in an enabled state. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-03 15:15:51 -05:00
USB: combine hub_activate and hub_restart This patch (as1071) combines hub_activate() and hub_restart() into a single routine. There's no point keeping them separate, since they are always called together. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:17 -04:00
USB: optimize port debouncing during hub activation This patch (as1082) makes a small optimization to the way the hub driver carries out port debouncing immediately after a hub is activated (i.e., initialized, reset, or resumed). If any port-change statuses are observed, the code will delay for a minimal debounce period -- thereby making a good start at debouncing all the ports at once. If this wasn't sufficient then khubd will debounce any port that still requires attention. But in most cases it should suffice; it's rare for a device to need more than a minimal debounce delay. (In the cases of hub initialization or reset even that is most likely not needed, since any devices plugged in at such times have probably been attached for a while.) Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:07 -04:00
USB: change hub initialization sleeps to delayed_work This patch (as1137) changes the hub_activate() routine, replacing the power-power-up and debounce delays with delayed_work calls. The idea is that on systems where the USB stack is compiled into the kernel rather than built as modules, these delays will no longer block the boot thread. At least 100 ms is saved for each root hub, which can add up to a significant savings in total boot time. Arjan van de Ven was very pleased to see that this shaved 700 ms off his computer's boot time. Since his total boot time is on the order of two seconds, the improvement is considerable. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-22 14:44:26 -04:00
USB: fix invalid memory access in hub_activate() Commit 8520f38099cc ("USB: change hub initialization sleeps to delayed_work") changed the hub_activate() routine to make part of it run in a workqueue. However, the commit failed to take a reference to the usb_hub structure or to lock the hub interface while doing so. As a result, if a hub is plugged in and quickly unplugged before the work routine can run, the routine will try to access memory that has been deallocated. Or, if the hub is unplugged while the routine is running, the memory may be deallocated while it is in active use. This patch fixes the problem by taking a reference to the usb_hub at the start of hub_activate() and releasing it at the end (when the work is finished), and by locking the hub interface while the work routine is running. It also adds a check at the start of the routine to see if the hub has already been disconnected, in which nothing should be done. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Alexandru Cornea <alexandru.cornea@intel.com> Tested-by: Alexandru Cornea <alexandru.cornea@intel.com> Fixes: 8520f38099cc ("USB: change hub initialization sleeps to delayed_work") CC: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-16 13:32:38 -05:00
USB: hub: change the locking in hub_activate The locking in hub_activate() is not adequate to provide full mutual exclusion with hub_quiesce(). The subroutine locks the hub's usb_interface, but the callers of hub_quiesce() (such as hub_pre_reset() and hub_event()) hold the lock to the hub's usb_device. This patch changes hub_activate() to make it acquire the same lock as those other routines. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: <stable@vger.kernel.org> #4.4+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-08-05 11:51:30 -04:00
USB: fix invalid memory access in hub_activate() Commit 8520f38099cc ("USB: change hub initialization sleeps to delayed_work") changed the hub_activate() routine to make part of it run in a workqueue. However, the commit failed to take a reference to the usb_hub structure or to lock the hub interface while doing so. As a result, if a hub is plugged in and quickly unplugged before the work routine can run, the routine will try to access memory that has been deallocated. Or, if the hub is unplugged while the routine is running, the memory may be deallocated while it is in active use. This patch fixes the problem by taking a reference to the usb_hub at the start of hub_activate() and releasing it at the end (when the work is finished), and by locking the hub interface while the work routine is running. It also adds a check at the start of the routine to see if the hub has already been disconnected, in which nothing should be done. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Alexandru Cornea <alexandru.cornea@intel.com> Tested-by: Alexandru Cornea <alexandru.cornea@intel.com> Fixes: 8520f38099cc ("USB: change hub initialization sleeps to delayed_work") CC: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-16 13:32:38 -05:00
USB: hub: fix up early-exit pathway in hub_activate The early-exit pathway in hub_activate, added by commit e50293ef9775 ("USB: fix invalid memory access in hub_activate()") needs improvement. It duplicates code that is already present at the end of the subroutine, and it neglects to undo the effect of a usb_autopm_get_interface_no_resume() call. This patch fixes both problems by making the early-exit pathway jump directly to the end of the subroutine. It simplifies the code at the end by merging two conditionals that actually test the same condition although they appear different: If type < HUB_INIT3 then type must be either HUB_INIT2 or HUB_INIT, and it can't be HUB_INIT because in that case the subroutine would have exited earlier. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: <stable@vger.kernel.org> #4.4+ Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-08-05 11:49:45 -04:00
USB: fix invalid memory access in hub_activate() Commit 8520f38099cc ("USB: change hub initialization sleeps to delayed_work") changed the hub_activate() routine to make part of it run in a workqueue. However, the commit failed to take a reference to the usb_hub structure or to lock the hub interface while doing so. As a result, if a hub is plugged in and quickly unplugged before the work routine can run, the routine will try to access memory that has been deallocated. Or, if the hub is unplugged while the routine is running, the memory may be deallocated while it is in active use. This patch fixes the problem by taking a reference to the usb_hub at the start of hub_activate() and releasing it at the end (when the work is finished), and by locking the hub interface while the work routine is running. It also adds a check at the start of the routine to see if the hub has already been disconnected, in which nothing should be done. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Alexandru Cornea <alexandru.cornea@intel.com> Tested-by: Alexandru Cornea <alexandru.cornea@intel.com> Fixes: 8520f38099cc ("USB: change hub initialization sleeps to delayed_work") CC: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-16 13:32:38 -05:00
USB: change hub initialization sleeps to delayed_work This patch (as1137) changes the hub_activate() routine, replacing the power-power-up and debounce delays with delayed_work calls. The idea is that on systems where the USB stack is compiled into the kernel rather than built as modules, these delays will no longer block the boot thread. At least 100 ms is saved for each root hub, which can add up to a significant savings in total boot time. Arjan van de Ven was very pleased to see that this shaved 700 ms off his computer's boot time. Since his total boot time is on the order of two seconds, the improvement is considerable. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-22 14:44:26 -04:00
USB: fix invalid memory access in hub_activate() Commit 8520f38099cc ("USB: change hub initialization sleeps to delayed_work") changed the hub_activate() routine to make part of it run in a workqueue. However, the commit failed to take a reference to the usb_hub structure or to lock the hub interface while doing so. As a result, if a hub is plugged in and quickly unplugged before the work routine can run, the routine will try to access memory that has been deallocated. Or, if the hub is unplugged while the routine is running, the memory may be deallocated while it is in active use. This patch fixes the problem by taking a reference to the usb_hub at the start of hub_activate() and releasing it at the end (when the work is finished), and by locking the hub interface while the work routine is running. It also adds a check at the start of the routine to see if the hub has already been disconnected, in which nothing should be done. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Alexandru Cornea <alexandru.cornea@intel.com> Tested-by: Alexandru Cornea <alexandru.cornea@intel.com> Fixes: 8520f38099cc ("USB: change hub initialization sleeps to delayed_work") CC: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-16 13:32:38 -05:00
USB: core: Add hub_get() and hub_put() routines Create hub_get() and hub_put() routines to encapsulate the kref_get() and kref_put() calls in hub.c. The new routines will be used by the next patch in this series. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/604da420-ae8a-4a9e-91a4-2d511ff404fb@rowland.harvard.edu Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-15 13:04:50 -04:00
USB: make USB-PERSIST work after every system sleep This patch (as1046) makes USB-PERSIST work more in accordance with the documentation. Currently it takes effect only in cases where the root hub has lost power or been reset, but it is supposed to operate whenever a power session was dropped during a system sleep. A new hub_restart() routine carries out the duties required during a reset or a reset-resume. It checks to see whether occupied ports are still enabled, and if they aren't then it clears the enable-change and connect-change features (to prevent interference by khubd) and sets the child device's reset_resume flag. It also checks ports that are supposed to be unoccupied to verify that the firmware hasn't left the port in an enabled state. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-03 15:15:51 -05:00
USB: Set hub depth after USB3 hub reset The superspeed device attached to a USB 3.0 hub(such as VIA's) doesn't respond the address device command after resume. The root cause is the superspeed hub will miss the Hub Depth value that is used as an offset into the route string to locate the bits it uses to determine the downstream port number after reset, and all packets can't be routed to the device attached to the superspeed hub. Hub driver sends a Set Hub Depth request to the superspeed hub except for USB 3.0 root hub when the hub is initialized and doesn't send the request again after reset due to the resume process. So moving the code that sends the Set Hub Depth request to the superspeed hub from hub_configure() to hub_activate() is to cover those situations include initialization and reset. The patch should be backported to kernels as old as 2.6.39. Signed-off-by: Elric Fu <elricfu1@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable@vger.kernel.org
2012-02-18 13:32:27 +08:00
USB: combine hub_activate and hub_restart This patch (as1071) combines hub_activate() and hub_restart() into a single routine. There's no point keeping them separate, since they are always called together. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:17 -04:00
USB: change hub initialization sleeps to delayed_work This patch (as1137) changes the hub_activate() routine, replacing the power-power-up and debounce delays with delayed_work calls. The idea is that on systems where the USB stack is compiled into the kernel rather than built as modules, these delays will no longer block the boot thread. At least 100 ms is saved for each root hub, which can add up to a significant savings in total boot time. Arjan van de Ven was very pleased to see that this shaved 700 ms off his computer's boot time. Since his total boot time is on the order of two seconds, the improvement is considerable. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-22 14:44:26 -04:00
USB: Set hub depth after USB3 hub reset The superspeed device attached to a USB 3.0 hub(such as VIA's) doesn't respond the address device command after resume. The root cause is the superspeed hub will miss the Hub Depth value that is used as an offset into the route string to locate the bits it uses to determine the downstream port number after reset, and all packets can't be routed to the device attached to the superspeed hub. Hub driver sends a Set Hub Depth request to the superspeed hub except for USB 3.0 root hub when the hub is initialized and doesn't send the request again after reset due to the resume process. So moving the code that sends the Set Hub Depth request to the superspeed hub from hub_configure() to hub_activate() is to cover those situations include initialization and reset. The patch should be backported to kernels as old as 2.6.39. Signed-off-by: Elric Fu <elricfu1@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable@vger.kernel.org
2012-02-18 13:32:27 +08:00
Revert "USB: core: hub.c: use usb_control_msg_send() in a few places" This reverts commit d6a499249543356002a1efbb26254c7272e62f4c. Control messages are needed in contexts when memory allocations are restricted, such as handling device resets and runtime PM. For this reason the control message API internally uses GFP_NOIO. This is a band aid introduced because when we recognized the issue, the call chains were highly convoluted. Continuing this trend is not a good idea. So I am shooting the whole kennel here. Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20200923134348.23862-2-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-23 15:43:35 +02:00
USB: Set hub depth after USB3 hub reset The superspeed device attached to a USB 3.0 hub(such as VIA's) doesn't respond the address device command after resume. The root cause is the superspeed hub will miss the Hub Depth value that is used as an offset into the route string to locate the bits it uses to determine the downstream port number after reset, and all packets can't be routed to the device attached to the superspeed hub. Hub driver sends a Set Hub Depth request to the superspeed hub except for USB 3.0 root hub when the hub is initialized and doesn't send the request again after reset due to the resume process. So moving the code that sends the Set Hub Depth request to the superspeed hub from hub_configure() to hub_activate() is to cover those situations include initialization and reset. The patch should be backported to kernels as old as 2.6.39. Signed-off-by: Elric Fu <elricfu1@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable@vger.kernel.org
2012-02-18 13:32:27 +08:00
USB: change hub initialization sleeps to delayed_work This patch (as1137) changes the hub_activate() routine, replacing the power-power-up and debounce delays with delayed_work calls. The idea is that on systems where the USB stack is compiled into the kernel rather than built as modules, these delays will no longer block the boot thread. At least 100 ms is saved for each root hub, which can add up to a significant savings in total boot time. Arjan van de Ven was very pleased to see that this shaved 700 ms off his computer's boot time. Since his total boot time is on the order of two seconds, the improvement is considerable. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-22 14:44:26 -04:00
usb: hub: remove redundant declarations Fix two occurrences of the Sparse warning: warning: symbol XXX shadows an earlier one Signed-off-by: Kris Borer <kborer@gmail.com> Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-21 10:47:46 +05:30
usb: block suspension of superspeed port while hispeed peer is active ClearPortFeature(PORT_POWER) on a usb3 port places the port in either a DSPORT.Powered-off-detect / DSPORT.Powered-off-reset loop, or the DSPORT.Powered-off state. There is no way to ensure that RX terminations will persist in this state, so it is possible a device will degrade to its usb2 connection. Prevent this by blocking power-off of a usb3 port while its usb2 peer is active, and powering on a usb3 port before its usb2 peer. By default the latency between peer power-on events is 0. In order for the device to not see usb2 active while usb3 is still powering up inject the hub recommended power_on_good delay. In support of satisfying the power_on_good delay outside of hub_power_on() refactor the places where the delay is consumed to call a new hub_power_on_good_delay() helper. Finally, because this introduces several new checks for whether a port is_superspeed, cache that disctinction at port creation so that we don't need to keep looking up the parent hub device. Acked-by: Alan Stern <stern@rowland.harvard.edu> [alan]: add a 'superspeed' flag to the port Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:57 -07:00
usb: don't use PREPARE_DELAYED_WORK PREPARE_[DELAYED_]WORK() are being phased out. They have few users and a nasty surprise in terms of reentrancy guarantee as workqueue considers work items to be different if they don't have the same work function. usb_hub->init_work is multiplexed with multiple work functions; however, the work item is never queued while in-flight, so we can simply use INIT_DELAYED_WORK() before each queueing. It would probably be best to route this with other related updates through the workqueue tree. Lightly tested. v2: Greg and Alan confirm that the work item is never queued while in-flight. Simply use INIT_DELAYED_WORK(). Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: linux-usb@vger.kernel.org
2014-03-07 10:24:48 -05:00
usb: move hub init and LED blink work to power efficient workqueue Allow the scheduler to select the best CPU to handle hub initalization and LED blinking work. This extends idle residency times on idle CPUs and conserves power. This functionality is enabled when CONFIG_WQ_POWER_EFFICIENT is selected. [zoran.markovic@linaro.org: Rebased to latest kernel. Added commit message. Changed reference from system to power efficient workqueue for LEDs in check_highspeed() and hub_port_connect_change().] Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Xenia Ragiadakou <burzalodowa@gmail.com> Cc: Julius Werner <jwerner@chromium.org> Cc: Krzysztof Mazur <krzysiek@podlesie.net> Cc: Matthias Beyer <mail@beyermatthias.de> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Mathias Nyman <mathias.nyman@linux.intel.com> Cc: Thomas Pugliese <thomas.pugliese@gmail.com> Signed-off-by: Shaibal Dutta <shaibal.dutta@broadcom.com> Signed-off-by: Zoran Markovic <zoran.markovic@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-01 19:16:46 -08:00
USB: change hub initialization sleeps to delayed_work This patch (as1137) changes the hub_activate() routine, replacing the power-power-up and debounce delays with delayed_work calls. The idea is that on systems where the USB stack is compiled into the kernel rather than built as modules, these delays will no longer block the boot thread. At least 100 ms is saved for each root hub, which can add up to a significant savings in total boot time. Arjan van de Ven was very pleased to see that this shaved 700 ms off his computer's boot time. Since his total boot time is on the order of two seconds, the improvement is considerable. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-22 14:44:26 -04:00
USB: prevent autosuspend during hub initialization This patch (as1153) fixes a potential problem in hub initialization. Starting in 2.6.28, initialization was split into several tasks to help speed up booting. This opens the possibility that the hub may be autosuspended before all the initialization tasks can complete. Normally that wouldn't matter, but with incomplete initialization there is a risk that the hub would never autoresume -- especially if devices were plugged into the hub beforehand. The solution is a simple one-line change to suppress autosuspend until the initialization is finished. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-10-27 12:07:44 -04:00
USB: prepare for changover to Runtime PM framework This patch (as1303) revises the USB Power Management infrastructure to make it compatible with the new driver-model Runtime PM framework: Drivers are no longer allowed to access intf->pm_usage_cnt directly; the PM framework manages its own usage counters. usb_autopm_set_interface() is eliminated, because it directly sets intf->pm_usage_cnt. usb_autopm_enable() and usb_autopm_disable() are eliminated, because they call usb_autopm_set_interface(). usb_autopm_get_interface_no_resume() and usb_autopm_put_interface_no_suspend() are added. They correspond to pm_runtime_get_noresume() and pm_runtime_put_noidle() in the PM framework. The power/level attribute no longer accepts "suspend", only "on" and "auto". The PM framework doesn't allow devices to be forced into a suspended mode. The hub driver contains the only code that violates the new guidelines. It is updated to use the new interface routines instead. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-07 13:01:37 -05:00
USB: change hub initialization sleeps to delayed_work This patch (as1137) changes the hub_activate() routine, replacing the power-power-up and debounce delays with delayed_work calls. The idea is that on systems where the USB stack is compiled into the kernel rather than built as modules, these delays will no longer block the boot thread. At least 100 ms is saved for each root hub, which can add up to a significant savings in total boot time. Arjan van de Ven was very pleased to see that this shaved 700 ms off his computer's boot time. Since his total boot time is on the order of two seconds, the improvement is considerable. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-22 14:44:26 -04:00
usb: Realloc xHCI structures after a hub is verified. When there's an xHCI host power loss after a suspend from memory, the USB core attempts to reset and verify the USB devices that are attached to the system. The xHCI driver has to reallocate those devices, since the hardware lost all knowledge of them during the power loss. When a hub is plugged in, and the host loses power, the xHCI hardware structures are not updated to say the device is a hub. This is usually done in hub_configure() when the USB hub is detected. That function is skipped during a reset and verify by the USB core, since the core restores the old configuration and alternate settings, and the hub driver has no idea this happened. This bug makes the xHCI host controller reject the enumeration of low speed devices under the resumed hub. Therefore, make the USB core re-setup the internal xHCI hub device information by calling update_hub_device() when hub_activate() is called for a hub reset resume. After a host power loss, all devices under the roothub get a reset-resume or a disconnect. This patch should be queued for the 2.6.37 stable tree. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@kernel.org
2010-12-23 11:12:42 -08:00
usb: core: Fix logging messages with spurious periods after newlines Using a period after a newline causes bad output. Miscellanea: o Coalesce formats too Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-05 22:22:05 -08:00
usb: Realloc xHCI structures after a hub is verified. When there's an xHCI host power loss after a suspend from memory, the USB core attempts to reset and verify the USB devices that are attached to the system. The xHCI driver has to reallocate those devices, since the hardware lost all knowledge of them during the power loss. When a hub is plugged in, and the host loses power, the xHCI hardware structures are not updated to say the device is a hub. This is usually done in hub_configure() when the USB hub is detected. That function is skipped during a reset and verify by the USB core, since the core restores the old configuration and alternate settings, and the hub driver has no idea this happened. This bug makes the xHCI host controller reject the enumeration of low speed devices under the resumed hub. Therefore, make the USB core re-setup the internal xHCI hub device information by calling update_hub_device() when hub_activate() is called for a hub reset resume. After a host power loss, all devices under the roothub get a reset-resume or a disconnect. This patch should be queued for the 2.6.37 stable tree. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@kernel.org
2010-12-23 11:12:42 -08:00
USB: change hub initialization sleeps to delayed_work This patch (as1137) changes the hub_activate() routine, replacing the power-power-up and debounce delays with delayed_work calls. The idea is that on systems where the USB stack is compiled into the kernel rather than built as modules, these delays will no longer block the boot thread. At least 100 ms is saved for each root hub, which can add up to a significant savings in total boot time. Arjan van de Ven was very pleased to see that this shaved 700 ms off his computer's boot time. Since his total boot time is on the order of two seconds, the improvement is considerable. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-22 14:44:26 -04:00
usb: hub: Add delay for SuperSpeed hub resume to let links transit to U0 When a new USB device gets plugged to nested hubs, the affected hub, which connects to usb 2-1.4-port2, doesn't report there's any change, hence the nested hubs go back to runtime suspend like nothing happened: [ 281.032951] usb usb2: usb wakeup-resume [ 281.032959] usb usb2: usb auto-resume [ 281.032974] hub 2-0:1.0: hub_resume [ 281.033011] usb usb2-port1: status 0263 change 0000 [ 281.033077] hub 2-0:1.0: state 7 ports 4 chg 0000 evt 0000 [ 281.049797] usb 2-1: usb wakeup-resume [ 281.069800] usb 2-1: Waited 0ms for CONNECT [ 281.069810] usb 2-1: finish resume [ 281.070026] hub 2-1:1.0: hub_resume [ 281.070250] usb 2-1-port4: status 0203 change 0000 [ 281.070272] usb usb2-port1: resume, status 0 [ 281.070282] hub 2-1:1.0: state 7 ports 4 chg 0010 evt 0000 [ 281.089813] usb 2-1.4: usb wakeup-resume [ 281.109792] usb 2-1.4: Waited 0ms for CONNECT [ 281.109801] usb 2-1.4: finish resume [ 281.109991] hub 2-1.4:1.0: hub_resume [ 281.110147] usb 2-1.4-port2: status 0263 change 0000 [ 281.110234] usb 2-1-port4: resume, status 0 [ 281.110239] usb 2-1-port4: status 0203, change 0000, 10.0 Gb/s [ 281.110266] hub 2-1.4:1.0: state 7 ports 4 chg 0000 evt 0000 [ 281.110426] hub 2-1.4:1.0: hub_suspend [ 281.110565] usb 2-1.4: usb auto-suspend, wakeup 1 [ 281.130998] hub 2-1:1.0: hub_suspend [ 281.137788] usb 2-1: usb auto-suspend, wakeup 1 [ 281.142935] hub 2-0:1.0: state 7 ports 4 chg 0000 evt 0000 [ 281.177828] usb 2-1: usb wakeup-resume [ 281.197839] usb 2-1: Waited 0ms for CONNECT [ 281.197850] usb 2-1: finish resume [ 281.197984] hub 2-1:1.0: hub_resume [ 281.198203] usb 2-1-port4: status 0203 change 0000 [ 281.198228] usb usb2-port1: resume, status 0 [ 281.198237] hub 2-1:1.0: state 7 ports 4 chg 0010 evt 0000 [ 281.217835] usb 2-1.4: usb wakeup-resume [ 281.237834] usb 2-1.4: Waited 0ms for CONNECT [ 281.237845] usb 2-1.4: finish resume [ 281.237990] hub 2-1.4:1.0: hub_resume [ 281.238067] usb 2-1.4-port2: status 0263 change 0000 [ 281.238148] usb 2-1-port4: resume, status 0 [ 281.238152] usb 2-1-port4: status 0203, change 0000, 10.0 Gb/s [ 281.238166] hub 2-1.4:1.0: state 7 ports 4 chg 0000 evt 0000 [ 281.238385] hub 2-1.4:1.0: hub_suspend [ 281.238523] usb 2-1.4: usb auto-suspend, wakeup 1 [ 281.258076] hub 2-1:1.0: hub_suspend [ 281.265744] usb 2-1: usb auto-suspend, wakeup 1 [ 281.285976] hub 2-0:1.0: hub_suspend [ 281.285988] usb usb2: bus auto-suspend, wakeup 1 USB 3.2 spec, 9.2.5.4 "Changing Function Suspend State" says that "If the link is in a non-U0 state, then the device must transition the link to U0 prior to sending the remote wake message", but the hub only transits the link to U0 after signaling remote wakeup. So be more forgiving and use a 20ms delay to let the link transit to U0 for remote wakeup. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Link: https://lore.kernel.org/r/20211215120108.336597-1-kai.heng.feng@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-15 20:01:06 +08:00
USB: change hub initialization sleeps to delayed_work This patch (as1137) changes the hub_activate() routine, replacing the power-power-up and debounce delays with delayed_work calls. The idea is that on systems where the USB stack is compiled into the kernel rather than built as modules, these delays will no longer block the boot thread. At least 100 ms is saved for each root hub, which can add up to a significant savings in total boot time. Arjan van de Ven was very pleased to see that this shaved 700 ms off his computer's boot time. Since his total boot time is on the order of two seconds, the improvement is considerable. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-22 14:44:26 -04:00
USB: combine hub_activate and hub_restart This patch (as1071) combines hub_activate() and hub_restart() into a single routine. There's no point keeping them separate, since they are always called together. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:17 -04:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
usb: hub: rename khubd to hub_wq in documentation and comments USB hub has started to use a workqueue instead of kthread. Let's update the documentation and comments here and there. This patch mostly just replaces "khubd" with "hub_wq". There are only few exceptions where the whole sentence was updated. These more complicated changes can be found in the following files: Documentation/usb/hotplug.txt drivers/net/usb/usbnet.c drivers/usb/core/hcd.c drivers/usb/host/ohci-hcd.c drivers/usb/host/xhci.c Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:23 +02:00
USB: simplify hub_restart() logic This patch (as1081) straightens out the logic of the hub_restart() routine. Each port of the hub is scanned and the driver makes sure that ports which are supposed to be disabled really _are_ disabled. Any ports with a significant change in status are flagged in hub->change_bits, so that khubd can focus on them without the need to scan all the ports a second time -- which means the hub->activating flag is no longer needed. Also, it is now recognized explicitly that the only reason for resuming a port which was not suspended is to carry out a reset-resume operation, which happens only in a non-CONFIG_USB_SUSPEND setting. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:42 -04:00
USB: make USB-PERSIST work after every system sleep This patch (as1046) makes USB-PERSIST work more in accordance with the documentation. Currently it takes effect only in cases where the root hub has lost power or been reset, but it is supposed to operate whenever a power session was dropped during a system sleep. A new hub_restart() routine carries out the duties required during a reset or a reset-resume. It checks to see whether occupied ports are still enabled, and if they aren't then it clears the enable-change and connect-change features (to prevent interference by khubd) and sets the child device's reset_resume flag. It also checks ports that are supposed to be unoccupied to verify that the firmware hasn't left the port in an enabled state. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-03 15:15:51 -05:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
USB: make USB-PERSIST work after every system sleep This patch (as1046) makes USB-PERSIST work more in accordance with the documentation. Currently it takes effect only in cases where the root hub has lost power or been reset, but it is supposed to operate whenever a power session was dropped during a system sleep. A new hub_restart() routine carries out the duties required during a reset or a reset-resume. It checks to see whether occupied ports are still enabled, and if they aren't then it clears the enable-change and connect-change features (to prevent interference by khubd) and sets the child device's reset_resume flag. It also checks ports that are supposed to be unoccupied to verify that the firmware hasn't left the port in an enabled state. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-03 15:15:51 -05:00
USB: simplify hub_restart() logic This patch (as1081) straightens out the logic of the hub_restart() routine. Each port of the hub is scanned and the driver makes sure that ports which are supposed to be disabled really _are_ disabled. Any ports with a significant change in status are flagged in hub->change_bits, so that khubd can focus on them without the need to scan all the ports a second time -- which means the hub->activating flag is no longer needed. Also, it is now recognized explicitly that the only reason for resuming a port which was not suspended is to carry out a reset-resume operation, which happens only in a non-CONFIG_USB_SUSPEND setting. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:42 -04:00
usb: hub: port: add sysfs entry to switch port power In some cases the port of an hub needs to be disabled or switched off and on again. E.g. when the connected device needs to be re-enumerated. Or it needs to be explicitly disabled while the rest of the usb tree stays working. For this purpose this patch adds an sysfs switch to enable/disable the port on any hub. In the case the hub is supporting power switching, the power line will be disabled to the connected device. When the port gets disabled, the associated device gets disconnected and removed from the logical usb tree. No further device will be enumerated on that port until the port gets enabled again. Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220607114522.3359148-1-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-07 13:45:22 +02:00
usb: hub: Fix error loop seen after hub communication errors While stress testing a usb controller using a bind/unbind looop, the following error loop was observed. usb 7-1.2: new low-speed USB device number 3 using xhci-hcd usb 7-1.2: hub failed to enable device, error -108 usb 7-1-port2: cannot disable (err = -22) usb 7-1-port2: couldn't allocate usb_device usb 7-1-port2: cannot disable (err = -22) hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: activate --> -22 hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: activate --> -22 hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: activate --> -22 hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: activate --> -22 hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: activate --> -22 hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: activate --> -22 hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: activate --> -22 hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: activate --> -22 hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: hub_ext_port_status failed (err = -22) ** 57 printk messages dropped ** hub 7-1:1.0: activate --> -22 ** 82 printk messages dropped ** hub 7-1:1.0: hub_ext_port_status failed (err = -22) This continues forever. After adding tracebacks into the code, the call sequence leading to this is found to be as follows. [<ffffffc0007fc8e0>] hub_activate+0x368/0x7b8 [<ffffffc0007fceb4>] hub_resume+0x2c/0x3c [<ffffffc00080b3b8>] usb_resume_interface.isra.6+0x128/0x158 [<ffffffc00080b5d0>] usb_suspend_both+0x1e8/0x288 [<ffffffc00080c9c4>] usb_runtime_suspend+0x3c/0x98 [<ffffffc0007820a0>] __rpm_callback+0x48/0x7c [<ffffffc00078217c>] rpm_callback+0xa8/0xd4 [<ffffffc000786234>] rpm_suspend+0x84/0x758 [<ffffffc000786ca4>] rpm_idle+0x2c8/0x498 [<ffffffc000786ed4>] __pm_runtime_idle+0x60/0xac [<ffffffc00080eba8>] usb_autopm_put_interface+0x6c/0x7c [<ffffffc000803798>] hub_event+0x10ac/0x12ac [<ffffffc000249bb8>] process_one_work+0x390/0x6b8 [<ffffffc00024abcc>] worker_thread+0x480/0x610 [<ffffffc000251a80>] kthread+0x164/0x178 [<ffffffc0002045d0>] ret_from_fork+0x10/0x40 kick_hub_wq() is called from hub_activate() even after failures to communicate with the hub. This results in an endless sequence of hub event -> hub activate -> wq trigger -> hub event -> ... Provide two solutions for the problem. - Only trigger the hub event queue if communication with the hub is successful. - After a suspend failure, only resume already suspended interfaces if the communication with the device is still possible. Each of the changes fixes the observed problem. Use both to improve robustness. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-20 11:16:11 -07:00
USB: simplify hub_restart() logic This patch (as1081) straightens out the logic of the hub_restart() routine. Each port of the hub is scanned and the driver makes sure that ports which are supposed to be disabled really _are_ disabled. Any ports with a significant change in status are flagged in hub->change_bits, so that khubd can focus on them without the need to scan all the ports a second time -- which means the hub->activating flag is no longer needed. Also, it is now recognized explicitly that the only reason for resuming a port which was not suspended is to carry out a reset-resume operation, which happens only in a non-CONFIG_USB_SUSPEND setting. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:42 -04:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
USB: make USB-PERSIST work after every system sleep This patch (as1046) makes USB-PERSIST work more in accordance with the documentation. Currently it takes effect only in cases where the root hub has lost power or been reset, but it is supposed to operate whenever a power session was dropped during a system sleep. A new hub_restart() routine carries out the duties required during a reset or a reset-resume. It checks to see whether occupied ports are still enabled, and if they aren't then it clears the enable-change and connect-change features (to prevent interference by khubd) and sets the child device's reset_resume flag. It also checks ports that are supposed to be unoccupied to verify that the firmware hasn't left the port in an enabled state. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-03 15:15:51 -05:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
USB: simplify hub_restart() logic This patch (as1081) straightens out the logic of the hub_restart() routine. Each port of the hub is scanned and the driver makes sure that ports which are supposed to be disabled really _are_ disabled. Any ports with a significant change in status are flagged in hub->change_bits, so that khubd can focus on them without the need to scan all the ports a second time -- which means the hub->activating flag is no longer needed. Also, it is now recognized explicitly that the only reason for resuming a port which was not suspended is to carry out a reset-resume operation, which happens only in a non-CONFIG_USB_SUSPEND setting. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:42 -04:00
USB: make USB-PERSIST work after every system sleep This patch (as1046) makes USB-PERSIST work more in accordance with the documentation. Currently it takes effect only in cases where the root hub has lost power or been reset, but it is supposed to operate whenever a power session was dropped during a system sleep. A new hub_restart() routine carries out the duties required during a reset or a reset-resume. It checks to see whether occupied ports are still enabled, and if they aren't then it clears the enable-change and connect-change features (to prevent interference by khubd) and sets the child device's reset_resume flag. It also checks ports that are supposed to be unoccupied to verify that the firmware hasn't left the port in an enabled state. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-03 15:15:51 -05:00
USB: simplify hub_restart() logic This patch (as1081) straightens out the logic of the hub_restart() routine. Each port of the hub is scanned and the driver makes sure that ports which are supposed to be disabled really _are_ disabled. Any ports with a significant change in status are flagged in hub->change_bits, so that khubd can focus on them without the need to scan all the ports a second time -- which means the hub->activating flag is no longer needed. Also, it is now recognized explicitly that the only reason for resuming a port which was not suspended is to carry out a reset-resume operation, which happens only in a non-CONFIG_USB_SUSPEND setting. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:42 -04:00
USB: usbcore: Do not disable USB3 protocol ports in hub_activate() When USB3 protocol port detects an USB3.0 device attach, the port will automatically transition to the Enabled state upon the completion of successful link training. Do not disable USB3 protocol ports in hub_activate(), or USB3.0 device will fail to be recognized if xHCI bus power management is implemented. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-05-07 18:09:27 +08:00
usb: hub_activate kill an 'else' Remove a few extra lines and make it clear that all implementations disable the port by sharing the same line of code. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-10-07 11:58:20 -07:00
USB: usbcore: Do not disable USB3 protocol ports in hub_activate() When USB3 protocol port detects an USB3.0 device attach, the port will automatically transition to the Enabled state upon the completion of successful link training. Do not disable USB3 protocol ports in hub_activate(), or USB3.0 device will fail to be recognized if xHCI bus power management is implemented. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-05-07 18:09:27 +08:00
usb: hub_activate kill an 'else' Remove a few extra lines and make it clear that all implementations disable the port by sharing the same line of code. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-10-07 11:58:20 -07:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
USB: usbcore: Do not disable USB3 protocol ports in hub_activate() When USB3 protocol port detects an USB3.0 device attach, the port will automatically transition to the Enabled state upon the completion of successful link training. Do not disable USB3 protocol ports in hub_activate(), or USB3.0 device will fail to be recognized if xHCI bus power management is implemented. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-05-07 18:09:27 +08:00
USB: simplify hub_restart() logic This patch (as1081) straightens out the logic of the hub_restart() routine. Each port of the hub is scanned and the driver makes sure that ports which are supposed to be disabled really _are_ disabled. Any ports with a significant change in status are flagged in hub->change_bits, so that khubd can focus on them without the need to scan all the ports a second time -- which means the hub->activating flag is no longer needed. Also, it is now recognized explicitly that the only reason for resuming a port which was not suspended is to carry out a reset-resume operation, which happens only in a non-CONFIG_USB_SUSPEND setting. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:42 -04:00
usb: handle warm-reset port requests on hub resume On plug-in of my USB-C device, its USB_SS_PORT_LS_SS_INACTIVE link state bit is set. Greping all the kernel for this bit shows that the port status requests a warm-reset this way. This just happens, if its the only device on the root hub, the hub therefore resumes and the HCDs status_urb isn't yet available. If a warm-reset request is detected, this sets the hubs event_bits, which will prevent any auto-suspend and allows the hubs workqueue to warm-reset the port later in port_event. Signed-off-by: Jan-Marek Glogowski <glogow@fbihome.de> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-01 13:52:31 +01:00
usb: hub: delay hub autosuspend if USB3 port is still link training When initializing a hub we want to give a USB3 port in link training the same debounce delay time before autosuspening the hub as already trained, connected enabled ports. USB3 ports won't reach the enabled state with "current connect status" and "connect status change" bits set until the USB3 link training finishes. Catching the port in link training (polling) and adding the debounce delay prevents unnecessary failed attempts to autosuspend the hub. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-11-28 15:55:21 +02:00
USB: optimize port debouncing during hub activation This patch (as1082) makes a small optimization to the way the hub driver carries out port debouncing immediately after a hub is activated (i.e., initialized, reset, or resumed). If any port-change statuses are observed, the code will delay for a minimal debounce period -- thereby making a good start at debouncing all the ports at once. If this wasn't sufficient then khubd will debounce any port that still requires attention. But in most cases it should suffice; it's rare for a device to need more than a minimal debounce delay. (In the cases of hub initialization or reset even that is most likely not needed, since any devices plugged in at such times have probably been attached for a while.) Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:07 -04:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
USB: optimize port debouncing during hub activation This patch (as1082) makes a small optimization to the way the hub driver carries out port debouncing immediately after a hub is activated (i.e., initialized, reset, or resumed). If any port-change statuses are observed, the code will delay for a minimal debounce period -- thereby making a good start at debouncing all the ports at once. If this wasn't sufficient then khubd will debounce any port that still requires attention. But in most cases it should suffice; it's rare for a device to need more than a minimal debounce delay. (In the cases of hub initialization or reset even that is most likely not needed, since any devices plugged in at such times have probably been attached for a while.) Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:07 -04:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
USB: optimize port debouncing during hub activation This patch (as1082) makes a small optimization to the way the hub driver carries out port debouncing immediately after a hub is activated (i.e., initialized, reset, or resumed). If any port-change statuses are observed, the code will delay for a minimal debounce period -- thereby making a good start at debouncing all the ports at once. If this wasn't sufficient then khubd will debounce any port that still requires attention. But in most cases it should suffice; it's rare for a device to need more than a minimal debounce delay. (In the cases of hub initialization or reset even that is most likely not needed, since any devices plugged in at such times have probably been attached for a while.) Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:07 -04:00
usb: hub: Clear Port Reset Change during init/resume This patch adds the Port Reset Change flag to the set of bits that are preemptively cleared on init/resume of a hub. In theory this bit should never be set unexpectedly... in practice it can still happen if BIOS, SMM or ACPI code plays around with USB devices without cleaning up correctly. This is especially dangerous for XHCI root hubs, which don't generate any more Port Status Change Events until all change bits are cleared, so this is a good precaution to have (similar to how it's already done for the Warm Port Reset Change flag). Signed-off-by: Julius Werner <jwerner@chromium.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-15 17:45:00 -07:00
usb, xhci: Clear warm reset change event during init I noticed on my Panther Point system that I wasn't getting hotplug events for my usb3.0 disk on a usb3 port. I tracked it down to the fact that the system had the warm reset change bit still set. This seemed to block future events from being received, including a hotplug event. Clearing this bit during initialization allowed the hotplug event to be received and the disk to be recognized correctly. This patch should be backported to kernels as old as 2.6.39. Signed-off-by: Don Zickus <dzickus@redhat.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2011-11-03 09:07:18 -04:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
usb, xhci: Clear warm reset change event during init I noticed on my Panther Point system that I wasn't getting hotplug events for my usb3.0 disk on a usb3 port. I tracked it down to the fact that the system had the warm reset change bit still set. This seemed to block future events from being received, including a hotplug event. Clearing this bit during initialization allowed the hotplug event to be received and the disk to be recognized correctly. This patch should be backported to kernels as old as 2.6.39. Signed-off-by: Don Zickus <dzickus@redhat.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2011-11-03 09:07:18 -04:00
USB: add a "remove hardware" sysfs attribute This patch (as1297) adds a "remove" attribute to each USB device's directory in sysfs. Writing to this attribute causes the device to be deconfigured (the same as writing 0 to the "bConfigurationValue" attribute) and then tells the hub driver to disable the device's upstream port. The device remains locked during these activities so there is no possibility of it getting reconfigured in between. The port will remain disabled until after the device is unplugged. The purpose of this is to provide a means for user programs to imitate the "Safely remove hardware" applet in Windows. Some devices do expect their ports to be disabled before they are unplugged, and they provide visual feedback to users indicating when they can safely be unplugged. The security implications are minimal. Writing to the "remove" attribute is no more dangerous than writing to the "bConfigurationValue" attribute. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: David Zeuthen <davidz@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 15:20:13 -04:00
USB: simplify hub_restart() logic This patch (as1081) straightens out the logic of the hub_restart() routine. Each port of the hub is scanned and the driver makes sure that ports which are supposed to be disabled really _are_ disabled. Any ports with a significant change in status are flagged in hub->change_bits, so that khubd can focus on them without the need to scan all the ports a second time -- which means the hub->activating flag is no longer needed. Also, it is now recognized explicitly that the only reason for resuming a port which was not suspended is to carry out a reset-resume operation, which happens only in a non-CONFIG_USB_SUSPEND setting. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:42 -04:00
usb: hub: rename khubd to hub_wq in documentation and comments USB hub has started to use a workqueue instead of kthread. Let's update the documentation and comments here and there. This patch mostly just replaces "khubd" with "hub_wq". There are only few exceptions where the whole sentence was updated. These more complicated changes can be found in the following files: Documentation/usb/hotplug.txt drivers/net/usb/usbnet.c drivers/usb/core/hcd.c drivers/usb/host/ohci-hcd.c drivers/usb/host/xhci.c Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:23 +02:00
usb: core: handle hub C_PORT_OVER_CURRENT condition Based on USB2.0 Spec Section 11.12.5, "If a hub has per-port power switching and per-port current limiting, an over-current on one port may still cause the power on another port to fall below specific minimums. In this case, the affected port is placed in the Power-Off state and C_PORT_OVER_CURRENT is set for the port, but PORT_OVER_CURRENT is not set." so let's check C_PORT_OVER_CURRENT too for over current condition. Fixes: 08d1dec6f405 ("usb:hub set hub->change_bits when over-current happens") Cc: <stable@vger.kernel.org> Tested-by: Alessandro Antenucci <antenucci@korg.it> Signed-off-by: Bin Liu <b-liu@ti.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-07-19 14:39:37 -05:00
USB: simplify hub_restart() logic This patch (as1081) straightens out the logic of the hub_restart() routine. Each port of the hub is scanned and the driver makes sure that ports which are supposed to be disabled really _are_ disabled. Any ports with a significant change in status are flagged in hub->change_bits, so that khubd can focus on them without the need to scan all the ports a second time -- which means the hub->activating flag is no longer needed. Also, it is now recognized explicitly that the only reason for resuming a port which was not suspended is to carry out a reset-resume operation, which happens only in a non-CONFIG_USB_SUSPEND setting. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:42 -04:00
usb:hub set hub->change_bits when over-current happens When we are doing compliance test with xHCI, we found that if we enable CONFIG_USB_SUSPEND and plug in a bad device which causes over-current condition to the root port, software will not be noticed. The reason is that current code don't set hub->change_bits in hub_activate() when over-current happens, and then hub_events() will not check the port status because it thinks nothing changed. If CONFIG_USB_SUSPEND is disabled, the interrupt pipe of the hub will report the change and set hub->event_bits, and then hub_events() will check what events happened.In this case over-current can be detected. Signed-off-by: Shen Guang <shenguang10@gmail.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>
2014-01-08 14:45:42 +08:00
usb: core: hub: Improved device recognition on remote wakeup If hub_activate() is called before D+ has stabilized after remote wakeup, the following situation might occur: __ ___________________ / \ / D+ __/ \__/ Hub _______________________________ | ^ ^ ^ | | | | Host _____v__|___|___________|______ | | | | | | | \-- Interrupt Transfer (*3) | | \-- ClearPortFeature (*2) | \-- GetPortStatus (*1) \-- Host detects remote wakeup - D+ goes high, Host starts running by remote wakeup - D+ is not stable, goes low - Host requests GetPortStatus at (*1) and gets the following hub status: - Current Connect Status bit is 0 - Connect Status Change bit is 1 - D+ stabilizes, goes high - Host requests ClearPortFeature and thus Connect Status Change bit is cleared at (*2) - After waiting 100 ms, Host starts the Interrupt Transfer at (*3) - Since the Connect Status Change bit is 0, Hub returns NAK. In this case, port_event() is not called in hub_event() and Host cannot recognize device. To solve this issue, flag change_bits even if only Connect Status Change bit is 1 when got in the first GetPortStatus. This issue occurs rarely because it only if D+ changes during a very short time between GetPortStatus and ClearPortFeature. However, it is fatal if it occurs in embedded system. Signed-off-by: Keiya Nobuta <nobuta.keiya@fujitsu.com> Cc: stable <stable@vger.kernel.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200109051448.28150-1-nobuta.keiya@fujitsu.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-09 14:14:48 +09:00
usb: core: handle hub C_PORT_OVER_CURRENT condition Based on USB2.0 Spec Section 11.12.5, "If a hub has per-port power switching and per-port current limiting, an over-current on one port may still cause the power on another port to fall below specific minimums. In this case, the affected port is placed in the Power-Off state and C_PORT_OVER_CURRENT is set for the port, but PORT_OVER_CURRENT is not set." so let's check C_PORT_OVER_CURRENT too for over current condition. Fixes: 08d1dec6f405 ("usb:hub set hub->change_bits when over-current happens") Cc: <stable@vger.kernel.org> Tested-by: Alessandro Antenucci <antenucci@korg.it> Signed-off-by: Bin Liu <b-liu@ti.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-07-19 14:39:37 -05:00
USB: simplify hub_restart() logic This patch (as1081) straightens out the logic of the hub_restart() routine. Each port of the hub is scanned and the driver makes sure that ports which are supposed to be disabled really _are_ disabled. Any ports with a significant change in status are flagged in hub->change_bits, so that khubd can focus on them without the need to scan all the ports a second time -- which means the hub->activating flag is no longer needed. Also, it is now recognized explicitly that the only reason for resuming a port which was not suspended is to carry out a reset-resume operation, which happens only in a non-CONFIG_USB_SUSPEND setting. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:42 -04:00
USB: Set wakeup bits for all children hubs. This patch takes care of the race condition between the Function Wake Device Notification and the auto-suspend timeout for this situation: Roothub | (U3) hub A | (U3) hub B | (U3) device C When device C signals a resume, the xHCI driver will set the wakeup_bits for the roothub port that hub A is attached to. However, since USB 3.0 hubs do not set a link state change bit on device-initiated resume, hub A will not indicate a port event when polled. Without this patch, khubd will notice the wakeup-bits are set for the roothub port, it will resume hub A, and then it will poll the events bits for hub A and notice that nothing has changed. Then it will be suspended after 2 seconds. Change hub_activate() to look at the port link state for each USB 3.0 hub port, and set hub->change_bits if the link state is U0, indicating the device has finished resume. Change the resume function called by hub_events(), hub_handle_remote_wakeup(), to check the link status for resume instead of just the port's wakeup_bits. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-01-24 11:46:50 -08:00
USB: simplify hub_restart() logic This patch (as1081) straightens out the logic of the hub_restart() routine. Each port of the hub is scanned and the driver makes sure that ports which are supposed to be disabled really _are_ disabled. Any ports with a significant change in status are flagged in hub->change_bits, so that khubd can focus on them without the need to scan all the ports a second time -- which means the hub->activating flag is no longer needed. Also, it is now recognized explicitly that the only reason for resuming a port which was not suspended is to carry out a reset-resume operation, which happens only in a non-CONFIG_USB_SUSPEND setting. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:42 -04:00
usb: hub: rename khubd to hub_wq in documentation and comments USB hub has started to use a workqueue instead of kthread. Let's update the documentation and comments here and there. This patch mostly just replaces "khubd" with "hub_wq". There are only few exceptions where the whole sentence was updated. These more complicated changes can be found in the following files: Documentation/usb/hotplug.txt drivers/net/usb/usbnet.c drivers/usb/core/hcd.c drivers/usb/host/ohci-hcd.c drivers/usb/host/xhci.c Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:23 +02:00
USB: Set wakeup bits for all children hubs. This patch takes care of the race condition between the Function Wake Device Notification and the auto-suspend timeout for this situation: Roothub | (U3) hub A | (U3) hub B | (U3) device C When device C signals a resume, the xHCI driver will set the wakeup_bits for the roothub port that hub A is attached to. However, since USB 3.0 hubs do not set a link state change bit on device-initiated resume, hub A will not indicate a port event when polled. Without this patch, khubd will notice the wakeup-bits are set for the roothub port, it will resume hub A, and then it will poll the events bits for hub A and notice that nothing has changed. Then it will be suspended after 2 seconds. Change hub_activate() to look at the port link state for each USB 3.0 hub port, and set hub->change_bits if the link state is U0, indicating the device has finished resume. Change the resume function called by hub_events(), hub_handle_remote_wakeup(), to check the link status for resume instead of just the port's wakeup_bits. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-01-24 11:46:50 -08:00
USB: simplify hub_restart() logic This patch (as1081) straightens out the logic of the hub_restart() routine. Each port of the hub is scanned and the driver makes sure that ports which are supposed to be disabled really _are_ disabled. Any ports with a significant change in status are flagged in hub->change_bits, so that khubd can focus on them without the need to scan all the ports a second time -- which means the hub->activating flag is no longer needed. Also, it is now recognized explicitly that the only reason for resuming a port which was not suspended is to carry out a reset-resume operation, which happens only in a non-CONFIG_USB_SUSPEND setting. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:42 -04:00
USB: Set wakeup bits for all children hubs. This patch takes care of the race condition between the Function Wake Device Notification and the auto-suspend timeout for this situation: Roothub | (U3) hub A | (U3) hub B | (U3) device C When device C signals a resume, the xHCI driver will set the wakeup_bits for the roothub port that hub A is attached to. However, since USB 3.0 hubs do not set a link state change bit on device-initiated resume, hub A will not indicate a port event when polled. Without this patch, khubd will notice the wakeup-bits are set for the roothub port, it will resume hub A, and then it will poll the events bits for hub A and notice that nothing has changed. Then it will be suspended after 2 seconds. Change hub_activate() to look at the port link state for each USB 3.0 hub port, and set hub->change_bits if the link state is U0, indicating the device has finished resume. Change the resume function called by hub_events(), hub_handle_remote_wakeup(), to check the link status for resume instead of just the port's wakeup_bits. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-01-24 11:46:50 -08:00
USB: core: Fix bug in resuming hub's handling of wakeup requests Bugzilla #213839 reports a 7-port hub that doesn't work properly when devices are plugged into some of the ports; the kernel goes into an unending disconnect/reinitialize loop as shown in the bug report. This "7-port hub" comprises two four-port hubs with one plugged into the other; the failures occur when a device is plugged into one of the downstream hub's ports. (These hubs have other problems too. For example, they bill themselves as USB-2.0 compliant but they only run at full speed.) It turns out that the failures are caused by bugs in both the kernel and the hub. The hub's bug is that it reports a different bmAttributes value in its configuration descriptor following a remote wakeup (0xe0 before, 0xc0 after -- the wakeup-support bit has changed). The kernel's bug is inside the hub driver's resume handler. When hub_activate() sees that one of the hub's downstream ports got a wakeup request from a child device, it notes this fact by setting the corresponding bit in the hub->change_bits variable. But this variable is meant for connection changes, not wakeup events; setting it causes the driver to believe the downstream port has been disconnected and then connected again (in addition to having received a wakeup request). Because of this, the hub driver then tries to check whether the device currently plugged into the downstream port is the same as the device that had been attached there before. Normally this check succeeds and wakeup handling continues with no harm done (which is why the bug remained undetected until now). But with these dodgy hubs, the check fails because the config descriptor has changed. This causes the hub driver to reinitialize the child device, leading to the disconnect/reinitialize loop described in the bug report. The proper way to note reception of a downstream wakeup request is to set a bit in the hub->event_bits variable instead of hub->change_bits. That way the hub driver will realize that something has happened to the port but will not think the port and child device have been disconnected. This patch makes that change. Cc: <stable@vger.kernel.org> Tested-by: Jonathan McDowell <noodles@earth.li> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/YdCw7nSfWYPKWQoD@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-01 14:52:14 -05:00
USB: simplify hub_restart() logic This patch (as1081) straightens out the logic of the hub_restart() routine. Each port of the hub is scanned and the driver makes sure that ports which are supposed to be disabled really _are_ disabled. Any ports with a significant change in status are flagged in hub->change_bits, so that khubd can focus on them without the need to scan all the ports a second time -- which means the hub->activating flag is no longer needed. Also, it is now recognized explicitly that the only reason for resuming a port which was not suspended is to carry out a reset-resume operation, which happens only in a non-CONFIG_USB_SUSPEND setting. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:42 -04:00
USB: make USB-PERSIST work after every system sleep This patch (as1046) makes USB-PERSIST work more in accordance with the documentation. Currently it takes effect only in cases where the root hub has lost power or been reset, but it is supposed to operate whenever a power session was dropped during a system sleep. A new hub_restart() routine carries out the duties required during a reset or a reset-resume. It checks to see whether occupied ports are still enabled, and if they aren't then it clears the enable-change and connect-change features (to prevent interference by khubd) and sets the child device's reset_resume flag. It also checks ports that are supposed to be unoccupied to verify that the firmware hasn't left the port in an enabled state. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-03 15:15:51 -05:00
USB: simplify hub_restart() logic This patch (as1081) straightens out the logic of the hub_restart() routine. Each port of the hub is scanned and the driver makes sure that ports which are supposed to be disabled really _are_ disabled. Any ports with a significant change in status are flagged in hub->change_bits, so that khubd can focus on them without the need to scan all the ports a second time -- which means the hub->activating flag is no longer needed. Also, it is now recognized explicitly that the only reason for resuming a port which was not suspended is to carry out a reset-resume operation, which happens only in a non-CONFIG_USB_SUSPEND setting. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:42 -04:00
USB: hub: Fix handling of connect changes during sleep Commit 8099f58f1ecd ("USB: hub: Don't record a connect-change event during reset-resume") wasn't very well conceived. The problem it tried to fix was that if a connect-change event occurred while the system was asleep (such as a device disconnecting itself from the bus when it is suspended and then reconnecting when it resumes) requiring a reset-resume during the system wakeup transition, the hub port's change_bit entry would remain set afterward. This would cause the hub driver to believe another connect-change event had occurred after the reset-resume, which was wrong and would lead the driver to send unnecessary requests to the device (which could interfere with a firmware update). The commit tried to fix this by not setting the change_bit during the wakeup. But this was the wrong thing to do; it means that when a device is unplugged while the system is asleep, the hub driver doesn't realize anything has happened: The change_bit flag which would tell it to handle the disconnect event is clear. The commit needs to be reverted and the problem fixed in a different way. Fortunately an alternative solution was noted in the commit's Changelog: We can continue to set the change_bit entry in hub_activate() but then clear it when a reset-resume occurs. That way the the hub driver will see the change_bit when a device is disconnected but won't see it when the device is still present. That's what this patch does. Reported-and-tested-by: Peter Chen <peter.chen@nxp.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Fixes: 8099f58f1ecd ("USB: hub: Don't record a connect-change event during reset-resume") Tested-by: Paul Zimmerman <pauldzim@gmail.com> CC: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2004221602480.11262-100000@iolanthe.rowland.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-22 16:09:51 -04:00
USB: try to salvage lost power sessions This patch (as1073) adds to khubd a way to recover from power-session interruption caused by transient connect-change or enable-change events. After the debouncing period, khubd attempts to do a USB-Persist-style reset or reset-resume. If it works, the connection will remain unscathed. The upshot is that we will be more immune to noise caused by EMI. The grace period is on the order of 100 ms, so this won't permit recovery from the "accidentally knocked the USB cable out of its socket" type of event, but it's a start. As an added bonus, if a device was suspended when the system goes to sleep then we no longer need to check for power-session interruptions when the system wakes up. Khubd will naturally see the status change while processing the device's parent hub and will do the right thing. The remote_wakeup() routine is changed; now it expects the caller to acquire the device lock rather than acquiring the lock itself. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:55 -04:00
USB: simplify hub_restart() logic This patch (as1081) straightens out the logic of the hub_restart() routine. Each port of the hub is scanned and the driver makes sure that ports which are supposed to be disabled really _are_ disabled. Any ports with a significant change in status are flagged in hub->change_bits, so that khubd can focus on them without the need to scan all the ports a second time -- which means the hub->activating flag is no longer needed. Also, it is now recognized explicitly that the only reason for resuming a port which was not suspended is to carry out a reset-resume operation, which happens only in a non-CONFIG_USB_SUSPEND setting. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:42 -04:00
usb: hub: rename khubd to hub_wq in documentation and comments USB hub has started to use a workqueue instead of kthread. Let's update the documentation and comments here and there. This patch mostly just replaces "khubd" with "hub_wq". There are only few exceptions where the whole sentence was updated. These more complicated changes can be found in the following files: Documentation/usb/hotplug.txt drivers/net/usb/usbnet.c drivers/usb/core/hcd.c drivers/usb/host/ohci-hcd.c drivers/usb/host/xhci.c Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:23 +02:00
USB: simplify hub_restart() logic This patch (as1081) straightens out the logic of the hub_restart() routine. Each port of the hub is scanned and the driver makes sure that ports which are supposed to be disabled really _are_ disabled. Any ports with a significant change in status are flagged in hub->change_bits, so that khubd can focus on them without the need to scan all the ports a second time -- which means the hub->activating flag is no longer needed. Also, it is now recognized explicitly that the only reason for resuming a port which was not suspended is to carry out a reset-resume operation, which happens only in a non-CONFIG_USB_SUSPEND setting. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:42 -04:00
USB: make USB-PERSIST work after every system sleep This patch (as1046) makes USB-PERSIST work more in accordance with the documentation. Currently it takes effect only in cases where the root hub has lost power or been reset, but it is supposed to operate whenever a power session was dropped during a system sleep. A new hub_restart() routine carries out the duties required during a reset or a reset-resume. It checks to see whether occupied ports are still enabled, and if they aren't then it clears the enable-change and connect-change features (to prevent interference by khubd) and sets the child device's reset_resume flag. It also checks ports that are supposed to be unoccupied to verify that the firmware hasn't left the port in an enabled state. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-03 15:15:51 -05:00
USB: optimize port debouncing during hub activation This patch (as1082) makes a small optimization to the way the hub driver carries out port debouncing immediately after a hub is activated (i.e., initialized, reset, or resumed). If any port-change statuses are observed, the code will delay for a minimal debounce period -- thereby making a good start at debouncing all the ports at once. If this wasn't sufficient then khubd will debounce any port that still requires attention. But in most cases it should suffice; it's rare for a device to need more than a minimal debounce delay. (In the cases of hub initialization or reset even that is most likely not needed, since any devices plugged in at such times have probably been attached for a while.) Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:07 -04:00
usb: hub: rename khubd to hub_wq in documentation and comments USB hub has started to use a workqueue instead of kthread. Let's update the documentation and comments here and there. This patch mostly just replaces "khubd" with "hub_wq". There are only few exceptions where the whole sentence was updated. These more complicated changes can be found in the following files: Documentation/usb/hotplug.txt drivers/net/usb/usbnet.c drivers/usb/core/hcd.c drivers/usb/host/ohci-hcd.c drivers/usb/host/xhci.c Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:23 +02:00
USB: optimize port debouncing during hub activation This patch (as1082) makes a small optimization to the way the hub driver carries out port debouncing immediately after a hub is activated (i.e., initialized, reset, or resumed). If any port-change statuses are observed, the code will delay for a minimal debounce period -- thereby making a good start at debouncing all the ports at once. If this wasn't sufficient then khubd will debounce any port that still requires attention. But in most cases it should suffice; it's rare for a device to need more than a minimal debounce delay. (In the cases of hub initialization or reset even that is most likely not needed, since any devices plugged in at such times have probably been attached for a while.) Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:07 -04:00
usb: hub: rename khubd to hub_wq in documentation and comments USB hub has started to use a workqueue instead of kthread. Let's update the documentation and comments here and there. This patch mostly just replaces "khubd" with "hub_wq". There are only few exceptions where the whole sentence was updated. These more complicated changes can be found in the following files: Documentation/usb/hotplug.txt drivers/net/usb/usbnet.c drivers/usb/core/hcd.c drivers/usb/host/ohci-hcd.c drivers/usb/host/xhci.c Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:23 +02:00
USB: optimize port debouncing during hub activation This patch (as1082) makes a small optimization to the way the hub driver carries out port debouncing immediately after a hub is activated (i.e., initialized, reset, or resumed). If any port-change statuses are observed, the code will delay for a minimal debounce period -- thereby making a good start at debouncing all the ports at once. If this wasn't sufficient then khubd will debounce any port that still requires attention. But in most cases it should suffice; it's rare for a device to need more than a minimal debounce delay. (In the cases of hub initialization or reset even that is most likely not needed, since any devices plugged in at such times have probably been attached for a while.) Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:07 -04:00
USB: change hub initialization sleeps to delayed_work This patch (as1137) changes the hub_activate() routine, replacing the power-power-up and debounce delays with delayed_work calls. The idea is that on systems where the USB stack is compiled into the kernel rather than built as modules, these delays will no longer block the boot thread. At least 100 ms is saved for each root hub, which can add up to a significant savings in total boot time. Arjan van de Ven was very pleased to see that this shaved 700 ms off his computer's boot time. Since his total boot time is on the order of two seconds, the improvement is considerable. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-22 14:44:26 -04:00
USB: combine hub_activate and hub_restart This patch (as1071) combines hub_activate() and hub_restart() into a single routine. There's no point keeping them separate, since they are always called together. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:17 -04:00
USB: change hub initialization sleeps to delayed_work This patch (as1137) changes the hub_activate() routine, replacing the power-power-up and debounce delays with delayed_work calls. The idea is that on systems where the USB stack is compiled into the kernel rather than built as modules, these delays will no longer block the boot thread. At least 100 ms is saved for each root hub, which can add up to a significant savings in total boot time. Arjan van de Ven was very pleased to see that this shaved 700 ms off his computer's boot time. Since his total boot time is on the order of two seconds, the improvement is considerable. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-22 14:44:26 -04:00
usb: don't use PREPARE_DELAYED_WORK PREPARE_[DELAYED_]WORK() are being phased out. They have few users and a nasty surprise in terms of reentrancy guarantee as workqueue considers work items to be different if they don't have the same work function. usb_hub->init_work is multiplexed with multiple work functions; however, the work item is never queued while in-flight, so we can simply use INIT_DELAYED_WORK() before each queueing. It would probably be best to route this with other related updates through the workqueue tree. Lightly tested. v2: Greg and Alan confirm that the work item is never queued while in-flight. Simply use INIT_DELAYED_WORK(). Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: linux-usb@vger.kernel.org
2014-03-07 10:24:48 -05:00
usb: move hub init and LED blink work to power efficient workqueue Allow the scheduler to select the best CPU to handle hub initalization and LED blinking work. This extends idle residency times on idle CPUs and conserves power. This functionality is enabled when CONFIG_WQ_POWER_EFFICIENT is selected. [zoran.markovic@linaro.org: Rebased to latest kernel. Added commit message. Changed reference from system to power efficient workqueue for LEDs in check_highspeed() and hub_port_connect_change().] Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Xenia Ragiadakou <burzalodowa@gmail.com> Cc: Julius Werner <jwerner@chromium.org> Cc: Krzysztof Mazur <krzysiek@podlesie.net> Cc: Matthias Beyer <mail@beyermatthias.de> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Mathias Nyman <mathias.nyman@linux.intel.com> Cc: Thomas Pugliese <thomas.pugliese@gmail.com> Signed-off-by: Shaibal Dutta <shaibal.dutta@broadcom.com> Signed-off-by: Zoran Markovic <zoran.markovic@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-01 19:16:46 -08:00
USB: change hub initialization sleeps to delayed_work This patch (as1137) changes the hub_activate() routine, replacing the power-power-up and debounce delays with delayed_work calls. The idea is that on systems where the USB stack is compiled into the kernel rather than built as modules, these delays will no longer block the boot thread. At least 100 ms is saved for each root hub, which can add up to a significant savings in total boot time. Arjan van de Ven was very pleased to see that this shaved 700 ms off his computer's boot time. Since his total boot time is on the order of two seconds, the improvement is considerable. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-22 14:44:26 -04:00
USB: hub: change the locking in hub_activate The locking in hub_activate() is not adequate to provide full mutual exclusion with hub_quiesce(). The subroutine locks the hub's usb_interface, but the callers of hub_quiesce() (such as hub_pre_reset() and hub_event()) hold the lock to the hub's usb_device. This patch changes hub_activate() to make it acquire the same lock as those other routines. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: <stable@vger.kernel.org> #4.4+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-08-05 11:51:30 -04:00
USB: change hub initialization sleeps to delayed_work This patch (as1137) changes the hub_activate() routine, replacing the power-power-up and debounce delays with delayed_work calls. The idea is that on systems where the USB stack is compiled into the kernel rather than built as modules, these delays will no longer block the boot thread. At least 100 ms is saved for each root hub, which can add up to a significant savings in total boot time. Arjan van de Ven was very pleased to see that this shaved 700 ms off his computer's boot time. Since his total boot time is on the order of two seconds, the improvement is considerable. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-22 14:44:26 -04:00
USB: combine hub_activate and hub_restart This patch (as1071) combines hub_activate() and hub_restart() into a single routine. There's no point keeping them separate, since they are always called together. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:17 -04:00
usb: move hub init and LED blink work to power efficient workqueue Allow the scheduler to select the best CPU to handle hub initalization and LED blinking work. This extends idle residency times on idle CPUs and conserves power. This functionality is enabled when CONFIG_WQ_POWER_EFFICIENT is selected. [zoran.markovic@linaro.org: Rebased to latest kernel. Added commit message. Changed reference from system to power efficient workqueue for LEDs in check_highspeed() and hub_port_connect_change().] Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Xenia Ragiadakou <burzalodowa@gmail.com> Cc: Julius Werner <jwerner@chromium.org> Cc: Krzysztof Mazur <krzysiek@podlesie.net> Cc: Matthias Beyer <mail@beyermatthias.de> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Mathias Nyman <mathias.nyman@linux.intel.com> Cc: Thomas Pugliese <thomas.pugliese@gmail.com> Signed-off-by: Shaibal Dutta <shaibal.dutta@broadcom.com> Signed-off-by: Zoran Markovic <zoran.markovic@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-01 19:16:46 -08:00
USB: combine hub_activate and hub_restart This patch (as1071) combines hub_activate() and hub_restart() into a single routine. There's no point keeping them separate, since they are always called together. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:17 -04:00
usb: hub: convert khubd into workqueue There is no need to have separate kthread for handling USB hub events. It is more elegant to use the workqueue framework. The workqueue is allocated as freezable because the original thread was freezable as well. Also it is allocated as ordered because the code is not ready for parallel processing of hub events, see choose_devnum(). struct usb_hub is passed via the work item. Therefore we do not need hub_event_list. Also hub_thread() is not longer needed. It would call only hub_event(). The rest of the code did manipulate the kthread and it is handled by the workqueue framework now. kick_khubd is renamed to kick_hub_wq() to make the function clear. And the protection against races is done another way, see below. hub_event_lock has been removed. It cannot longer be used to protect struct usb_hub between hub_event() and hub_disconnect(). Instead we need to get hub->kref already in kick_hub_wq(). The lock is not really needed for the other scenarios as well. queue_work() returns whether it succeeded. We could revert the needed operations accordingly. This is enough to avoid duplicity and inconsistencies. Yes, the removed lock causes that there is not longer such a strong synchronization between scheduling the work and manipulating hub->disconnected. But kick_hub_wq() must never be called together with hub_disconnect() otherwise even the original code would have failed. Any callers are responsible for this. Therefore the only problem is that hub_disconnect() could be called in parallel with hub_event(). But this was possible even in the past. struct usb_hub is still guarded by hub->kref and released in hub_events() when needed. Note that the source file is still full of the obsolete "khubd" strings. Let's remove them in a follow up patch. This patch already is complex enough. Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to allocate the workqueue. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:21 +02:00
usb: hub: Fix error loop seen after hub communication errors While stress testing a usb controller using a bind/unbind looop, the following error loop was observed. usb 7-1.2: new low-speed USB device number 3 using xhci-hcd usb 7-1.2: hub failed to enable device, error -108 usb 7-1-port2: cannot disable (err = -22) usb 7-1-port2: couldn't allocate usb_device usb 7-1-port2: cannot disable (err = -22) hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: activate --> -22 hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: activate --> -22 hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: activate --> -22 hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: activate --> -22 hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: activate --> -22 hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: activate --> -22 hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: activate --> -22 hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: activate --> -22 hub 7-1:1.0: hub_ext_port_status failed (err = -22) hub 7-1:1.0: hub_ext_port_status failed (err = -22) ** 57 printk messages dropped ** hub 7-1:1.0: activate --> -22 ** 82 printk messages dropped ** hub 7-1:1.0: hub_ext_port_status failed (err = -22) This continues forever. After adding tracebacks into the code, the call sequence leading to this is found to be as follows. [<ffffffc0007fc8e0>] hub_activate+0x368/0x7b8 [<ffffffc0007fceb4>] hub_resume+0x2c/0x3c [<ffffffc00080b3b8>] usb_resume_interface.isra.6+0x128/0x158 [<ffffffc00080b5d0>] usb_suspend_both+0x1e8/0x288 [<ffffffc00080c9c4>] usb_runtime_suspend+0x3c/0x98 [<ffffffc0007820a0>] __rpm_callback+0x48/0x7c [<ffffffc00078217c>] rpm_callback+0xa8/0xd4 [<ffffffc000786234>] rpm_suspend+0x84/0x758 [<ffffffc000786ca4>] rpm_idle+0x2c8/0x498 [<ffffffc000786ed4>] __pm_runtime_idle+0x60/0xac [<ffffffc00080eba8>] usb_autopm_put_interface+0x6c/0x7c [<ffffffc000803798>] hub_event+0x10ac/0x12ac [<ffffffc000249bb8>] process_one_work+0x390/0x6b8 [<ffffffc00024abcc>] worker_thread+0x480/0x610 [<ffffffc000251a80>] kthread+0x164/0x178 [<ffffffc0002045d0>] ret_from_fork+0x10/0x40 kick_hub_wq() is called from hub_activate() even after failures to communicate with the hub. This results in an endless sequence of hub event -> hub activate -> wq trigger -> hub event -> ... Provide two solutions for the problem. - Only trigger the hub event queue if communication with the hub is successful. - After a suspend failure, only resume already suspended interfaces if the communication with the device is still possible. Each of the changes fixes the observed problem. Use both to improve robustness. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-20 11:16:11 -07:00
USB: hub: fix up early-exit pathway in hub_activate The early-exit pathway in hub_activate, added by commit e50293ef9775 ("USB: fix invalid memory access in hub_activate()") needs improvement. It duplicates code that is already present at the end of the subroutine, and it neglects to undo the effect of a usb_autopm_get_interface_no_resume() call. This patch fixes both problems by making the early-exit pathway jump directly to the end of the subroutine. It simplifies the code at the end by merging two conditionals that actually test the same condition although they appear different: If type < HUB_INIT3 then type must be either HUB_INIT2 or HUB_INIT, and it can't be HUB_INIT because in that case the subroutine would have exited earlier. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: <stable@vger.kernel.org> #4.4+ Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-08-05 11:49:45 -04:00
USB: prepare for changover to Runtime PM framework This patch (as1303) revises the USB Power Management infrastructure to make it compatible with the new driver-model Runtime PM framework: Drivers are no longer allowed to access intf->pm_usage_cnt directly; the PM framework manages its own usage counters. usb_autopm_set_interface() is eliminated, because it directly sets intf->pm_usage_cnt. usb_autopm_enable() and usb_autopm_disable() are eliminated, because they call usb_autopm_set_interface(). usb_autopm_get_interface_no_resume() and usb_autopm_put_interface_no_suspend() are added. They correspond to pm_runtime_get_noresume() and pm_runtime_put_noidle() in the PM framework. The power/level attribute no longer accepts "suspend", only "on" and "auto". The PM framework doesn't allow devices to be forced into a suspended mode. The hub driver contains the only code that violates the new guidelines. It is updated to use the new interface routines instead. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-07 13:01:37 -05:00
USB: hub: change the locking in hub_activate The locking in hub_activate() is not adequate to provide full mutual exclusion with hub_quiesce(). The subroutine locks the hub's usb_interface, but the callers of hub_quiesce() (such as hub_pre_reset() and hub_event()) hold the lock to the hub's usb_device. This patch changes hub_activate() to make it acquire the same lock as those other routines. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: <stable@vger.kernel.org> #4.4+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-08-05 11:51:30 -04:00
USB: hub: fix up early-exit pathway in hub_activate The early-exit pathway in hub_activate, added by commit e50293ef9775 ("USB: fix invalid memory access in hub_activate()") needs improvement. It duplicates code that is already present at the end of the subroutine, and it neglects to undo the effect of a usb_autopm_get_interface_no_resume() call. This patch fixes both problems by making the early-exit pathway jump directly to the end of the subroutine. It simplifies the code at the end by merging two conditionals that actually test the same condition although they appear different: If type < HUB_INIT3 then type must be either HUB_INIT2 or HUB_INIT, and it can't be HUB_INIT because in that case the subroutine would have exited earlier. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: <stable@vger.kernel.org> #4.4+ Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-08-05 11:49:45 -04:00
USB: fix invalid memory access in hub_activate() Commit 8520f38099cc ("USB: change hub initialization sleeps to delayed_work") changed the hub_activate() routine to make part of it run in a workqueue. However, the commit failed to take a reference to the usb_hub structure or to lock the hub interface while doing so. As a result, if a hub is plugged in and quickly unplugged before the work routine can run, the routine will try to access memory that has been deallocated. Or, if the hub is unplugged while the routine is running, the memory may be deallocated while it is in active use. This patch fixes the problem by taking a reference to the usb_hub at the start of hub_activate() and releasing it at the end (when the work is finished), and by locking the hub interface while the work routine is running. It also adds a check at the start of the routine to see if the hub has already been disconnected, in which nothing should be done. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Alexandru Cornea <alexandru.cornea@intel.com> Tested-by: Alexandru Cornea <alexandru.cornea@intel.com> Fixes: 8520f38099cc ("USB: change hub initialization sleeps to delayed_work") CC: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-16 13:32:38 -05:00
USB: core: Add hub_get() and hub_put() routines Create hub_get() and hub_put() routines to encapsulate the kref_get() and kref_put() calls in hub.c. The new routines will be used by the next patch in this series. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/604da420-ae8a-4a9e-91a4-2d511ff404fb@rowland.harvard.edu Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-15 13:04:50 -04:00
USB: make USB-PERSIST work after every system sleep This patch (as1046) makes USB-PERSIST work more in accordance with the documentation. Currently it takes effect only in cases where the root hub has lost power or been reset, but it is supposed to operate whenever a power session was dropped during a system sleep. A new hub_restart() routine carries out the duties required during a reset or a reset-resume. It checks to see whether occupied ports are still enabled, and if they aren't then it clears the enable-change and connect-change features (to prevent interference by khubd) and sets the child device's reset_resume flag. It also checks ports that are supposed to be unoccupied to verify that the firmware hasn't left the port in an enabled state. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-03 15:15:51 -05:00
USB: change hub initialization sleeps to delayed_work This patch (as1137) changes the hub_activate() routine, replacing the power-power-up and debounce delays with delayed_work calls. The idea is that on systems where the USB stack is compiled into the kernel rather than built as modules, these delays will no longer block the boot thread. At least 100 ms is saved for each root hub, which can add up to a significant savings in total boot time. Arjan van de Ven was very pleased to see that this shaved 700 ms off his computer's boot time. Since his total boot time is on the order of two seconds, the improvement is considerable. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-22 14:44:26 -04:00
USB: combine hub_quiesce and hub_stop This patch (as1083) combines hub_quiesce() and hub_stop() into a single routine. There's no point keeping them separate since they are usually called together. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:31 -04:00
usb: hub: add retry routine after intr URB submit error The hub sends hot-plug events to the host trough it's interrupt URB. The driver takes care of completing the URB and re-submitting it. Completion errors are handled in the hub_event() work, yet submission errors are ignored, rendering the device unresponsive. All further events are lost. It is fairly hard to find this issue in the wild, since you have to time the USB hot-plug event with the URB submission failure. For instance it could be the system running out of memory or some malfunction in the USB controller driver. Nevertheless, it's pretty reasonable to think it'll happen sometime. One can trigger this issue using eBPF's function override feature (see BCC's inject.py script). This patch adds a retry routine to the event of a submission error. The HUB driver will try to re-submit the URB once every second until it's successful or the HUB is disconnected. As some USB subsystems already take care of this issue, the implementation was inspired from usbhid/hid_core.c's. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Oliver Neukum <oneukum@suse.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-08 16:45:22 +01:00
USB: combine hub_quiesce and hub_stop This patch (as1083) combines hub_quiesce() and hub_stop() into a single routine. There's no point keeping them separate since they are usually called together. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:31 -04:00
usb: hub: rename khubd to hub_wq in documentation and comments USB hub has started to use a workqueue instead of kthread. Let's update the documentation and comments here and there. This patch mostly just replaces "khubd" with "hub_wq". There are only few exceptions where the whole sentence was updated. These more complicated changes can be found in the following files: Documentation/usb/hotplug.txt drivers/net/usb/usbnet.c drivers/usb/core/hcd.c drivers/usb/host/ohci-hcd.c drivers/usb/host/xhci.c Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:23 +02:00
usb: hub: add retry routine after intr URB submit error The hub sends hot-plug events to the host trough it's interrupt URB. The driver takes care of completing the URB and re-submitting it. Completion errors are handled in the hub_event() work, yet submission errors are ignored, rendering the device unresponsive. All further events are lost. It is fairly hard to find this issue in the wild, since you have to time the USB hot-plug event with the URB submission failure. For instance it could be the system running out of memory or some malfunction in the USB controller driver. Nevertheless, it's pretty reasonable to think it'll happen sometime. One can trigger this issue using eBPF's function override feature (see BCC's inject.py script). This patch adds a retry routine to the event of a submission error. The HUB driver will try to re-submit the URB once every second until it's successful or the HUB is disconnected. As some USB subsystems already take care of this issue, the implementation was inspired from usbhid/hid_core.c's. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Oliver Neukum <oneukum@suse.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-08 16:45:22 +01:00
USB: combine hub_quiesce and hub_stop This patch (as1083) combines hub_quiesce() and hub_stop() into a single routine. There's no point keeping them separate since they are usually called together. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:31 -04:00
usb: hub: add retry routine after intr URB submit error The hub sends hot-plug events to the host trough it's interrupt URB. The driver takes care of completing the URB and re-submitting it. Completion errors are handled in the hub_event() work, yet submission errors are ignored, rendering the device unresponsive. All further events are lost. It is fairly hard to find this issue in the wild, since you have to time the USB hot-plug event with the URB submission failure. For instance it could be the system running out of memory or some malfunction in the USB controller driver. Nevertheless, it's pretty reasonable to think it'll happen sometime. One can trigger this issue using eBPF's function override feature (see BCC's inject.py script). This patch adds a retry routine to the event of a submission error. The HUB driver will try to re-submit the URB once every second until it's successful or the HUB is disconnected. As some USB subsystems already take care of this issue, the implementation was inspired from usbhid/hid_core.c's. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Oliver Neukum <oneukum@suse.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-08 16:45:22 +01:00
USB: combine hub_quiesce and hub_stop This patch (as1083) combines hub_quiesce() and hub_stop() into a single routine. There's no point keeping them separate since they are usually called together. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:31 -04:00
usb: move children to struct usb_port The usb_device structure contains an array of usb_device "children". This array is only valid if the usb_device is a hub, so it makes no sense to store it there. Instead, store the usb_device child in its parent usb_port structure. Since usb_port is an internal USB core structure, add a new function to get the USB device child, usb_hub_find_child(). Add a new macro, usb_hub_get_each_child(), to iterate over all the children attached to a particular USB hub. Remove the printing the USB children array pointer from the usb-ip driver, since it's really not necessary. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-05 13:44:32 +08:00
USB: combine hub_quiesce and hub_stop This patch (as1083) combines hub_quiesce() and hub_stop() into a single routine. There's no point keeping them separate since they are usually called together. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:31 -04:00
usb: hub: rename khubd to hub_wq in documentation and comments USB hub has started to use a workqueue instead of kthread. Let's update the documentation and comments here and there. This patch mostly just replaces "khubd" with "hub_wq". There are only few exceptions where the whole sentence was updated. These more complicated changes can be found in the following files: Documentation/usb/hotplug.txt drivers/net/usb/usbnet.c drivers/usb/core/hcd.c drivers/usb/host/ohci-hcd.c drivers/usb/host/xhci.c Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:23 +02:00
usb: hub: add retry routine after intr URB submit error The hub sends hot-plug events to the host trough it's interrupt URB. The driver takes care of completing the URB and re-submitting it. Completion errors are handled in the hub_event() work, yet submission errors are ignored, rendering the device unresponsive. All further events are lost. It is fairly hard to find this issue in the wild, since you have to time the USB hot-plug event with the URB submission failure. For instance it could be the system running out of memory or some malfunction in the USB controller driver. Nevertheless, it's pretty reasonable to think it'll happen sometime. One can trigger this issue using eBPF's function override feature (see BCC's inject.py script). This patch adds a retry routine to the event of a submission error. The HUB driver will try to re-submit the URB once every second until it's successful or the HUB is disconnected. As some USB subsystems already take care of this issue, the implementation was inspired from usbhid/hid_core.c's. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Oliver Neukum <oneukum@suse.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-08 16:45:22 +01:00
USB: combine hub_quiesce and hub_stop This patch (as1083) combines hub_quiesce() and hub_stop() into a single routine. There's no point keeping them separate since they are usually called together. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:31 -04:00
usb hub: use flush_work instead of flush_work_sync flush_work_sync and flush_work are now the same and flush_work_sync has been deprecated. This fixes the following warning: drivers/usb/core/hub.c: In function hub_quiesce: drivers/usb/core/hub.c:1216:3: warning: flush_work_sync is deprecated (declared at include/linux/workqueue.h:448) [-Wdeprecated-declarations] Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Octavian Purdila <octavian.purdila@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-23 11:33:12 +03:00
USB: combine hub_quiesce and hub_stop This patch (as1083) combines hub_quiesce() and hub_stop() into a single routine. There's no point keeping them separate since they are usually called together. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:31 -04:00
USB: mutual exclusion for resetting a hub and power-managing a port The USB core doesn't properly handle mutual exclusion between resetting a hub and changing the power states of the hub's ports. We need to avoid sending port-power requests to the hub while it is being reset, because such requests cannot succeed. This patch fixes the problem by keeping track of when a reset is in progress. At such times, attempts to suspend (power-off) a port will fail immediately with -EBUSY, and calls to usb_port_runtime_resume() will update the power_is_on flag and return immediately. When the reset is complete, hub_activate() will automatically restore each port to the proper power state. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:07 -07:00
USB: reorganize code in hub.c This patch (as1045) reorganizes some code in the hub driver. hub_port_status() is moved earlier in the file, and a new hub_stop() routine is created to do the work currently in hub_preset() (i.e., disconnect all child devices and quiesce the hub). There are no functional changes. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-03 15:15:43 -05:00
USB: combine hub_quiesce and hub_stop This patch (as1083) combines hub_quiesce() and hub_stop() into a single routine. There's no point keeping them separate since they are usually called together. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:31 -04:00
USB: mutual exclusion for resetting a hub and power-managing a port The USB core doesn't properly handle mutual exclusion between resetting a hub and changing the power states of the hub's ports. We need to avoid sending port-power requests to the hub while it is being reset, because such requests cannot succeed. This patch fixes the problem by keeping track of when a reset is in progress. At such times, attempts to suspend (power-off) a port will fail immediately with -EBUSY, and calls to usb_port_runtime_resume() will update the power_is_on flag and return immediately. When the reset is complete, hub_activate() will automatically restore each port to the proper power state. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:07 -07:00
USB: add reset_resume method This patch (as918) introduces a new USB driver method: reset_resume. It is called when a device needs to be reset as part of a resume procedure (whether because of a device quirk or because of the USB-Persist facility), thereby taking over a role formerly assigned to the post_reset method. As a consequence, post_reset no longer needs an argument indicating whether it is being called as part of a reset-resume. This separation of functions makes the code clearer. In addition, the pre_reset and post_reset method return types are changed; they now must return an error code. The return value is unused at present, but at some later time we may unbind drivers and re-probe if they encounter an error during reset handling. The existing pre_reset and post_reset methods in the usbhid, usb-storage, and hub drivers are updated to match the new requirements. For usbhid the post_reset routine is also used for reset_resume (duplicate method pointers); for the other drivers a new reset_resume routine is added. The change to hub.c looks bigger than it really is, because mark_children_for_reset_resume() gets moved down next to the new hub_reset_resume() routine. A minor change to usb-storage makes the usb_stor_report_bus_reset() routine acquire the host lock instead of requiring the caller to hold it already. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Jiri Kosina <jkosina@suse.cz> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:38:16 -04:00
[PATCH] USB: Disconnect children during hub unbind This patch (as606b) is an updated version of my earlier patch to disconnect children from a hub device when the hub driver is unbound. Thanks to the changes in the driver core locking, we now know that the entire hub device (and not just the interface) is locked whenever the hub driver's disconnect method runs. Hence it is safe to disconnect the child device structures immediately instead of deferring the job. The earlier version of the patch neglected to disable the hub's ports. We don't want to forget that; otherwise we'd end up with live devices using addresses that have been recycled. This update adds the necessary code. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-18 12:06:34 -05:00
USB: add reset_resume method This patch (as918) introduces a new USB driver method: reset_resume. It is called when a device needs to be reset as part of a resume procedure (whether because of a device quirk or because of the USB-Persist facility), thereby taking over a role formerly assigned to the post_reset method. As a consequence, post_reset no longer needs an argument indicating whether it is being called as part of a reset-resume. This separation of functions makes the code clearer. In addition, the pre_reset and post_reset method return types are changed; they now must return an error code. The return value is unused at present, but at some later time we may unbind drivers and re-probe if they encounter an error during reset handling. The existing pre_reset and post_reset methods in the usbhid, usb-storage, and hub drivers are updated to match the new requirements. For usbhid the post_reset routine is also used for reset_resume (duplicate method pointers); for the other drivers a new reset_resume routine is added. The change to hub.c looks bigger than it really is, because mark_children_for_reset_resume() gets moved down next to the new hub_reset_resume() routine. A minor change to usb-storage makes the usb_stor_report_bus_reset() routine acquire the host lock instead of requiring the caller to hold it already. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Jiri Kosina <jkosina@suse.cz> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:38:16 -04:00
[PATCH] USB: Disconnect children during hub unbind This patch (as606b) is an updated version of my earlier patch to disconnect children from a hub device when the hub driver is unbound. Thanks to the changes in the driver core locking, we now know that the entire hub device (and not just the interface) is locked whenever the hub driver's disconnect method runs. Hence it is safe to disconnect the child device structures immediately instead of deferring the job. The earlier version of the patch neglected to disable the hub's ports. We don't want to forget that; otherwise we'd end up with live devices using addresses that have been recycled. This update adds the necessary code. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-18 12:06:34 -05:00
[PATCH] USB hub: use usb_reset_composite_device This patch (as700) modifies the hub driver to take advantage of the new usb_reset_composite_device API. The existing code had special-case calls stuck into usb_reset_device, just before and after the reset. With the new version there's no need for special-case stuff; it all happens naturally in the form of pre_reset and post_reset notifications. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-01 13:37:24 -04:00
USB: mutual exclusion for resetting a hub and power-managing a port The USB core doesn't properly handle mutual exclusion between resetting a hub and changing the power states of the hub's ports. We need to avoid sending port-power requests to the hub while it is being reset, because such requests cannot succeed. This patch fixes the problem by keeping track of when a reset is in progress. At such times, attempts to suspend (power-off) a port will fail immediately with -EBUSY, and calls to usb_port_runtime_resume() will update the power_is_on flag and return immediately. When the reset is complete, hub_activate() will automatically restore each port to the proper power state. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:07 -07:00
USB: combine hub_activate and hub_restart This patch (as1071) combines hub_activate() and hub_restart() into a single routine. There's no point keeping them separate, since they are always called together. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:17 -04:00
USB: add reset_resume method This patch (as918) introduces a new USB driver method: reset_resume. It is called when a device needs to be reset as part of a resume procedure (whether because of a device quirk or because of the USB-Persist facility), thereby taking over a role formerly assigned to the post_reset method. As a consequence, post_reset no longer needs an argument indicating whether it is being called as part of a reset-resume. This separation of functions makes the code clearer. In addition, the pre_reset and post_reset method return types are changed; they now must return an error code. The return value is unused at present, but at some later time we may unbind drivers and re-probe if they encounter an error during reset handling. The existing pre_reset and post_reset methods in the usbhid, usb-storage, and hub drivers are updated to match the new requirements. For usbhid the post_reset routine is also used for reset_resume (duplicate method pointers); for the other drivers a new reset_resume routine is added. The change to hub.c looks bigger than it really is, because mark_children_for_reset_resume() gets moved down next to the new hub_reset_resume() routine. A minor change to usb-storage makes the usb_stor_report_bus_reset() routine acquire the host lock instead of requiring the caller to hold it already. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Jiri Kosina <jkosina@suse.cz> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:38:16 -04:00
[PATCH] USB: Disconnect children during hub unbind This patch (as606b) is an updated version of my earlier patch to disconnect children from a hub device when the hub driver is unbound. Thanks to the changes in the driver core locking, we now know that the entire hub device (and not just the interface) is locked whenever the hub driver's disconnect method runs. Hence it is safe to disconnect the child device structures immediately instead of deferring the job. The earlier version of the patch neglected to disable the hub's ports. We don't want to forget that; otherwise we'd end up with live devices using addresses that have been recycled. This update adds the necessary code. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-18 12:06:34 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: Add hub descriptor update hook for xHCI Add a hook for updating xHCI internal structures after khubd fetches the hub descriptor and sets up the hub's TT information. The xHCI driver must update the internal structures before devices under the hub can be enumerated. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-09-04 10:53:24 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] USB: make wHubCharacteristics __le16 to match other usb descriptor fields Also has the nice benefit of making sparc alignment issues go away. Thanks to David Miller for pointing out the problems here. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> drivers/usb/core/hub.c | 22 ++++++++++++---------- drivers/usb/core/hub.h | 2 +- 2 files changed, 13 insertions(+), 11 deletions(-)
2005-06-20 21:15:16 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: make usb port a real device This patch turns each USB port on a hub into a new struct device. This new device has the USB hub interface device as its parent. The port devices are stored in a new structure (usb_port), and an array of usb_ports are dynamically allocated once we know how many ports the USB hub has. Move the port_owner variable out of usb_hub and into this new structure. A new file will be created in the hub interface sysfs directory, so add documentation. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-05 13:44:31 +08:00
USB: add API for userspace drivers to "claim" ports This patch (as1258) implements a feature that users have been asking for: It gives programs the ability to "claim" a port on a hub, via a new usbfs ioctl. A device plugged into a "claimed" port will not be touched by the kernel beyond the immediate necessities of initialization and enumeration. In particular, when a device is plugged into a "claimed" port, the kernel will not select and install a configuration. And when a config is installed by usbfs or sysfs, the kernel will not probe any drivers for any of the interfaces. (However the kernel will fetch various string descriptors during enumeration. One could argue that this isn't really necessary, but the strings are exported in sysfs.) The patch does not guarantee exclusive access to these devices; it is still possible for more than one program to open the device file concurrently. Programs are responsible for coordinating access among themselves. A demonstration program showing how to use the new interface can be found in an attachment to http://marc.info/?l=linux-usb&m=124345857431452&w=2 The patch also makes a small simplification to the hub driver, replacing a bunch of more-or-less useless variants of "out of memory" with a single message. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:56:54 -04:00
usb/core: update power budget for SuperSpeed Sarah pointed out that the USB3.0 spec also updates the amount of power that may be consumed by the device and quoted 9.2.5.1: |"The amount of current draw for SuperSpeed devices are increased to 150 |mA for low-power devices and 900 mA for high-power" This patch tries to update all users to use the larger values for SuperSpeed devices and use the "old" ones for everything else. While here, two other changes suggested by Alan: - the comment referering to 7.2.1.1 has been updated to 7.2.1 which is the correct source of the action. - the check for hubs with zero ports has been removed. - compute bus power by full_load * num_ports on root hubs Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-12-18 15:25:47 +01:00
usb: assign default peer ports for root hubs Assume that the peer of a superspeed port is the port with the same id on the shared_hcd root hub. This identification scheme is required of external hubs by the USB3 spec [1]. However, for root hubs, tier mismatch may be in effect [2]. Tier mismatch can only be enumerated via platform firmware. For now, simply perform the nominal association. A new lock 'usb_port_peer_mutex' is introduced to synchronize port device add/remove with peer lookups. It protects peering against changes to hcd->shared_hcd, hcd->self.root_hub, hdev->maxchild, and port_dev->child pointers. [1]: usb 3.1 section 10.3.3 [2]: xhci 1.1 appendix D Cc: Alan Stern <stern@rowland.harvard.edu> [alan: usb_port_peer_mutex locking scheme] Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:28 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: don't use a fixed DMA mapping for hub status URBs This patch (as1296) gets rid of the fixed DMA-buffer mapping used by the hub driver for its status URB. This URB doesn't get used much -- mainly when a device is plugged in or unplugged -- so the dynamic mapping overhead is minimal. And most systems have many fewer external hubs than root hubs, which don't need a mapped buffer anyway. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 15:18:46 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: fix concurrent buffer access in the hub driver This patch (as849) fixes a bug in the USB hub driver. A single pre-allocated buffer is used for all port status reads, but nothing guarantees exclusive use of the buffer. A mutex is added to provide this guarantee. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-02-05 09:56:15 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: hub: fix non-SS hub-descriptor handling Add missing sanity check on the non-SuperSpeed hub-descriptor length in order to avoid parsing and leaking two bytes of uninitialised slab data through sysfs removable-attributes (or a compound-device debug statement). Note that we only make sure that the DeviceRemovable field is always present (and specifically ignore the unused PortPwrCtrlMask field) in order to continue support any hubs with non-compliant descriptors. As a further safeguard, the descriptor buffer is also cleared. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable <stable@vger.kernel.org> # 2.6.12 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>
2017-05-10 18:18:28 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: hub: fix SS hub-descriptor handling A SuperSpeed hub descriptor does not have any variable-length fields so bail out when reading a short descriptor. This avoids parsing and leaking two bytes of uninitialised slab data through sysfs removable-attributes. Fixes: dbe79bbe9dcb ("USB 3.0 Hub Changes") Cc: stable <stable@vger.kernel.org> # 2.6.39 Cc: John Youn <John.Youn@synopsys.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-05-10 18:18:27 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB 3.0 Hub Changes Update the USB core to deal with USB 3.0 hubs. These hubs have a slightly different hub descriptor than USB 2.0 hubs, with a fixed (rather than variable length) size. Change the USB core's hub descriptor to have a union for the last fields that differ. Change the host controller drivers that access those last fields (DeviceRemovable and PortPowerCtrlMask) to use the union. Translate the new version of the hub port status field into the old version that khubd understands. (Note: we need to fix it to translate the roothub's port status once we stop converting it to USB 2.0 hub status internally.) Add new code to handle link state change status. Send out new control messages that are needed for USB 3.0 hubs, like Set Hub Depth. This patch is a modified version of the original patch submitted by John Youn. It's updated to reflect the removal of the "bitmap" #define, and change the hub descriptor accesses of a couple new host controller drivers. Signed-off-by: John Youn <johnyoun@synopsys.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com> Cc: Tony Olech <tony.olech@elandigitalsystems.com> Cc: "Robert P. J. Day" <rpjday@crashcourse.ca> Cc: Max Vozeler <mvz@vozeler.com> Cc: Tejun Heo <tj@kernel.org> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Cc: Rodolfo Giometti <giometti@linux.it> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Anton Vorontsov <avorontsov@mvista.com> Cc: Sebastian Siewior <bigeasy@linutronix.de> Cc: Lothar Wassmann <LW@KARO-electronics.de> Cc: Olav Kongas <ok@artecdesign.ee> Cc: Martin Fuzzey <mfuzzey@gmail.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: David Brownell <dbrownell@users.sourceforge.net>
2001-09-17 00:00:00 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: hub: fix SS max number of ports Add define for the maximum number of ports on a SuperSpeed hub as per USB 3.1 spec Table 10-5, and use it when verifying the retrieved hub descriptor. This specifically avoids benign attempts to update the DeviceRemovable mask for non-existing ports (should we get that far). Fixes: dbe79bbe9dcb ("USB 3.0 Hub Changes") Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-05-10 18:18:29 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: hub: Avoid NULL pointer dereference when hub doesn't have any ports Return an error if hub->descriptor->bNbrPorts==0. Without this additional check, we can end up doing a "hub->ports = kzalloc(0, GFP_KERNEL)". This hub->ports pointer will therefore be non-NULL and will be used. Example of dmesg: INIT: usb 1-1: New USB device found, idVendor=0424, idProduct=2512 usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 hub 1-1:1.0: USB hub found version 2.86 bootinghub 1-1:1.0: 0 ports detected Unable to handle kernel NULL pointer dereference at virtual address 00000010 Signed-off-by: David Linares <dlinares.linux@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-25 10:50:27 +00:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: add support for USB_REQ_SET_ISOCH_DELAY USB SS and SSP hubs provide wHubDelay values on their hub descriptor which we should inform the USB Device about. The USB Specification 3.0 explains, on section 9.4.11, how to calculate the value and how to issue the request. Note that a USB_REQ_SET_ISOCH_DELAY is valid on all device states (Default, Address, Configured), we just *chose* to issue it from Address state right after successfully fetching the USB Device Descriptor. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-14 09:50:39 +02:00
usb: assign default peer ports for root hubs Assume that the peer of a superspeed port is the port with the same id on the shared_hcd root hub. This identification scheme is required of external hubs by the USB3 spec [1]. However, for root hubs, tier mismatch may be in effect [2]. Tier mismatch can only be enumerated via platform firmware. For now, simply perform the nominal association. A new lock 'usb_port_peer_mutex' is introduced to synchronize port device add/remove with peer lookups. It protects peering against changes to hcd->shared_hcd, hcd->self.root_hub, hdev->maxchild, and port_dev->child pointers. [1]: usb 3.1 section 10.3.3 [2]: xhci 1.1 appendix D Cc: Alan Stern <stern@rowland.harvard.edu> [alan: usb_port_peer_mutex locking scheme] Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:28 -07:00
USB: Use str_enable_disable-like helpers Replace ternary (condition ? "enable" : "disable") syntax with helpers from string_choices.h because: 1. Simple function call with one argument is easier to read. Ternary operator has three arguments and with wrapping might lead to quite long code. 2. Is slightly shorter thus also easier to read. 3. It brings uniformity in the text - same string. 4. Allows deduping by the linker, which results in a smaller binary file. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250114-str-enable-disable-usb-v1-6-c8405df47c19@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-14 21:05:39 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
treewide: kzalloc() -> kcalloc() The kzalloc() function has a 2-factor argument form, kcalloc(). This patch replaces cases of: kzalloc(a * b, gfp) with: kcalloc(a * b, gfp) as well as handling cases of: kzalloc(a * b * c, gfp) with: kzalloc(array3_size(a, b, c), gfp) as it's slightly less ugly than: kzalloc_array(array_size(a, b), c, gfp) This does, however, attempt to ignore constant size factors like: kzalloc(4 * 1024, gfp) though any constants defined via macros get caught up in the conversion. Any factors with a sizeof() of "unsigned char", "char", and "u8" were dropped, since they're redundant. The Coccinelle script used for this was: // Fix redundant parens around sizeof(). @@ type TYPE; expression THING, E; @@ ( kzalloc( - (sizeof(TYPE)) * E + sizeof(TYPE) * E , ...) | kzalloc( - (sizeof(THING)) * E + sizeof(THING) * E , ...) ) // Drop single-byte sizes and redundant parens. @@ expression COUNT; typedef u8; typedef __u8; @@ ( kzalloc( - sizeof(u8) * (COUNT) + COUNT , ...) | kzalloc( - sizeof(__u8) * (COUNT) + COUNT , ...) | kzalloc( - sizeof(char) * (COUNT) + COUNT , ...) | kzalloc( - sizeof(unsigned char) * (COUNT) + COUNT , ...) | kzalloc( - sizeof(u8) * COUNT + COUNT , ...) | kzalloc( - sizeof(__u8) * COUNT + COUNT , ...) | kzalloc( - sizeof(char) * COUNT + COUNT , ...) | kzalloc( - sizeof(unsigned char) * COUNT + COUNT , ...) ) // 2-factor product with sizeof(type/expression) and identifier or constant. @@ type TYPE; expression THING; identifier COUNT_ID; constant COUNT_CONST; @@ ( - kzalloc + kcalloc ( - sizeof(TYPE) * (COUNT_ID) + COUNT_ID, sizeof(TYPE) , ...) | - kzalloc + kcalloc ( - sizeof(TYPE) * COUNT_ID + COUNT_ID, sizeof(TYPE) , ...) | - kzalloc + kcalloc ( - sizeof(TYPE) * (COUNT_CONST) + COUNT_CONST, sizeof(TYPE) , ...) | - kzalloc + kcalloc ( - sizeof(TYPE) * COUNT_CONST + COUNT_CONST, sizeof(TYPE) , ...) | - kzalloc + kcalloc ( - sizeof(THING) * (COUNT_ID) + COUNT_ID, sizeof(THING) , ...) | - kzalloc + kcalloc ( - sizeof(THING) * COUNT_ID + COUNT_ID, sizeof(THING) , ...) | - kzalloc + kcalloc ( - sizeof(THING) * (COUNT_CONST) + COUNT_CONST, sizeof(THING) , ...) | - kzalloc + kcalloc ( - sizeof(THING) * COUNT_CONST + COUNT_CONST, sizeof(THING) , ...) ) // 2-factor product, only identifiers. @@ identifier SIZE, COUNT; @@ - kzalloc + kcalloc ( - SIZE * COUNT + COUNT, SIZE , ...) // 3-factor product with 1 sizeof(type) or sizeof(expression), with // redundant parens removed. @@ expression THING; identifier STRIDE, COUNT; type TYPE; @@ ( kzalloc( - sizeof(TYPE) * (COUNT) * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | kzalloc( - sizeof(TYPE) * (COUNT) * STRIDE + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | kzalloc( - sizeof(TYPE) * COUNT * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | kzalloc( - sizeof(TYPE) * COUNT * STRIDE + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | kzalloc( - sizeof(THING) * (COUNT) * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | kzalloc( - sizeof(THING) * (COUNT) * STRIDE + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | kzalloc( - sizeof(THING) * COUNT * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | kzalloc( - sizeof(THING) * COUNT * STRIDE + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) ) // 3-factor product with 2 sizeof(variable), with redundant parens removed. @@ expression THING1, THING2; identifier COUNT; type TYPE1, TYPE2; @@ ( kzalloc( - sizeof(TYPE1) * sizeof(TYPE2) * COUNT + array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2)) , ...) | kzalloc( - sizeof(TYPE1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2)) , ...) | kzalloc( - sizeof(THING1) * sizeof(THING2) * COUNT + array3_size(COUNT, sizeof(THING1), sizeof(THING2)) , ...) | kzalloc( - sizeof(THING1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(THING1), sizeof(THING2)) , ...) | kzalloc( - sizeof(TYPE1) * sizeof(THING2) * COUNT + array3_size(COUNT, sizeof(TYPE1), sizeof(THING2)) , ...) | kzalloc( - sizeof(TYPE1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(TYPE1), sizeof(THING2)) , ...) ) // 3-factor product, only identifiers, with redundant parens removed. @@ identifier STRIDE, SIZE, COUNT; @@ ( kzalloc( - (COUNT) * STRIDE * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | kzalloc( - COUNT * (STRIDE) * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | kzalloc( - COUNT * STRIDE * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | kzalloc( - (COUNT) * (STRIDE) * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | kzalloc( - COUNT * (STRIDE) * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | kzalloc( - (COUNT) * STRIDE * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | kzalloc( - (COUNT) * (STRIDE) * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | kzalloc( - COUNT * STRIDE * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) ) // Any remaining multi-factor products, first at least 3-factor products, // when they're not all constants... @@ expression E1, E2, E3; constant C1, C2, C3; @@ ( kzalloc(C1 * C2 * C3, ...) | kzalloc( - (E1) * E2 * E3 + array3_size(E1, E2, E3) , ...) | kzalloc( - (E1) * (E2) * E3 + array3_size(E1, E2, E3) , ...) | kzalloc( - (E1) * (E2) * (E3) + array3_size(E1, E2, E3) , ...) | kzalloc( - E1 * E2 * E3 + array3_size(E1, E2, E3) , ...) ) // And then all remaining 2 factors products when they're not all constants, // keeping sizeof() as the second factor argument. @@ expression THING, E1, E2; type TYPE; constant C1, C2, C3; @@ ( kzalloc(sizeof(THING) * C2, ...) | kzalloc(sizeof(TYPE) * C2, ...) | kzalloc(C1 * C2 * C3, ...) | kzalloc(C1 * C2, ...) | - kzalloc + kcalloc ( - sizeof(TYPE) * (E2) + E2, sizeof(TYPE) , ...) | - kzalloc + kcalloc ( - sizeof(TYPE) * E2 + E2, sizeof(TYPE) , ...) | - kzalloc + kcalloc ( - sizeof(THING) * (E2) + E2, sizeof(THING) , ...) | - kzalloc + kcalloc ( - sizeof(THING) * E2 + E2, sizeof(THING) , ...) | - kzalloc + kcalloc ( - (E1) * E2 + E1, E2 , ...) | - kzalloc + kcalloc ( - (E1) * (E2) + E1, E2 , ...) | - kzalloc + kcalloc ( - E1 * E2 + E1, E2 , ...) ) Signed-off-by: Kees Cook <keescook@chromium.org>
2018-06-12 14:03:40 -07:00
usb: move children to struct usb_port The usb_device structure contains an array of usb_device "children". This array is only valid if the usb_device is a hub, so it makes no sense to store it there. Instead, store the usb_device child in its parent usb_port structure. Since usb_port is an internal USB core structure, add a new function to get the USB device child, usb_hub_find_child(). Add a new macro, usb_hub_get_each_child(), to iterate over all the children attached to a particular USB hub. Remove the printing the USB children array pointer from the usb-ip driver, since it's really not necessary. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-05 13:44:32 +08:00
USB: add API for userspace drivers to "claim" ports This patch (as1258) implements a feature that users have been asking for: It gives programs the ability to "claim" a port on a hub, via a new usbfs ioctl. A device plugged into a "claimed" port will not be touched by the kernel beyond the immediate necessities of initialization and enumeration. In particular, when a device is plugged into a "claimed" port, the kernel will not select and install a configuration. And when a config is installed by usbfs or sysfs, the kernel will not probe any drivers for any of the interfaces. (However the kernel will fetch various string descriptors during enumeration. One could argue that this isn't really necessary, but the strings are exported in sysfs.) The patch does not guarantee exclusive access to these devices; it is still possible for more than one program to open the device file concurrently. Programs are responsible for coordinating access among themselves. A demonstration program showing how to use the new interface can be found in an attachment to http://marc.info/?l=linux-usb&m=124345857431452&w=2 The patch also makes a small simplification to the hub driver, replacing a bunch of more-or-less useless variants of "out of memory" with a single message. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:56:54 -04:00
[PATCH] USB: make wHubCharacteristics __le16 to match other usb descriptor fields Also has the nice benefit of making sparc alignment issues go away. Thanks to David Miller for pointing out the problems here. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> drivers/usb/core/hub.c | 22 ++++++++++++---------- drivers/usb/core/hub.h | 2 +- 2 files changed, 13 insertions(+), 11 deletions(-)
2005-06-20 21:15:16 -07:00
usb/core: update power budget for SuperSpeed Sarah pointed out that the USB3.0 spec also updates the amount of power that may be consumed by the device and quoted 9.2.5.1: |"The amount of current draw for SuperSpeed devices are increased to 150 |mA for low-power devices and 900 mA for high-power" This patch tries to update all users to use the larger values for SuperSpeed devices and use the "old" ones for everything else. While here, two other changes suggested by Alan: - the comment referering to 7.2.1.1 has been updated to 7.2.1 which is the correct source of the action. - the check for hubs with zero ports has been removed. - compute bus power by full_load * num_ports on root hubs Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-12-18 15:25:47 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB 3.0 Hub Changes Update the USB core to deal with USB 3.0 hubs. These hubs have a slightly different hub descriptor than USB 2.0 hubs, with a fixed (rather than variable length) size. Change the USB core's hub descriptor to have a union for the last fields that differ. Change the host controller drivers that access those last fields (DeviceRemovable and PortPowerCtrlMask) to use the union. Translate the new version of the hub port status field into the old version that khubd understands. (Note: we need to fix it to translate the roothub's port status once we stop converting it to USB 2.0 hub status internally.) Add new code to handle link state change status. Send out new control messages that are needed for USB 3.0 hubs, like Set Hub Depth. This patch is a modified version of the original patch submitted by John Youn. It's updated to reflect the removal of the "bitmap" #define, and change the hub descriptor accesses of a couple new host controller drivers. Signed-off-by: John Youn <johnyoun@synopsys.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com> Cc: Tony Olech <tony.olech@elandigitalsystems.com> Cc: "Robert P. J. Day" <rpjday@crashcourse.ca> Cc: Max Vozeler <mvz@vozeler.com> Cc: Tejun Heo <tj@kernel.org> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Cc: Rodolfo Giometti <giometti@linux.it> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Anton Vorontsov <avorontsov@mvista.com> Cc: Sebastian Siewior <bigeasy@linutronix.de> Cc: Lothar Wassmann <LW@KARO-electronics.de> Cc: Olav Kongas <ok@artecdesign.ee> Cc: Martin Fuzzey <mfuzzey@gmail.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: David Brownell <dbrownell@users.sourceforge.net>
2001-09-17 00:00:00 -07:00
drivers: usb: core: {file,hub,sysfs,usb}.c: Whitespace fixes including: - removing of trailing whitespace - removing spaces before array indexing (foo [] to foo[]) - reindention of a switch-case block - spaces to tabs Signed-off-by: Matthias Beyer <mail@beyermatthias.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-10 23:41:27 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: assign default peer ports for root hubs Assume that the peer of a superspeed port is the port with the same id on the shared_hcd root hub. This identification scheme is required of external hubs by the USB3 spec [1]. However, for root hubs, tier mismatch may be in effect [2]. Tier mismatch can only be enumerated via platform firmware. For now, simply perform the nominal association. A new lock 'usb_port_peer_mutex' is introduced to synchronize port device add/remove with peer lookups. It protects peering against changes to hcd->shared_hcd, hcd->self.root_hub, hdev->maxchild, and port_dev->child pointers. [1]: usb 3.1 section 10.3.3 [2]: xhci 1.1 appendix D Cc: Alan Stern <stern@rowland.harvard.edu> [alan: usb_port_peer_mutex locking scheme] Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:28 -07:00
USB 3.0 Hub Changes Update the USB core to deal with USB 3.0 hubs. These hubs have a slightly different hub descriptor than USB 2.0 hubs, with a fixed (rather than variable length) size. Change the USB core's hub descriptor to have a union for the last fields that differ. Change the host controller drivers that access those last fields (DeviceRemovable and PortPowerCtrlMask) to use the union. Translate the new version of the hub port status field into the old version that khubd understands. (Note: we need to fix it to translate the roothub's port status once we stop converting it to USB 2.0 hub status internally.) Add new code to handle link state change status. Send out new control messages that are needed for USB 3.0 hubs, like Set Hub Depth. This patch is a modified version of the original patch submitted by John Youn. It's updated to reflect the removal of the "bitmap" #define, and change the hub descriptor accesses of a couple new host controller drivers. Signed-off-by: John Youn <johnyoun@synopsys.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com> Cc: Tony Olech <tony.olech@elandigitalsystems.com> Cc: "Robert P. J. Day" <rpjday@crashcourse.ca> Cc: Max Vozeler <mvz@vozeler.com> Cc: Tejun Heo <tj@kernel.org> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Cc: Rodolfo Giometti <giometti@linux.it> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Anton Vorontsov <avorontsov@mvista.com> Cc: Sebastian Siewior <bigeasy@linutronix.de> Cc: Lothar Wassmann <LW@KARO-electronics.de> Cc: Olav Kongas <ok@artecdesign.ee> Cc: Martin Fuzzey <mfuzzey@gmail.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: David Brownell <dbrownell@users.sourceforge.net>
2001-09-17 00:00:00 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: assign default peer ports for root hubs Assume that the peer of a superspeed port is the port with the same id on the shared_hcd root hub. This identification scheme is required of external hubs by the USB3 spec [1]. However, for root hubs, tier mismatch may be in effect [2]. Tier mismatch can only be enumerated via platform firmware. For now, simply perform the nominal association. A new lock 'usb_port_peer_mutex' is introduced to synchronize port device add/remove with peer lookups. It protects peering against changes to hcd->shared_hcd, hcd->self.root_hub, hdev->maxchild, and port_dev->child pointers. [1]: usb 3.1 section 10.3.3 [2]: xhci 1.1 appendix D Cc: Alan Stern <stern@rowland.harvard.edu> [alan: usb_port_peer_mutex locking scheme] Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:28 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] USB: make wHubCharacteristics __le16 to match other usb descriptor fields Also has the nice benefit of making sparc alignment issues go away. Thanks to David Miller for pointing out the problems here. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> drivers/usb/core/hub.c | 22 ++++++++++++---------- drivers/usb/core/hub.h | 2 +- 2 files changed, 13 insertions(+), 11 deletions(-)
2005-06-20 21:15:16 -07:00
USB: Adding #define in hub_configure() and hcd.c file This patch is in succession of previous patch commit c8421147926fcacf53081a36438a0bed394da9f5 xHCI: Adding #define values used for hub descriptor Hub descriptors characteristics #defines values are added in hub_configure() in place of magic numbers as asked by Alan Stern. And the indentation for switch and case is changed to be same. Some #defines values are added in ch11.h for defining hub class protocols and used in hub.c and hcd.c in which magic values were used for hub class protocols. Signed-off-by: Aman Deep <amandeep3986@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-12-08 12:05:22 +05:30
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] USB: make wHubCharacteristics __le16 to match other usb descriptor fields Also has the nice benefit of making sparc alignment issues go away. Thanks to David Miller for pointing out the problems here. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> drivers/usb/core/hub.c | 22 ++++++++++++---------- drivers/usb/core/hub.h | 2 +- 2 files changed, 13 insertions(+), 11 deletions(-)
2005-06-20 21:15:16 -07:00
USB: Adding #define in hub_configure() and hcd.c file This patch is in succession of previous patch commit c8421147926fcacf53081a36438a0bed394da9f5 xHCI: Adding #define values used for hub descriptor Hub descriptors characteristics #defines values are added in hub_configure() in place of magic numbers as asked by Alan Stern. And the indentation for switch and case is changed to be same. Some #defines values are added in ch11.h for defining hub class protocols and used in hub.c and hcd.c in which magic values were used for hub class protocols. Signed-off-by: Aman Deep <amandeep3986@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-12-08 12:05:22 +05:30
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: hub: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-11 21:34:37 -07:00
USB: fix the clear_tt_buffer interface This patch (as1255) updates the interface for calling usb_hub_clear_tt_buffer(). Even the name of the function is changed! When an async URB (i.e., Control or Bulk) going through a high-speed hub to a non-high-speed device is cancelled or fails, the hub's Transaction Translator buffer may be left busy still trying to complete the transaction. The buffer has to be cleared; that's what usb_hub_clear_tt_buffer() does. It isn't safe to send any more URBs to the same endpoint until the TT buffer is fully clear. Therefore the HCD needs to be told when the Clear-TT-Buffer request has finished. This patch adds a callback method to struct hc_driver for that purpose, and makes the hub driver invoke the callback at the proper time. The patch also changes a couple of names; "hub_tt_kevent" and "tt.kevent" now look rather antiquated. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:43:32 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: Adding #define in hub_configure() and hcd.c file This patch is in succession of previous patch commit c8421147926fcacf53081a36438a0bed394da9f5 xHCI: Adding #define values used for hub descriptor Hub descriptors characteristics #defines values are added in hub_configure() in place of magic numbers as asked by Alan Stern. And the indentation for switch and case is changed to be same. Some #defines values are added in ch11.h for defining hub class protocols and used in hub.c and hcd.c in which magic values were used for hub class protocols. Signed-off-by: Aman Deep <amandeep3986@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-12-08 12:05:22 +05:30
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] ehci: add think_time This adds think_time to the usb_tt struct and sets it appropriately (measured in ns); this can help us implement better split transaction scheduling. Signed-off-by: Dan Streetman <ddstreet@ieee.org> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-08-13 18:41:04 -07:00
[PATCH] USB: make wHubCharacteristics __le16 to match other usb descriptor fields Also has the nice benefit of making sparc alignment issues go away. Thanks to David Miller for pointing out the problems here. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> drivers/usb/core/hub.c | 22 ++++++++++++---------- drivers/usb/core/hub.h | 2 +- 2 files changed, 13 insertions(+), 11 deletions(-)
2005-06-20 21:15:16 -07:00
drivers: usb: core: {file,hub,sysfs,usb}.c: Whitespace fixes including: - removing of trailing whitespace - removing spaces before array indexing (foo [] to foo[]) - reindention of a switch-case block - spaces to tabs Signed-off-by: Matthias Beyer <mail@beyermatthias.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-10 23:41:27 +02:00
[PATCH] ehci: add think_time This adds think_time to the usb_tt struct and sets it appropriately (measured in ns); this can help us implement better split transaction scheduling. Signed-off-by: Dan Streetman <ddstreet@ieee.org> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-08-13 18:41:04 -07:00
drivers: usb: core: {file,hub,sysfs,usb}.c: Whitespace fixes including: - removing of trailing whitespace - removing spaces before array indexing (foo [] to foo[]) - reindention of a switch-case block - spaces to tabs Signed-off-by: Matthias Beyer <mail@beyermatthias.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-10 23:41:27 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] USB: make wHubCharacteristics __le16 to match other usb descriptor fields Also has the nice benefit of making sparc alignment issues go away. Thanks to David Miller for pointing out the problems here. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> drivers/usb/core/hub.c | 22 ++++++++++++---------- drivers/usb/core/hub.h | 2 +- 2 files changed, 13 insertions(+), 11 deletions(-)
2005-06-20 21:15:16 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: introduce a new usb_get_std_status() helper This new helper is a simple wrapper around usb_get_status(). This patch is in preparation to adding support for fetching PTM_STATUS types. No functional changes. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-02 10:57:40 +02:00
USB: simplify the interface of usb_get_status() This patch simplifies the interface presented by usb_get_status(). Instead of forcing callers to check for the proper data length and convert the status value to host byte order, the function will now do these things itself. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-30 15:35:40 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb/core: update power budget for SuperSpeed Sarah pointed out that the USB3.0 spec also updates the amount of power that may be consumed by the device and quoted 9.2.5.1: |"The amount of current draw for SuperSpeed devices are increased to 150 |mA for low-power devices and 900 mA for high-power" This patch tries to update all users to use the larger values for SuperSpeed devices and use the "old" ones for everything else. While here, two other changes suggested by Alan: - the comment referering to 7.2.1.1 has been updated to 7.2.1 which is the correct source of the action. - the check for hubs with zero ports has been removed. - compute bus power by full_load * num_ports on root hubs Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-12-18 15:25:47 +01:00
[PATCH] usbcore: Remove hub_set_power_budget This patch removes the hub_set_power_budget routine, which was used by a couple of HCDs to indicate that the root hub was running on battery power. In its place is a new field added to struct usb_hcd, which HCDs can set before the root hub is registered. Special-case code in the hub driver knows to look at this field when configuring a root hub. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-04-25 11:18:32 -04:00
usb/core: update power budget for SuperSpeed Sarah pointed out that the USB3.0 spec also updates the amount of power that may be consumed by the device and quoted 9.2.5.1: |"The amount of current draw for SuperSpeed devices are increased to 150 |mA for low-power devices and 900 mA for high-power" This patch tries to update all users to use the larger values for SuperSpeed devices and use the "old" ones for everything else. While here, two other changes suggested by Alan: - the comment referering to 7.2.1.1 has been updated to 7.2.1 which is the correct source of the action. - the check for hubs with zero ports has been removed. - compute bus power by full_load * num_ports on root hubs Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-12-18 15:25:47 +01:00
usb: assign default peer ports for root hubs Assume that the peer of a superspeed port is the port with the same id on the shared_hcd root hub. This identification scheme is required of external hubs by the USB3 spec [1]. However, for root hubs, tier mismatch may be in effect [2]. Tier mismatch can only be enumerated via platform firmware. For now, simply perform the nominal association. A new lock 'usb_port_peer_mutex' is introduced to synchronize port device add/remove with peer lookups. It protects peering against changes to hcd->shared_hcd, hcd->self.root_hub, hdev->maxchild, and port_dev->child pointers. [1]: usb 3.1 section 10.3.3 [2]: xhci 1.1 appendix D Cc: Alan Stern <stern@rowland.harvard.edu> [alan: usb_port_peer_mutex locking scheme] Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:28 -07:00
usb/core: update power budget for SuperSpeed Sarah pointed out that the USB3.0 spec also updates the amount of power that may be consumed by the device and quoted 9.2.5.1: |"The amount of current draw for SuperSpeed devices are increased to 150 |mA for low-power devices and 900 mA for high-power" This patch tries to update all users to use the larger values for SuperSpeed devices and use the "old" ones for everything else. While here, two other changes suggested by Alan: - the comment referering to 7.2.1.1 has been updated to 7.2.1 which is the correct source of the action. - the check for hubs with zero ports has been removed. - compute bus power by full_load * num_ports on root hubs Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-12-18 15:25:47 +01:00
[PATCH] USB: Consider power budget when choosing configuration This patch (as609) changes the way we keep track of power budgeting for USB hubs and devices, and it updates the choose_configuration routine to take this information into account. (This is something we should have been doing all along.) A new field in struct usb_device holds the amount of bus current available from the upstream port, and the usb_hub structure keeps track of the current available for each downstream port. Two new rules for configuration selection are added: Don't select a self-powered configuration when only bus power is available. Don't select a configuration requiring more bus power than is available. However the first rule is #if-ed out, because I found that the internal hub in my HP USB keyboard claims that its only configuration is self-powered. The rule would prevent the configuration from being chosen, leaving the hub & keyboard unconfigured. Since similar descriptor errors may turn out to be fairly common, it seemed wise not to include a rule that would break automatic configuration unnecessarily for such devices. The second rule may also trigger unnecessarily, although this should be less common. More likely it will annoy people by sometimes failing to accept configurations that should never have been chosen in the first place. The patch also changes usbcore's reaction when no configuration is suitable. Instead of raising an error and rejecting the device, now the core will simply leave the device unconfigured. People can always work around such problems by installing configurations manually through sysfs. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-23 12:03:12 -05:00
[PATCH] usbcore: Remove hub_set_power_budget This patch removes the hub_set_power_budget routine, which was used by a couple of HCDs to indicate that the root hub was running on battery power. In its place is a new field added to struct usb_hcd, which HCDs can set before the root hub is registered. Special-case code in the hub driver knows to look at this field when configuring a root hub. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-04-25 11:18:32 -04:00
usb/core: update power budget for SuperSpeed Sarah pointed out that the USB3.0 spec also updates the amount of power that may be consumed by the device and quoted 9.2.5.1: |"The amount of current draw for SuperSpeed devices are increased to 150 |mA for low-power devices and 900 mA for high-power" This patch tries to update all users to use the larger values for SuperSpeed devices and use the "old" ones for everything else. While here, two other changes suggested by Alan: - the comment referering to 7.2.1.1 has been updated to 7.2.1 which is the correct source of the action. - the check for hubs with zero ports has been removed. - compute bus power by full_load * num_ports on root hubs Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-12-18 15:25:47 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] USB: Consider power budget when choosing configuration This patch (as609) changes the way we keep track of power budgeting for USB hubs and devices, and it updates the choose_configuration routine to take this information into account. (This is something we should have been doing all along.) A new field in struct usb_device holds the amount of bus current available from the upstream port, and the usb_hub structure keeps track of the current available for each downstream port. Two new rules for configuration selection are added: Don't select a self-powered configuration when only bus power is available. Don't select a configuration requiring more bus power than is available. However the first rule is #if-ed out, because I found that the internal hub in my HP USB keyboard claims that its only configuration is self-powered. The rule would prevent the configuration from being chosen, leaving the hub & keyboard unconfigured. Since similar descriptor errors may turn out to be fairly common, it seemed wise not to include a rule that would break automatic configuration unnecessarily for such devices. The second rule may also trigger unnecessarily, although this should be less common. More likely it will annoy people by sometimes failing to accept configurations that should never have been chosen in the first place. The patch also changes usbcore's reaction when no configuration is suitable. Instead of raising an error and rejecting the device, now the core will simply leave the device unconfigured. People can always work around such problems by installing configurations manually through sysfs. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-23 12:03:12 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: assign default peer ports for root hubs Assume that the peer of a superspeed port is the port with the same id on the shared_hcd root hub. This identification scheme is required of external hubs by the USB3 spec [1]. However, for root hubs, tier mismatch may be in effect [2]. Tier mismatch can only be enumerated via platform firmware. For now, simply perform the nominal association. A new lock 'usb_port_peer_mutex' is introduced to synchronize port device add/remove with peer lookups. It protects peering against changes to hcd->shared_hcd, hcd->self.root_hub, hdev->maxchild, and port_dev->child pointers. [1]: usb 3.1 section 10.3.3 [2]: xhci 1.1 appendix D Cc: Alan Stern <stern@rowland.harvard.edu> [alan: usb_port_peer_mutex locking scheme] Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:28 -07:00
usb/core: update power budget for SuperSpeed Sarah pointed out that the USB3.0 spec also updates the amount of power that may be consumed by the device and quoted 9.2.5.1: |"The amount of current draw for SuperSpeed devices are increased to 150 |mA for low-power devices and 900 mA for high-power" This patch tries to update all users to use the larger values for SuperSpeed devices and use the "old" ones for everything else. While here, two other changes suggested by Alan: - the comment referering to 7.2.1.1 has been updated to 7.2.1 which is the correct source of the action. - the check for hubs with zero ports has been removed. - compute bus power by full_load * num_ports on root hubs Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-12-18 15:25:47 +01:00
[PATCH] USB: Consider power budget when choosing configuration This patch (as609) changes the way we keep track of power budgeting for USB hubs and devices, and it updates the choose_configuration routine to take this information into account. (This is something we should have been doing all along.) A new field in struct usb_device holds the amount of bus current available from the upstream port, and the usb_hub structure keeps track of the current available for each downstream port. Two new rules for configuration selection are added: Don't select a self-powered configuration when only bus power is available. Don't select a configuration requiring more bus power than is available. However the first rule is #if-ed out, because I found that the internal hub in my HP USB keyboard claims that its only configuration is self-powered. The rule would prevent the configuration from being chosen, leaving the hub & keyboard unconfigured. Since similar descriptor errors may turn out to be fairly common, it seemed wise not to include a rule that would break automatic configuration unnecessarily for such devices. The second rule may also trigger unnecessarily, although this should be less common. More likely it will annoy people by sometimes failing to accept configurations that should never have been chosen in the first place. The patch also changes usbcore's reaction when no configuration is suitable. Instead of raising an error and rejecting the device, now the core will simply leave the device unconfigured. People can always work around such problems by installing configurations manually through sysfs. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-23 12:03:12 -05:00
usb/core: update power budget for SuperSpeed Sarah pointed out that the USB3.0 spec also updates the amount of power that may be consumed by the device and quoted 9.2.5.1: |"The amount of current draw for SuperSpeed devices are increased to 150 |mA for low-power devices and 900 mA for high-power" This patch tries to update all users to use the larger values for SuperSpeed devices and use the "old" ones for everything else. While here, two other changes suggested by Alan: - the comment referering to 7.2.1.1 has been updated to 7.2.1 which is the correct source of the action. - the check for hubs with zero ports has been removed. - compute bus power by full_load * num_ports on root hubs Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-12-18 15:25:47 +01:00
[PATCH] USB: Consider power budget when choosing configuration This patch (as609) changes the way we keep track of power budgeting for USB hubs and devices, and it updates the choose_configuration routine to take this information into account. (This is something we should have been doing all along.) A new field in struct usb_device holds the amount of bus current available from the upstream port, and the usb_hub structure keeps track of the current available for each downstream port. Two new rules for configuration selection are added: Don't select a self-powered configuration when only bus power is available. Don't select a configuration requiring more bus power than is available. However the first rule is #if-ed out, because I found that the internal hub in my HP USB keyboard claims that its only configuration is self-powered. The rule would prevent the configuration from being chosen, leaving the hub & keyboard unconfigured. Since similar descriptor errors may turn out to be fairly common, it seemed wise not to include a rule that would break automatic configuration unnecessarily for such devices. The second rule may also trigger unnecessarily, although this should be less common. More likely it will annoy people by sometimes failing to accept configurations that should never have been chosen in the first place. The patch also changes usbcore's reaction when no configuration is suitable. Instead of raising an error and rejecting the device, now the core will simply leave the device unconfigured. People can always work around such problems by installing configurations manually through sysfs. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-23 12:03:12 -05:00
usb/core: update power budget for SuperSpeed Sarah pointed out that the USB3.0 spec also updates the amount of power that may be consumed by the device and quoted 9.2.5.1: |"The amount of current draw for SuperSpeed devices are increased to 150 |mA for low-power devices and 900 mA for high-power" This patch tries to update all users to use the larger values for SuperSpeed devices and use the "old" ones for everything else. While here, two other changes suggested by Alan: - the comment referering to 7.2.1.1 has been updated to 7.2.1 which is the correct source of the action. - the check for hubs with zero ports has been removed. - compute bus power by full_load * num_ports on root hubs Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-12-18 15:25:47 +01:00
[PATCH] USB: Consider power budget when choosing configuration This patch (as609) changes the way we keep track of power budgeting for USB hubs and devices, and it updates the choose_configuration routine to take this information into account. (This is something we should have been doing all along.) A new field in struct usb_device holds the amount of bus current available from the upstream port, and the usb_hub structure keeps track of the current available for each downstream port. Two new rules for configuration selection are added: Don't select a self-powered configuration when only bus power is available. Don't select a configuration requiring more bus power than is available. However the first rule is #if-ed out, because I found that the internal hub in my HP USB keyboard claims that its only configuration is self-powered. The rule would prevent the configuration from being chosen, leaving the hub & keyboard unconfigured. Since similar descriptor errors may turn out to be fairly common, it seemed wise not to include a rule that would break automatic configuration unnecessarily for such devices. The second rule may also trigger unnecessarily, although this should be less common. More likely it will annoy people by sometimes failing to accept configurations that should never have been chosen in the first place. The patch also changes usbcore's reaction when no configuration is suitable. Instead of raising an error and rejecting the device, now the core will simply leave the device unconfigured. People can always work around such problems by installing configurations manually through sysfs. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-23 12:03:12 -05:00
usb/core: update power budget for SuperSpeed Sarah pointed out that the USB3.0 spec also updates the amount of power that may be consumed by the device and quoted 9.2.5.1: |"The amount of current draw for SuperSpeed devices are increased to 150 |mA for low-power devices and 900 mA for high-power" This patch tries to update all users to use the larger values for SuperSpeed devices and use the "old" ones for everything else. While here, two other changes suggested by Alan: - the comment referering to 7.2.1.1 has been updated to 7.2.1 which is the correct source of the action. - the check for hubs with zero ports has been removed. - compute bus power by full_load * num_ports on root hubs Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-12-18 15:25:47 +01:00
[PATCH] USB: Consider power budget when choosing configuration This patch (as609) changes the way we keep track of power budgeting for USB hubs and devices, and it updates the choose_configuration routine to take this information into account. (This is something we should have been doing all along.) A new field in struct usb_device holds the amount of bus current available from the upstream port, and the usb_hub structure keeps track of the current available for each downstream port. Two new rules for configuration selection are added: Don't select a self-powered configuration when only bus power is available. Don't select a configuration requiring more bus power than is available. However the first rule is #if-ed out, because I found that the internal hub in my HP USB keyboard claims that its only configuration is self-powered. The rule would prevent the configuration from being chosen, leaving the hub & keyboard unconfigured. Since similar descriptor errors may turn out to be fairly common, it seemed wise not to include a rule that would break automatic configuration unnecessarily for such devices. The second rule may also trigger unnecessarily, although this should be less common. More likely it will annoy people by sometimes failing to accept configurations that should never have been chosen in the first place. The patch also changes usbcore's reaction when no configuration is suitable. Instead of raising an error and rejecting the device, now the core will simply leave the device unconfigured. People can always work around such problems by installing configurations manually through sysfs. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-23 12:03:12 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] USB: make wHubCharacteristics __le16 to match other usb descriptor fields Also has the nice benefit of making sparc alignment issues go away. Thanks to David Miller for pointing out the problems here. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> drivers/usb/core/hub.c | 22 ++++++++++++---------- drivers/usb/core/hub.h | 2 +- 2 files changed, 13 insertions(+), 11 deletions(-)
2005-06-20 21:15:16 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb hub: fix root hub code so it takes more than 15 devices per root hub Wireless USB Host Controllers accept a large number of devices per host, which shows up as a large number of ports in its root hub. When the number of ports in a hub device goes over 16, the activation of the hub fails with the cryptic message in klogd. hub 2-0:1.0: activate --> -22 Following this further, it was seen that: hub_probe() hub_configure() generates pipe number pseudo allocates buffer 'maxp' bytes in size using usb_maxpacket() The endpoint descriptor for a root hub interrupt endpoint is declared in drivers/usb/core/hcd.c:hs_rh_config_descriptor and declares it to be size two (supporting 15 devices max). hub_activate() usb_hcd_submit_urb() rh_urb_enqueue() urb->pipe is neither int nor ctl, so it errors out rh_queue_status() Returns -EINVAL because the buffer length is smaller than the minimum needed to report all the hub port bits as in accordance with USB2.0[11.12.3]. There has to be trunc((PORTS + 1 + 7) / 8) bytes of space at least. Alan Stern confirmed that the reason for reading maxpktsize and not the right amount is because some hubs are known to return more data and thus cause overflow. So this patch simply changes the code to make the interrupt endpoint's max packet size be at least the minimum required by USB_MAXCHILDREN (instead of a fixed magic number) and add documentation for that. This way we are always ahead of the limit. Signed-off-by: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-10-11 20:05:59 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: remove third argument of usb_maxpacket() The third argument of usb_maxpacket(): in_out has been deprecated because it could be derived from the second argument (e.g. using usb_pipeout(pipe)). N.B. function usb_maxpacket() was made variadic to accommodate the transition from the old prototype with three arguments to the new one with only two arguments (so that no renaming is needed). The variadic argument is to be removed once all users of usb_maxpacket() get migrated. CC: Duncan Sands <duncan.sands@free.fr> CC: Alan Stern <stern@rowland.harvard.edu> CC: Olav Kongas <ok@artecdesign.ee> CC: Rui Miguel Silva <rui.silva@linaro.org> Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/20220317035514.6378-7-mailhol.vincent@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-17 12:55:11 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
drivers: usb: core: {file,hub,sysfs,usb}.c: Whitespace fixes including: - removing of trailing whitespace - removing spaces before array indexing (foo [] to foo[]) - reindention of a switch-case block - spaces to tabs Signed-off-by: Matthias Beyer <mail@beyermatthias.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-10 23:41:27 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: assign default peer ports for root hubs Assume that the peer of a superspeed port is the port with the same id on the shared_hcd root hub. This identification scheme is required of external hubs by the USB3 spec [1]. However, for root hubs, tier mismatch may be in effect [2]. Tier mismatch can only be enumerated via platform firmware. For now, simply perform the nominal association. A new lock 'usb_port_peer_mutex' is introduced to synchronize port device add/remove with peer lookups. It protects peering against changes to hcd->shared_hcd, hcd->self.root_hub, hdev->maxchild, and port_dev->child pointers. [1]: usb 3.1 section 10.3.3 [2]: xhci 1.1 appendix D Cc: Alan Stern <stern@rowland.harvard.edu> [alan: usb_port_peer_mutex locking scheme] Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:28 -07:00
usb: fail on usb_hub_create_port_device() errors Ignoring usb_hub_create_port_device() errors cause later NULL pointer deference when uninitialized hub->ports[i] entries are dereferenced after port memory allocation error. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-22 14:49:39 +02:00
usb: make usb port a real device This patch turns each USB port on a hub into a new struct device. This new device has the USB hub interface device as its parent. The port devices are stored in a new structure (usb_port), and an array of usb_ports are dynamically allocated once we know how many ports the USB hub has. Move the port_owner variable out of usb_hub and into this new structure. A new file will be created in the hub interface sysfs directory, so add documentation. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-05 13:44:31 +08:00
usb: assign default peer ports for root hubs Assume that the peer of a superspeed port is the port with the same id on the shared_hcd root hub. This identification scheme is required of external hubs by the USB3 spec [1]. However, for root hubs, tier mismatch may be in effect [2]. Tier mismatch can only be enumerated via platform firmware. For now, simply perform the nominal association. A new lock 'usb_port_peer_mutex' is introduced to synchronize port device add/remove with peer lookups. It protects peering against changes to hcd->shared_hcd, hcd->self.root_hub, hdev->maxchild, and port_dev->child pointers. [1]: usb 3.1 section 10.3.3 [2]: xhci 1.1 appendix D Cc: Alan Stern <stern@rowland.harvard.edu> [alan: usb_port_peer_mutex locking scheme] Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:28 -07:00
usb: fail on usb_hub_create_port_device() errors Ignoring usb_hub_create_port_device() errors cause later NULL pointer deference when uninitialized hub->ports[i] entries are dereferenced after port memory allocation error. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-22 14:49:39 +02:00
usb: assign default peer ports for root hubs Assume that the peer of a superspeed port is the port with the same id on the shared_hcd root hub. This identification scheme is required of external hubs by the USB3 spec [1]. However, for root hubs, tier mismatch may be in effect [2]. Tier mismatch can only be enumerated via platform firmware. For now, simply perform the nominal association. A new lock 'usb_port_peer_mutex' is introduced to synchronize port device add/remove with peer lookups. It protects peering against changes to hcd->shared_hcd, hcd->self.root_hub, hdev->maxchild, and port_dev->child pointers. [1]: usb 3.1 section 10.3.3 [2]: xhci 1.1 appendix D Cc: Alan Stern <stern@rowland.harvard.edu> [alan: usb_port_peer_mutex locking scheme] Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:28 -07:00
usb: fix hub-port pm_runtime_enable() vs runtime pm transitions Commit 9262c19d14c4 "usb: disable port power control if not supported in wHubCharacteristics" gated enabling runtime pm for usb_port devices on whether the parent hub supports power control, which causes a regression. The port must still be allowed to carry out runtime pm callbacks and receive a -EAGAIN or -EBUSY result. Otherwise the usb_port device will transition to the pm error state and trigger the same for the child usb_device. Prior to the offending commit usb_hub_create_port_device() arranged for runtime pm to be disabled is dev_pm_qos_expose_flags() failed. Instead, force the default state of PM_QOS_FLAG_NO_POWER_OFF flag to be set prior to enabling runtime pm. If that policy can not be set then fail registration. Report: http://marc.info/?l=linux-usb&m=140290586301336&w=2 Fixes: 9262c19d14c4 ("usb: disable port power control if not supported in wHubCharacteristics") Reported-by: Bjørn Mork <bjorn@mork.no> Reported-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-17 16:16:32 -07:00
usb: assign default peer ports for root hubs Assume that the peer of a superspeed port is the port with the same id on the shared_hcd root hub. This identification scheme is required of external hubs by the USB3 spec [1]. However, for root hubs, tier mismatch may be in effect [2]. Tier mismatch can only be enumerated via platform firmware. For now, simply perform the nominal association. A new lock 'usb_port_peer_mutex' is introduced to synchronize port device add/remove with peer lookups. It protects peering against changes to hcd->shared_hcd, hcd->self.root_hub, hdev->maxchild, and port_dev->child pointers. [1]: usb 3.1 section 10.3.3 [2]: xhci 1.1 appendix D Cc: Alan Stern <stern@rowland.harvard.edu> [alan: usb_port_peer_mutex locking scheme] Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:28 -07:00
usb: make usb port a real device This patch turns each USB port on a hub into a new struct device. This new device has the USB hub interface device as its parent. The port devices are stored in a new structure (usb_port), and an array of usb_ports are dynamically allocated once we know how many ports the USB hub has. Move the port_owner variable out of usb_hub and into this new structure. A new file will be created in the hub interface sysfs directory, so add documentation. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-05 13:44:31 +08:00
usb: hub: rename khubd to hub_wq in documentation and comments USB hub has started to use a workqueue instead of kthread. Let's update the documentation and comments here and there. This patch mostly just replaces "khubd" with "hub_wq". There are only few exceptions where the whole sentence was updated. These more complicated changes can be found in the following files: Documentation/usb/hotplug.txt drivers/net/usb/usbnet.c drivers/usb/core/hcd.c drivers/usb/host/ohci-hcd.c drivers/usb/host/xhci.c Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:23 +02:00
usb: fix ->update_hub_device() vs hdev->maxchild Commit d8521afe3586 "usb: assign default peer ports for root hubs" delayed marking a hub valid (set hdev->maxchild) until it had been fully configured and to enable the publishing of valid hubs to be serialized by usb_port_peer_mutex. However, xhci_update_hub_device() in some cases depends on hdev->maxchild already being set. Do the minimal fix and move it after the setting of hdev->maxchild. Cc: Mathias Nyman <mathias.nyman@linux.intel.com> Reported-by: Valdis Kletnieks <Valdis.Kletnieks@vt.edu> Tested-by: Valdis Kletnieks <Valdis.Kletnieks@vt.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-05 14:23:04 -07:00
USB: Set usb port's DeviceRemovable according acpi information ACPI provide "_PLD" and "_UPC" aml methods to describe usb port visibility and connectability. This patch is to add usb_hub_adjust_DeviceRemovable() to adjust usb hub port's DeviceRemovable according ACPI information and invoke it in the rh_call_control(). When hub descriptor request is issued at first time, usb port device isn't created and usb port is not bound with acpi. So first hub descriptor request is not changed based on ACPI information. After usb port devices being created, call usb_hub_adjust_DeviceRemovable in the hub_configure() and then set hub port's DeviceRemovable according ACPI information and this also works for non-root hub. 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>
2013-01-21 22:18:00 +08:00
USB: combine hub_activate and hub_restart This patch (as1071) combines hub_activate() and hub_restart() into a single routine. There's no point keeping them separate, since they are always called together. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:17 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: hub: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-11 21:34:37 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: make hub driver's release more robust This revised patch (as893c) improves the method used by the hub driver to release its private data structure. The current code is non-robust, relying on a memory region not getting reused by another driver after it has been freed. The patch adds a reference count to the structure, resolving the question of when to release it. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-04 11:55:11 -04:00
usb: hub: keep hub->dev reference all the time when struct usb_hub lives This is just a small optimization of the fix from the commit c605f3cdff53a743f6 ("usb: hub: take hub->hdev reference when processing from eventlist). We do not need to take the reference for each event. Instead we could get it when struct usb_hub is allocated and put it when it is released. By other words, we could handle it the same way as the reference for hub->intfdev. The motivation is that it will make the life easier when switching from khubd kthread to a workqueue. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:19 +02:00
USB: make hub driver's release more robust This revised patch (as893c) improves the method used by the hub driver to release its private data structure. The current code is non-robust, relying on a memory region not getting reused by another driver after it has been freed. The patch adds a reference count to the structure, resolving the question of when to release it. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-04 11:55:11 -04:00
USB: core: Add hub_get() and hub_put() routines Create hub_get() and hub_put() routines to encapsulate the kref_get() and kref_put() calls in hub.c. The new routines will be used by the next patch in this series. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/604da420-ae8a-4a9e-91a4-2d511ff404fb@rowland.harvard.edu Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-15 13:04:50 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: dynamically allocate usb_device children pointers instead of using a fix array Non-hub device has no child, and even a real USB hub has ports far less than USB_MAXCHILDREN, so there is no need using a fix array for child devices, just allocate it dynamically according real port number. Signed-off-by: Huajun Li <huajun.li.lee@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-03-12 21:00:19 +08:00
Revert "usb: move struct usb_device->children to struct usb_hub_port->child" 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-14 09:20:37 -07:00
USB: fix race between hub_disconnect and recursively_mark_NOTATTACHED There is a race in the hub driver between hub_disconnect() and recursively_mark_NOTATTACHED(). This race can be triggered if the driver is unbound from a device at the same time as the bus's root hub is removed. When the race occurs, it can cause an oops: BUG: unable to handle kernel NULL pointer dereference at 0000015c IP: [<c16d5fb0>] recursively_mark_NOTATTACHED+0x20/0x60 Call Trace: [<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60 [<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60 [<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60 [<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60 [<c16d6082>] usb_set_device_state+0x92/0x120 [<c16d862b>] usb_disconnect+0x2b/0x1a0 [<c16dd4c0>] usb_remove_hcd+0xb0/0x160 [<c19ca846>] ? _raw_spin_unlock_irqrestore+0x26/0x50 [<c1704efc>] ehci_mid_remove+0x1c/0x30 [<c1704f26>] ehci_mid_stop_host+0x16/0x30 [<c16f7698>] penwell_otg_work+0xd28/0x3520 [<c19c945b>] ? __schedule+0x39b/0x7f0 [<c19cdb9d>] ? sub_preempt_count+0x3d/0x50 [<c125e97d>] process_one_work+0x11d/0x3d0 [<c19c7f4d>] ? mutex_unlock+0xd/0x10 [<c125e0e5>] ? manage_workers.isra.24+0x1b5/0x270 [<c125f009>] worker_thread+0xf9/0x320 [<c19ca846>] ? _raw_spin_unlock_irqrestore+0x26/0x50 [<c125ef10>] ? rescuer_thread+0x2b0/0x2b0 [<c1264ac4>] kthread+0x94/0xa0 [<c19d0f77>] ret_from_kernel_thread+0x1b/0x28 [<c1264a30>] ? kthread_create_on_node+0xc0/0xc0 One problem is that recursively_mark_NOTATTACHED() uses the intfdata value and hub->hdev->maxchild while hub_disconnect() is clearing them. Another problem is that it uses hub->ports[i] while the port device is being released. To fix this race, we need to hold the device_state_lock while hub_disconnect() changes the values. (Note that usb_disconnect() and hub_port_connect_change() already acquire this lock at similar critical times during a USB device's life cycle.) We also need to remove the port devices after maxchild has been set to 0, instead of before. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: "Du, Changbin" <changbinx.du@intel.com> Tested-by: "Du, Changbin" <changbinx.du@intel.com> CC: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-01-07 10:43:02 -05:00
usb: make usb port a real device This patch turns each USB port on a hub into a new struct device. This new device has the USB hub interface device as its parent. The port devices are stored in a new structure (usb_port), and an array of usb_ports are dynamically allocated once we know how many ports the USB hub has. Move the port_owner variable out of usb_hub and into this new structure. A new file will be created in the hub interface sysfs directory, so add documentation. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-05 13:44:31 +08:00
usb: hub: convert khubd into workqueue There is no need to have separate kthread for handling USB hub events. It is more elegant to use the workqueue framework. The workqueue is allocated as freezable because the original thread was freezable as well. Also it is allocated as ordered because the code is not ready for parallel processing of hub events, see choose_devnum(). struct usb_hub is passed via the work item. Therefore we do not need hub_event_list. Also hub_thread() is not longer needed. It would call only hub_event(). The rest of the code did manipulate the kthread and it is handled by the workqueue framework now. kick_khubd is renamed to kick_hub_wq() to make the function clear. And the protection against races is done another way, see below. hub_event_lock has been removed. It cannot longer be used to protect struct usb_hub between hub_event() and hub_disconnect(). Instead we need to get hub->kref already in kick_hub_wq(). The lock is not really needed for the other scenarios as well. queue_work() returns whether it succeeded. We could revert the needed operations accordingly. This is enough to avoid duplicity and inconsistencies. Yes, the removed lock causes that there is not longer such a strong synchronization between scheduling the work and manipulating hub->disconnected. But kick_hub_wq() must never be called together with hub_disconnect() otherwise even the original code would have failed. Any callers are responsible for this. Therefore the only problem is that hub_disconnect() could be called in parallel with hub_event(). But this was possible even in the past. struct usb_hub is still guarded by hub->kref and released in hub_events() when needed. Note that the source file is still full of the obsolete "khubd" strings. Let's remove them in a follow up patch. This patch already is complex enough. Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to allocate the workqueue. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:21 +02:00
USB: make hub driver's release more robust This revised patch (as893c) improves the method used by the hub driver to release its private data structure. The current code is non-robust, relying on a memory region not getting reused by another driver after it has been freed. The patch adds a reference count to the structure, resolving the question of when to release it. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-04 11:55:11 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] USB hub: use usb_reset_composite_device This patch (as700) modifies the hub driver to take advantage of the new usb_reset_composite_device API. The existing code had special-case calls stuck into usb_reset_device, just before and after the reset. With the new version there's no need for special-case stuff; it all happens naturally in the form of pre_reset and post_reset notifications. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-01 13:37:24 -04:00
USB: combine hub_quiesce and hub_stop This patch (as1083) combines hub_quiesce() and hub_stop() into a single routine. There's no point keeping them separate since they are usually called together. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:31 -04:00
[PATCH] USB hub: use usb_reset_composite_device This patch (as700) modifies the hub driver to take advantage of the new usb_reset_composite_device API. The existing code had special-case calls stuck into usb_reset_device, just before and after the reset. With the new version there's no need for special-case stuff; it all happens naturally in the form of pre_reset and post_reset notifications. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-01 13:37:24 -04:00
usb: assign default peer ports for root hubs Assume that the peer of a superspeed port is the port with the same id on the shared_hcd root hub. This identification scheme is required of external hubs by the USB3 spec [1]. However, for root hubs, tier mismatch may be in effect [2]. Tier mismatch can only be enumerated via platform firmware. For now, simply perform the nominal association. A new lock 'usb_port_peer_mutex' is introduced to synchronize port device add/remove with peer lookups. It protects peering against changes to hcd->shared_hcd, hcd->self.root_hub, hdev->maxchild, and port_dev->child pointers. [1]: usb 3.1 section 10.3.3 [2]: xhci 1.1 appendix D Cc: Alan Stern <stern@rowland.harvard.edu> [alan: usb_port_peer_mutex locking scheme] Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:28 -07:00
USB: fix race between hub_disconnect and recursively_mark_NOTATTACHED There is a race in the hub driver between hub_disconnect() and recursively_mark_NOTATTACHED(). This race can be triggered if the driver is unbound from a device at the same time as the bus's root hub is removed. When the race occurs, it can cause an oops: BUG: unable to handle kernel NULL pointer dereference at 0000015c IP: [<c16d5fb0>] recursively_mark_NOTATTACHED+0x20/0x60 Call Trace: [<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60 [<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60 [<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60 [<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60 [<c16d6082>] usb_set_device_state+0x92/0x120 [<c16d862b>] usb_disconnect+0x2b/0x1a0 [<c16dd4c0>] usb_remove_hcd+0xb0/0x160 [<c19ca846>] ? _raw_spin_unlock_irqrestore+0x26/0x50 [<c1704efc>] ehci_mid_remove+0x1c/0x30 [<c1704f26>] ehci_mid_stop_host+0x16/0x30 [<c16f7698>] penwell_otg_work+0xd28/0x3520 [<c19c945b>] ? __schedule+0x39b/0x7f0 [<c19cdb9d>] ? sub_preempt_count+0x3d/0x50 [<c125e97d>] process_one_work+0x11d/0x3d0 [<c19c7f4d>] ? mutex_unlock+0xd/0x10 [<c125e0e5>] ? manage_workers.isra.24+0x1b5/0x270 [<c125f009>] worker_thread+0xf9/0x320 [<c19ca846>] ? _raw_spin_unlock_irqrestore+0x26/0x50 [<c125ef10>] ? rescuer_thread+0x2b0/0x2b0 [<c1264ac4>] kthread+0x94/0xa0 [<c19d0f77>] ret_from_kernel_thread+0x1b/0x28 [<c1264a30>] ? kthread_create_on_node+0xc0/0xc0 One problem is that recursively_mark_NOTATTACHED() uses the intfdata value and hub->hdev->maxchild while hub_disconnect() is clearing them. Another problem is that it uses hub->ports[i] while the port device is being released. To fix this race, we need to hold the device_state_lock while hub_disconnect() changes the values. (Note that usb_disconnect() and hub_port_connect_change() already acquire this lock at similar critical times during a USB device's life cycle.) We also need to remove the port devices after maxchild has been set to 0, instead of before. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: "Du, Changbin" <changbinx.du@intel.com> Tested-by: "Du, Changbin" <changbinx.du@intel.com> CC: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-01-07 10:43:02 -05:00
usb: move children deallocation after quiescing the hub Commit ff823c79a5c33194c2e5594f7c4686ea3547910c ("usb: move children to struct usb_port") forgot to consider the hub_disconnect sequence, which releases ports before quiescing the hub, which will lead to a use-after-free, since hub_quiesce() will try to disconnect ports' children, which are already deallocated. Simple modprobe dummy_hcd && rmmod dummy_hcd will illustrate the problem. This patch moves deallocation of hub's ports after hub_quiesce() call in hub_disconnect(). Cc: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-12 14:48:31 +03:00
USB: fix race between hub_disconnect and recursively_mark_NOTATTACHED There is a race in the hub driver between hub_disconnect() and recursively_mark_NOTATTACHED(). This race can be triggered if the driver is unbound from a device at the same time as the bus's root hub is removed. When the race occurs, it can cause an oops: BUG: unable to handle kernel NULL pointer dereference at 0000015c IP: [<c16d5fb0>] recursively_mark_NOTATTACHED+0x20/0x60 Call Trace: [<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60 [<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60 [<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60 [<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60 [<c16d6082>] usb_set_device_state+0x92/0x120 [<c16d862b>] usb_disconnect+0x2b/0x1a0 [<c16dd4c0>] usb_remove_hcd+0xb0/0x160 [<c19ca846>] ? _raw_spin_unlock_irqrestore+0x26/0x50 [<c1704efc>] ehci_mid_remove+0x1c/0x30 [<c1704f26>] ehci_mid_stop_host+0x16/0x30 [<c16f7698>] penwell_otg_work+0xd28/0x3520 [<c19c945b>] ? __schedule+0x39b/0x7f0 [<c19cdb9d>] ? sub_preempt_count+0x3d/0x50 [<c125e97d>] process_one_work+0x11d/0x3d0 [<c19c7f4d>] ? mutex_unlock+0xd/0x10 [<c125e0e5>] ? manage_workers.isra.24+0x1b5/0x270 [<c125f009>] worker_thread+0xf9/0x320 [<c19ca846>] ? _raw_spin_unlock_irqrestore+0x26/0x50 [<c125ef10>] ? rescuer_thread+0x2b0/0x2b0 [<c1264ac4>] kthread+0x94/0xa0 [<c19d0f77>] ret_from_kernel_thread+0x1b/0x28 [<c1264a30>] ? kthread_create_on_node+0xc0/0xc0 One problem is that recursively_mark_NOTATTACHED() uses the intfdata value and hub->hdev->maxchild while hub_disconnect() is clearing them. Another problem is that it uses hub->ports[i] while the port device is being released. To fix this race, we need to hold the device_state_lock while hub_disconnect() changes the values. (Note that usb_disconnect() and hub_port_connect_change() already acquire this lock at similar critical times during a USB device's life cycle.) We also need to remove the port devices after maxchild has been set to 0, instead of before. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: "Du, Changbin" <changbinx.du@intel.com> Tested-by: "Du, Changbin" <changbinx.du@intel.com> CC: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-01-07 10:43:02 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: assign default peer ports for root hubs Assume that the peer of a superspeed port is the port with the same id on the shared_hcd root hub. This identification scheme is required of external hubs by the USB3 spec [1]. However, for root hubs, tier mismatch may be in effect [2]. Tier mismatch can only be enumerated via platform firmware. For now, simply perform the nominal association. A new lock 'usb_port_peer_mutex' is introduced to synchronize port device add/remove with peer lookups. It protects peering against changes to hcd->shared_hcd, hcd->self.root_hub, hdev->maxchild, and port_dev->child pointers. [1]: usb 3.1 section 10.3.3 [2]: xhci 1.1 appendix D Cc: Alan Stern <stern@rowland.harvard.edu> [alan: usb_port_peer_mutex locking scheme] Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:28 -07:00
USB: make hub driver's release more robust This revised patch (as893c) improves the method used by the hub driver to release its private data structure. The current code is non-robust, relying on a memory region not getting reused by another driver after it has been freed. The patch adds a reference count to the structure, resolving the question of when to release it. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-04 11:55:11 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: make usb port a real device This patch turns each USB port on a hub into a new struct device. This new device has the USB hub interface device as its parent. The port devices are stored in a new structure (usb_port), and an array of usb_ports are dynamically allocated once we know how many ports the USB hub has. Move the port_owner variable out of usb_hub and into this new structure. A new file will be created in the hub interface sysfs directory, so add documentation. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-05 13:44:31 +08:00
[PATCH] USB: kfree cleanup for drivers/usb/* - no need to check for NULL Get rid of a bunch of redundant NULL pointer checks in drivers/usb/*, there's no need to check a pointer for NULL before calling kfree() on it. Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Index: gregkh-2.6/drivers/usb/class/audio.c ===================================================================
2005-04-18 17:39:34 -07:00
USB: don't use a fixed DMA mapping for hub status URBs This patch (as1296) gets rid of the fixed DMA-buffer mapping used by the hub driver for its status URB. This URB doesn't get used much -- mainly when a device is plugged in or unplugged -- so the dynamic mapping overhead is minimal. And most systems have many fewer external hubs than root hubs, which don't need a mapped buffer anyway. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 15:18:46 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: add runtime pm support for usb port device This patch is to add runtime pm callback for usb port device. Set/clear PORT_POWER feature in the resume/suspend callback. Add portnum for struct usb_port to record port number. Do pm_rumtime_get_sync/put(portdev) when a device is plugged/unplugged to prevent it from being powered off when it is active. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:29 +08:00
USB: hub: Fix the broken detection of USB3 device in SMSC hub Renesas R-Car H3ULCB + Kingfisher Infotainment Board is either not able to detect the USB3.0 mass storage devices or is detecting those as USB2.0 high speed devices. The explanation given by Renesas is that, due to a HW issue, the XHCI driver does not wake up after going to sleep on connecting a USB3.0 device. In order to mitigate that, disable the auto-suspend feature specifically for SMSC hubs from hub_probe() function, as a quirk. Renesas Kingfisher Infotainment Board has two USB3.0 ports (CN2) which are connected via USB5534B 4-port SuperSpeed/Hi-Speed, low-power, configurable hub controller. [1] SanDisk USB 3.0 device detected as USB-2.0 before the patch [ 74.036390] usb 5-1.1: new high-speed USB device number 4 using xhci-hcd [ 74.061598] usb 5-1.1: New USB device found, idVendor=0781, idProduct=5581, bcdDevice= 1.00 [ 74.069976] usb 5-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 74.077303] usb 5-1.1: Product: Ultra [ 74.080980] usb 5-1.1: Manufacturer: SanDisk [ 74.085263] usb 5-1.1: SerialNumber: 4C530001110208116550 [2] SanDisk USB 3.0 device detected as USB-3.0 after the patch [ 34.565078] usb 6-1.1: new SuperSpeed Gen 1 USB device number 3 using xhci-hcd [ 34.588719] usb 6-1.1: New USB device found, idVendor=0781, idProduct=5581, bcdDevice= 1.00 [ 34.597098] usb 6-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 34.604430] usb 6-1.1: Product: Ultra [ 34.608110] usb 6-1.1: Manufacturer: SanDisk [ 34.612397] usb 6-1.1: SerialNumber: 4C530001110208116550 Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Eugeniu Rosca <erosca@de.adit-jv.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/1580989763-32291-1-git-send-email-hgajjar@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-06 12:49:23 +01:00
usb: misc: onboard_hub: rename to onboard_dev This patch prepares onboad_hub to support non-hub devices by renaming the driver files and their content, the headers and their references. The comments and descriptions have been slightly modified to keep coherence and account for the specific cases that only affect onboard hubs (e.g. peer-hub). The "hub" variables in functions where "dev" (and similar names) variables already exist have been renamed to onboard_dev for clarity, which adds a few lines in cases where more than 80 characters are used. No new functionality has been added. Acked-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net> Link: https://lore.kernel.org/r/20240325-onboard_xvf3500-v8-2-29e3f9222922@wolfvision.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-25 10:15:12 +01:00
usb: core: hub: Create platform devices for onboard hubs in hub_probe() Call onboard_hub_create/destroy_pdevs() from hub_probe/disconnect() to create/destroy platform devices for onboard USB hubs that may be connected to the hub. The onboard hubs must have nodes in the device tree. onboard_hub_create/destroy_pdevs() are NOPs unless CONFIG_USB_ONBOARD_HUB=y/m. Also add a field to struct usb_hub to keep track of the onboard hub platform devices that are owned by the hub. Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Link: https://lore.kernel.org/r/20220630123445.v24.4.Ic9dd36078f9d803de82ca01a6700c58b8e4de27e@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-30 12:35:30 -07:00
USB: core: Add hub_get() and hub_put() routines Create hub_get() and hub_put() routines to encapsulate the kref_get() and kref_put() calls in hub.c. The new routines will be used by the next patch in this series. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/604da420-ae8a-4a9e-91a4-2d511ff404fb@rowland.harvard.edu Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-15 13:04:50 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB hub_probe: rework ugly goto-into-compound-statement Rework smelling code (goto inside compound statement). Perhaps this is legacy. Anyway such code is not appropriate for Linux kernel. Signed-off-by: Eugene Korenevsky <ekorenevsky@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-06-25 11:08:14 +03:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: set hub's default autosuspend delay as 0 This patch sets hub device's default autosuspend delay as 0 to speedup bus suspend, see comments in code for details. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-24 11:59:25 +08:00
usb: hub: Prevent hub autosuspend if usbcore.autosuspend is -1 If user specifies that USB autosuspend must be disabled by module parameter "usbcore.autosuspend=-1" then we must prevent autosuspend of USB hub devices as well. commit 596d789a211d introduced in v3.8 changed the original behaivour and stopped respecting the usbcore.autosuspend parameter for hubs. Fixes: 596d789a211d "USB: set hub's default autosuspend delay as 0" Cc: [3.8+] <stable@vger.kernel.org> Signed-off-by: Roger Quadros <rogerq@ti.com> Tested-by: Michael Welling <mwelling@emacinc.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-08-04 12:44:46 +03:00
USB: set hub's default autosuspend delay as 0 This patch sets hub device's default autosuspend delay as 0 to speedup bus suspend, see comments in code for details. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-24 11:59:25 +08:00
USB / PM: Drop CONFIG_PM_RUNTIME from the USB core 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 <rafael.j.wysocki@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-29 23:47:05 +01:00
usb: hub: Prevent hub autosuspend if usbcore.autosuspend is -1 If user specifies that USB autosuspend must be disabled by module parameter "usbcore.autosuspend=-1" then we must prevent autosuspend of USB hub devices as well. commit 596d789a211d introduced in v3.8 changed the original behaivour and stopped respecting the usbcore.autosuspend parameter for hubs. Fixes: 596d789a211d "USB: set hub's default autosuspend delay as 0" Cc: [3.8+] <stable@vger.kernel.org> Signed-off-by: Roger Quadros <rogerq@ti.com> Tested-by: Michael Welling <mwelling@emacinc.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-08-04 12:44:46 +03:00
USB: fix build error with CONFIG_PM_RUNTIME disabled commit bdd405d2a528 ("usb: hub: Prevent hub autosuspend if usbcore.autosuspend is -1") causes a build error if CONFIG_PM_RUNTIME is disabled. Fix that by doing a simple #ifdef guard around it. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reported-by: kbuild test robot <fengguang.wu@intel.com> Cc: Roger Quadros <rogerq@ti.com> Cc: Michael Welling <mwelling@emacinc.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-08-27 16:55:29 -07:00
USB: set hub's default autosuspend delay as 0 This patch sets hub device's default autosuspend delay as 0 to speedup bus suspend, see comments in code for details. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-24 11:59:25 +08:00
USB: Avoid runtime suspend loops for HCDs that can't handle suspend/resume 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 <stern@rowland.harvard.edu> Reported-by: Will Deacon <will.deacon@arm.com> Tested-by: Will Deacon <will.deacon@arm.com> CC: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-23 10:45:54 -04:00
USB: implement usb_enable_autosuspend This patch (as1326) adds usb_enable_autosuspend() and usb_disable_autosuspend() routines for use by drivers. If a driver knows that its device can handle suspends and resumes correctly, it can enable autosuspend all by itself. This is equivalent to the user writing "auto" to the device's power/level attribute. The implementation differs slightly from what it used to be. Now autosuspend is disabled simply by doing usb_autoresume_device() (to increment the usage counter) and enabled by doing usb_autosuspend_device() (to decrement the usage counter). The set_level() attribute method is updated to use the new routines, and the USB Power-Management documentation is updated. The patch adds a usb_enable_autosuspend() call to the hub driver's probe routine, allowing the special-case code for hubs in quirks.c to be removed. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-08 12:56:54 -05:00
usb: hub: add check for unsupported bus topology We can't allow hubs on the 7th tier as they would allow devices on the 8th tier. Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-12 10:49:47 +03:00
USB: make printk messages more searchable USB: make printk messages more searchable Make USB printk messages long and straightforward. One of these decorated USB error messages cost me non-trivial efforts to locate. Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-15 15:32:01 +08:00
usb: hub: add check for unsupported bus topology We can't allow hubs on the 7th tier as they would allow devices on the 8th tier. Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-12 10:49:47 +03:00
USB: rename USB OTG hub configuration option The USB OTG code has the ability to disable external hubs, but the configuration option for it is oddly named. Rename it to be more obvious as to what it does. Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Bin Liu <b-liu@ti.com> Cc: Paul Cercueil <paul@crapouillou.net> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Eugeniu Rosca <erosca@de.adit-jv.com> Cc: Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: David Heinzelmann <heinzelmann.david@gmail.com> Cc: "Lee, Chiasheng" <chiasheng.lee@intel.com> Cc: Keiya Nobuta <nobuta.keiya@fujitsu.com> Cc: Hardik Gajjar <hgajjar@de.adit-jv.com> Link: https://lore.kernel.org/r/20200618094300.1887727-3-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-18 11:42:54 +02:00
[PATCH] USB: otg hub support is optional USB OTG devices are not required to support external hubs. This adds a configuration option to disable that support. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-04-02 10:18:09 -08:00
USB hub_probe: rework ugly goto-into-compound-statement Rework smelling code (goto inside compound statement). Perhaps this is legacy. Anyway such code is not appropriate for Linux kernel. Signed-off-by: Eugene Korenevsky <ekorenevsky@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-06-25 11:08:14 +03:00
usb: core: hub: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-11 21:34:37 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: hub: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-11 21:34:37 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] usbcore: Use kzalloc instead of kmalloc/memset This patch (as590) fixes up all the remaining places where usbcore can use kzalloc rather than kmalloc/memset. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-10-24 15:38:24 -04:00
usb: core: hub: don't print on ENOMEM All kmalloc-based functions print enough information on failures. Signed-off-by: Wolfram Sang <wsa-dev@sang-engineering.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-08-25 19:38:59 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: make hub driver's release more robust This revised patch (as893c) improves the method used by the hub driver to release its private data structure. The current code is non-robust, relying on a memory region not getting reused by another driver after it has been freed. The patch adds a reference count to the structure, resolving the question of when to release it. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-04 11:55:11 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
WorkStruct: make allyesconfig Fix up for make allyesconfig. Signed-Off-By: David Howells <dhowells@redhat.com>
2006-11-22 14:57:56 +00:00
USB: change hub initialization sleeps to delayed_work This patch (as1137) changes the hub_activate() routine, replacing the power-power-up and debounce delays with delayed_work calls. The idea is that on systems where the USB stack is compiled into the kernel rather than built as modules, these delays will no longer block the boot thread. At least 100 ms is saved for each root hub, which can add up to a significant savings in total boot time. Arjan van de Ven was very pleased to see that this shaved 700 ms off his computer's boot time. Since his total boot time is on the order of two seconds, the improvement is considerable. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-22 14:44:26 -04:00
usb: hub: convert khubd into workqueue There is no need to have separate kthread for handling USB hub events. It is more elegant to use the workqueue framework. The workqueue is allocated as freezable because the original thread was freezable as well. Also it is allocated as ordered because the code is not ready for parallel processing of hub events, see choose_devnum(). struct usb_hub is passed via the work item. Therefore we do not need hub_event_list. Also hub_thread() is not longer needed. It would call only hub_event(). The rest of the code did manipulate the kthread and it is handled by the workqueue framework now. kick_khubd is renamed to kick_hub_wq() to make the function clear. And the protection against races is done another way, see below. hub_event_lock has been removed. It cannot longer be used to protect struct usb_hub between hub_event() and hub_disconnect(). Instead we need to get hub->kref already in kick_hub_wq(). The lock is not really needed for the other scenarios as well. queue_work() returns whether it succeeded. We could revert the needed operations accordingly. This is enough to avoid duplicity and inconsistencies. Yes, the removed lock causes that there is not longer such a strong synchronization between scheduling the work and manipulating hub->disconnected. But kick_hub_wq() must never be called together with hub_disconnect() otherwise even the original code would have failed. Any callers are responsible for this. Therefore the only problem is that hub_disconnect() could be called in parallel with hub_event(). But this was possible even in the past. struct usb_hub is still guarded by hub->kref and released in hub_events() when needed. Note that the source file is still full of the obsolete "khubd" strings. Let's remove them in a follow up patch. This patch already is complex enough. Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to allocate the workqueue. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:21 +02:00
usb: misc: onboard_hub: rename to onboard_dev This patch prepares onboad_hub to support non-hub devices by renaming the driver files and their content, the headers and their references. The comments and descriptions have been slightly modified to keep coherence and account for the specific cases that only affect onboard hubs (e.g. peer-hub). The "hub" variables in functions where "dev" (and similar names) variables already exist have been renamed to onboard_dev for clarity, which adds a few lines in cases where more than 80 characters are used. No new functionality has been added. Acked-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net> Link: https://lore.kernel.org/r/20240325-onboard_xvf3500-v8-2-29e3f9222922@wolfvision.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-25 10:15:12 +01:00
usb: hub: add retry routine after intr URB submit error The hub sends hot-plug events to the host trough it's interrupt URB. The driver takes care of completing the URB and re-submitting it. Completion errors are handled in the hub_event() work, yet submission errors are ignored, rendering the device unresponsive. All further events are lost. It is fairly hard to find this issue in the wild, since you have to time the USB hot-plug event with the URB submission failure. For instance it could be the system running out of memory or some malfunction in the USB controller driver. Nevertheless, it's pretty reasonable to think it'll happen sometime. One can trigger this issue using eBPF's function override feature (see BCC's inject.py script). This patch adds a retry routine to the event of a submission error. The HUB driver will try to re-submit the URB once every second until it's successful or the HUB is disconnected. As some USB subsystems already take care of this issue, the implementation was inspired from usbhid/hid_core.c's. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Oliver Neukum <oneukum@suse.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-08 16:45:22 +01:00
USB: make hub driver's release more robust This revised patch (as893c) improves the method used by the hub driver to release its private data structure. The current code is non-robust, relying on a memory region not getting reused by another driver after it has been freed. The patch adds a reference count to the structure, resolving the question of when to release it. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-04 11:55:11 -04:00
usb: hub: keep hub->dev reference all the time when struct usb_hub lives This is just a small optimization of the fix from the commit c605f3cdff53a743f6 ("usb: hub: take hub->hdev reference when processing from eventlist). We do not need to take the reference for each event. Instead we could get it when struct usb_hub is allocated and put it when it is released. By other words, we could handle it the same way as the reference for hub->intfdev. The motivation is that it will make the life easier when switching from khubd kthread to a workqueue. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:19 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: hub: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-11 21:34:37 -07:00
USB: Add autosuspend support to the hub driver This patch (as742b) adds autosuspend/autoresume support to the USB hub driver. The largest aspect of the change is that we no longer need a special flag for root hubs that want to be resumed. Now every hub is autoresumed whenever khubd needs to access it. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-11-09 14:44:33 -05:00
usb: add runtime pm support for usb port device This patch is to add runtime pm callback for usb port device. Set/clear PORT_POWER feature in the resume/suspend callback. Add portnum for struct usb_port to record port number. Do pm_rumtime_get_sync/put(portdev) when a device is plugged/unplugged to prevent it from being powered off when it is active. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:29 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: check port changes before hub runtime suspend for some bug device The hub status endpoint has a long 'bInterval', which is 255ms for FS/LS device and 256ms for HS device according to USB 2.0 spec, so the device connection change may be reported later more than 255ms via status pipe. The connection change in hub may have been happened already on the downstream ports, but no status URB completes when it is killed in hub_suspend(auto), so the connection change may be missed by some buggy hub devices, which won't generate remote wakeup signal after their remote wakeup is enabled and they are put into suspend state. The problem can be observed at least on the below Genesys Logic, Inc. hub devices: 0x05e3,0x0606 0x05e3,0x0608 In theory, there is no way to fix the problem completely, but we can make it less likely to occur by this patch. This patch introduces one quirk of HUB_QUIRK_CHECK_PORTS_AUTOSUSPEND to check ports' change during hub_suspend(auto) for the buggy devices. If ports' change is found, terminate the auto suspend and return to working state. So for the buggy hubs, if the connection change happend before the ports' check, it can be handled correctly. If it happens between the ports' check and enabling remote wakeup/entering suspend, it will be missed. Considered the interval is quite short, it is very less likely to happen during the window. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-24 11:59:24 +08:00
USB: hub: Fix the broken detection of USB3 device in SMSC hub Renesas R-Car H3ULCB + Kingfisher Infotainment Board is either not able to detect the USB3.0 mass storage devices or is detecting those as USB2.0 high speed devices. The explanation given by Renesas is that, due to a HW issue, the XHCI driver does not wake up after going to sleep on connecting a USB3.0 device. In order to mitigate that, disable the auto-suspend feature specifically for SMSC hubs from hub_probe() function, as a quirk. Renesas Kingfisher Infotainment Board has two USB3.0 ports (CN2) which are connected via USB5534B 4-port SuperSpeed/Hi-Speed, low-power, configurable hub controller. [1] SanDisk USB 3.0 device detected as USB-2.0 before the patch [ 74.036390] usb 5-1.1: new high-speed USB device number 4 using xhci-hcd [ 74.061598] usb 5-1.1: New USB device found, idVendor=0781, idProduct=5581, bcdDevice= 1.00 [ 74.069976] usb 5-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 74.077303] usb 5-1.1: Product: Ultra [ 74.080980] usb 5-1.1: Manufacturer: SanDisk [ 74.085263] usb 5-1.1: SerialNumber: 4C530001110208116550 [2] SanDisk USB 3.0 device detected as USB-3.0 after the patch [ 34.565078] usb 6-1.1: new SuperSpeed Gen 1 USB device number 3 using xhci-hcd [ 34.588719] usb 6-1.1: New USB device found, idVendor=0781, idProduct=5581, bcdDevice= 1.00 [ 34.597098] usb 6-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 34.604430] usb 6-1.1: Product: Ultra [ 34.608110] usb 6-1.1: Manufacturer: SanDisk [ 34.612397] usb 6-1.1: SerialNumber: 4C530001110208116550 Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Eugeniu Rosca <erosca@de.adit-jv.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/1580989763-32291-1-git-send-email-hgajjar@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-06 12:49:23 +01:00
usb: core: hub: fix unhandled return by employing a void function Address below Coverity complaint (Feb 25, 2020, 8:06 AM CET): *** CID 1458999: Error handling issues (CHECKED_RETURN) /drivers/usb/core/hub.c: 1869 in hub_probe() 1863 1864 if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND) 1865 hub->quirk_check_port_auto_suspend = 1; 1866 1867 if (id->driver_info & HUB_QUIRK_DISABLE_AUTOSUSPEND) { 1868 hub->quirk_disable_autosuspend = 1; >>> CID 1458999: Error handling issues (CHECKED_RETURN) >>> Calling "usb_autopm_get_interface" without checking return value (as is done elsewhere 97 out of 111 times). 1869 usb_autopm_get_interface(intf); 1870 } 1871 1872 if (hub_configure(hub, &desc->endpoint[0].desc) >= 0) 1873 return 0; 1874 Rather than checking the return value of 'usb_autopm_get_interface()', switch to the usb_autopm_get_interface_no_resume() API, as per: On Tue, Feb 25, 2020 at 10:32:32AM -0500, Alan Stern wrote: ------ 8< ------ > This change (i.e. 'ret = usb_autopm_get_interface') is not necessary, > because the resume operation cannot fail at this point (interfaces > are always powered-up during probe). A better solution would be to > call usb_autopm_get_interface_no_resume() instead. ------ 8< ------ Fixes: 1208f9e1d758c9 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub") Cc: Hardik Gajjar <hgajjar@de.adit-jv.com> Cc: stable@vger.kernel.org # v4.14+ Reported-by: scan-admin@coverity.com Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200226175036.14946-1-erosca@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-26 18:50:34 +01:00
USB: hub: Fix the broken detection of USB3 device in SMSC hub Renesas R-Car H3ULCB + Kingfisher Infotainment Board is either not able to detect the USB3.0 mass storage devices or is detecting those as USB2.0 high speed devices. The explanation given by Renesas is that, due to a HW issue, the XHCI driver does not wake up after going to sleep on connecting a USB3.0 device. In order to mitigate that, disable the auto-suspend feature specifically for SMSC hubs from hub_probe() function, as a quirk. Renesas Kingfisher Infotainment Board has two USB3.0 ports (CN2) which are connected via USB5534B 4-port SuperSpeed/Hi-Speed, low-power, configurable hub controller. [1] SanDisk USB 3.0 device detected as USB-2.0 before the patch [ 74.036390] usb 5-1.1: new high-speed USB device number 4 using xhci-hcd [ 74.061598] usb 5-1.1: New USB device found, idVendor=0781, idProduct=5581, bcdDevice= 1.00 [ 74.069976] usb 5-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 74.077303] usb 5-1.1: Product: Ultra [ 74.080980] usb 5-1.1: Manufacturer: SanDisk [ 74.085263] usb 5-1.1: SerialNumber: 4C530001110208116550 [2] SanDisk USB 3.0 device detected as USB-3.0 after the patch [ 34.565078] usb 6-1.1: new SuperSpeed Gen 1 USB device number 3 using xhci-hcd [ 34.588719] usb 6-1.1: New USB device found, idVendor=0781, idProduct=5581, bcdDevice= 1.00 [ 34.597098] usb 6-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 34.604430] usb 6-1.1: Product: Ultra [ 34.608110] usb 6-1.1: Manufacturer: SanDisk [ 34.612397] usb 6-1.1: SerialNumber: 4C530001110208116550 Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Eugeniu Rosca <erosca@de.adit-jv.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/1580989763-32291-1-git-send-email-hgajjar@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-06 12:49:23 +01:00
usb: hub: Add quirk to decrease IN-ep poll interval for Microchip USB491x hub There is a potential delay in notifying Linux USB drivers of downstream USB bus activity when connecting a high-speed or superSpeed device via the Microchip USB491x hub. This delay is due to the fixed bInterval value of 12 in the silicon of the Microchip USB491x hub. Microchip requested to ignore the device descriptor and decrease that value to 9 as it was too late to modify that in silicon. This patch speeds up the USB enummeration process that helps to pass Apple Carplay certifications and improve the User experience when utilizing the USB device via Microchip Multihost USB491x Hub. A new hub quirk HUB_QUIRK_REDUCE_FRAME_INTR_BINTERVAL speeds up the notification process for Microchip USB491x hub by limiting the maximum bInterval value to 9. Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20231205181829.127353-2-hgajjar@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-05 19:18:29 +01:00
usb: core: hub: Create platform devices for onboard hubs in hub_probe() Call onboard_hub_create/destroy_pdevs() from hub_probe/disconnect() to create/destroy platform devices for onboard USB hubs that may be connected to the hub. The onboard hubs must have nodes in the device tree. onboard_hub_create/destroy_pdevs() are NOPs unless CONFIG_USB_ONBOARD_HUB=y/m. Also add a field to struct usb_hub to keep track of the onboard hub platform devices that are owned by the hub. Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Link: https://lore.kernel.org/r/20220630123445.v24.4.Ic9dd36078f9d803de82ca01a6700c58b8e4de27e@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-30 12:35:30 -07:00
usb: misc: onboard_hub: rename to onboard_dev This patch prepares onboad_hub to support non-hub devices by renaming the driver files and their content, the headers and their references. The comments and descriptions have been slightly modified to keep coherence and account for the specific cases that only affect onboard hubs (e.g. peer-hub). The "hub" variables in functions where "dev" (and similar names) variables already exist have been renamed to onboard_dev for clarity, which adds a few lines in cases where more than 80 characters are used. No new functionality has been added. Acked-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net> Link: https://lore.kernel.org/r/20240325-onboard_xvf3500-v8-2-29e3f9222922@wolfvision.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-25 10:15:12 +01:00
usb: core: hub: Create platform devices for onboard hubs in hub_probe() Call onboard_hub_create/destroy_pdevs() from hub_probe/disconnect() to create/destroy platform devices for onboard USB hubs that may be connected to the hub. The onboard hubs must have nodes in the device tree. onboard_hub_create/destroy_pdevs() are NOPs unless CONFIG_USB_ONBOARD_HUB=y/m. Also add a field to struct usb_hub to keep track of the onboard hub platform devices that are owned by the hub. Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Link: https://lore.kernel.org/r/20220630123445.v24.4.Ic9dd36078f9d803de82ca01a6700c58b8e4de27e@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-30 12:35:30 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: hub: Create platform devices for onboard hubs in hub_probe() Call onboard_hub_create/destroy_pdevs() from hub_probe/disconnect() to create/destroy platform devices for onboard USB hubs that may be connected to the hub. The onboard hubs must have nodes in the device tree. onboard_hub_create/destroy_pdevs() are NOPs unless CONFIG_USB_ONBOARD_HUB=y/m. Also add a field to struct usb_hub to keep track of the onboard hub platform devices that are owned by the hub. Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Link: https://lore.kernel.org/r/20220630123445.v24.4.Ic9dd36078f9d803de82ca01a6700c58b8e4de27e@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-30 12:35:30 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: hub: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-11 21:34:37 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: hub: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-11 21:34:37 -07:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: move children to struct usb_port The usb_device structure contains an array of usb_device "children". This array is only valid if the usb_device is a hub, so it makes no sense to store it there. Instead, store the usb_device child in its parent usb_port structure. Since usb_port is an internal USB core structure, add a new function to get the USB device child, usb_hub_find_child(). Add a new macro, usb_hub_get_each_child(), to iterate over all the children attached to a particular USB hub. Remove the printing the USB children array pointer from the usb-ip driver, since it's really not necessary. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-05 13:44:32 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: move children to struct usb_port The usb_device structure contains an array of usb_device "children". This array is only valid if the usb_device is a hub, so it makes no sense to store it there. Instead, store the usb_device child in its parent usb_port structure. Since usb_port is an internal USB core structure, add a new function to get the USB device child, usb_hub_find_child(). Add a new macro, usb_hub_get_each_child(), to iterate over all the children attached to a particular USB hub. Remove the printing the USB children array pointer from the usb-ip driver, since it's really not necessary. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-05 13:44:32 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: add API for userspace drivers to "claim" ports This patch (as1258) implements a feature that users have been asking for: It gives programs the ability to "claim" a port on a hub, via a new usbfs ioctl. A device plugged into a "claimed" port will not be touched by the kernel beyond the immediate necessities of initialization and enumeration. In particular, when a device is plugged into a "claimed" port, the kernel will not select and install a configuration. And when a config is installed by usbfs or sysfs, the kernel will not probe any drivers for any of the interfaces. (However the kernel will fetch various string descriptors during enumeration. One could argue that this isn't really necessary, but the strings are exported in sysfs.) The patch does not guarantee exclusive access to these devices; it is still possible for more than one program to open the device file concurrently. Programs are responsible for coordinating access among themselves. A demonstration program showing how to use the new interface can be found in an attachment to http://marc.info/?l=linux-usb&m=124345857431452&w=2 The patch also makes a small simplification to the hub driver, replacing a bunch of more-or-less useless variants of "out of memory" with a single message. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:56:54 -04:00
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>
2014-03-10 10:36:40 +02:00
USB: add API for userspace drivers to "claim" ports This patch (as1258) implements a feature that users have been asking for: It gives programs the ability to "claim" a port on a hub, via a new usbfs ioctl. A device plugged into a "claimed" port will not be touched by the kernel beyond the immediate necessities of initialization and enumeration. In particular, when a device is plugged into a "claimed" port, the kernel will not select and install a configuration. And when a config is installed by usbfs or sysfs, the kernel will not probe any drivers for any of the interfaces. (However the kernel will fetch various string descriptors during enumeration. One could argue that this isn't really necessary, but the strings are exported in sysfs.) The patch does not guarantee exclusive access to these devices; it is still possible for more than one program to open the device file concurrently. Programs are responsible for coordinating access among themselves. A demonstration program showing how to use the new interface can be found in an attachment to http://marc.info/?l=linux-usb&m=124345857431452&w=2 The patch also makes a small simplification to the hub driver, replacing a bunch of more-or-less useless variants of "out of memory" with a single message. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:56:54 -04:00
usb: check usb_hub_to_struct_hub() return value usb_hub_to_struct_hub() can return NULL in some unlikely cases. Add checks where appropriate, or pass the hub pointer as an additional argument if it's known to be valid. The places it makes sense to check usb_hub_to_struct_hub() are picked based on feedback from Alan Stern. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-18 17:28:48 +03:00
USB: add API for userspace drivers to "claim" ports This patch (as1258) implements a feature that users have been asking for: It gives programs the ability to "claim" a port on a hub, via a new usbfs ioctl. A device plugged into a "claimed" port will not be touched by the kernel beyond the immediate necessities of initialization and enumeration. In particular, when a device is plugged into a "claimed" port, the kernel will not select and install a configuration. And when a config is installed by usbfs or sysfs, the kernel will not probe any drivers for any of the interfaces. (However the kernel will fetch various string descriptors during enumeration. One could argue that this isn't really necessary, but the strings are exported in sysfs.) The patch does not guarantee exclusive access to these devices; it is still possible for more than one program to open the device file concurrently. Programs are responsible for coordinating access among themselves. A demonstration program showing how to use the new interface can be found in an attachment to http://marc.info/?l=linux-usb&m=124345857431452&w=2 The patch also makes a small simplification to the hub driver, replacing a bunch of more-or-less useless variants of "out of memory" with a single message. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:56:54 -04:00
usb: check usb_hub_to_struct_hub() return value usb_hub_to_struct_hub() can return NULL in some unlikely cases. Add checks where appropriate, or pass the hub pointer as an additional argument if it's known to be valid. The places it makes sense to check usb_hub_to_struct_hub() are picked based on feedback from Alan Stern. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-18 17:28:48 +03:00
USB: add API for userspace drivers to "claim" ports This patch (as1258) implements a feature that users have been asking for: It gives programs the ability to "claim" a port on a hub, via a new usbfs ioctl. A device plugged into a "claimed" port will not be touched by the kernel beyond the immediate necessities of initialization and enumeration. In particular, when a device is plugged into a "claimed" port, the kernel will not select and install a configuration. And when a config is installed by usbfs or sysfs, the kernel will not probe any drivers for any of the interfaces. (However the kernel will fetch various string descriptors during enumeration. One could argue that this isn't really necessary, but the strings are exported in sysfs.) The patch does not guarantee exclusive access to these devices; it is still possible for more than one program to open the device file concurrently. Programs are responsible for coordinating access among themselves. A demonstration program showing how to use the new interface can be found in an attachment to http://marc.info/?l=linux-usb&m=124345857431452&w=2 The patch also makes a small simplification to the hub driver, replacing a bunch of more-or-less useless variants of "out of memory" with a single message. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:56:54 -04:00
usb: check usb_hub_to_struct_hub() return value usb_hub_to_struct_hub() can return NULL in some unlikely cases. Add checks where appropriate, or pass the hub pointer as an additional argument if it's known to be valid. The places it makes sense to check usb_hub_to_struct_hub() are picked based on feedback from Alan Stern. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-18 17:28:48 +03:00
USB: add API for userspace drivers to "claim" ports This patch (as1258) implements a feature that users have been asking for: It gives programs the ability to "claim" a port on a hub, via a new usbfs ioctl. A device plugged into a "claimed" port will not be touched by the kernel beyond the immediate necessities of initialization and enumeration. In particular, when a device is plugged into a "claimed" port, the kernel will not select and install a configuration. And when a config is installed by usbfs or sysfs, the kernel will not probe any drivers for any of the interfaces. (However the kernel will fetch various string descriptors during enumeration. One could argue that this isn't really necessary, but the strings are exported in sysfs.) The patch does not guarantee exclusive access to these devices; it is still possible for more than one program to open the device file concurrently. Programs are responsible for coordinating access among themselves. A demonstration program showing how to use the new interface can be found in an attachment to http://marc.info/?l=linux-usb&m=124345857431452&w=2 The patch also makes a small simplification to the hub driver, replacing a bunch of more-or-less useless variants of "out of memory" with a single message. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:56:54 -04:00
usb: convert port_owners type from void * to struct dev_state * 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-06 14:13:52 +08:00
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>
2014-03-10 10:36:40 +02:00
USB: add API for userspace drivers to "claim" ports This patch (as1258) implements a feature that users have been asking for: It gives programs the ability to "claim" a port on a hub, via a new usbfs ioctl. A device plugged into a "claimed" port will not be touched by the kernel beyond the immediate necessities of initialization and enumeration. In particular, when a device is plugged into a "claimed" port, the kernel will not select and install a configuration. And when a config is installed by usbfs or sysfs, the kernel will not probe any drivers for any of the interfaces. (However the kernel will fetch various string descriptors during enumeration. One could argue that this isn't really necessary, but the strings are exported in sysfs.) The patch does not guarantee exclusive access to these devices; it is still possible for more than one program to open the device file concurrently. Programs are responsible for coordinating access among themselves. A demonstration program showing how to use the new interface can be found in an attachment to http://marc.info/?l=linux-usb&m=124345857431452&w=2 The patch also makes a small simplification to the hub driver, replacing a bunch of more-or-less useless variants of "out of memory" with a single message. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:56:54 -04:00
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>
2014-03-10 10:36:40 +02:00
USB: add API for userspace drivers to "claim" ports This patch (as1258) implements a feature that users have been asking for: It gives programs the ability to "claim" a port on a hub, via a new usbfs ioctl. A device plugged into a "claimed" port will not be touched by the kernel beyond the immediate necessities of initialization and enumeration. In particular, when a device is plugged into a "claimed" port, the kernel will not select and install a configuration. And when a config is installed by usbfs or sysfs, the kernel will not probe any drivers for any of the interfaces. (However the kernel will fetch various string descriptors during enumeration. One could argue that this isn't really necessary, but the strings are exported in sysfs.) The patch does not guarantee exclusive access to these devices; it is still possible for more than one program to open the device file concurrently. Programs are responsible for coordinating access among themselves. A demonstration program showing how to use the new interface can be found in an attachment to http://marc.info/?l=linux-usb&m=124345857431452&w=2 The patch also makes a small simplification to the hub driver, replacing a bunch of more-or-less useless variants of "out of memory" with a single message. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:56:54 -04:00
staging: usbip: claim ports used by shared devices A device should not be able to be used concurrently both by the server and the client. Claiming the port used by the shared device ensures no interface drivers bind to it and that it is not usable from the server. Signed-off-by: Valentina Manea <valentina.manea.m@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-08 14:53:34 +02:00
USB: add API for userspace drivers to "claim" ports This patch (as1258) implements a feature that users have been asking for: It gives programs the ability to "claim" a port on a hub, via a new usbfs ioctl. A device plugged into a "claimed" port will not be touched by the kernel beyond the immediate necessities of initialization and enumeration. In particular, when a device is plugged into a "claimed" port, the kernel will not select and install a configuration. And when a config is installed by usbfs or sysfs, the kernel will not probe any drivers for any of the interfaces. (However the kernel will fetch various string descriptors during enumeration. One could argue that this isn't really necessary, but the strings are exported in sysfs.) The patch does not guarantee exclusive access to these devices; it is still possible for more than one program to open the device file concurrently. Programs are responsible for coordinating access among themselves. A demonstration program showing how to use the new interface can be found in an attachment to http://marc.info/?l=linux-usb&m=124345857431452&w=2 The patch also makes a small simplification to the hub driver, replacing a bunch of more-or-less useless variants of "out of memory" with a single message. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:56:54 -04:00
usb: convert port_owners type from void * to struct dev_state * 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-06 14:13:52 +08:00
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>
2014-03-10 10:36:40 +02:00
USB: add API for userspace drivers to "claim" ports This patch (as1258) implements a feature that users have been asking for: It gives programs the ability to "claim" a port on a hub, via a new usbfs ioctl. A device plugged into a "claimed" port will not be touched by the kernel beyond the immediate necessities of initialization and enumeration. In particular, when a device is plugged into a "claimed" port, the kernel will not select and install a configuration. And when a config is installed by usbfs or sysfs, the kernel will not probe any drivers for any of the interfaces. (However the kernel will fetch various string descriptors during enumeration. One could argue that this isn't really necessary, but the strings are exported in sysfs.) The patch does not guarantee exclusive access to these devices; it is still possible for more than one program to open the device file concurrently. Programs are responsible for coordinating access among themselves. A demonstration program showing how to use the new interface can be found in an attachment to http://marc.info/?l=linux-usb&m=124345857431452&w=2 The patch also makes a small simplification to the hub driver, replacing a bunch of more-or-less useless variants of "out of memory" with a single message. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:56:54 -04:00
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>
2014-03-10 10:36:40 +02:00
USB: add API for userspace drivers to "claim" ports This patch (as1258) implements a feature that users have been asking for: It gives programs the ability to "claim" a port on a hub, via a new usbfs ioctl. A device plugged into a "claimed" port will not be touched by the kernel beyond the immediate necessities of initialization and enumeration. In particular, when a device is plugged into a "claimed" port, the kernel will not select and install a configuration. And when a config is installed by usbfs or sysfs, the kernel will not probe any drivers for any of the interfaces. (However the kernel will fetch various string descriptors during enumeration. One could argue that this isn't really necessary, but the strings are exported in sysfs.) The patch does not guarantee exclusive access to these devices; it is still possible for more than one program to open the device file concurrently. Programs are responsible for coordinating access among themselves. A demonstration program showing how to use the new interface can be found in an attachment to http://marc.info/?l=linux-usb&m=124345857431452&w=2 The patch also makes a small simplification to the hub driver, replacing a bunch of more-or-less useless variants of "out of memory" with a single message. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:56:54 -04:00
staging: usbip: claim ports used by shared devices A device should not be able to be used concurrently both by the server and the client. Claiming the port used by the shared device ensures no interface drivers bind to it and that it is not usable from the server. Signed-off-by: Valentina Manea <valentina.manea.m@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-08 14:53:34 +02:00
USB: add API for userspace drivers to "claim" ports This patch (as1258) implements a feature that users have been asking for: It gives programs the ability to "claim" a port on a hub, via a new usbfs ioctl. A device plugged into a "claimed" port will not be touched by the kernel beyond the immediate necessities of initialization and enumeration. In particular, when a device is plugged into a "claimed" port, the kernel will not select and install a configuration. And when a config is installed by usbfs or sysfs, the kernel will not probe any drivers for any of the interfaces. (However the kernel will fetch various string descriptors during enumeration. One could argue that this isn't really necessary, but the strings are exported in sysfs.) The patch does not guarantee exclusive access to these devices; it is still possible for more than one program to open the device file concurrently. Programs are responsible for coordinating access among themselves. A demonstration program showing how to use the new interface can be found in an attachment to http://marc.info/?l=linux-usb&m=124345857431452&w=2 The patch also makes a small simplification to the hub driver, replacing a bunch of more-or-less useless variants of "out of memory" with a single message. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:56:54 -04:00
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>
2014-03-10 10:36:40 +02:00
USB: add API for userspace drivers to "claim" ports This patch (as1258) implements a feature that users have been asking for: It gives programs the ability to "claim" a port on a hub, via a new usbfs ioctl. A device plugged into a "claimed" port will not be touched by the kernel beyond the immediate necessities of initialization and enumeration. In particular, when a device is plugged into a "claimed" port, the kernel will not select and install a configuration. And when a config is installed by usbfs or sysfs, the kernel will not probe any drivers for any of the interfaces. (However the kernel will fetch various string descriptors during enumeration. One could argue that this isn't really necessary, but the strings are exported in sysfs.) The patch does not guarantee exclusive access to these devices; it is still possible for more than one program to open the device file concurrently. Programs are responsible for coordinating access among themselves. A demonstration program showing how to use the new interface can be found in an attachment to http://marc.info/?l=linux-usb&m=124345857431452&w=2 The patch also makes a small simplification to the hub driver, replacing a bunch of more-or-less useless variants of "out of memory" with a single message. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:56:54 -04:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
USB: add API for userspace drivers to "claim" ports This patch (as1258) implements a feature that users have been asking for: It gives programs the ability to "claim" a port on a hub, via a new usbfs ioctl. A device plugged into a "claimed" port will not be touched by the kernel beyond the immediate necessities of initialization and enumeration. In particular, when a device is plugged into a "claimed" port, the kernel will not select and install a configuration. And when a config is installed by usbfs or sysfs, the kernel will not probe any drivers for any of the interfaces. (However the kernel will fetch various string descriptors during enumeration. One could argue that this isn't really necessary, but the strings are exported in sysfs.) The patch does not guarantee exclusive access to these devices; it is still possible for more than one program to open the device file concurrently. Programs are responsible for coordinating access among themselves. A demonstration program showing how to use the new interface can be found in an attachment to http://marc.info/?l=linux-usb&m=124345857431452&w=2 The patch also makes a small simplification to the hub driver, replacing a bunch of more-or-less useless variants of "out of memory" with a single message. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:56:54 -04:00
usb: make usb port a real device This patch turns each USB port on a hub into a new struct device. This new device has the USB hub interface device as its parent. The port devices are stored in a new structure (usb_port), and an array of usb_ports are dynamically allocated once we know how many ports the USB hub has. Move the port_owner variable out of usb_hub and into this new structure. A new file will be created in the hub interface sysfs directory, so add documentation. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-05 13:44:31 +08:00
USB: add API for userspace drivers to "claim" ports This patch (as1258) implements a feature that users have been asking for: It gives programs the ability to "claim" a port on a hub, via a new usbfs ioctl. A device plugged into a "claimed" port will not be touched by the kernel beyond the immediate necessities of initialization and enumeration. In particular, when a device is plugged into a "claimed" port, the kernel will not select and install a configuration. And when a config is installed by usbfs or sysfs, the kernel will not probe any drivers for any of the interfaces. (However the kernel will fetch various string descriptors during enumeration. One could argue that this isn't really necessary, but the strings are exported in sysfs.) The patch does not guarantee exclusive access to these devices; it is still possible for more than one program to open the device file concurrently. Programs are responsible for coordinating access among themselves. A demonstration program showing how to use the new interface can be found in an attachment to http://marc.info/?l=linux-usb&m=124345857431452&w=2 The patch also makes a small simplification to the hub driver, replacing a bunch of more-or-less useless variants of "out of memory" with a single message. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:56:54 -04:00
usb: make usb port a real device This patch turns each USB port on a hub into a new struct device. This new device has the USB hub interface device as its parent. The port devices are stored in a new structure (usb_port), and an array of usb_ports are dynamically allocated once we know how many ports the USB hub has. Move the port_owner variable out of usb_hub and into this new structure. A new file will be created in the hub interface sysfs directory, so add documentation. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-05 13:44:31 +08:00
USB: add API for userspace drivers to "claim" ports This patch (as1258) implements a feature that users have been asking for: It gives programs the ability to "claim" a port on a hub, via a new usbfs ioctl. A device plugged into a "claimed" port will not be touched by the kernel beyond the immediate necessities of initialization and enumeration. In particular, when a device is plugged into a "claimed" port, the kernel will not select and install a configuration. And when a config is installed by usbfs or sysfs, the kernel will not probe any drivers for any of the interfaces. (However the kernel will fetch various string descriptors during enumeration. One could argue that this isn't really necessary, but the strings are exported in sysfs.) The patch does not guarantee exclusive access to these devices; it is still possible for more than one program to open the device file concurrently. Programs are responsible for coordinating access among themselves. A demonstration program showing how to use the new interface can be found in an attachment to http://marc.info/?l=linux-usb&m=124345857431452&w=2 The patch also makes a small simplification to the hub driver, replacing a bunch of more-or-less useless variants of "out of memory" with a single message. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:56:54 -04:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
usb: make usb port a real device This patch turns each USB port on a hub into a new struct device. This new device has the USB hub interface device as its parent. The port devices are stored in a new structure (usb_port), and an array of usb_ports are dynamically allocated once we know how many ports the USB hub has. Move the port_owner variable out of usb_hub and into this new structure. A new file will be created in the hub interface sysfs directory, so add documentation. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-05 13:44:31 +08:00
USB: add API for userspace drivers to "claim" ports This patch (as1258) implements a feature that users have been asking for: It gives programs the ability to "claim" a port on a hub, via a new usbfs ioctl. A device plugged into a "claimed" port will not be touched by the kernel beyond the immediate necessities of initialization and enumeration. In particular, when a device is plugged into a "claimed" port, the kernel will not select and install a configuration. And when a config is installed by usbfs or sysfs, the kernel will not probe any drivers for any of the interfaces. (However the kernel will fetch various string descriptors during enumeration. One could argue that this isn't really necessary, but the strings are exported in sysfs.) The patch does not guarantee exclusive access to these devices; it is still possible for more than one program to open the device file concurrently. Programs are responsible for coordinating access among themselves. A demonstration program showing how to use the new interface can be found in an attachment to http://marc.info/?l=linux-usb&m=124345857431452&w=2 The patch also makes a small simplification to the hub driver, replacing a bunch of more-or-less useless variants of "out of memory" with a single message. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-29 10:56:54 -04:00
usb: core: add sysfs entry for usb device state Expose usb device state to userland as the information is useful in detecting non-compliant setups and diagnosing enumeration failures. For example: - End-to-end signal integrity issues: the device would fail port reset repeatedly and thus be stuck in POWERED state. - Charge-only cables (missing D+/D- lines): the device would never enter POWERED state as the HC would not see any pullup. What's the status quo? We do have error logs such as "Cannot enable. Maybe the USB cable is bad?" to flag potential setup issues, but there's no good way to expose them to userspace. Why add a sysfs entry in struct usb_port instead of struct usb_device? The struct usb_device is not device_add() to the system until it's in ADDRESS state hence we would miss the first two states. The struct usb_port is a better place to keep the information because its life cycle is longer than the struct usb_device that is attached to the port. Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202306042228.e532af6e-oliver.sang@intel.com Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Roy Luo <royluo@google.com> Message-ID: <20230608015913.1679984-1-royluo@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-08 01:59:12 +00:00
usb: core: Prevent null pointer dereference in update_port_device_state Currently, the function update_port_device_state gets the usb_hub from udev->parent by calling usb_hub_to_struct_hub. However, in case the actconfig or the maxchild is 0, the usb_hub would be NULL and upon further accessing to get port_dev would result in null pointer dereference. Fix this by introducing an if check after the usb_hub is populated. Fixes: 83cb2604f641 ("usb: core: add sysfs entry for usb device state") Cc: stable@vger.kernel.org Signed-off-by: Udipto Goswami <quic_ugoswami@quicinc.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20240110095814.7626-1-quic_ugoswami@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-10 15:28:14 +05:30
usb: core: add sysfs entry for usb device state Expose usb device state to userland as the information is useful in detecting non-compliant setups and diagnosing enumeration failures. For example: - End-to-end signal integrity issues: the device would fail port reset repeatedly and thus be stuck in POWERED state. - Charge-only cables (missing D+/D- lines): the device would never enter POWERED state as the HC would not see any pullup. What's the status quo? We do have error logs such as "Cannot enable. Maybe the USB cable is bad?" to flag potential setup issues, but there's no good way to expose them to userspace. Why add a sysfs entry in struct usb_port instead of struct usb_device? The struct usb_device is not device_add() to the system until it's in ADDRESS state hence we would miss the first two states. The struct usb_port is a better place to keep the information because its life cycle is longer than the struct usb_device that is attached to the port. Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202306042228.e532af6e-oliver.sang@intel.com Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Roy Luo <royluo@google.com> Message-ID: <20230608015913.1679984-1-royluo@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-08 01:59:12 +00:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: move children to struct usb_port The usb_device structure contains an array of usb_device "children". This array is only valid if the usb_device is a hub, so it makes no sense to store it there. Instead, store the usb_device child in its parent usb_port structure. Since usb_port is an internal USB core structure, add a new function to get the USB device child, usb_hub_find_child(). Add a new macro, usb_hub_get_each_child(), to iterate over all the children attached to a particular USB hub. Remove the printing the USB children array pointer from the usb-ip driver, since it's really not necessary. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-05 13:44:32 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
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>
2010-01-08 12:57:28 -05:00
USB: Export suspend statistics This patch exports two statistics to userspace: /sys/bus/usb/device/.../power/connected_duration /sys/bus/usb/device/.../power/active_duration connected_duration is the total time (in msec) that the device has been connected. active_duration is the total time the device has not been suspended. With these two statistics, tools like PowerTOP can calculate the percentage time that a device is active, i.e. not suspended or auto-suspended. Users can also use the active_duration to check if a device is actually autosuspended. Currently, they can set power/level to auto and power/autosuspend to a positive timeout, but there's no way to know from userspace if a device was actually autosuspended without looking at the dmesg output. These statistics will be useful in creating an automated userspace script to test autosuspend for USB devices. Signed-off-by: Sarah Sharp <sarah.a.sharp@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-21 16:54:15 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: add sysfs entry for usb device state Expose usb device state to userland as the information is useful in detecting non-compliant setups and diagnosing enumeration failures. For example: - End-to-end signal integrity issues: the device would fail port reset repeatedly and thus be stuck in POWERED state. - Charge-only cables (missing D+/D- lines): the device would never enter POWERED state as the HC would not see any pullup. What's the status quo? We do have error logs such as "Cannot enable. Maybe the USB cable is bad?" to flag potential setup issues, but there's no good way to expose them to userspace. Why add a sysfs entry in struct usb_port instead of struct usb_device? The struct usb_device is not device_add() to the system until it's in ADDRESS state hence we would miss the first two states. The struct usb_port is a better place to keep the information because its life cycle is longer than the struct usb_device that is attached to the port. Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202306042228.e532af6e-oliver.sang@intel.com Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Roy Luo <royluo@google.com> Message-ID: <20230608015913.1679984-1-royluo@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-08 01:59:12 +00:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB / Hub: Do not call device_set_wakeup_capable() under spinlock A subsequent patch will modify device_set_wakeup_capable() in such a way that it will call functions which may sleep and therefore it shouldn't be called under spinlocks. In preparation to that, modify usb_set_device_state() to avoid calling device_set_wakeup_capable() under device_state_lock. Tested-by: Minchan Kim <minchan.kim@gmail.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-08 23:25:48 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] usb device wakeup flags This patch teaches "usb_device" about the new driver model wakeup support: - It updates device wakeup capabilities when entering a configuration with the WAKEUP attribute; - During suspend processing it consults the policy bit to see whether it should enable wakeup for that device. (This resolves a FIXME to not assume the answer is always "yes"; some devices lie about supporting remote wakeup.) Support for root hubs and the HCDs is separate (and more complex). Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-12 19:39:39 -07:00
[PATCH] USB: remove usbcore-specific wakeup flags This makes usbcore use the driver model wakeup flags for host controllers and for their root hubs. Since previous patches have removed all users of the HCD flags they replace, this converts the last users of those flags. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-24 08:40:27 -08:00
usbcore: add autosuspend/autoresume infrastructure This patch (as739) adds the basic infrastructure for USB autosuspend and autoresume. The main features are: PM usage counters added to struct usb_device and struct usb_interface, indicating whether it's okay to autosuspend them or they are currently in use. Flag added to usb_device indicating whether the current suspend/resume operation originated from outside or as an autosuspend/autoresume. Flag added to usb_driver indicating whether the driver supports autosuspend. If not, no device bound to the driver will be autosuspended. Mutex added to usb_device for protecting PM operations. Unlike the device semaphore, the locking rule for the pm_mutex is that you must acquire the locks going _up_ the device tree. New routines handling autosuspend/autoresume requests for interfaces and devices. Suspend and resume requests are propagated up the device tree (but not outside the USB subsystem). work_struct added to usb_device, for carrying out delayed autosuspend requests. Autoresume added (and autosuspend prevented) during probe and disconnect. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-08-30 15:47:02 -04:00
USB: Add device quirk for ASUS T100 Base Station keyboard This full-speed USB device generates spurious remote wakeup event as soon as USB_DEVICE_REMOTE_WAKEUP feature is set. As the result, Linux can't enter system suspend and S0ix power saving modes once this keyboard is used. This patch tries to introduce USB_QUIRK_IGNORE_REMOTE_WAKEUP quirk. With this quirk set, wakeup capability will be ignored during device configure. This patch could be back-ported to kernels as old as 2.6.39. Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 10:13:50 +08:00
usbcore: add autosuspend/autoresume infrastructure This patch (as739) adds the basic infrastructure for USB autosuspend and autoresume. The main features are: PM usage counters added to struct usb_device and struct usb_interface, indicating whether it's okay to autosuspend them or they are currently in use. Flag added to usb_device indicating whether the current suspend/resume operation originated from outside or as an autosuspend/autoresume. Flag added to usb_driver indicating whether the driver supports autosuspend. If not, no device bound to the driver will be autosuspended. Mutex added to usb_device for protecting PM operations. Unlike the device semaphore, the locking rule for the pm_mutex is that you must acquire the locks going _up_ the device tree. New routines handling autosuspend/autoresume requests for interfaces and devices. Suspend and resume requests are propagated up the device tree (but not outside the USB subsystem). work_struct added to usb_device, for carrying out delayed autosuspend requests. Autoresume added (and autosuspend prevented) during probe and disconnect. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-08-30 15:47:02 -04:00
USB / Hub: Do not call device_set_wakeup_capable() under spinlock A subsequent patch will modify device_set_wakeup_capable() in such a way that it will call functions which may sleep and therefore it shouldn't be called under spinlocks. In preparation to that, modify usb_set_device_state() to avoid calling device_set_wakeup_capable() under device_state_lock. Tested-by: Minchan Kim <minchan.kim@gmail.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-08 23:25:48 +01:00
[PATCH] USB: remove usbcore-specific wakeup flags This makes usbcore use the driver model wakeup flags for host controllers and for their root hubs. Since previous patches have removed all users of the HCD flags they replace, this converts the last users of those flags. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-24 08:40:27 -08:00
USB: Export suspend statistics This patch exports two statistics to userspace: /sys/bus/usb/device/.../power/connected_duration /sys/bus/usb/device/.../power/active_duration connected_duration is the total time (in msec) that the device has been connected. active_duration is the total time the device has not been suspended. With these two statistics, tools like PowerTOP can calculate the percentage time that a device is active, i.e. not suspended or auto-suspended. Users can also use the active_duration to check if a device is actually autosuspended. Currently, they can set power/level to auto and power/autosuspend to a positive timeout, but there's no way to know from userspace if a device was actually autosuspended without looking at the dmesg output. These statistics will be useful in creating an automated userspace script to test autosuspend for USB devices. Signed-off-by: Sarah Sharp <sarah.a.sharp@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-21 16:54:15 -08:00
usbcore: add autosuspend/autoresume infrastructure This patch (as739) adds the basic infrastructure for USB autosuspend and autoresume. The main features are: PM usage counters added to struct usb_device and struct usb_interface, indicating whether it's okay to autosuspend them or they are currently in use. Flag added to usb_device indicating whether the current suspend/resume operation originated from outside or as an autosuspend/autoresume. Flag added to usb_driver indicating whether the driver supports autosuspend. If not, no device bound to the driver will be autosuspended. Mutex added to usb_device for protecting PM operations. Unlike the device semaphore, the locking rule for the pm_mutex is that you must acquire the locks going _up_ the device tree. New routines handling autosuspend/autoresume requests for interfaces and devices. Suspend and resume requests are propagated up the device tree (but not outside the USB subsystem). work_struct added to usb_device, for carrying out delayed autosuspend requests. Autoresume added (and autosuspend prevented) during probe and disconnect. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-08-30 15:47:02 -04:00
usb: core: add sysfs entry for usb device state Expose usb device state to userland as the information is useful in detecting non-compliant setups and diagnosing enumeration failures. For example: - End-to-end signal integrity issues: the device would fail port reset repeatedly and thus be stuck in POWERED state. - Charge-only cables (missing D+/D- lines): the device would never enter POWERED state as the HC would not see any pullup. What's the status quo? We do have error logs such as "Cannot enable. Maybe the USB cable is bad?" to flag potential setup issues, but there's no good way to expose them to userspace. Why add a sysfs entry in struct usb_port instead of struct usb_device? The struct usb_device is not device_add() to the system until it's in ADDRESS state hence we would miss the first two states. The struct usb_port is a better place to keep the information because its life cycle is longer than the struct usb_device that is attached to the port. Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202306042228.e532af6e-oliver.sang@intel.com Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Roy Luo <royluo@google.com> Message-ID: <20230608015913.1679984-1-royluo@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-08 01:59:12 +00:00
[PATCH] usb device wakeup flags This patch teaches "usb_device" about the new driver model wakeup support: - It updates device wakeup capabilities when entering a configuration with the WAKEUP attribute; - During suspend processing it consults the policy bit to see whether it should enable wakeup for that device. (This resolves a FIXME to not assume the answer is always "yes"; some devices lie about supporting remote wakeup.) Support for root hubs and the HCDs is separate (and more complex). Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-12 19:39:39 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB / Hub: Do not call device_set_wakeup_capable() under spinlock A subsequent patch will modify device_set_wakeup_capable() in such a way that it will call functions which may sleep and therefore it shouldn't be called under spinlocks. In preparation to that, modify usb_set_device_state() to avoid calling device_set_wakeup_capable() under device_state_lock. Tested-by: Minchan Kim <minchan.kim@gmail.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-08 23:25:48 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: allow libusb to talk to unauthenticated WUSB devices To permit a userspace application to associate with WUSB devices using numeric association, control transfers to unauthenticated WUSB devices must be allowed. This requires that wusbcore correctly sets the device state to UNAUTHENTICATED, DEFAULT and ADDRESS and that control transfers can be performed to UNAUTHENTICATED devices. Signed-off-by: David Vrabel <david.vrabel@csr.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-02-18 14:43:47 +00:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
wusb: teach choose_address() about wireless devices Modify choose_address() so it knows about our special scheme of addressing WUSB devices (1:1 w/ port number). Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-08 13:24:46 -07:00
USB: use "device number" instead of "address" The USB stack historically has conflated device numbers (i.e., the value of udev->devnum) with device addresses. This is understandable, because until recently the two values were always the same. But with USB-3.0 they aren't the same, so we should start calling these things by their correct names. This patch (as1449b) changes many of the references to "address" in the hub driver to "device number" or "devnum". The patch also removes some unnecessary or misleading comments. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Luben Tuikov <ltuikov@yahoo.com> Reviewed-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-22 09:53:41 -05:00
USB: Support for addressing a USB device under xHCI Add host controller driver API and a slot_id variable to struct usb_device. This allows the xHCI host controller driver to ask the hardware to allocate a slot for the device when a struct usb_device is allocated. The slot needs to be allocated at that point because the hardware can run out of internal resources, and we want to know that very early in the device connection process. Don't call this new API for root hubs, since they aren't real devices. Add HCD API to let the host controller choose the device address. This is especially important for xHCI hardware running in a virtualized environment. The guests running under the VM don't need to know which addresses on the bus are taken, because the hardware picks the address for them. Announce SuperSpeed USB devices after the address has been assigned by the hardware. Don't use the new get descriptor/set address scheme with xHCI. Unless special handling is done in the host controller driver, the xHC can't issue control transfers before you set the device address. Support for the older addressing scheme will be added when the xHCI driver supports the Block Set Address Request (BSR) flag in the Address Device command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-27 19:57:26 -07:00
wusb: teach choose_address() about wireless devices Modify choose_address() so it knows about our special scheme of addressing WUSB devices (1:1 w/ port number). Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-08 13:24:46 -07:00
USB: use "device number" instead of "address" The USB stack historically has conflated device numbers (i.e., the value of udev->devnum) with device addresses. This is understandable, because until recently the two values were always the same. But with USB-3.0 they aren't the same, so we should start calling these things by their correct names. This patch (as1449b) changes many of the references to "address" in the hub driver to "device number" or "devnum". The patch also removes some unnecessary or misleading comments. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Luben Tuikov <ltuikov@yahoo.com> Reviewed-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-22 09:53:41 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: allow to process more usb hub events in parallel It seems that only choose_devnum() was not ready to process more hub events at the same time. All should be fine if we take bus->usb_address0_mutex there. It will make sure that more devnums will not be chosen for the given bus and the related devices at the same time. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:24 +02:00
usb: core: hub: hub_port_init lock controller instead of bus The XHCI controller presents two USB buses to the system - one for USB2 and one for USB3. The hub init code (hub_port_init) is reentrant but only locks one bus per thread, leading to a race condition failure when two threads attempt to simultaneously initialise a USB2 and USB3 device: [ 8.034843] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command [ 13.183701] usb 3-3: device descriptor read/all, error -110 On a test system this failure occurred on 6% of all boots. The call traces at the point of failure are: Call Trace: [<ffffffff81b9bab7>] schedule+0x37/0x90 [<ffffffff817da7cd>] usb_kill_urb+0x8d/0xd0 [<ffffffff8111e5e0>] ? wake_up_atomic_t+0x30/0x30 [<ffffffff817dafbe>] usb_start_wait_urb+0xbe/0x150 [<ffffffff817db10c>] usb_control_msg+0xbc/0xf0 [<ffffffff817d07de>] hub_port_init+0x51e/0xb70 [<ffffffff817d4697>] hub_event+0x817/0x1570 [<ffffffff810f3e6f>] process_one_work+0x1ff/0x620 [<ffffffff810f3dcf>] ? process_one_work+0x15f/0x620 [<ffffffff810f4684>] worker_thread+0x64/0x4b0 [<ffffffff810f4620>] ? rescuer_thread+0x390/0x390 [<ffffffff810fa7f5>] kthread+0x105/0x120 [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200 [<ffffffff81ba183f>] ret_from_fork+0x3f/0x70 [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200 Call Trace: [<ffffffff817fd36d>] xhci_setup_device+0x53d/0xa40 [<ffffffff817fd87e>] xhci_address_device+0xe/0x10 [<ffffffff817d047f>] hub_port_init+0x1bf/0xb70 [<ffffffff811247ed>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff817d4697>] hub_event+0x817/0x1570 [<ffffffff810f3e6f>] process_one_work+0x1ff/0x620 [<ffffffff810f3dcf>] ? process_one_work+0x15f/0x620 [<ffffffff810f4684>] worker_thread+0x64/0x4b0 [<ffffffff810f4620>] ? rescuer_thread+0x390/0x390 [<ffffffff810fa7f5>] kthread+0x105/0x120 [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200 [<ffffffff81ba183f>] ret_from_fork+0x3f/0x70 [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200 Which results from the two call chains: hub_port_init usb_get_device_descriptor usb_get_descriptor usb_control_msg usb_internal_control_msg usb_start_wait_urb usb_submit_urb / wait_for_completion_timeout / usb_kill_urb hub_port_init hub_set_address xhci_address_device xhci_setup_device Mathias Nyman explains the current behaviour violates the XHCI spec: hub_port_reset() will end up moving the corresponding xhci device slot to default state. As hub_port_reset() is called several times in hub_port_init() it sounds reasonable that we could end up with two threads having their xhci device slots in default state at the same time, which according to xhci 4.5.3 specs still is a big no no: "Note: Software shall not transition more than one Device Slot to the Default State at a time" So both threads fail at their next task after this. One fails to read the descriptor, and the other fails addressing the device. Fix this in hub_port_init by locking the USB controller (instead of an individual bus) to prevent simultaneous initialisation of both buses. Fixes: 638139eb95d2 ("usb: hub: allow to process more usb hub events in parallel") Link: https://lkml.org/lkml/2016/2/8/312 Link: https://lkml.org/lkml/2016/2/4/748 Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com> Cc: stable <stable@vger.kernel.org> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-04-25 13:48:38 +01:00
USB: Remove remnants of Wireless USB and UWB Wireless USB has long been defunct, and kernel support for it was removed in 2020 by commit caa6772db4c1 ("Staging: remove wusbcore and UWB from the kernel tree."). Nevertheless, some vestiges of the old implementation still clutter up the USB subsystem and one or two other places. Let's get rid of them once and for all. The only parts still left are the user-facing APIs in include/uapi/linux/usb/ch9.h. (There are also a couple of misleading instances, such as the Sierra Wireless USB modem, which is a USB modem made by Sierra Wireless.) Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/b4f2710f-a2de-4fb0-b50f-76776f3a961b@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-08 20:44:18 -04:00
usb: core: Remove the useless struct usb_devmap which is just a bitmap struct usb_devmap is really just a bitmap. No need to have a dedicated structure for that. Simplify code and use DECLARE_BITMAP() directly instead. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/1d818575ff7a1e8317674aecf761ee23c89fdc84.1714815990.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-05-04 11:47:05 +02:00
USB: Remove remnants of Wireless USB and UWB Wireless USB has long been defunct, and kernel support for it was removed in 2020 by commit caa6772db4c1 ("Staging: remove wusbcore and UWB from the kernel tree."). Nevertheless, some vestiges of the old implementation still clutter up the USB subsystem and one or two other places. Let's get rid of them once and for all. The only parts still left are the user-facing APIs in include/uapi/linux/usb/ch9.h. (There are also a couple of misleading instances, such as the Sierra Wireless USB modem, which is a USB modem made by Sierra Wireless.) Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/b4f2710f-a2de-4fb0-b50f-76776f3a961b@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-08 20:44:18 -04:00
usb: core: Remove the useless struct usb_devmap which is just a bitmap struct usb_devmap is really just a bitmap. No need to have a dedicated structure for that. Simplify code and use DECLARE_BITMAP() directly instead. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/1d818575ff7a1e8317674aecf761ee23c89fdc84.1714815990.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-05-04 11:47:05 +02:00
USB: Remove remnants of Wireless USB and UWB Wireless USB has long been defunct, and kernel support for it was removed in 2020 by commit caa6772db4c1 ("Staging: remove wusbcore and UWB from the kernel tree."). Nevertheless, some vestiges of the old implementation still clutter up the USB subsystem and one or two other places. Let's get rid of them once and for all. The only parts still left are the user-facing APIs in include/uapi/linux/usb/ch9.h. (There are also a couple of misleading instances, such as the Sierra Wireless USB modem, which is a USB modem made by Sierra Wireless.) Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/b4f2710f-a2de-4fb0-b50f-76776f3a961b@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-08 20:44:18 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: Remove the useless struct usb_devmap which is just a bitmap struct usb_devmap is really just a bitmap. No need to have a dedicated structure for that. Simplify code and use DECLARE_BITMAP() directly instead. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/1d818575ff7a1e8317674aecf761ee23c89fdc84.1714815990.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-05-04 11:47:05 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: hub: hub_port_init lock controller instead of bus The XHCI controller presents two USB buses to the system - one for USB2 and one for USB3. The hub init code (hub_port_init) is reentrant but only locks one bus per thread, leading to a race condition failure when two threads attempt to simultaneously initialise a USB2 and USB3 device: [ 8.034843] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command [ 13.183701] usb 3-3: device descriptor read/all, error -110 On a test system this failure occurred on 6% of all boots. The call traces at the point of failure are: Call Trace: [<ffffffff81b9bab7>] schedule+0x37/0x90 [<ffffffff817da7cd>] usb_kill_urb+0x8d/0xd0 [<ffffffff8111e5e0>] ? wake_up_atomic_t+0x30/0x30 [<ffffffff817dafbe>] usb_start_wait_urb+0xbe/0x150 [<ffffffff817db10c>] usb_control_msg+0xbc/0xf0 [<ffffffff817d07de>] hub_port_init+0x51e/0xb70 [<ffffffff817d4697>] hub_event+0x817/0x1570 [<ffffffff810f3e6f>] process_one_work+0x1ff/0x620 [<ffffffff810f3dcf>] ? process_one_work+0x15f/0x620 [<ffffffff810f4684>] worker_thread+0x64/0x4b0 [<ffffffff810f4620>] ? rescuer_thread+0x390/0x390 [<ffffffff810fa7f5>] kthread+0x105/0x120 [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200 [<ffffffff81ba183f>] ret_from_fork+0x3f/0x70 [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200 Call Trace: [<ffffffff817fd36d>] xhci_setup_device+0x53d/0xa40 [<ffffffff817fd87e>] xhci_address_device+0xe/0x10 [<ffffffff817d047f>] hub_port_init+0x1bf/0xb70 [<ffffffff811247ed>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff817d4697>] hub_event+0x817/0x1570 [<ffffffff810f3e6f>] process_one_work+0x1ff/0x620 [<ffffffff810f3dcf>] ? process_one_work+0x15f/0x620 [<ffffffff810f4684>] worker_thread+0x64/0x4b0 [<ffffffff810f4620>] ? rescuer_thread+0x390/0x390 [<ffffffff810fa7f5>] kthread+0x105/0x120 [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200 [<ffffffff81ba183f>] ret_from_fork+0x3f/0x70 [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200 Which results from the two call chains: hub_port_init usb_get_device_descriptor usb_get_descriptor usb_control_msg usb_internal_control_msg usb_start_wait_urb usb_submit_urb / wait_for_completion_timeout / usb_kill_urb hub_port_init hub_set_address xhci_address_device xhci_setup_device Mathias Nyman explains the current behaviour violates the XHCI spec: hub_port_reset() will end up moving the corresponding xhci device slot to default state. As hub_port_reset() is called several times in hub_port_init() it sounds reasonable that we could end up with two threads having their xhci device slots in default state at the same time, which according to xhci 4.5.3 specs still is a big no no: "Note: Software shall not transition more than one Device Slot to the Default State at a time" So both threads fail at their next task after this. One fails to read the descriptor, and the other fails addressing the device. Fix this in hub_port_init by locking the USB controller (instead of an individual bus) to prevent simultaneous initialisation of both buses. Fixes: 638139eb95d2 ("usb: hub: allow to process more usb hub events in parallel") Link: https://lkml.org/lkml/2016/2/8/312 Link: https://lkml.org/lkml/2016/2/4/748 Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com> Cc: stable <stable@vger.kernel.org> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-04-25 13:48:38 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: use "device number" instead of "address" The USB stack historically has conflated device numbers (i.e., the value of udev->devnum) with device addresses. This is understandable, because until recently the two values were always the same. But with USB-3.0 they aren't the same, so we should start calling these things by their correct names. This patch (as1449b) changes many of the references to "address" in the hub driver to "device number" or "devnum". The patch also removes some unnecessary or misleading comments. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Luben Tuikov <ltuikov@yahoo.com> Reviewed-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-22 09:53:41 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: Remove the useless struct usb_devmap which is just a bitmap struct usb_devmap is really just a bitmap. No need to have a dedicated structure for that. Simplify code and use DECLARE_BITMAP() directly instead. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/1d818575ff7a1e8317674aecf761ee23c89fdc84.1714815990.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-05-04 11:47:05 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: use "device number" instead of "address" The USB stack historically has conflated device numbers (i.e., the value of udev->devnum) with device addresses. This is understandable, because until recently the two values were always the same. But with USB-3.0 they aren't the same, so we should start calling these things by their correct names. This patch (as1449b) changes many of the references to "address" in the hub driver to "device number" or "devnum". The patch also removes some unnecessary or misleading comments. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Luben Tuikov <ltuikov@yahoo.com> Reviewed-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-22 09:53:41 -05:00
usb: don't update devnum for wusb devices For WUSB devices, usb_dev.devnum is a device index and not the real device address (which is managed by wusbcore). Therefore, only set devnum once (in choose_address()) and never change it. Signed-off-by: David Vrabel <david.vrabel@csr.com> Cc: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-08 13:24:46 -07:00
USB: Remove remnants of Wireless USB and UWB Wireless USB has long been defunct, and kernel support for it was removed in 2020 by commit caa6772db4c1 ("Staging: remove wusbcore and UWB from the kernel tree."). Nevertheless, some vestiges of the old implementation still clutter up the USB subsystem and one or two other places. Let's get rid of them once and for all. The only parts still left are the user-facing APIs in include/uapi/linux/usb/ch9.h. (There are also a couple of misleading instances, such as the Sierra Wireless USB modem, which is a USB modem made by Sierra Wireless.) Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/b4f2710f-a2de-4fb0-b50f-76776f3a961b@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-08 20:44:18 -04:00
usb: Add devaddr in struct usb_device The Clear_TT_Buffer request sent to the hub includes the address of the LS/FS child device in wValue field. usb_hub_clear_tt_buffer() uses udev->devnum to set the address wValue. This won't work for devices connected to xHC. For other host controllers udev->devnum is the same as the address of the usb device, chosen and set by usb core. With xHC the controller hardware assigns the address, and won't be the same as devnum. Here we add devaddr in "struct usb_device" for usb_hub_clear_tt_buffer() to use. Signed-off-by: Jim Lin <jilin@nvidia.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-03 18:53:43 +08:00
usb: don't update devnum for wusb devices For WUSB devices, usb_dev.devnum is a device index and not the real device address (which is managed by wusbcore). Therefore, only set devnum once (in choose_address()) and never change it. Signed-off-by: David Vrabel <david.vrabel@csr.com> Cc: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-08 13:24:46 -07:00
USB: Move hcd free_dev call into usb_disconnect to fix oops USB: Move hcd free_dev call into usb_disconnect I found a way to oops the kernel: 1. Open a USB device through devio. 2. Remove the hcd module in the host kernel. 3. Close the devio file descriptor. The problem is that closing the file descriptor does usb_release_dev as it is the last reference. usb_release_dev then tries to invoke the hcd free_dev function (or rather dereferencing the hcd driver struct). This causes an oops as the hcd driver has already been unloaded so the struct is gone. This patch tries to fix this by bringing the free_dev call earlier and into usb_disconnect. I have verified that repeating the above steps no longer crashes with this patch applied. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-10 20:15:03 +11:00
usb: resume child device when port is powered on Unconditionally wake up the child device when the power session is recovered. This addresses the following scenarios: 1/ The device may need a reset on power-session loss, without this change port power-on recovery exposes khubd to scenarios that usb_port_resume() is set to handle. Prior to port power control the only time a power session would be lost is during dpm_suspend of the hub. In that scenario usb_port_resume() is guaranteed to be called prior to khubd running for that port. With this change we wakeup the child device as soon as possible (prior to khubd running again for this port). Although khubd has facilities to wake a child device it will only do so if the portstatus / portchange indicates a suspend state. In the case of port power control we are not coming from a hub-port-suspend state. This implementation simply uses pm_request_resume() to wake the device and relies on the port_dev->status_lock to prevent any collisions between khubd and usb_port_resume(). 2/ This mechanism rate limits port power toggling. The minimum port power on/off period is now gated by the child device suspend/resume latency. Empirically this mitigates devices downgrading their connection on perceived instability of the host connection. This ratelimiting is really only relevant to port power control testing, but it is a nice side effect of closing the above race. Namely, the race of khubd for the given port running while a usb_port_resume() event is pending. 3/ Going forward we are finding that power-session recovery requires warm-resets (http://marc.info/?t=138659232900003&r=1&w=2). This mechanism allows for warm-resets to be requested at the same point in the resume path for hub dpm_suspend power session losses, or port rpm_suspend power session losses. 4/ If the device *was* disconnected the only time we'll know for sure is after a failed resume, so it's necessary for usb_port_runtime_resume() to expedite a usb_port_resume() to clean up the removed device. The reasoning for this is "least surprise" for the user. Turning on a port means that hotplug detection is again enabled for the port, it is surprising that devices that were removed while the port was off are not disconnected until they are attempted to be used. As a user "why would I try to use a device I removed from the system?" 1, 2, and 4 are not a problem in the system dpm_resume() case because, although the power-session is lost, khubd is frozen until after device resume. For the rpm_resume() case pm_request_resume() is used to request re-validation of the device, and if it happens to collide with a khubd run we rely on the port_dev->status_lock to synchronize those operations. Besides testing, the primary scenario where this mechanism is expected to be triggered is when the user changes the port power policy (control/pm_qos_no_poweroff, or power/control). Each time power is enabled want to revalidate the child device, where the revalidation is handled by usb_port_resume(). Given that this arranges for port_dev->child to be de-referenced in usb_port_runtime_resume() we need to make sure not to collide with usb_disconnect() that frees the usb_device. To this end we hold the port active with the "child_usage" reference across the disconnect event. Subsequently, the need to access hub->child_usage_bits lead to the creation of hub_disconnect_children() to remove any ambiguity of which "hub" is being acted on in usb_disconnect() (prompted-by sharp eyes from Alan). Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:36 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: Replace in_interrupt() in comments The usage of in_interrupt() in drivers is phased out for various reasons. Various comments use !in_interrupt() to describe calling context for functions which might sleep. That's wrong because the calling context has to be preemptible task context, which is not what !in_interrupt() describes. Replace !in_interrupt() with more accurate plain text descriptions. The comment for usb_hcd_poll_rh_status() is misleading as this function is called from all kinds of contexts including preemptible task context. Remove it as there is obviously no restriction. Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: linux-usb@vger.kernel.org Link: https://lore.kernel.org/r/20201019101110.851821025@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-19 12:06:41 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: rename mutex usb_bus_list_lock to usb_bus_idr_lock Now that usb_bus_list has been removed and switched to idr rename the related mutex accordingly. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-03 23:35:23 +01:00
USB: correct the usb_disconnect() comment about usb_bus_list_lock usb_disconnect() no longer acquires usb_bus_list_lock, so update its comment to that effect. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-09-13 13:57:34 -06:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: resume child device when port is powered on Unconditionally wake up the child device when the power session is recovered. This addresses the following scenarios: 1/ The device may need a reset on power-session loss, without this change port power-on recovery exposes khubd to scenarios that usb_port_resume() is set to handle. Prior to port power control the only time a power session would be lost is during dpm_suspend of the hub. In that scenario usb_port_resume() is guaranteed to be called prior to khubd running for that port. With this change we wakeup the child device as soon as possible (prior to khubd running again for this port). Although khubd has facilities to wake a child device it will only do so if the portstatus / portchange indicates a suspend state. In the case of port power control we are not coming from a hub-port-suspend state. This implementation simply uses pm_request_resume() to wake the device and relies on the port_dev->status_lock to prevent any collisions between khubd and usb_port_resume(). 2/ This mechanism rate limits port power toggling. The minimum port power on/off period is now gated by the child device suspend/resume latency. Empirically this mitigates devices downgrading their connection on perceived instability of the host connection. This ratelimiting is really only relevant to port power control testing, but it is a nice side effect of closing the above race. Namely, the race of khubd for the given port running while a usb_port_resume() event is pending. 3/ Going forward we are finding that power-session recovery requires warm-resets (http://marc.info/?t=138659232900003&r=1&w=2). This mechanism allows for warm-resets to be requested at the same point in the resume path for hub dpm_suspend power session losses, or port rpm_suspend power session losses. 4/ If the device *was* disconnected the only time we'll know for sure is after a failed resume, so it's necessary for usb_port_runtime_resume() to expedite a usb_port_resume() to clean up the removed device. The reasoning for this is "least surprise" for the user. Turning on a port means that hotplug detection is again enabled for the port, it is surprising that devices that were removed while the port was off are not disconnected until they are attempted to be used. As a user "why would I try to use a device I removed from the system?" 1, 2, and 4 are not a problem in the system dpm_resume() case because, although the power-session is lost, khubd is frozen until after device resume. For the rpm_resume() case pm_request_resume() is used to request re-validation of the device, and if it happens to collide with a khubd run we rely on the port_dev->status_lock to synchronize those operations. Besides testing, the primary scenario where this mechanism is expected to be triggered is when the user changes the port power policy (control/pm_qos_no_poweroff, or power/control). Each time power is enabled want to revalidate the child device, where the revalidation is handled by usb_port_resume(). Given that this arranges for port_dev->child to be de-referenced in usb_port_runtime_resume() we need to make sure not to collide with usb_disconnect() that frees the usb_device. To this end we hold the port active with the "child_usage" reference across the disconnect event. Subsequently, the need to access hub->child_usage_bits lead to the creation of hub_disconnect_children() to remove any ambiguity of which "hub" is being acted on in usb_disconnect() (prompted-by sharp eyes from Alan). Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:36 -07:00
usb: core: fix below build warning linux-2.6/drivers/usb/core/hub.c: In function 'usb_disconnect': linux-2.6/drivers/usb/core/hub.c:2110: warning: 'hub' may be used uninitialized in this function linux-2.6/drivers/usb/core/hub.c:2111: warning: 'port1' may be used uninitialized in this function Signed-off-by: Peter Chen <peter.chen@freescale.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-08-19 08:56:21 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
Fix common misspellings Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
2011-03-30 22:57:33 -03:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: use "device number" instead of "address" The USB stack historically has conflated device numbers (i.e., the value of udev->devnum) with device addresses. This is understandable, because until recently the two values were always the same. But with USB-3.0 they aren't the same, so we should start calling these things by their correct names. This patch (as1449b) changes many of the references to "address" in the hub driver to "device number" or "devnum". The patch also removes some unnecessary or misleading comments. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Luben Tuikov <ltuikov@yahoo.com> Reviewed-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-22 09:53:41 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: Do not attempt to autosuspend disconnected devices While running a bind/unbind stress test with the dwc3 usb driver on rk3399, the following crash was observed. Unable to handle kernel NULL pointer dereference at virtual address 00000218 pgd = ffffffc00165f000 [00000218] *pgd=000000000174f003, *pud=000000000174f003, *pmd=0000000001750003, *pte=00e8000001751713 Internal error: Oops: 96000005 [#1] PREEMPT SMP Modules linked in: uinput uvcvideo videobuf2_vmalloc cmac ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat rfcomm xt_mark fuse bridge stp llc zram btusb btrtl btbcm btintel bluetooth ip6table_filter mwifiex_pcie mwifiex cfg80211 cdc_ether usbnet r8152 mii joydev snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device ppp_async ppp_generic slhc tun CPU: 1 PID: 29814 Comm: kworker/1:1 Not tainted 4.4.52 #507 Hardware name: Google Kevin (DT) Workqueue: pm pm_runtime_work task: ffffffc0ac540000 ti: ffffffc0af4d4000 task.ti: ffffffc0af4d4000 PC is at autosuspend_check+0x74/0x174 LR is at autosuspend_check+0x70/0x174 ... Call trace: [<ffffffc00080dcc0>] autosuspend_check+0x74/0x174 [<ffffffc000810500>] usb_runtime_idle+0x20/0x40 [<ffffffc000785ae0>] __rpm_callback+0x48/0x7c [<ffffffc000786af0>] rpm_idle+0x1e8/0x498 [<ffffffc000787cdc>] pm_runtime_work+0x88/0xcc [<ffffffc000249bb8>] process_one_work+0x390/0x6b8 [<ffffffc00024abcc>] worker_thread+0x480/0x610 [<ffffffc000251a80>] kthread+0x164/0x178 [<ffffffc0002045d0>] ret_from_fork+0x10/0x40 Source: (gdb) l *0xffffffc00080dcc0 0xffffffc00080dcc0 is in autosuspend_check (drivers/usb/core/driver.c:1778). 1773 /* We don't need to check interfaces that are 1774 * disabled for runtime PM. Either they are unbound 1775 * or else their drivers don't support autosuspend 1776 * and so they are permanently active. 1777 */ 1778 if (intf->dev.power.disable_depth) 1779 continue; 1780 if (atomic_read(&intf->dev.power.usage_count) > 0) 1781 return -EBUSY; 1782 w |= intf->needs_remote_wakeup; Code analysis shows that intf is set to NULL in usb_disable_device() prior to setting actconfig to NULL. At the same time, usb_runtime_idle() does not lock the usb device, and neither does any of the functions in the traceback. This means that there is no protection against a race condition where usb_disable_device() is removing dev->actconfig->interface[] pointers while those are being accessed from autosuspend_check(). To solve the problem, synchronize and validate device state between autosuspend_check() and usb_disconnect(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-20 14:30:50 -07:00
[PATCH] USB: Remove USB private semaphore This patch (as605) removes the private udev->serialize semaphore, relying instead on the locking provided by the embedded struct device's semaphore. The changes are confined to the core, except that the usb_trylock_device routine now uses the return convention of down_trylock rather than down_read_trylock (they return opposite values for no good reason). A couple of other associated changes are included as well: Now that we aren't concerned about HCDs that avoid using the hcd glue layer, usb_disconnect no longer needs to acquire the usb_bus_lock -- that can be done by usb_remove_hcd where it belongs. Devices aren't locked over the same scope of code in usb_new_device and hub_port_connect_change as they used to be. This shouldn't cause any trouble. Along with the preceding driver core patch, this needs a lot of testing. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-17 17:10:32 -05:00
usb: resume child device when port is powered on Unconditionally wake up the child device when the power session is recovered. This addresses the following scenarios: 1/ The device may need a reset on power-session loss, without this change port power-on recovery exposes khubd to scenarios that usb_port_resume() is set to handle. Prior to port power control the only time a power session would be lost is during dpm_suspend of the hub. In that scenario usb_port_resume() is guaranteed to be called prior to khubd running for that port. With this change we wakeup the child device as soon as possible (prior to khubd running again for this port). Although khubd has facilities to wake a child device it will only do so if the portstatus / portchange indicates a suspend state. In the case of port power control we are not coming from a hub-port-suspend state. This implementation simply uses pm_request_resume() to wake the device and relies on the port_dev->status_lock to prevent any collisions between khubd and usb_port_resume(). 2/ This mechanism rate limits port power toggling. The minimum port power on/off period is now gated by the child device suspend/resume latency. Empirically this mitigates devices downgrading their connection on perceived instability of the host connection. This ratelimiting is really only relevant to port power control testing, but it is a nice side effect of closing the above race. Namely, the race of khubd for the given port running while a usb_port_resume() event is pending. 3/ Going forward we are finding that power-session recovery requires warm-resets (http://marc.info/?t=138659232900003&r=1&w=2). This mechanism allows for warm-resets to be requested at the same point in the resume path for hub dpm_suspend power session losses, or port rpm_suspend power session losses. 4/ If the device *was* disconnected the only time we'll know for sure is after a failed resume, so it's necessary for usb_port_runtime_resume() to expedite a usb_port_resume() to clean up the removed device. The reasoning for this is "least surprise" for the user. Turning on a port means that hotplug detection is again enabled for the port, it is surprising that devices that were removed while the port was off are not disconnected until they are attempted to be used. As a user "why would I try to use a device I removed from the system?" 1, 2, and 4 are not a problem in the system dpm_resume() case because, although the power-session is lost, khubd is frozen until after device resume. For the rpm_resume() case pm_request_resume() is used to request re-validation of the device, and if it happens to collide with a khubd run we rely on the port_dev->status_lock to synchronize those operations. Besides testing, the primary scenario where this mechanism is expected to be triggered is when the user changes the port power policy (control/pm_qos_no_poweroff, or power/control). Each time power is enabled want to revalidate the child device, where the revalidation is handled by usb_port_resume(). Given that this arranges for port_dev->child to be de-referenced in usb_port_runtime_resume() we need to make sure not to collide with usb_disconnect() that frees the usb_device. To this end we hold the port active with the "child_usage" reference across the disconnect event. Subsequently, the need to access hub->child_usage_bits lead to the creation of hub_disconnect_children() to remove any ambiguity of which "hub" is being acted on in usb_disconnect() (prompted-by sharp eyes from Alan). Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:36 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: hub: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-11 21:34:37 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: fix crash when URBs are unlinked after the device is gone This patch (as1151) protects usbcore against drivers that try to unlink an URB after the URB's device or bus have been removed. The core does not currently check for this, and certain drivers can cause a crash if they are running while an HCD is unloaded. Certainly it would be best to fix the guilty drivers. But a little defensive programming doesn't hurt, especially since it appears that quite a few drivers need to be fixed. The patch prevents the problem by grabbing a reference to the device while an unlink is in progress and using a new spinlock to synchronize unlinks with device removal. (There's no need to acquire a reference to the bus as well, since the device structure itself keeps a reference to the bus.) In addition, the kerneldoc is updated to indicate that URBs should not be unlinked after the disconnect method returns. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-10-21 15:28:46 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: Create link files between child device and usb port device. To show the relationship between usb port and child device, add link file "port" under usb device's sysfs directoy and "device" under usb port device's sysfs directory. They are linked to each other. 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>
2013-01-20 01:53:33 +08:00
usb: resume child device when port is powered on Unconditionally wake up the child device when the power session is recovered. This addresses the following scenarios: 1/ The device may need a reset on power-session loss, without this change port power-on recovery exposes khubd to scenarios that usb_port_resume() is set to handle. Prior to port power control the only time a power session would be lost is during dpm_suspend of the hub. In that scenario usb_port_resume() is guaranteed to be called prior to khubd running for that port. With this change we wakeup the child device as soon as possible (prior to khubd running again for this port). Although khubd has facilities to wake a child device it will only do so if the portstatus / portchange indicates a suspend state. In the case of port power control we are not coming from a hub-port-suspend state. This implementation simply uses pm_request_resume() to wake the device and relies on the port_dev->status_lock to prevent any collisions between khubd and usb_port_resume(). 2/ This mechanism rate limits port power toggling. The minimum port power on/off period is now gated by the child device suspend/resume latency. Empirically this mitigates devices downgrading their connection on perceived instability of the host connection. This ratelimiting is really only relevant to port power control testing, but it is a nice side effect of closing the above race. Namely, the race of khubd for the given port running while a usb_port_resume() event is pending. 3/ Going forward we are finding that power-session recovery requires warm-resets (http://marc.info/?t=138659232900003&r=1&w=2). This mechanism allows for warm-resets to be requested at the same point in the resume path for hub dpm_suspend power session losses, or port rpm_suspend power session losses. 4/ If the device *was* disconnected the only time we'll know for sure is after a failed resume, so it's necessary for usb_port_runtime_resume() to expedite a usb_port_resume() to clean up the removed device. The reasoning for this is "least surprise" for the user. Turning on a port means that hotplug detection is again enabled for the port, it is surprising that devices that were removed while the port was off are not disconnected until they are attempted to be used. As a user "why would I try to use a device I removed from the system?" 1, 2, and 4 are not a problem in the system dpm_resume() case because, although the power-session is lost, khubd is frozen until after device resume. For the rpm_resume() case pm_request_resume() is used to request re-validation of the device, and if it happens to collide with a khubd run we rely on the port_dev->status_lock to synchronize those operations. Besides testing, the primary scenario where this mechanism is expected to be triggered is when the user changes the port power policy (control/pm_qos_no_poweroff, or power/control). Each time power is enabled want to revalidate the child device, where the revalidation is handled by usb_port_resume(). Given that this arranges for port_dev->child to be de-referenced in usb_port_runtime_resume() we need to make sure not to collide with usb_disconnect() that frees the usb_device. To this end we hold the port active with the "child_usage" reference across the disconnect event. Subsequently, the need to access hub->child_usage_bits lead to the creation of hub_disconnect_children() to remove any ambiguity of which "hub" is being acted on in usb_disconnect() (prompted-by sharp eyes from Alan). Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:36 -07:00
usb: Create link files between child device and usb port device. To show the relationship between usb port and child device, add link file "port" under usb device's sysfs directoy and "device" under usb port device's sysfs directory. They are linked to each other. 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>
2013-01-20 01:53:33 +08:00
usb: add runtime pm support for usb port device This patch is to add runtime pm callback for usb port device. Set/clear PORT_POWER feature in the resume/suspend callback. Add portnum for struct usb_port to record port number. Do pm_rumtime_get_sync/put(portdev) when a device is plugged/unplugged to prevent it from being powered off when it is active. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:29 +08:00
usb: resume child device when port is powered on Unconditionally wake up the child device when the power session is recovered. This addresses the following scenarios: 1/ The device may need a reset on power-session loss, without this change port power-on recovery exposes khubd to scenarios that usb_port_resume() is set to handle. Prior to port power control the only time a power session would be lost is during dpm_suspend of the hub. In that scenario usb_port_resume() is guaranteed to be called prior to khubd running for that port. With this change we wakeup the child device as soon as possible (prior to khubd running again for this port). Although khubd has facilities to wake a child device it will only do so if the portstatus / portchange indicates a suspend state. In the case of port power control we are not coming from a hub-port-suspend state. This implementation simply uses pm_request_resume() to wake the device and relies on the port_dev->status_lock to prevent any collisions between khubd and usb_port_resume(). 2/ This mechanism rate limits port power toggling. The minimum port power on/off period is now gated by the child device suspend/resume latency. Empirically this mitigates devices downgrading their connection on perceived instability of the host connection. This ratelimiting is really only relevant to port power control testing, but it is a nice side effect of closing the above race. Namely, the race of khubd for the given port running while a usb_port_resume() event is pending. 3/ Going forward we are finding that power-session recovery requires warm-resets (http://marc.info/?t=138659232900003&r=1&w=2). This mechanism allows for warm-resets to be requested at the same point in the resume path for hub dpm_suspend power session losses, or port rpm_suspend power session losses. 4/ If the device *was* disconnected the only time we'll know for sure is after a failed resume, so it's necessary for usb_port_runtime_resume() to expedite a usb_port_resume() to clean up the removed device. The reasoning for this is "least surprise" for the user. Turning on a port means that hotplug detection is again enabled for the port, it is surprising that devices that were removed while the port was off are not disconnected until they are attempted to be used. As a user "why would I try to use a device I removed from the system?" 1, 2, and 4 are not a problem in the system dpm_resume() case because, although the power-session is lost, khubd is frozen until after device resume. For the rpm_resume() case pm_request_resume() is used to request re-validation of the device, and if it happens to collide with a khubd run we rely on the port_dev->status_lock to synchronize those operations. Besides testing, the primary scenario where this mechanism is expected to be triggered is when the user changes the port power policy (control/pm_qos_no_poweroff, or power/control). Each time power is enabled want to revalidate the child device, where the revalidation is handled by usb_port_resume(). Given that this arranges for port_dev->child to be de-referenced in usb_port_runtime_resume() we need to make sure not to collide with usb_disconnect() that frees the usb_device. To this end we hold the port active with the "child_usage" reference across the disconnect event. Subsequently, the need to access hub->child_usage_bits lead to the creation of hub_disconnect_children() to remove any ambiguity of which "hub" is being acted on in usb_disconnect() (prompted-by sharp eyes from Alan). Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:36 -07:00
usb: Inform the USB Type-C class about enumerated devices The Type-C port drivers can make PM related decisions based on is the device USB3 or USB2. Suggested-by: Benson Leung <bleung@chromium.org> Tested-by: Benson Leung <bleung@chromium.org> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20231011105825.320062-3-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-11 13:58:25 +03:00
usb: Create link files between child device and usb port device. To show the relationship between usb port and child device, add link file "port" under usb device's sysfs directoy and "device" under usb port device's sysfs directory. They are linked to each other. 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>
2013-01-20 01:53:33 +08:00
USB: utilize the bus notifiers This patch (as1185) makes usbcore take advantage of the bus notifications sent out by the driver core. Now we can create all our device and interface attribute files before the device or interface uevent is broadcast. A side effect is that we no longer create the endpoint "pseudo" devices at the same time as a device or interface is registered -- it seems like a bad idea to try registering an endpoint before the registration of its parent is complete. So the routines for creating and removing endpoint devices have been split out and renamed, and they are called explicitly when needed. A new bitflag is used for keeping track of whether or not the interface's endpoint devices have been created, since (just as with the interface attributes) they vary with the altsetting and hence can be changed at random times. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-05 14:10:34 -05:00
usbcore: make usb_generic a usb_device_driver This patch (as714b) makes usb_generic into a usb_device_driver capable of being probed and unbound, just like other drivers. A fair amount of the work that used to get done during discovery or removal of a USB device have been moved to the probe and disconnect methods of usb_generic: creating the sysfs attributes and selecting an initial configuration. However the normal behavior should continue to be the same as before. We will now have the possibility of creating other USB device drivers, They will assist with exporting devices to remote systems (USB-over-TCPIP) or to paravirtual guest operating systems. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-07-01 22:09:35 -04:00
[PATCH] USB: add notifier functions to the USB core for devices and busses This should let us get rid of all of the different hooks in the USB core for when something has changed. Also, some other parts of the kernel have wanted to know this kind of information at times. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-06-20 21:15:16 -07:00
usbcore: make usb_generic a usb_device_driver This patch (as714b) makes usb_generic into a usb_device_driver capable of being probed and unbound, just like other drivers. A fair amount of the work that used to get done during discovery or removal of a USB device have been moved to the probe and disconnect methods of usb_generic: creating the sysfs attributes and selecting an initial configuration. However the normal behavior should continue to be the same as before. We will now have the possibility of creating other USB device drivers, They will assist with exporting devices to remote systems (USB-over-TCPIP) or to paravirtual guest operating systems. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-07-01 22:09:35 -04:00
USB: utilize the bus notifiers This patch (as1185) makes usbcore take advantage of the bus notifications sent out by the driver core. Now we can create all our device and interface attribute files before the device or interface uevent is broadcast. A side effect is that we no longer create the endpoint "pseudo" devices at the same time as a device or interface is registered -- it seems like a bad idea to try registering an endpoint before the registration of its parent is complete. So the routines for creating and removing endpoint devices have been split out and renamed, and they are called explicitly when needed. A new bitflag is used for keeping track of whether or not the interface's endpoint devices have been created, since (just as with the interface attributes) they vary with the altsetting and hence can be changed at random times. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-05 14:10:34 -05:00
usbcore: make usb_generic a usb_device_driver This patch (as714b) makes usb_generic into a usb_device_driver capable of being probed and unbound, just like other drivers. A fair amount of the work that used to get done during discovery or removal of a USB device have been moved to the probe and disconnect methods of usb_generic: creating the sysfs attributes and selecting an initial configuration. However the normal behavior should continue to be the same as before. We will now have the possibility of creating other USB device drivers, They will assist with exporting devices to remote systems (USB-over-TCPIP) or to paravirtual guest operating systems. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-07-01 22:09:35 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: use "device number" instead of "address" The USB stack historically has conflated device numbers (i.e., the value of udev->devnum) with device addresses. This is understandable, because until recently the two values were always the same. But with USB-3.0 they aren't the same, so we should start calling these things by their correct names. This patch (as1449b) changes many of the references to "address" in the hub driver to "device number" or "devnum". The patch also removes some unnecessary or misleading comments. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Luben Tuikov <ltuikov@yahoo.com> Reviewed-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-22 09:53:41 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: resume child device when port is powered on Unconditionally wake up the child device when the power session is recovered. This addresses the following scenarios: 1/ The device may need a reset on power-session loss, without this change port power-on recovery exposes khubd to scenarios that usb_port_resume() is set to handle. Prior to port power control the only time a power session would be lost is during dpm_suspend of the hub. In that scenario usb_port_resume() is guaranteed to be called prior to khubd running for that port. With this change we wakeup the child device as soon as possible (prior to khubd running again for this port). Although khubd has facilities to wake a child device it will only do so if the portstatus / portchange indicates a suspend state. In the case of port power control we are not coming from a hub-port-suspend state. This implementation simply uses pm_request_resume() to wake the device and relies on the port_dev->status_lock to prevent any collisions between khubd and usb_port_resume(). 2/ This mechanism rate limits port power toggling. The minimum port power on/off period is now gated by the child device suspend/resume latency. Empirically this mitigates devices downgrading their connection on perceived instability of the host connection. This ratelimiting is really only relevant to port power control testing, but it is a nice side effect of closing the above race. Namely, the race of khubd for the given port running while a usb_port_resume() event is pending. 3/ Going forward we are finding that power-session recovery requires warm-resets (http://marc.info/?t=138659232900003&r=1&w=2). This mechanism allows for warm-resets to be requested at the same point in the resume path for hub dpm_suspend power session losses, or port rpm_suspend power session losses. 4/ If the device *was* disconnected the only time we'll know for sure is after a failed resume, so it's necessary for usb_port_runtime_resume() to expedite a usb_port_resume() to clean up the removed device. The reasoning for this is "least surprise" for the user. Turning on a port means that hotplug detection is again enabled for the port, it is surprising that devices that were removed while the port was off are not disconnected until they are attempted to be used. As a user "why would I try to use a device I removed from the system?" 1, 2, and 4 are not a problem in the system dpm_resume() case because, although the power-session is lost, khubd is frozen until after device resume. For the rpm_resume() case pm_request_resume() is used to request re-validation of the device, and if it happens to collide with a khubd run we rely on the port_dev->status_lock to synchronize those operations. Besides testing, the primary scenario where this mechanism is expected to be triggered is when the user changes the port power policy (control/pm_qos_no_poweroff, or power/control). Each time power is enabled want to revalidate the child device, where the revalidation is handled by usb_port_resume(). Given that this arranges for port_dev->child to be de-referenced in usb_port_runtime_resume() we need to make sure not to collide with usb_disconnect() that frees the usb_device. To this end we hold the port active with the "child_usage" reference across the disconnect event. Subsequently, the need to access hub->child_usage_bits lead to the creation of hub_disconnect_children() to remove any ambiguity of which "hub" is being acted on in usb_disconnect() (prompted-by sharp eyes from Alan). Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:36 -07:00
USB: Move hcd free_dev call into usb_disconnect to fix oops USB: Move hcd free_dev call into usb_disconnect I found a way to oops the kernel: 1. Open a USB device through devio. 2. Remove the hcd module in the host kernel. 3. Close the devio file descriptor. The problem is that closing the file descriptor does usb_release_dev as it is the last reference. usb_release_dev then tries to invoke the hcd free_dev function (or rather dereferencing the hcd driver struct). This causes an oops as the hcd driver has already been unloaded so the struct is gone. This patch tries to fix this by bringing the free_dev call earlier and into usb_disconnect. I have verified that repeating the above steps no longer crashes with this patch applied. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-10 20:15:03 +11:00
usbcore: make usb_generic a usb_device_driver This patch (as714b) makes usb_generic into a usb_device_driver capable of being probed and unbound, just like other drivers. A fair amount of the work that used to get done during discovery or removal of a USB device have been moved to the probe and disconnect methods of usb_generic: creating the sysfs attributes and selecting an initial configuration. However the normal behavior should continue to be the same as before. We will now have the possibility of creating other USB device drivers, They will assist with exporting devices to remote systems (USB-over-TCPIP) or to paravirtual guest operating systems. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-07-01 22:09:35 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: always announce a device has been added to the system Distros (like SuSE) want to know this information, to make it easier to handle support issues. Might as well let everyone benefit from this. This is also enabled whenever CONFIG_USB_DEBUG is enabled, to help with debugging. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26 22:11:55 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: Convert dev_printk(KERN_<LEVEL> to dev_<level>( dev_<level> calls take less code than dev_printk(KERN_<LEVEL> and reducing object size is good. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-28 01:05:51 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: always announce a device has been added to the system Distros (like SuSE) want to know this information, to make it easier to handle support issues. Might as well let everyone benefit from this. This is also enabled whenever CONFIG_USB_DEBUG is enabled, to help with debugging. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26 22:11:55 -08:00
USB: announce bcdDevice as well as idVendor, idProduct. Print bcdDevice which is used by vendors to identify different versions of the same product (or different versions of firmware). Adding this to the logs will be useful for support purposes. Match the %2x.%02x formatting that's used by lsusb -v for this same value. Signed-off-by: Benson Leung <bleung@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-03-24 10:40:27 -07:00
USB: always announce a device has been added to the system Distros (like SuSE) want to know this information, to make it easier to handle support issues. Might as well let everyone benefit from this. This is also enabled whenever CONFIG_USB_DEBUG is enabled, to help with debugging. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26 22:11:55 -08:00
USB: announce bcdDevice as well as idVendor, idProduct. Print bcdDevice which is used by vendors to identify different versions of the same product (or different versions of firmware). Adding this to the logs will be useful for support purposes. Match the %2x.%02x formatting that's used by lsusb -v for this same value. Signed-off-by: Benson Leung <bleung@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-03-24 10:40:27 -07:00
USB: make printk messages more searchable USB: make printk messages more searchable Make USB printk messages long and straightforward. One of these decorated USB error messages cost me non-trivial efforts to locate. Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-15 15:32:01 +08:00
USB: always announce a device has been added to the system Distros (like SuSE) want to know this information, to make it easier to handle support issues. Might as well let everyone benefit from this. This is also enabled whenever CONFIG_USB_DEBUG is enabled, to help with debugging. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26 22:11:55 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: always announce a device has been added to the system Distros (like SuSE) want to know this information, to make it easier to handle support issues. Might as well let everyone benefit from this. This is also enabled whenever CONFIG_USB_DEBUG is enabled, to help with debugging. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-26 22:11:55 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: total removal of multithreaded probing in usb The whole approach is simply wrong. Forking a thread means that - errors are ignored - locking is ignored Doing this correctly would require major surgery for questionable benefit. Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-01-11 14:35:50 +01:00
USB: rename usb_configure_device This patch (as1314) renames usb_configure_device() and usb_configure_device_otg() in the hub driver. Neither name is appropriate because these routines enumerate devices, they don't configure them. That's handled by usb_choose_configuration() and usb_set_configuration(). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08 15:50:41 -05:00
USB: total removal of multithreaded probing in usb The whole approach is simply wrong. Forking a thread means that - errors are ignored - locking is ignored Doing this correctly would require major surgery for questionable benefit. Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-01-11 14:35:50 +01:00
USB: rename usb_configure_device This patch (as1314) renames usb_configure_device() and usb_configure_device_otg() in the hub driver. Neither name is appropriate because these routines enumerate devices, they don't configure them. That's handled by usb_choose_configuration() and usb_set_configuration(). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08 15:50:41 -05:00
usb: fix some scripts/kernel-doc warnings When building the htmldocs (in verbose mode), scripts/kernel-doc reports the following type of warnings: Warning(drivers/usb/core/usb.c:76): No description found for return value of 'usb_find_alt_setting' Fix them by: - adding some missing descriptions of return values - using "Return" sections for those descriptions Signed-off-by: Yacine Belkadi <yacine.belkadi.1@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-02 20:10:04 +02:00
USB: total removal of multithreaded probing in usb The whole approach is simply wrong. Forking a thread means that - errors are ignored - locking is ignored Doing this correctly would require major surgery for questionable benefit. Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-01-11 14:35:50 +01:00
USB: rename usb_configure_device This patch (as1314) renames usb_configure_device() and usb_configure_device_otg() in the hub driver. Neither name is appropriate because these routines enumerate devices, they don't configure them. That's handled by usb_choose_configuration() and usb_set_configuration(). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08 15:50:41 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: split usb_new_device for clarity and refactoring This patch takes hub.c:usb_new_device() and splits it in three parts: - The actual actions of adding a new device (quirk detection, announcement and autoresume tracking) - Actual discovery and probing of the configuration and interfaces (split into __usb_configure_device()) - Configuration of the On-the-go parameters (split into __usb_configure_device_otg()). The fundamental reasons for doing this split are clarity (smaller functions are easier to maintain) and to allow part of the code to be reused when authorizing devices to connect. When a device is authorized connection, we need to run through the hoops we didn't run when it was connected but not authorized, which is basically parsing the configurations and probing them. usb_configure_device() will do that for us. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-31 20:34:05 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: core: hub: fix sparse warning Fix the following sparse warning: drivers/usb/core/hub.c:1664:37: warning: Using plain integer as NULL pointer Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-04 15:47:43 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: otg: don't set a_alt_hnp_support feature for OTG 2.0 device Since a_alt_hnp_support is obsolete in OTG 2.0, HNP capable host should send this set feature request only if the otg device is connecting to a non-HNP port and it's compliant with OTG 1.x revision. This is done by checking its otg descriptor length, OTG 2.0 uses usb_otg20_descriptor which has different length than OTG 1.x using usb_otg_descriptor. Signed-off-by: Li Jun <jun.li@freescale.com> Acked-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-31 16:20:49 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: otg: don't set a_alt_hnp_support feature for OTG 2.0 device Since a_alt_hnp_support is obsolete in OTG 2.0, HNP capable host should send this set feature request only if the otg device is connecting to a non-HNP port and it's compliant with OTG 1.x revision. This is done by checking its otg descriptor length, OTG 2.0 uses usb_otg20_descriptor which has different length than OTG 1.x using usb_otg_descriptor. Signed-off-by: Li Jun <jun.li@freescale.com> Acked-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-31 16:20:49 +08:00
USB: check usb_get_extra_descriptor for proper size When reading an extra descriptor, we need to properly check the minimum and maximum size allowed, to prevent from invalid data being sent by a device. Reported-by: Hui Peng <benquike@gmail.com> Reported-by: Mathias Payer <mathias.payer@nebelwelt.net> Co-developed-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Hui Peng <benquike@gmail.com> Signed-off-by: Mathias Payer <mathias.payer@nebelwelt.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-05 21:19:59 +01:00
usb: otg: don't set a_alt_hnp_support feature for OTG 2.0 device Since a_alt_hnp_support is obsolete in OTG 2.0, HNP capable host should send this set feature request only if the otg device is connecting to a non-HNP port and it's compliant with OTG 1.x revision. This is done by checking its otg descriptor length, OTG 2.0 uses usb_otg20_descriptor which has different length than OTG 1.x using usb_otg_descriptor. Signed-off-by: Li Jun <jun.li@freescale.com> Acked-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-31 16:20:49 +08:00
USB: remove OTG build warning Somewhere along the line, a variable in a USB-OTG codepath stopped being used; this removes the relevant compiler warning. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-09-18 16:53:26 -07:00
usb: otg: don't set a_alt_hnp_support feature for OTG 2.0 device Since a_alt_hnp_support is obsolete in OTG 2.0, HNP capable host should send this set feature request only if the otg device is connecting to a non-HNP port and it's compliant with OTG 1.x revision. This is done by checking its otg descriptor length, OTG 2.0 uses usb_otg20_descriptor which has different length than OTG 1.x using usb_otg_descriptor. Signed-off-by: Li Jun <jun.li@freescale.com> Acked-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-31 16:20:49 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: otg: don't set a_alt_hnp_support feature for OTG 2.0 device Since a_alt_hnp_support is obsolete in OTG 2.0, HNP capable host should send this set feature request only if the otg device is connecting to a non-HNP port and it's compliant with OTG 1.x revision. This is done by checking its otg descriptor length, OTG 2.0 uses usb_otg20_descriptor which has different length than OTG 1.x using usb_otg_descriptor. Signed-off-by: Li Jun <jun.li@freescale.com> Acked-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-31 16:20:49 +08:00
Revert "USB: core: hub.c: use usb_control_msg_send() in a few places" This reverts commit d6a499249543356002a1efbb26254c7272e62f4c. Control messages are needed in contexts when memory allocations are restricted, such as handling device resets and runtime PM. For this reason the control message API internally uses GFP_NOIO. This is a band aid introduced because when we recognized the issue, the call chains were highly convoluted. Continuing this trend is not a good idea. So I am shooting the whole kennel here. Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20200923134348.23862-2-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-23 15:43:35 +02:00
usb: otg: don't set a_alt_hnp_support feature for OTG 2.0 device Since a_alt_hnp_support is obsolete in OTG 2.0, HNP capable host should send this set feature request only if the otg device is connecting to a non-HNP port and it's compliant with OTG 1.x revision. This is done by checking its otg descriptor length, OTG 2.0 uses usb_otg20_descriptor which has different length than OTG 1.x using usb_otg_descriptor. Signed-off-by: Li Jun <jun.li@freescale.com> Acked-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-31 16:20:49 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: otg: don't set a_alt_hnp_support feature for OTG 2.0 device Since a_alt_hnp_support is obsolete in OTG 2.0, HNP capable host should send this set feature request only if the otg device is connecting to a non-HNP port and it's compliant with OTG 1.x revision. This is done by checking its otg descriptor length, OTG 2.0 uses usb_otg20_descriptor which has different length than OTG 1.x using usb_otg_descriptor. Signed-off-by: Li Jun <jun.li@freescale.com> Acked-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-31 16:20:49 +08:00
USB: hub: check for alternate port before enabling A_ALT_HNP_SUPPORT The OTG 1.3 spec has the feature A_ALT_HNP_SUPPORT, which tells a device that it is connected to the wrong port. Some devices refuse to operate if you enable that feature, because it indicates to them that they ought to request to be connected to another port. According to the spec this feature may be used based only the following three conditions: 6.5.3 a_alt_hnp_support Setting this feature indicates to the B-device that it is connected to an A-device port that is not capable of HNP, but that the A-device does have an alternate port that is capable of HNP. The A-device is required to set this feature under the following conditions: • the A-device has multiple receptacles • the A-device port that connects to the B-device does not support HNP • the A-device has another port that does support HNP A check for the third and first condition is missing. Add it. Signed-off-by: Oliver Neukum <oneukum@suse.com> Cc: stable <stable@kernel.org> Fixes: 7d2d641c44269 ("usb: otg: don't set a_alt_hnp_support feature for OTG 2.0 device") Link: https://lore.kernel.org/r/20240122153545.12284-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-22 16:35:32 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: split usb_new_device for clarity and refactoring This patch takes hub.c:usb_new_device() and splits it in three parts: - The actual actions of adding a new device (quirk detection, announcement and autoresume tracking) - Actual discovery and probing of the configuration and interfaces (split into __usb_configure_device()) - Configuration of the On-the-go parameters (split into __usb_configure_device_otg()). The fundamental reasons for doing this split are clarity (smaller functions are easier to maintain) and to allow part of the code to be reused when authorizing devices to connect. When a device is authorized connection, we need to run through the hoops we didn't run when it was connected but not authorized, which is basically parsing the configurations and probing them. usb_configure_device() will do that for us. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-31 20:34:05 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: split usb_new_device for clarity and refactoring This patch takes hub.c:usb_new_device() and splits it in three parts: - The actual actions of adding a new device (quirk detection, announcement and autoresume tracking) - Actual discovery and probing of the configuration and interfaces (split into __usb_configure_device()) - Configuration of the On-the-go parameters (split into __usb_configure_device_otg()). The fundamental reasons for doing this split are clarity (smaller functions are easier to maintain) and to allow part of the code to be reused when authorizing devices to connect. When a device is authorized connection, we need to run through the hoops we didn't run when it was connected but not authorized, which is basically parsing the configurations and probing them. usb_configure_device() will do that for us. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-31 20:34:05 -07:00
USB: rename usb_configure_device This patch (as1314) renames usb_configure_device() and usb_configure_device_otg() in the hub driver. Neither name is appropriate because these routines enumerate devices, they don't configure them. That's handled by usb_choose_configuration() and usb_set_configuration(). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08 15:50:41 -05:00
usb: split usb_new_device for clarity and refactoring This patch takes hub.c:usb_new_device() and splits it in three parts: - The actual actions of adding a new device (quirk detection, announcement and autoresume tracking) - Actual discovery and probing of the configuration and interfaces (split into __usb_configure_device()) - Configuration of the On-the-go parameters (split into __usb_configure_device_otg()). The fundamental reasons for doing this split are clarity (smaller functions are easier to maintain) and to allow part of the code to be reused when authorizing devices to connect. When a device is authorized connection, we need to run through the hoops we didn't run when it was connected but not authorized, which is basically parsing the configurations and probing them. usb_configure_device() will do that for us. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-31 20:34:05 -07:00
USB: core: Don't hold device lock while reading the "descriptors" sysfs file Ever since commit 83e83ecb79a8 ("usb: core: get config and string descriptors for unauthorized devices") was merged in 2013, there has been no mechanism for reallocating the rawdescriptors buffers in struct usb_device after the initial enumeration. Before that commit, the buffers would be deallocated when a device was deauthorized and reallocated when it was authorized and enumerated. This means that the locking in the read_descriptors() routine is not needed, since the buffers it reads will never be reallocated while the routine is running. This locking can interfere with user programs trying to read a hub's descriptors via sysfs while new child devices of the hub are being initialized, since the hub is locked during this procedure. Since the locking in read_descriptors() hasn't been needed for over nine years, we can remove it. Reported-and-tested-by: Troels Liebe Bentsen <troels@connectedcars.dk> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: stable@vger.kernel.org Link: https://lore.kernel.org/r/Y9l+wDTRbuZABzsE@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-01-31 15:49:04 -05:00
usb: split usb_new_device for clarity and refactoring This patch takes hub.c:usb_new_device() and splits it in three parts: - The actual actions of adding a new device (quirk detection, announcement and autoresume tracking) - Actual discovery and probing of the configuration and interfaces (split into __usb_configure_device()) - Configuration of the On-the-go parameters (split into __usb_configure_device_otg()). The fundamental reasons for doing this split are clarity (smaller functions are easier to maintain) and to allow part of the code to be reused when authorizing devices to connect. When a device is authorized connection, we need to run through the hoops we didn't run when it was connected but not authorized, which is basically parsing the configurations and probing them. usb_configure_device() will do that for us. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-31 20:34:05 -07:00
usb: fix some scripts/kernel-doc warnings When building the htmldocs (in verbose mode), scripts/kernel-doc reports the following type of warnings: Warning(drivers/usb/core/usb.c:76): No description found for return value of 'usb_find_alt_setting' Fix them by: - adding some missing descriptions of return values - using "Return" sections for those descriptions Signed-off-by: Yacine Belkadi <yacine.belkadi.1@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-02 20:10:04 +02:00
usb: split usb_new_device for clarity and refactoring This patch takes hub.c:usb_new_device() and splits it in three parts: - The actual actions of adding a new device (quirk detection, announcement and autoresume tracking) - Actual discovery and probing of the configuration and interfaces (split into __usb_configure_device()) - Configuration of the On-the-go parameters (split into __usb_configure_device_otg()). The fundamental reasons for doing this split are clarity (smaller functions are easier to maintain) and to allow part of the code to be reused when authorizing devices to connect. When a device is authorized connection, we need to run through the hoops we didn't run when it was connected but not authorized, which is basically parsing the configurations and probing them. usb_configure_device() will do that for us. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-31 20:34:05 -07:00
USB: rename usb_configure_device This patch (as1314) renames usb_configure_device() and usb_configure_device_otg() in the hub driver. Neither name is appropriate because these routines enumerate devices, they don't configure them. That's handled by usb_choose_configuration() and usb_set_configuration(). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08 15:50:41 -05:00
usb: split usb_new_device for clarity and refactoring This patch takes hub.c:usb_new_device() and splits it in three parts: - The actual actions of adding a new device (quirk detection, announcement and autoresume tracking) - Actual discovery and probing of the configuration and interfaces (split into __usb_configure_device()) - Configuration of the On-the-go parameters (split into __usb_configure_device_otg()). The fundamental reasons for doing this split are clarity (smaller functions are easier to maintain) and to allow part of the code to be reused when authorizing devices to connect. When a device is authorized connection, we need to run through the hoops we didn't run when it was connected but not authorized, which is basically parsing the configurations and probing them. usb_configure_device() will do that for us. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-31 20:34:05 -07:00
usb: core: TPL should apply for both OTG and EH According to On-The-Go and Embedded Host Supplement to the USB Revision 2.0 Specification, the targeted hosts (non-PC hosts) include both embedded hosts and otg, and each targeted host product defines the set of supported peripherals on a TPL (Targeted Peripheral List). So, TPL should apply for both OTG and embedded host, and the otg support is not a must for embedded host. The TPL support feature will only be effect when CONFIG_USB_OTG_WHITELIST has been chosen and hcd->tpl_support flag is set, it can avoid the enumeration fails problem for the user who chooses CONFIG_USB_OTG_WHITELIST wrongly. Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-08-19 09:51:53 +08:00
usb: split usb_new_device for clarity and refactoring This patch takes hub.c:usb_new_device() and splits it in three parts: - The actual actions of adding a new device (quirk detection, announcement and autoresume tracking) - Actual discovery and probing of the configuration and interfaces (split into __usb_configure_device()) - Configuration of the On-the-go parameters (split into __usb_configure_device_otg()). The fundamental reasons for doing this split are clarity (smaller functions are easier to maintain) and to allow part of the code to be reused when authorizing devices to connect. When a device is authorized connection, we need to run through the hoops we didn't run when it was connected but not authorized, which is basically parsing the configurations and probing them. usb_configure_device() will do that for us. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-31 20:34:05 -07:00
USB: avoid error messages when a device is disconnected This patch (as1673) reduces the amount of log spew from the hub driver by removing a bunch of error messages in the case where the device in question is already known to have been disconnected. Since the disconnect event itself appears in the log, there's no need for other error messages. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Jenya Y <jy.gerstmaier@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-27 16:14:01 -04:00
usb: Add quirk detection based on interface information When a whole class of devices (possibly from a specific vendor, or across multiple vendors) require a quirk, explictly listing all devices in the class make the quirks table unnecessarily large. Fix this by allowing matching devices based on interface information. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-07-19 12:39:13 +02:00
usb: split usb_new_device for clarity and refactoring This patch takes hub.c:usb_new_device() and splits it in three parts: - The actual actions of adding a new device (quirk detection, announcement and autoresume tracking) - Actual discovery and probing of the configuration and interfaces (split into __usb_configure_device()) - Configuration of the On-the-go parameters (split into __usb_configure_device_otg()). The fundamental reasons for doing this split are clarity (smaller functions are easier to maintain) and to allow part of the code to be reused when authorizing devices to connect. When a device is authorized connection, we need to run through the hoops we didn't run when it was connected but not authorized, which is basically parsing the configurations and probing them. usb_configure_device() will do that for us. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-31 20:34:05 -07:00
usb: core: get config and string descriptors for unauthorized devices There is no need to skip querying the config and string descriptors for unauthorized WUSB devices when usb_new_device is called. It is allowed by WUSB spec. The only action that needs to be delayed until authorization time is the set config. This change allows user mode tools to see the config and string descriptors earlier in enumeration which is needed for some WUSB devices to function properly on Android systems. It also reduces the amount of divergent code paths needed for WUSB devices. Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-09 13:40:29 -06:00
USB: rename usb_configure_device This patch (as1314) renames usb_configure_device() and usb_configure_device_otg() in the hub driver. Neither name is appropriate because these routines enumerate devices, they don't configure them. That's handled by usb_choose_configuration() and usb_set_configuration(). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08 15:50:41 -05:00
usb: Add quirk detection based on interface information When a whole class of devices (possibly from a specific vendor, or across multiple vendors) require a quirk, explictly listing all devices in the class make the quirks table unnecessarily large. Fix this by allowing matching devices based on interface information. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-07-19 12:39:13 +02:00
USB: OTG: rename product list of devices Rename the list of specific devices that an OTG device could support to make it more obvious as to what this list is for and what it is doing. Also rename the configuration option to make it more obvious as well. Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Paul Burton <paulburton@kernel.org> Cc: "Diego Elio Pettenò" <flameeyes@flameeyes.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: Jiaxun Yang <jiaxun.yang@flygoat.com> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: "Philippe Mathieu-Daudé" <f4bug@amsat.org> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Eugeniu Rosca <erosca@de.adit-jv.com> Cc: Qi Zhou <atmgnd@outlook.com> Cc: Andrey Konovalov <andreyknvl@google.com> Cc: Hardik Gajjar <hgajjar@de.adit-jv.com> Cc: Harry Pan <harry.pan@intel.com> Cc: David Heinzelmann <heinzelmann.david@gmail.com> Cc: Nishad Kamdar <nishadkamdar@gmail.com> Link: https://lore.kernel.org/r/20200618094300.1887727-9-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-18 11:43:00 +02:00
usb: core: return -ENOTSUPP for all targeted hosts The current code only returns -ENOTSUPP for OTG host, but in fact, embedded host also needs to returns -ENOTSUPP if the peripheral is not at TPL. Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-29 10:09:31 +08:00
usb: core: TPL should apply for both OTG and EH According to On-The-Go and Embedded Host Supplement to the USB Revision 2.0 Specification, the targeted hosts (non-PC hosts) include both embedded hosts and otg, and each targeted host product defines the set of supported peripherals on a TPL (Targeted Peripheral List). So, TPL should apply for both OTG and embedded host, and the otg support is not a must for embedded host. The TPL support feature will only be effect when CONFIG_USB_OTG_WHITELIST has been chosen and hcd->tpl_support flag is set, it can avoid the enumeration fails problem for the user who chooses CONFIG_USB_OTG_WHITELIST wrongly. Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-08-19 09:51:53 +08:00
usb: core: return -ENOTSUPP for all targeted hosts The current code only returns -ENOTSUPP for OTG host, but in fact, embedded host also needs to returns -ENOTSUPP if the peripheral is not at TPL. Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-29 10:09:31 +08:00
usb: core: TPL should apply for both OTG and EH According to On-The-Go and Embedded Host Supplement to the USB Revision 2.0 Specification, the targeted hosts (non-PC hosts) include both embedded hosts and otg, and each targeted host product defines the set of supported peripherals on a TPL (Targeted Peripheral List). So, TPL should apply for both OTG and embedded host, and the otg support is not a must for embedded host. The TPL support feature will only be effect when CONFIG_USB_OTG_WHITELIST has been chosen and hcd->tpl_support flag is set, it can avoid the enumeration fails problem for the user who chooses CONFIG_USB_OTG_WHITELIST wrongly. Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-08-19 09:51:53 +08:00
usb: Add quirk detection based on interface information When a whole class of devices (possibly from a specific vendor, or across multiple vendors) require a quirk, explictly listing all devices in the class make the quirks table unnecessarily large. Fix this by allowing matching devices based on interface information. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-07-19 12:39:13 +02:00
usb: split usb_new_device for clarity and refactoring This patch takes hub.c:usb_new_device() and splits it in three parts: - The actual actions of adding a new device (quirk detection, announcement and autoresume tracking) - Actual discovery and probing of the configuration and interfaces (split into __usb_configure_device()) - Configuration of the On-the-go parameters (split into __usb_configure_device_otg()). The fundamental reasons for doing this split are clarity (smaller functions are easier to maintain) and to allow part of the code to be reused when authorizing devices to connect. When a device is authorized connection, we need to run through the hoops we didn't run when it was connected but not authorized, which is basically parsing the configurations and probing them. usb_configure_device() will do that for us. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-31 20:34:05 -07:00
usb: Use hub port data to determine whether a port is removable Hubs have a flag to indicate whether a given port carries removable devices or not. This is not strictly accurate in that some built-in devices will be flagged as removable, but followup patches will make use of platform data to make this more reliable. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-03 17:11:55 -05:00
driver core: Move the "removable" attribute from USB to core Move the "removable" attribute from USB to core in order to allow it to be supported by other subsystem / buses. Individual buses that want to support this attribute can populate the removable property of the device while enumerating it with the 3 possible values - - "unknown" - "fixed" - "removable" Leaving the field unchanged (i.e. "not supported") would mean that the attribute would not show up in sysfs for that device. The UAPI (location, symantics etc) for the attribute remains unchanged. Move the "removable" attribute from USB to the device core so it can be used by other subsystems / buses. By default, devices do not have a "removable" attribute in sysfs. If a subsystem or bus driver wants to support a "removable" attribute, it should call device_set_removable() before calling device_register() or device_add(), e.g.: device_set_removable(dev, DEVICE_REMOVABLE); device_register(dev); The possible values and the resulting sysfs attribute contents are: DEVICE_REMOVABLE_UNKNOWN -> "unknown" DEVICE_REMOVABLE -> "removable" DEVICE_FIXED -> "fixed" Convert the USB "removable" attribute to use this new device core functionality. There should be no user-visible change in the location or semantics of attribute for USB devices. Reviewed-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Rajat Jain <rajatja@google.com> Link: https://lore.kernel.org/r/20210524171812.18095-1-rajatja@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-24 10:18:11 -07:00
usb: Use hub port data to determine whether a port is removable Hubs have a flag to indicate whether a given port carries removable devices or not. This is not strictly accurate in that some built-in devices will be flagged as removable, but followup patches will make use of platform data to make this more reliable. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-03 17:11:55 -05:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
usb: Use hub port data to determine whether a port is removable Hubs have a flag to indicate whether a given port carries removable devices or not. This is not strictly accurate in that some built-in devices will be flagged as removable, but followup patches will make use of platform data to make this more reliable. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-03 17:11:55 -05:00
usb: Prefer firmware values when determining whether a port is removable Windows appears to pay more attention to the ACPI values than any hub configuration, so prefer the firmware's opinion on whether a port is fixed or removable before falling back to the hub values. Signed-off-by: Matthew Garrett <mjg59@coreos.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-08 16:36:00 -07:00
driver core: Move the "removable" attribute from USB to core Move the "removable" attribute from USB to core in order to allow it to be supported by other subsystem / buses. Individual buses that want to support this attribute can populate the removable property of the device while enumerating it with the 3 possible values - - "unknown" - "fixed" - "removable" Leaving the field unchanged (i.e. "not supported") would mean that the attribute would not show up in sysfs for that device. The UAPI (location, symantics etc) for the attribute remains unchanged. Move the "removable" attribute from USB to the device core so it can be used by other subsystems / buses. By default, devices do not have a "removable" attribute in sysfs. If a subsystem or bus driver wants to support a "removable" attribute, it should call device_set_removable() before calling device_register() or device_add(), e.g.: device_set_removable(dev, DEVICE_REMOVABLE); device_register(dev); The possible values and the resulting sysfs attribute contents are: DEVICE_REMOVABLE_UNKNOWN -> "unknown" DEVICE_REMOVABLE -> "removable" DEVICE_FIXED -> "fixed" Convert the USB "removable" attribute to use this new device core functionality. There should be no user-visible change in the location or semantics of attribute for USB devices. Reviewed-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Rajat Jain <rajatja@google.com> Link: https://lore.kernel.org/r/20210524171812.18095-1-rajatja@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-24 10:18:11 -07:00
usb: Prefer firmware values when determining whether a port is removable Windows appears to pay more attention to the ACPI values than any hub configuration, so prefer the firmware's opinion on whether a port is fixed or removable before falling back to the hub values. Signed-off-by: Matthew Garrett <mjg59@coreos.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-08 16:36:00 -07:00
usb: Set unused ports to "fixed" rather than "unknown" The Microsoft document "Using ACPI to Configure USB Ports on a Computer" makes it clear that the removable flag will be cleared on ports that are marked as unused by the firmware. Handle this case to match. Signed-off-by: Matthew Garrett <mjg59@coreos.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-08 16:36:01 -07:00
driver core: Move the "removable" attribute from USB to core Move the "removable" attribute from USB to core in order to allow it to be supported by other subsystem / buses. Individual buses that want to support this attribute can populate the removable property of the device while enumerating it with the 3 possible values - - "unknown" - "fixed" - "removable" Leaving the field unchanged (i.e. "not supported") would mean that the attribute would not show up in sysfs for that device. The UAPI (location, symantics etc) for the attribute remains unchanged. Move the "removable" attribute from USB to the device core so it can be used by other subsystems / buses. By default, devices do not have a "removable" attribute in sysfs. If a subsystem or bus driver wants to support a "removable" attribute, it should call device_set_removable() before calling device_register() or device_add(), e.g.: device_set_removable(dev, DEVICE_REMOVABLE); device_register(dev); The possible values and the resulting sysfs attribute contents are: DEVICE_REMOVABLE_UNKNOWN -> "unknown" DEVICE_REMOVABLE -> "removable" DEVICE_FIXED -> "fixed" Convert the USB "removable" attribute to use this new device core functionality. There should be no user-visible change in the location or semantics of attribute for USB devices. Reviewed-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Rajat Jain <rajatja@google.com> Link: https://lore.kernel.org/r/20210524171812.18095-1-rajatja@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-24 10:18:11 -07:00
usb: Prefer firmware values when determining whether a port is removable Windows appears to pay more attention to the ACPI values than any hub configuration, so prefer the firmware's opinion on whether a port is fixed or removable before falling back to the hub values. Signed-off-by: Matthew Garrett <mjg59@coreos.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-08 16:36:00 -07:00
usb: Set unused ports to "fixed" rather than "unknown" The Microsoft document "Using ACPI to Configure USB Ports on a Computer" makes it clear that the removable flag will be cleared on ports that are marked as unused by the firmware. Handle this case to match. Signed-off-by: Matthew Garrett <mjg59@coreos.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-08 16:36:01 -07:00
usb: Prefer firmware values when determining whether a port is removable Windows appears to pay more attention to the ACPI values than any hub configuration, so prefer the firmware's opinion on whether a port is fixed or removable before falling back to the hub values. Signed-off-by: Matthew Garrett <mjg59@coreos.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-08 16:36:00 -07:00
usb: Use hub port data to determine whether a port is removable Hubs have a flag to indicate whether a given port carries removable devices or not. This is not strictly accurate in that some built-in devices will be flagged as removable, but followup patches will make use of platform data to make this more reliable. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-03 17:11:55 -05:00
usb: add little-endian transform for DeviceRemovable of usb3.0 hub Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-11 04:22:36 +08:00
usb: Use hub port data to determine whether a port is removable Hubs have a flag to indicate whether a given port carries removable devices or not. This is not strictly accurate in that some built-in devices will be flagged as removable, but followup patches will make use of platform data to make this more reliable. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-03 17:11:55 -05:00
driver core: Move the "removable" attribute from USB to core Move the "removable" attribute from USB to core in order to allow it to be supported by other subsystem / buses. Individual buses that want to support this attribute can populate the removable property of the device while enumerating it with the 3 possible values - - "unknown" - "fixed" - "removable" Leaving the field unchanged (i.e. "not supported") would mean that the attribute would not show up in sysfs for that device. The UAPI (location, symantics etc) for the attribute remains unchanged. Move the "removable" attribute from USB to the device core so it can be used by other subsystems / buses. By default, devices do not have a "removable" attribute in sysfs. If a subsystem or bus driver wants to support a "removable" attribute, it should call device_set_removable() before calling device_register() or device_add(), e.g.: device_set_removable(dev, DEVICE_REMOVABLE); device_register(dev); The possible values and the resulting sysfs attribute contents are: DEVICE_REMOVABLE_UNKNOWN -> "unknown" DEVICE_REMOVABLE -> "removable" DEVICE_FIXED -> "fixed" Convert the USB "removable" attribute to use this new device core functionality. There should be no user-visible change in the location or semantics of attribute for USB devices. Reviewed-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Rajat Jain <rajatja@google.com> Link: https://lore.kernel.org/r/20210524171812.18095-1-rajatja@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-24 10:18:11 -07:00
usb: Use hub port data to determine whether a port is removable Hubs have a flag to indicate whether a given port carries removable devices or not. This is not strictly accurate in that some built-in devices will be flagged as removable, but followup patches will make use of platform data to make this more reliable. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-03 17:11:55 -05:00
driver core: Move the "removable" attribute from USB to core Move the "removable" attribute from USB to core in order to allow it to be supported by other subsystem / buses. Individual buses that want to support this attribute can populate the removable property of the device while enumerating it with the 3 possible values - - "unknown" - "fixed" - "removable" Leaving the field unchanged (i.e. "not supported") would mean that the attribute would not show up in sysfs for that device. The UAPI (location, symantics etc) for the attribute remains unchanged. Move the "removable" attribute from USB to the device core so it can be used by other subsystems / buses. By default, devices do not have a "removable" attribute in sysfs. If a subsystem or bus driver wants to support a "removable" attribute, it should call device_set_removable() before calling device_register() or device_add(), e.g.: device_set_removable(dev, DEVICE_REMOVABLE); device_register(dev); The possible values and the resulting sysfs attribute contents are: DEVICE_REMOVABLE_UNKNOWN -> "unknown" DEVICE_REMOVABLE -> "removable" DEVICE_FIXED -> "fixed" Convert the USB "removable" attribute to use this new device core functionality. There should be no user-visible change in the location or semantics of attribute for USB devices. Reviewed-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Rajat Jain <rajatja@google.com> Link: https://lore.kernel.org/r/20210524171812.18095-1-rajatja@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-24 10:18:11 -07:00
usb: cleanup setting udev->removable from port_dev->connect_type Once usb-acpi has set the port's connect type the usb_device's ->removable attribute can be set in the standard location set_usb_port_removable(). This also changes behavior in the case where the firmware says that the port connect type is unknown. In that case just use the default setting determined from the hub descriptor. Note, we no longer pass udev->portnum to acpi_find_child_device() in the root hub case since: 1/ the usb-core sets this to zero 2/ acpi always expects zero ...just pass zero. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:22 -07:00
usb: Use hub port data to determine whether a port is removable Hubs have a flag to indicate whether a given port carries removable devices or not. This is not strictly accurate in that some built-in devices will be flagged as removable, but followup patches will make use of platform data to make this more reliable. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-03 17:11:55 -05:00
usb: split usb_new_device for clarity and refactoring This patch takes hub.c:usb_new_device() and splits it in three parts: - The actual actions of adding a new device (quirk detection, announcement and autoresume tracking) - Actual discovery and probing of the configuration and interfaces (split into __usb_configure_device()) - Configuration of the On-the-go parameters (split into __usb_configure_device_otg()). The fundamental reasons for doing this split are clarity (smaller functions are easier to maintain) and to allow part of the code to be reused when authorizing devices to connect. When a device is authorized connection, we need to run through the hoops we didn't run when it was connected but not authorized, which is basically parsing the configurations and probing them. usb_configure_device() will do that for us. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-31 20:34:05 -07:00
USB: rename usb_configure_device This patch (as1314) renames usb_configure_device() and usb_configure_device_otg() in the hub driver. Neither name is appropriate because these routines enumerate devices, they don't configure them. That's handled by usb_choose_configuration() and usb_set_configuration(). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08 15:50:41 -05:00
usb: split usb_new_device for clarity and refactoring This patch takes hub.c:usb_new_device() and splits it in three parts: - The actual actions of adding a new device (quirk detection, announcement and autoresume tracking) - Actual discovery and probing of the configuration and interfaces (split into __usb_configure_device()) - Configuration of the On-the-go parameters (split into __usb_configure_device_otg()). The fundamental reasons for doing this split are clarity (smaller functions are easier to maintain) and to allow part of the code to be reused when authorizing devices to connect. When a device is authorized connection, we need to run through the hoops we didn't run when it was connected but not authorized, which is basically parsing the configurations and probing them. usb_configure_device() will do that for us. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-31 20:34:05 -07:00
usb: core: rename mutex usb_bus_list_lock to usb_bus_idr_lock Now that usb_bus_list has been removed and switched to idr rename the related mutex accordingly. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-03 23:35:23 +01:00
usb: split usb_new_device for clarity and refactoring This patch takes hub.c:usb_new_device() and splits it in three parts: - The actual actions of adding a new device (quirk detection, announcement and autoresume tracking) - Actual discovery and probing of the configuration and interfaces (split into __usb_configure_device()) - Configuration of the On-the-go parameters (split into __usb_configure_device_otg()). The fundamental reasons for doing this split are clarity (smaller functions are easier to maintain) and to allow part of the code to be reused when authorizing devices to connect. When a device is authorized connection, we need to run through the hoops we didn't run when it was connected but not authorized, which is basically parsing the configurations and probing them. usb_configure_device() will do that for us. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-31 20:34:05 -07:00
usb: fix some scripts/kernel-doc warnings When building the htmldocs (in verbose mode), scripts/kernel-doc reports the following type of warnings: Warning(drivers/usb/core/usb.c:76): No description found for return value of 'usb_find_alt_setting' Fix them by: - adding some missing descriptions of return values - using "Return" sections for those descriptions Signed-off-by: Yacine Belkadi <yacine.belkadi.1@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-02 20:10:04 +02:00
usb: split usb_new_device for clarity and refactoring This patch takes hub.c:usb_new_device() and splits it in three parts: - The actual actions of adding a new device (quirk detection, announcement and autoresume tracking) - Actual discovery and probing of the configuration and interfaces (split into __usb_configure_device()) - Configuration of the On-the-go parameters (split into __usb_configure_device_otg()). The fundamental reasons for doing this split are clarity (smaller functions are easier to maintain) and to allow part of the code to be reused when authorizing devices to connect. When a device is authorized connection, we need to run through the hoops we didn't run when it was connected but not authorized, which is basically parsing the configurations and probing them. usb_configure_device() will do that for us. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-31 20:34:05 -07:00
USB: retain USB device power/wakeup setting across reconfiguration Currently a non-root-hub USB device's wakeup settings are initialized when the device is set to a configured state using device_init_wakeup(), but this is not correct as wakeup is split into "capable" (can_wakeup) and "enabled" (should_wakeup). The settings should be initialized instead in the device initialization (usb_new_device) with the "capable" setting disabled and the "enabled" setting enabled. The "capable" setting should be set based on the device being configured or unconfigured, and "enabled" setting set based on the sysfs power/wakeup control. This patch retains the sysfs power/wakeup setting of a non-root-hub USB device over a USB device re-configuration, which can happen (for example) after a suspend/resume cycle. Signed-off-by: Dan Streetman <ddstreet@ieee.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-06 09:56:53 -05:00
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>
2010-01-08 12:57:28 -05:00
USB: improve uses of usb_mark_last_busy This patch (as1434) cleans up the uses of usb_mark_last_busy() in usbcore. The function will be called when a device is resumed and whenever a usage count is decremented. A call that was missing from the hub driver is added: A hub is used whenever one of its ports gets suspended (this prevents hubs from suspending immediately after their last child). In addition, the call to disable autosuspend support for new devices by default is moved from usb_detect_quirks() (where it doesn't really belong) into usb_new_device() along with all the other runtime-PM initializations. Finally, an extra pm_runtime_get_noresume() is added to prevent new devices from autosuspending while they are being registered. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-15 15:57:58 -05:00
USB: use the runtime-PM autosuspend implementation This patch (as1428) converts USB over to the new runtime-PM core autosuspend framework. One slightly awkward aspect of the conversion is that USB devices will now have two suspend-delay attributes: the old power/autosuspend file and the new power/autosuspend_delay_ms file. One expresses the delay time in seconds and the other in milliseconds, but otherwise they do the same thing. The old attribute can be deprecated and then removed eventually. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-15 15:57:51 -05:00
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>
2010-01-08 12:57:28 -05:00
USB: improve uses of usb_mark_last_busy This patch (as1434) cleans up the uses of usb_mark_last_busy() in usbcore. The function will be called when a device is resumed and whenever a usage count is decremented. A call that was missing from the hub driver is added: A hub is used whenever one of its ports gets suspended (this prevents hubs from suspending immediately after their last child). In addition, the call to disable autosuspend support for new devices by default is moved from usb_detect_quirks() (where it doesn't really belong) into usb_new_device() along with all the other runtime-PM initializations. Finally, an extra pm_runtime_get_noresume() is added to prevent new devices from autosuspending while they are being registered. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-15 15:57:58 -05:00
USB: rename usb_configure_device This patch (as1314) renames usb_configure_device() and usb_configure_device_otg() in the hub driver. Neither name is appropriate because these routines enumerate devices, they don't configure them. That's handled by usb_choose_configuration() and usb_set_configuration(). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08 15:50:41 -05:00
usb: split usb_new_device for clarity and refactoring This patch takes hub.c:usb_new_device() and splits it in three parts: - The actual actions of adding a new device (quirk detection, announcement and autoresume tracking) - Actual discovery and probing of the configuration and interfaces (split into __usb_configure_device()) - Configuration of the On-the-go parameters (split into __usb_configure_device_otg()). The fundamental reasons for doing this split are clarity (smaller functions are easier to maintain) and to allow part of the code to be reused when authorizing devices to connect. When a device is authorized connection, we need to run through the hoops we didn't run when it was connected but not authorized, which is basically parsing the configurations and probing them. usb_configure_device() will do that for us. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-31 20:34:05 -07:00
USB: Support for addressing a USB device under xHCI Add host controller driver API and a slot_id variable to struct usb_device. This allows the xHCI host controller driver to ask the hardware to allocate a slot for the device when a struct usb_device is allocated. The slot needs to be allocated at that point because the hardware can run out of internal resources, and we want to know that very early in the device connection process. Don't call this new API for root hubs, since they aren't real devices. Add HCD API to let the host controller choose the device address. This is especially important for xHCI hardware running in a virtualized environment. The guests running under the VM don't need to know which addresses on the bus are taken, because the hardware picks the address for them. Announce SuperSpeed USB devices after the address has been assigned by the hardware. Don't use the new get descriptor/set address scheme with xHCI. Unless special handling is done in the host controller driver, the xHC can't issue control transfers before you set the device address. Support for the older addressing scheme will be added when the xHCI driver supports the Block Set Address Request (BSR) flag in the Address Device command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-27 19:57:26 -07:00
USB: make usbdevices export their device nodes instead of using a separate class o The "real" usb-devices export now a device node which can populate /dev/bus/usb. o The usb_device class is optional now and can be disabled in the kernel config. Major/minor of the "real" devices and class devices are the same. o The environment of the usb-device event contains DEVNUM and BUSNUM to help udev and get rid of the ugly udev rule we need for the class devices. o The usb-devices and usb-interfaces share the same bus, so I used the new "struct device_type" to let these devices identify themselves. This also removes the current logic of using a magic platform-pointer. The name of the device_type is also added to the environment which makes it easier to distinguish the different kinds of devices on the same subsystem. It looks like this: add@/devices/pci0000:00/0000:00:1d.1/usb2/2-1 ACTION=add DEVPATH=/devices/pci0000:00/0000:00:1d.1/usb2/2-1 SUBSYSTEM=usb SEQNUM=1533 MAJOR=189 MINOR=131 DEVTYPE=usb_device PRODUCT=46d/c03e/2000 TYPE=0/0/0 BUSNUM=002 DEVNUM=004 This udev rule works as a replacement for usb_device class devices: SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", \ NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0644" Updated patch, which needs the device_type patches in Greg's tree. I also got a bugzilla assigned for this. :) https://bugzilla.novell.com/show_bug.cgi?id=250659 Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-03-13 15:59:31 +01:00
USB: announce new devices earlier This patch (as1166) changes usb_new_device(). Now new devices will be announced in the log _prior_ to being registered; this way the "new device" lines will appear before all the output from driver probing, which seems much more logical. Also, the patch adds a call to usb_stop_pm() to the failure pathway, so that the parent's count of unsuspended children will remain correct if registration fails. In order for this to work properly, the code to increment that count has to be moved forward, before the first point where a failure can occur. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-13 15:08:30 -05:00
USB: fix warning caused by autosuspend counter going negative This patch (as937) fixes a minor bug in the autosuspend usage-counting code. Each hub's usage counter keeps track of the number of unsuspended children. However the current driver increments the counter after registering a new child, by which time the child may already have been suspended and caused the counter to go negative. The obvious solution is to increment the counter before registering the child. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-16 15:28:19 -04:00
usb: feed USB device information to the /dev/random driver 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-04 11:22:20 -04:00
PM: Allow USB devices to suspend/resume asynchronously Set power.async_suspend for USB devices, endpoints and interfaces, allowing them to be suspended and resumed asynchronously during system sleep transitions. The power.async_suspend flag is also set for devices that don't have suspend or resume callbacks, because otherwise they would make the main suspend/resume thread wait for their "asynchronous" children (during suspend) or parents (during resume), effectively negating the possible gains from executing these devices' suspend and resume callbacks asynchronously. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-02-08 19:18:16 +01:00
usb: Use hub port data to determine whether a port is removable Hubs have a flag to indicate whether a given port carries removable devices or not. This is not strictly accurate in that some built-in devices will be flagged as removable, but followup patches will make use of platform data to make this more reliable. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-03 17:11:55 -05:00
usb: cleanup setting udev->removable from port_dev->connect_type Once usb-acpi has set the port's connect type the usb_device's ->removable attribute can be set in the standard location set_usb_port_removable(). This also changes behavior in the case where the firmware says that the port connect type is unknown. In that case just use the default setting determined from the hub descriptor. Note, we no longer pass udev->portnum to acpi_find_child_device() in the root hub case since: 1/ the usb-core sets this to zero 2/ acpi always expects zero ...just pass zero. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:22 -07:00
driver core: Move the "removable" attribute from USB to core Move the "removable" attribute from USB to core in order to allow it to be supported by other subsystem / buses. Individual buses that want to support this attribute can populate the removable property of the device while enumerating it with the 3 possible values - - "unknown" - "fixed" - "removable" Leaving the field unchanged (i.e. "not supported") would mean that the attribute would not show up in sysfs for that device. The UAPI (location, symantics etc) for the attribute remains unchanged. Move the "removable" attribute from USB to the device core so it can be used by other subsystems / buses. By default, devices do not have a "removable" attribute in sysfs. If a subsystem or bus driver wants to support a "removable" attribute, it should call device_set_removable() before calling device_register() or device_add(), e.g.: device_set_removable(dev, DEVICE_REMOVABLE); device_register(dev); The possible values and the resulting sysfs attribute contents are: DEVICE_REMOVABLE_UNKNOWN -> "unknown" DEVICE_REMOVABLE -> "removable" DEVICE_FIXED -> "fixed" Convert the USB "removable" attribute to use this new device core functionality. There should be no user-visible change in the location or semantics of attribute for USB devices. Reviewed-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Rajat Jain <rajatja@google.com> Link: https://lore.kernel.org/r/20210524171812.18095-1-rajatja@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-24 10:18:11 -07:00
usb: Use hub port data to determine whether a port is removable Hubs have a flag to indicate whether a given port carries removable devices or not. This is not strictly accurate in that some built-in devices will be flagged as removable, but followup patches will make use of platform data to make this more reliable. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-03 17:11:55 -05:00
usbcore: make usb_generic a usb_device_driver This patch (as714b) makes usb_generic into a usb_device_driver capable of being probed and unbound, just like other drivers. A fair amount of the work that used to get done during discovery or removal of a USB device have been moved to the probe and disconnect methods of usb_generic: creating the sysfs attributes and selecting an initial configuration. However the normal behavior should continue to be the same as before. We will now have the possibility of creating other USB device drivers, They will assist with exporting devices to remote systems (USB-over-TCPIP) or to paravirtual guest operating systems. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-07-01 22:09:35 -04:00
USB: utilize the bus notifiers This patch (as1185) makes usbcore take advantage of the bus notifications sent out by the driver core. Now we can create all our device and interface attribute files before the device or interface uevent is broadcast. A side effect is that we no longer create the endpoint "pseudo" devices at the same time as a device or interface is registered -- it seems like a bad idea to try registering an endpoint before the registration of its parent is complete. So the routines for creating and removing endpoint devices have been split out and renamed, and they are called explicitly when needed. A new bitflag is used for keeping track of whether or not the interface's endpoint devices have been created, since (just as with the interface attributes) they vary with the altsetting and hence can be changed at random times. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-05 14:10:34 -05:00
usbcore: make usb_generic a usb_device_driver This patch (as714b) makes usb_generic into a usb_device_driver capable of being probed and unbound, just like other drivers. A fair amount of the work that used to get done during discovery or removal of a USB device have been moved to the probe and disconnect methods of usb_generic: creating the sysfs attributes and selecting an initial configuration. However the normal behavior should continue to be the same as before. We will now have the possibility of creating other USB device drivers, They will assist with exporting devices to remote systems (USB-over-TCPIP) or to paravirtual guest operating systems. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-07-01 22:09:35 -04:00
USB: make usbdevices export their device nodes instead of using a separate class o The "real" usb-devices export now a device node which can populate /dev/bus/usb. o The usb_device class is optional now and can be disabled in the kernel config. Major/minor of the "real" devices and class devices are the same. o The environment of the usb-device event contains DEVNUM and BUSNUM to help udev and get rid of the ugly udev rule we need for the class devices. o The usb-devices and usb-interfaces share the same bus, so I used the new "struct device_type" to let these devices identify themselves. This also removes the current logic of using a magic platform-pointer. The name of the device_type is also added to the environment which makes it easier to distinguish the different kinds of devices on the same subsystem. It looks like this: add@/devices/pci0000:00/0000:00:1d.1/usb2/2-1 ACTION=add DEVPATH=/devices/pci0000:00/0000:00:1d.1/usb2/2-1 SUBSYSTEM=usb SEQNUM=1533 MAJOR=189 MINOR=131 DEVTYPE=usb_device PRODUCT=46d/c03e/2000 TYPE=0/0/0 BUSNUM=002 DEVNUM=004 This udev rule works as a replacement for usb_device class devices: SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", \ NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0644" Updated patch, which needs the device_type patches in Greg's tree. I also got a bugzilla assigned for this. :) https://bugzilla.novell.com/show_bug.cgi?id=250659 Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-03-13 15:59:31 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] USB: Remove USB private semaphore This patch (as605) removes the private udev->serialize semaphore, relying instead on the locking provided by the embedded struct device's semaphore. The changes are confined to the core, except that the usb_trylock_device routine now uses the return convention of down_trylock rather than down_read_trylock (they return opposite values for no good reason). A couple of other associated changes are included as well: Now that we aren't concerned about HCDs that avoid using the hcd glue layer, usb_disconnect no longer needs to acquire the usb_bus_lock -- that can be done by usb_remove_hcd where it belongs. Devices aren't locked over the same scope of code in usb_new_device and hub_port_connect_change as they used to be. This shouldn't cause any trouble. Along with the preceding driver core patch, this needs a lot of testing. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-17 17:10:32 -05:00
usb: Create link files between child device and usb port device. To show the relationship between usb port and child device, add link file "port" under usb device's sysfs directoy and "device" under usb port device's sysfs directory. They are linked to each other. 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>
2013-01-20 01:53:33 +08:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
usb: make usb_port flags atomic, rename did_runtime_put to child_usage We want to manipulate ->did_runtime_put in usb_port_runtime_resume(), but we don't want that to collide with other updates. Move usb_port flags to new port-bitmap fields in usb_hub. "did_runtime_put" is renamed "child_usage_bits" to reflect that it is strictly standing in for the fact that usb_devices are not the device_model children of their parent port. Signed-off-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:52 -07:00
usb: Create link files between child device and usb port device. To show the relationship between usb port and child device, add link file "port" under usb device's sysfs directoy and "device" under usb port device's sysfs directory. They are linked to each other. 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>
2013-01-20 01:53:33 +08:00
usb: fix reference leak in usb_new_device() When device_add(&udev->dev) succeeds and a later call fails, usb_new_device() does not properly call device_del(). As comment of device_add() says, 'if device_add() succeeds, you should call device_del() when you want to get rid of it. If device_add() has not succeeded, use only put_device() to drop the reference count'. Found by code review. Cc: stable <stable@kernel.org> Fixes: 9f8b17e643fe ("USB: make usbdevices export their device nodes instead of using a separate class") Signed-off-by: Ma Ke <make_ruc2021@163.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20241218071346.2973980-1-make_ruc2021@163.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-12-18 15:13:46 +08:00
usb: Create link files between child device and usb port device. To show the relationship between usb port and child device, add link file "port" under usb device's sysfs directoy and "device" under usb port device's sysfs directory. They are linked to each other. 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>
2013-01-20 01:53:33 +08:00
usb: fix reference leak in usb_new_device() When device_add(&udev->dev) succeeds and a later call fails, usb_new_device() does not properly call device_del(). As comment of device_add() says, 'if device_add() succeeds, you should call device_del() when you want to get rid of it. If device_add() has not succeeded, use only put_device() to drop the reference count'. Found by code review. Cc: stable <stable@kernel.org> Fixes: 9f8b17e643fe ("USB: make usbdevices export their device nodes instead of using a separate class") Signed-off-by: Ma Ke <make_ruc2021@163.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20241218071346.2973980-1-make_ruc2021@163.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-12-18 15:13:46 +08:00
usb: Create link files between child device and usb port device. To show the relationship between usb port and child device, add link file "port" under usb device's sysfs directoy and "device" under usb port device's sysfs directory. They are linked to each other. 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>
2013-01-20 01:53:33 +08:00
usb: add runtime pm support for usb port device This patch is to add runtime pm callback for usb port device. Set/clear PORT_POWER feature in the resume/suspend callback. Add portnum for struct usb_port to record port number. Do pm_rumtime_get_sync/put(portdev) when a device is plugged/unplugged to prevent it from being powered off when it is active. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:29 +08:00
usb: make usb_port flags atomic, rename did_runtime_put to child_usage We want to manipulate ->did_runtime_put in usb_port_runtime_resume(), but we don't want that to collide with other updates. Move usb_port flags to new port-bitmap fields in usb_hub. "did_runtime_put" is renamed "child_usage_bits" to reflect that it is strictly standing in for the fact that usb_devices are not the device_model children of their parent port. Signed-off-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:52 -07:00
usb: Inform the USB Type-C class about enumerated devices The Type-C port drivers can make PM related decisions based on is the device USB3 or USB2. Suggested-by: Benson Leung <bleung@chromium.org> Tested-by: Benson Leung <bleung@chromium.org> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20231011105825.320062-3-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-11 13:58:25 +03:00
usb: Create link files between child device and usb port device. To show the relationship between usb port and child device, add link file "port" under usb device's sysfs directoy and "device" under usb port device's sysfs directory. They are linked to each other. 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>
2013-01-20 01:53:33 +08:00
USB: utilize the bus notifiers This patch (as1185) makes usbcore take advantage of the bus notifications sent out by the driver core. Now we can create all our device and interface attribute files before the device or interface uevent is broadcast. A side effect is that we no longer create the endpoint "pseudo" devices at the same time as a device or interface is registered -- it seems like a bad idea to try registering an endpoint before the registration of its parent is complete. So the routines for creating and removing endpoint devices have been split out and renamed, and they are called explicitly when needed. A new bitflag is used for keeping track of whether or not the interface's endpoint devices have been created, since (just as with the interface attributes) they vary with the altsetting and hence can be changed at random times. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-05 14:10:34 -05:00
USB: improve uses of usb_mark_last_busy This patch (as1434) cleans up the uses of usb_mark_last_busy() in usbcore. The function will be called when a device is resumed and whenever a usage count is decremented. A call that was missing from the hub driver is added: A hub is used whenever one of its ports gets suspended (this prevents hubs from suspending immediately after their last child). In addition, the call to disable autosuspend support for new devices by default is moved from usb_detect_quirks() (where it doesn't really belong) into usb_new_device() along with all the other runtime-PM initializations. Finally, an extra pm_runtime_get_noresume() is added to prevent new devices from autosuspending while they are being registered. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-15 15:57:58 -05:00
USB: create a new thread for every USB device found during the probe sequence Might speed up some systems. If nothing else, a bad driver should not take the whole USB subsystem down with it. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-08-11 01:55:12 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: fix reference leak in usb_new_device() When device_add(&udev->dev) succeeds and a later call fails, usb_new_device() does not properly call device_del(). As comment of device_add() says, 'if device_add() succeeds, you should call device_del() when you want to get rid of it. If device_add() has not succeeded, use only put_device() to drop the reference count'. Found by code review. Cc: stable <stable@kernel.org> Fixes: 9f8b17e643fe ("USB: make usbdevices export their device nodes instead of using a separate class") Signed-off-by: Ma Ke <make_ruc2021@163.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20241218071346.2973980-1-make_ruc2021@163.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-12-18 15:13:46 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
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>
2010-01-08 12:57:28 -05:00
usb: split usb_new_device for clarity and refactoring This patch takes hub.c:usb_new_device() and splits it in three parts: - The actual actions of adding a new device (quirk detection, announcement and autoresume tracking) - Actual discovery and probing of the configuration and interfaces (split into __usb_configure_device()) - Configuration of the On-the-go parameters (split into __usb_configure_device_otg()). The fundamental reasons for doing this split are clarity (smaller functions are easier to maintain) and to allow part of the code to be reused when authorizing devices to connect. When a device is authorized connection, we need to run through the hoops we didn't run when it was connected but not authorized, which is basically parsing the configurations and probing them. usb_configure_device() will do that for us. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-31 20:34:05 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: introduce usb_authorize/deauthorize() These USB API functions will do the full authorization/deauthorization to be used for a device. When authorized we effectively allow a configuration to be set. Reverse that when deauthorized. Effectively this means that we have to clean all the configuration descriptors on deauthorize and reload them when we authorized. We could do without throwing them out for wired devices, but for wireless, we can read them only after authenticating, and thus, when authorizing an authenticated device we would need to read them. So to simplify, always release them on deauthorize(), re-read them on authorize(). Also fix leak reported by Ragner Magalhaes; in usb_deauthorize_device(), bNumConfigurations was being set to zero before the for loop, and thus the different raw descriptors where never being freed. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-31 20:34:06 -07:00
docbook: fix usb content Fix USB docbook warnings. Warning(linux-2.6.23-git8//include/linux/usb/gadget.h:487): No description found for parameter 'g' Warning(linux-2.6.23-git8//include/linux/usb/gadget.h:506): No description found for parameter 'g' Warning(linux-2.6.23-git8//drivers/usb/core/hub.c:1416): No description found for parameter 'usb_dev' Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-15 17:30:02 -07:00
usb: introduce usb_authorize/deauthorize() These USB API functions will do the full authorization/deauthorization to be used for a device. When authorized we effectively allow a configuration to be set. Reverse that when deauthorized. Effectively this means that we have to clean all the configuration descriptors on deauthorize and reload them when we authorized. We could do without throwing them out for wired devices, but for wireless, we can read them only after authenticating, and thus, when authorizing an authenticated device we would need to read them. So to simplify, always release them on deauthorize(), re-read them on authorize(). Also fix leak reported by Ragner Magalhaes; in usb_deauthorize_device(), bNumConfigurations was being set to zero before the for loop, and thus the different raw descriptors where never being freed. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-31 20:34:06 -07:00
usb: fix some scripts/kernel-doc warnings When building the htmldocs (in verbose mode), scripts/kernel-doc reports the following type of warnings: Warning(drivers/usb/core/usb.c:76): No description found for return value of 'usb_find_alt_setting' Fix them by: - adding some missing descriptions of return values - using "Return" sections for those descriptions Signed-off-by: Yacine Belkadi <yacine.belkadi.1@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-02 20:10:04 +02:00
usb: introduce usb_authorize/deauthorize() These USB API functions will do the full authorization/deauthorization to be used for a device. When authorized we effectively allow a configuration to be set. Reverse that when deauthorized. Effectively this means that we have to clean all the configuration descriptors on deauthorize and reload them when we authorized. We could do without throwing them out for wired devices, but for wireless, we can read them only after authenticating, and thus, when authorizing an authenticated device we would need to read them. So to simplify, always release them on deauthorize(), re-read them on authorize(). Also fix leak reported by Ragner Magalhaes; in usb_deauthorize_device(), bNumConfigurations was being set to zero before the for loop, and thus the different raw descriptors where never being freed. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-31 20:34:06 -07:00
USB: fix bugs in usb_(de)authorize_device This patch (as1315) fixes some bugs in the USB core authorization code: usb_deauthorize_device() should deallocate the device strings instead of leaking them, and it should invoke usb_destroy_configuration() (which does proper reference counting) instead of freeing the config information directly. usb_authorize_device() shouldn't change the device strings until it knows that the authorization will succeed, and it should autosuspend the device at the end (having autoresumed the device at the start). Because the device strings can be changed, the sysfs routines to display the strings must protect the string pointers by locking the device. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Inaky Perez-Gonzalez <inaky@linux.intel.com> Acked-by: David Vrabel <david.vrabel@csr.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08 15:54:44 -05:00
usb: introduce usb_authorize/deauthorize() These USB API functions will do the full authorization/deauthorization to be used for a device. When authorized we effectively allow a configuration to be set. Reverse that when deauthorized. Effectively this means that we have to clean all the configuration descriptors on deauthorize and reload them when we authorized. We could do without throwing them out for wired devices, but for wireless, we can read them only after authenticating, and thus, when authorizing an authenticated device we would need to read them. So to simplify, always release them on deauthorize(), re-read them on authorize(). Also fix leak reported by Ragner Magalhaes; in usb_deauthorize_device(), bNumConfigurations was being set to zero before the for loop, and thus the different raw descriptors where never being freed. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-31 20:34:06 -07:00
USB: fix bugs in usb_(de)authorize_device This patch (as1315) fixes some bugs in the USB core authorization code: usb_deauthorize_device() should deallocate the device strings instead of leaking them, and it should invoke usb_destroy_configuration() (which does proper reference counting) instead of freeing the config information directly. usb_authorize_device() shouldn't change the device strings until it knows that the authorization will succeed, and it should autosuspend the device at the end (having autoresumed the device at the start). Because the device strings can be changed, the sysfs routines to display the strings must protect the string pointers by locking the device. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Inaky Perez-Gonzalez <inaky@linux.intel.com> Acked-by: David Vrabel <david.vrabel@csr.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08 15:54:44 -05:00
usb: introduce usb_authorize/deauthorize() These USB API functions will do the full authorization/deauthorization to be used for a device. When authorized we effectively allow a configuration to be set. Reverse that when deauthorized. Effectively this means that we have to clean all the configuration descriptors on deauthorize and reload them when we authorized. We could do without throwing them out for wired devices, but for wireless, we can read them only after authenticating, and thus, when authorizing an authenticated device we would need to read them. So to simplify, always release them on deauthorize(), re-read them on authorize(). Also fix leak reported by Ragner Magalhaes; in usb_deauthorize_device(), bNumConfigurations was being set to zero before the for loop, and thus the different raw descriptors where never being freed. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-31 20:34:06 -07:00
USB: fix bugs in usb_(de)authorize_device This patch (as1315) fixes some bugs in the USB core authorization code: usb_deauthorize_device() should deallocate the device strings instead of leaking them, and it should invoke usb_destroy_configuration() (which does proper reference counting) instead of freeing the config information directly. usb_authorize_device() shouldn't change the device strings until it knows that the authorization will succeed, and it should autosuspend the device at the end (having autoresumed the device at the start). Because the device strings can be changed, the sysfs routines to display the strings must protect the string pointers by locking the device. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Inaky Perez-Gonzalez <inaky@linux.intel.com> Acked-by: David Vrabel <david.vrabel@csr.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08 15:54:44 -05:00
usb: introduce usb_authorize/deauthorize() These USB API functions will do the full authorization/deauthorization to be used for a device. When authorized we effectively allow a configuration to be set. Reverse that when deauthorized. Effectively this means that we have to clean all the configuration descriptors on deauthorize and reload them when we authorized. We could do without throwing them out for wired devices, but for wireless, we can read them only after authenticating, and thus, when authorizing an authenticated device we would need to read them. So to simplify, always release them on deauthorize(), re-read them on authorize(). Also fix leak reported by Ragner Magalhaes; in usb_deauthorize_device(), bNumConfigurations was being set to zero before the for loop, and thus the different raw descriptors where never being freed. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-31 20:34:06 -07:00
USB: fix bugs in usb_(de)authorize_device This patch (as1315) fixes some bugs in the USB core authorization code: usb_deauthorize_device() should deallocate the device strings instead of leaking them, and it should invoke usb_destroy_configuration() (which does proper reference counting) instead of freeing the config information directly. usb_authorize_device() shouldn't change the device strings until it knows that the authorization will succeed, and it should autosuspend the device at the end (having autoresumed the device at the start). Because the device strings can be changed, the sysfs routines to display the strings must protect the string pointers by locking the device. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Inaky Perez-Gonzalez <inaky@linux.intel.com> Acked-by: David Vrabel <david.vrabel@csr.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08 15:54:44 -05:00
usb: introduce usb_authorize/deauthorize() These USB API functions will do the full authorization/deauthorization to be used for a device. When authorized we effectively allow a configuration to be set. Reverse that when deauthorized. Effectively this means that we have to clean all the configuration descriptors on deauthorize and reload them when we authorized. We could do without throwing them out for wired devices, but for wireless, we can read them only after authenticating, and thus, when authorizing an authenticated device we would need to read them. So to simplify, always release them on deauthorize(), re-read them on authorize(). Also fix leak reported by Ragner Magalhaes; in usb_deauthorize_device(), bNumConfigurations was being set to zero before the for loop, and thus the different raw descriptors where never being freed. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-31 20:34:06 -07:00
usb: Do not re-read descriptors for wired devices in usb_authorize_device() This patch modifies the usb_authorize_device() function such as that it does not reload the device descriptor for wired devices. The reasons for this are as follows: * Some devices dislike the master requesting the descriptor from them twice, failing on the usb_get_device_descriptor() call with -ETIMEOUT. Observed this on my Pretec 16GB flash drive (4146:ba65). * Malicious device could send two different descriptors - one before authorization, used by userspace to determine whether to authorize it and second to be actually used by the kernel when determining which drivers to bind. Signed-off-by: Josef Gajdusek <atx@atx.name> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-09 15:47:54 +02:00
usb: introduce usb_authorize/deauthorize() These USB API functions will do the full authorization/deauthorization to be used for a device. When authorized we effectively allow a configuration to be set. Reverse that when deauthorized. Effectively this means that we have to clean all the configuration descriptors on deauthorize and reload them when we authorized. We could do without throwing them out for wired devices, but for wireless, we can read them only after authenticating, and thus, when authorizing an authenticated device we would need to read them. So to simplify, always release them on deauthorize(), re-read them on authorize(). Also fix leak reported by Ragner Magalhaes; in usb_deauthorize_device(), bNumConfigurations was being set to zero before the for loop, and thus the different raw descriptors where never being freed. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-31 20:34:06 -07:00
USB: rename choose_configuration As it is global, give it a usb specific name in the global namespace. Cc: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-08-02 22:44:27 -06:00
usb: introduce usb_authorize/deauthorize() These USB API functions will do the full authorization/deauthorization to be used for a device. When authorized we effectively allow a configuration to be set. Reverse that when deauthorized. Effectively this means that we have to clean all the configuration descriptors on deauthorize and reload them when we authorized. We could do without throwing them out for wired devices, but for wireless, we can read them only after authenticating, and thus, when authorizing an authenticated device we would need to read them. So to simplify, always release them on deauthorize(), re-read them on authorize(). Also fix leak reported by Ragner Magalhaes; in usb_deauthorize_device(), bNumConfigurations was being set to zero before the for loop, and thus the different raw descriptors where never being freed. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-31 20:34:06 -07:00
USB: fix bugs in usb_(de)authorize_device This patch (as1315) fixes some bugs in the USB core authorization code: usb_deauthorize_device() should deallocate the device strings instead of leaking them, and it should invoke usb_destroy_configuration() (which does proper reference counting) instead of freeing the config information directly. usb_authorize_device() shouldn't change the device strings until it knows that the authorization will succeed, and it should autosuspend the device at the end (having autoresumed the device at the start). Because the device strings can be changed, the sysfs routines to display the strings must protect the string pointers by locking the device. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Inaky Perez-Gonzalez <inaky@linux.intel.com> Acked-by: David Vrabel <david.vrabel@csr.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-08 15:54:44 -05:00
usb: introduce usb_authorize/deauthorize() These USB API functions will do the full authorization/deauthorization to be used for a device. When authorized we effectively allow a configuration to be set. Reverse that when deauthorized. Effectively this means that we have to clean all the configuration descriptors on deauthorize and reload them when we authorized. We could do without throwing them out for wired devices, but for wireless, we can read them only after authenticating, and thus, when authorizing an authenticated device we would need to read them. So to simplify, always release them on deauthorize(), re-read them on authorize(). Also fix leak reported by Ragner Magalhaes; in usb_deauthorize_device(), bNumConfigurations was being set to zero before the for loop, and thus the different raw descriptors where never being freed. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-31 20:34:06 -07:00
drivers: usb: core: hub.c: Comments shouldnt be C99 // comment style Signed-off-by: Matthias Beyer <mail@beyermatthias.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-10 23:41:29 +02:00
usb: introduce usb_authorize/deauthorize() These USB API functions will do the full authorization/deauthorization to be used for a device. When authorized we effectively allow a configuration to be set. Reverse that when deauthorized. Effectively this means that we have to clean all the configuration descriptors on deauthorize and reload them when we authorized. We could do without throwing them out for wired devices, but for wireless, we can read them only after authenticating, and thus, when authorizing an authenticated device we would need to read them. So to simplify, always release them on deauthorize(), re-read them on authorize(). Also fix leak reported by Ragner Magalhaes; in usb_deauthorize_device(), bNumConfigurations was being set to zero before the for loop, and thus the different raw descriptors where never being freed. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-31 20:34:06 -07:00
usb: core: Track SuperSpeed Plus GenXxY Introduce ssp_rate field to usb_device structure to capture the connected SuperSpeed Plus signaling rate generation and lane count with the corresponding usb_ssp_rate enum. Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/b7805d121e5ae4ad5ae144bd860b6ac04ee47436.1615432770.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-10 19:42:44 -08:00
usb: hub: Guard against accesses to uninitialized BOS descriptors Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h access fields inside udev->bos without checking if it was allocated and initialized. If usb_get_bos_descriptor() fails for whatever reason, udev->bos will be NULL and those accesses will result in a crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1> Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:hub_port_reset+0x193/0x788 Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9 RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310 RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840 RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0 Call Trace: hub_event+0x73f/0x156e ? hub_activate+0x5b7/0x68f process_one_work+0x1a2/0x487 worker_thread+0x11a/0x288 kthread+0x13a/0x152 ? process_one_work+0x487/0x487 ? kthread_associate_blkcg+0x70/0x70 ret_from_fork+0x1f/0x30 Fall back to a default behavior if the BOS descriptor isn't accessible and skip all the functionalities that depend on it: LPM support checks, Super Speed capabilitiy checks, U1/U2 states setup. Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20230830100418.1952143-1-ricardo.canuelo@collabora.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-30 12:04:18 +02:00
usb: core: Track SuperSpeed Plus GenXxY Introduce ssp_rate field to usb_device structure to capture the connected SuperSpeed Plus signaling rate generation and lane count with the corresponding usb_ssp_rate enum. Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/b7805d121e5ae4ad5ae144bd860b6ac04ee47436.1615432770.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-10 19:42:44 -08:00
usb: hub: Guard against accesses to uninitialized BOS descriptors Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h access fields inside udev->bos without checking if it was allocated and initialized. If usb_get_bos_descriptor() fails for whatever reason, udev->bos will be NULL and those accesses will result in a crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1> Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:hub_port_reset+0x193/0x788 Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9 RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310 RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840 RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0 Call Trace: hub_event+0x73f/0x156e ? hub_activate+0x5b7/0x68f process_one_work+0x1a2/0x487 worker_thread+0x11a/0x288 kthread+0x13a/0x152 ? process_one_work+0x487/0x487 ? kthread_associate_blkcg+0x70/0x70 ret_from_fork+0x1f/0x30 Fall back to a default behavior if the BOS descriptor isn't accessible and skip all the functionalities that depend on it: LPM support checks, Super Speed capabilitiy checks, U1/U2 states setup. Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20230830100418.1952143-1-ricardo.canuelo@collabora.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-30 12:04:18 +02:00
usb: core: Track SuperSpeed Plus GenXxY Introduce ssp_rate field to usb_device structure to capture the connected SuperSpeed Plus signaling rate generation and lane count with the corresponding usb_ssp_rate enum. Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/b7805d121e5ae4ad5ae144bd860b6ac04ee47436.1615432770.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-10 19:42:44 -08:00
USB: hub: Add Kconfig option to reduce number of port initialization retries Description based on one by Yasushi Asano: According to 6.7.22 A-UUT “Device No Response” for connection timeout of USB OTG and EH automated compliance plan v1.2, enumeration failure has to be detected within 30 seconds. However, the old and new enumeration schemes each make a total of 12 attempts, and each attempt can take 5 seconds to time out, so the PET test fails. This patch adds a new Kconfig option (CONFIG_USB_FEW_INIT_RETRIES); when the option is set all the initialization retry loops except the outermost are reduced to a single iteration. This reduces the total number of attempts to four, allowing Linux hosts to pass the PET test. The new option is disabled by default to preserve the existing behavior. The reduced number of retries may fail to initialize a few devices that currently do work, but for the most part there should be no change. And in cases where the initialization does fail, it will fail much more quickly. Reported-and-tested-by: yasushi asano <yazzep@gmail.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200928152217.GB134701@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-28 11:22:17 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: hub: Add Kconfig option to reduce number of port initialization retries Description based on one by Yasushi Asano: According to 6.7.22 A-UUT “Device No Response” for connection timeout of USB OTG and EH automated compliance plan v1.2, enumeration failure has to be detected within 30 seconds. However, the old and new enumeration schemes each make a total of 12 attempts, and each attempt can take 5 seconds to time out, so the PET test fails. This patch adds a new Kconfig option (CONFIG_USB_FEW_INIT_RETRIES); when the option is set all the initialization retry loops except the outermost are reduced to a single iteration. This reduces the total number of attempts to four, allowing Linux hosts to pass the PET test. The new option is disabled by default to preserve the existing behavior. The reduced number of retries may fail to initialize a few devices that currently do work, but for the most part there should be no change. And in cases where the initialization does fail, it will fail much more quickly. Reported-and-tested-by: yasushi asano <yazzep@gmail.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200928152217.GB134701@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-28 11:22:17 -04:00
USB: hub: Clean up use of port initialization schemes and retries The SET_CONFIG_TRIES macro in hub.c is badly named; it controls the number of port-initialization retry attempts rather than the number of Set-Configuration attempts. Furthermore, the USE_NEW_SCHEME macro and use_new_scheme() function are written in a very confusing manner, making it almost impossible to figure out exactly what they do or check that they are correct. This patch renames SET_CONFIG_TRIES to PORT_INIT_TRIES, removes USE_NEW_SCHEME entirely, and rewrites use_new_scheme() to be much more transparent, with added comments explaining how it works. The patch also pulls the single call site of use_new_scheme() out from the Get-Descriptor retry loop (where it returns the same value each time) and renames the local variable used to store the result. The overall effect is a minor cleanup. However, there is one functional change: If the "use_both_schemes" module parameter isn't set (by default it is set), the existing code does only two retry iterations. After this patch it will always perform four, regardless of the parameter's value. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200928152050.GA134701@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-28 11:20:50 -04:00
USB: hub: Add Kconfig option to reduce number of port initialization retries Description based on one by Yasushi Asano: According to 6.7.22 A-UUT “Device No Response” for connection timeout of USB OTG and EH automated compliance plan v1.2, enumeration failure has to be detected within 30 seconds. However, the old and new enumeration schemes each make a total of 12 attempts, and each attempt can take 5 seconds to time out, so the PET test fails. This patch adds a new Kconfig option (CONFIG_USB_FEW_INIT_RETRIES); when the option is set all the initialization retry loops except the outermost are reduced to a single iteration. This reduces the total number of attempts to four, allowing Linux hosts to pass the PET test. The new option is disabled by default to preserve the existing behavior. The reduced number of retries may fail to initialize a few devices that currently do work, but for the most part there should be no change. And in cases where the initialization does fail, it will fail much more quickly. Reported-and-tested-by: yasushi asano <yazzep@gmail.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200928152217.GB134701@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-28 11:22:17 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: avoid warm port reset during USB3 disconnect During disconnect USB-3 ports often go via SS.Inactive link error state before the missing terminations are noticed, and link finally goes to RxDetect state Avoid immediately warm-resetting ports in SS.Inactive state. Let ports settle for a while and re-read the link status a few times 20ms apart to see if the ports transitions out of SS.Inactive. According to USB 3.x spec 7.5.2, a port in SS.Inactive should automatically check for missing far-end receiver termination every 12 ms (SSInactiveQuietTimeout) The futile multiple warm reset retries of a disconnected device takes a lot of time, also the resetting of a removed devices has caused cases where the reset bit got stuck for a long time on xHCI roothub. This lead to issues in detecting new devices connected to the same port shortly after. Tested-by: Mark Pearson <markpearson@lenovo.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211210111653.1378381-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-10 13:16:53 +02:00
usb: Increase root hub reset signaling time to prevent retry Save 80ms device enumeration time by increasing root hub port reset time The 50ms reset signaling time is not enough for most root hub ports. Increasing the reset time to 60ms allows host controllers to finish port reset and removes a retry causing an extra 50ms delay. The USB 2 specification requires "at least 50ms" for driving root port reset. The current msleep is exactly 50ms which may not be enough if there are any delays between writing the reset bit to host controller portsc register and phy actually driving reset. On Haswell, Skylake and Kabylake xHC port reset took in average 52-59ms The 80ms improvement comes from (40ms * 2 port resets) save at enumeration for each device connected to a root hub port. more details about root port reset in USB2 section 7.1.7.5:. "Software must ensure that resets issued to the root ports drive reset long enough to overwhelm any concurrent resume attempts by downstream devices. It is required that resets from root ports have a duration of at least 50 ms (TDRSTR). Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-08-16 14:23:25 +03:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usbcore: refine warm reset logic Current waiting time for warm(BH) reset in hub_port_warm_reset() is too short for xHC host to complete the warm reset and report a BH reset change. This patch increases the waiting time for warm reset and merges the function into hub_port_reset(), so it can handle both cold reset and warm reset, and factor out hub_port_finish_reset() to make the code looks cleaner. This fixes the issue that driver fails to clear BH reset change and port is "dead". Signed-off-by: Andiry Xu <andiry.xu@amd.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-13 16:41:11 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: Increase reset timeout. John's NEC 0.96 xHCI host controller needs a longer timeout for a warm reset to complete. The logs show it takes 650ms to complete the warm reset, so extend the hub reset timeout to 800ms to be on the safe side. This commit should be backported to kernels as old as 3.2, that contain the commit 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm reset logic". Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: John Covici <covici@ccs.covici.com> Cc: stable@vger.kernel.org
2012-11-14 17:16:52 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: Per-port setting to use old enumeration scheme The "old" enumeration scheme is considerably faster (it takes ~244ms instead of ~356ms to get the descriptor). It is currently only possible to use the old scheme globally (/sys/module/usbcore/parameters/old_scheme_first), which is not desirable as the new scheme was introduced to increase compatibility with more devices. However, in our case, we care about time-to-active for a specific USB device (which we make the firmware for), on a specific port (that is pogo-pin based: not a standard USB port). This new sysfs option makes it possible to use the old scheme on a single port only. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-28 14:32:18 +08:00
usb: xhci: change enumeration scheme to 'new scheme' by default Change the default enumeration scheme for xhci attached non-SuperSpeed devices from: Reset SetAddress [xhci address-device BSR = 0] GetDescriptor(8) GetDescriptor(18) ...to: Reset [xhci address-device BSR = 1] GetDescriptor(64) Reset SetAddress [xhci address-device BSR = 0] GetDescriptor(18) ...as some devices misbehave when encountering a SetAddress command prior to GetDescriptor. There are known legacy devices that require this scheme, but testing has found at least one USB3 device that fails enumeration when presented with this ordering. For now, follow the ehci case and enable 'new scheme' by default for non-SuperSpeed devices. To support this enumeration scheme on xhci the AddressDevice operation needs to be performed twice. The first instance of the command enables the HC's device and slot context info for the device, but omits sending the device a SetAddress command (BSR == block set address request). Then, after GetDescriptor completes, follow up with the full AddressDevice+SetAddress operation. As mentioned before, this ordering of events with USB3 devices causes an extra state transition to be exposed to xhci. Previously USB3 devices would transition directly from 'enabled' to 'addressed' and never need to underrun responses to 'get descriptor'. We do see the 64-byte descriptor fetch the correct data, but the following 18-byte descriptor read after the reset gets: bLength = 0 bDescriptorType = 0 bcdUSB = 0 bDeviceClass = 0 bDeviceSubClass = 0 bDeviceProtocol = 0 bMaxPacketSize0 = 9 instead of: bLength = 12 bDescriptorType = 1 bcdUSB = 300 bDeviceClass = 0 bDeviceSubClass = 0 bDeviceProtocol = 0 bMaxPacketSize0 = 9 which results in the discovery process looping until falling back to 'old scheme' enumeration. Acked-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: David Moore <david.moore@gmail.com> Suggested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-12-05 17:07:27 -08:00
usb: hub: Per-port setting to use old enumeration scheme The "old" enumeration scheme is considerably faster (it takes ~244ms instead of ~356ms to get the descriptor). It is currently only possible to use the old scheme globally (/sys/module/usbcore/parameters/old_scheme_first), which is not desirable as the new scheme was introduced to increase compatibility with more devices. However, in our case, we care about time-to-active for a specific USB device (which we make the firmware for), on a specific port (that is pogo-pin based: not a standard USB port). This new sysfs option makes it possible to use the old scheme on a single port only. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-28 14:32:18 +08:00
USB: hub: Clean up use of port initialization schemes and retries The SET_CONFIG_TRIES macro in hub.c is badly named; it controls the number of port-initialization retry attempts rather than the number of Set-Configuration attempts. Furthermore, the USE_NEW_SCHEME macro and use_new_scheme() function are written in a very confusing manner, making it almost impossible to figure out exactly what they do or check that they are correct. This patch renames SET_CONFIG_TRIES to PORT_INIT_TRIES, removes USE_NEW_SCHEME entirely, and rewrites use_new_scheme() to be much more transparent, with added comments explaining how it works. The patch also pulls the single call site of use_new_scheme() out from the Get-Descriptor retry loop (where it returns the same value each time) and renames the local variable used to store the result. The overall effect is a minor cleanup. However, there is one functional change: If the "use_both_schemes" module parameter isn't set (by default it is set), the existing code does only two retry iterations. After this patch it will always perform four, regardless of the parameter's value. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200928152050.GA134701@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-28 11:20:50 -04:00
usb: hub: Per-port setting to use old enumeration scheme The "old" enumeration scheme is considerably faster (it takes ~244ms instead of ~356ms to get the descriptor). It is currently only possible to use the old scheme globally (/sys/module/usbcore/parameters/old_scheme_first), which is not desirable as the new scheme was introduced to increase compatibility with more devices. However, in our case, we care about time-to-active for a specific USB device (which we make the firmware for), on a specific port (that is pogo-pin based: not a standard USB port). This new sysfs option makes it possible to use the old scheme on a single port only. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-28 14:32:18 +08:00
USB: hub: Clean up use of port initialization schemes and retries The SET_CONFIG_TRIES macro in hub.c is badly named; it controls the number of port-initialization retry attempts rather than the number of Set-Configuration attempts. Furthermore, the USE_NEW_SCHEME macro and use_new_scheme() function are written in a very confusing manner, making it almost impossible to figure out exactly what they do or check that they are correct. This patch renames SET_CONFIG_TRIES to PORT_INIT_TRIES, removes USE_NEW_SCHEME entirely, and rewrites use_new_scheme() to be much more transparent, with added comments explaining how it works. The patch also pulls the single call site of use_new_scheme() out from the Get-Descriptor retry loop (where it returns the same value each time) and renames the local variable used to store the result. The overall effect is a minor cleanup. However, there is one functional change: If the "use_both_schemes" module parameter isn't set (by default it is set), the existing code does only two retry iterations. After this patch it will always perform four, regardless of the parameter's value. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200928152050.GA134701@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-28 11:20:50 -04:00
usb: define USB_SPEED_SUPER_PLUS speed for SuperSpeedPlus USB3.1 devices Add a new USB_SPEED_SUPER_PLUS device speed, and make sure usb core can handle the new speed. In most cases the behaviour is the same as with USB_SPEED_SUPER SuperSpeed devices. In a few places we add a "Plus" string to inform the user of the new speed. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-10 09:59:25 +02:00
usb: xhci: change enumeration scheme to 'new scheme' by default Change the default enumeration scheme for xhci attached non-SuperSpeed devices from: Reset SetAddress [xhci address-device BSR = 0] GetDescriptor(8) GetDescriptor(18) ...to: Reset [xhci address-device BSR = 1] GetDescriptor(64) Reset SetAddress [xhci address-device BSR = 0] GetDescriptor(18) ...as some devices misbehave when encountering a SetAddress command prior to GetDescriptor. There are known legacy devices that require this scheme, but testing has found at least one USB3 device that fails enumeration when presented with this ordering. For now, follow the ehci case and enable 'new scheme' by default for non-SuperSpeed devices. To support this enumeration scheme on xhci the AddressDevice operation needs to be performed twice. The first instance of the command enables the HC's device and slot context info for the device, but omits sending the device a SetAddress command (BSR == block set address request). Then, after GetDescriptor completes, follow up with the full AddressDevice+SetAddress operation. As mentioned before, this ordering of events with USB3 devices causes an extra state transition to be exposed to xhci. Previously USB3 devices would transition directly from 'enabled' to 'addressed' and never need to underrun responses to 'get descriptor'. We do see the 64-byte descriptor fetch the correct data, but the following 18-byte descriptor read after the reset gets: bLength = 0 bDescriptorType = 0 bcdUSB = 0 bDeviceClass = 0 bDeviceSubClass = 0 bDeviceProtocol = 0 bMaxPacketSize0 = 9 instead of: bLength = 12 bDescriptorType = 1 bcdUSB = 300 bDeviceClass = 0 bDeviceSubClass = 0 bDeviceProtocol = 0 bMaxPacketSize0 = 9 which results in the discovery process looping until falling back to 'old scheme' enumeration. Acked-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: David Moore <david.moore@gmail.com> Suggested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-12-05 17:07:27 -08:00
USB: hub: Clean up use of port initialization schemes and retries The SET_CONFIG_TRIES macro in hub.c is badly named; it controls the number of port-initialization retry attempts rather than the number of Set-Configuration attempts. Furthermore, the USE_NEW_SCHEME macro and use_new_scheme() function are written in a very confusing manner, making it almost impossible to figure out exactly what they do or check that they are correct. This patch renames SET_CONFIG_TRIES to PORT_INIT_TRIES, removes USE_NEW_SCHEME entirely, and rewrites use_new_scheme() to be much more transparent, with added comments explaining how it works. The patch also pulls the single call site of use_new_scheme() out from the Get-Descriptor retry loop (where it returns the same value each time) and renames the local variable used to store the result. The overall effect is a minor cleanup. However, there is one functional change: If the "use_both_schemes" module parameter isn't set (by default it is set), the existing code does only two retry iterations. After this patch it will always perform four, regardless of the parameter's value. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200928152050.GA134701@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-28 11:20:50 -04:00
usb: xhci: change enumeration scheme to 'new scheme' by default Change the default enumeration scheme for xhci attached non-SuperSpeed devices from: Reset SetAddress [xhci address-device BSR = 0] GetDescriptor(8) GetDescriptor(18) ...to: Reset [xhci address-device BSR = 1] GetDescriptor(64) Reset SetAddress [xhci address-device BSR = 0] GetDescriptor(18) ...as some devices misbehave when encountering a SetAddress command prior to GetDescriptor. There are known legacy devices that require this scheme, but testing has found at least one USB3 device that fails enumeration when presented with this ordering. For now, follow the ehci case and enable 'new scheme' by default for non-SuperSpeed devices. To support this enumeration scheme on xhci the AddressDevice operation needs to be performed twice. The first instance of the command enables the HC's device and slot context info for the device, but omits sending the device a SetAddress command (BSR == block set address request). Then, after GetDescriptor completes, follow up with the full AddressDevice+SetAddress operation. As mentioned before, this ordering of events with USB3 devices causes an extra state transition to be exposed to xhci. Previously USB3 devices would transition directly from 'enabled' to 'addressed' and never need to underrun responses to 'get descriptor'. We do see the 64-byte descriptor fetch the correct data, but the following 18-byte descriptor read after the reset gets: bLength = 0 bDescriptorType = 0 bcdUSB = 0 bDeviceClass = 0 bDeviceSubClass = 0 bDeviceProtocol = 0 bMaxPacketSize0 = 9 instead of: bLength = 12 bDescriptorType = 1 bcdUSB = 300 bDeviceClass = 0 bDeviceSubClass = 0 bDeviceProtocol = 0 bMaxPacketSize0 = 9 which results in the discovery process looping until falling back to 'old scheme' enumeration. Acked-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: David Moore <david.moore@gmail.com> Suggested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-12-05 17:07:27 -08:00
USB: core: correct spelling mistakes in comments and warning Signed-off-by: Rahul Bedarkar <rahulbedarkar89@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-01-04 11:24:41 +05:30
USB: core: correct a spelling mistake in the comment Fix a spelling typo in the function comment. Signed-off-by: Harry Pan <harry.pan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-20 13:58:23 +08:00
usb: Add support for root hub port status CAS 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-18 15:20:00 +02:00
usb: force warm reset to break link re-connect livelock Resuming a powered down port sometimes results in the port state being stuck in the training sequence. hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0 port1: can't get reconnection after setting port power on, status -110 hub 3-0:1.0: port 1 status 0000.02e0 after resume, -19 usb 3-1: can't resume, status -19 hub 3-0:1.0: logical disconnect on port 1 In the case above we wait for the port re-connect timeout of 2 seconds and observe that the port status is USB_SS_PORT_LS_POLLING (although it is likely toggling between this state and USB_SS_PORT_LS_RX_DETECT). This is indicative of a case where the device is failing to progress the link training state machine. It is resolved by issuing a warm reset to get the hub and device link state machines back in sync. hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0 usb usb3: port1 usb_port_runtime_resume requires warm reset hub 3-0:1.0: port 1 not warm reset yet, waiting 50ms usb 3-1: reset SuperSpeed USB device number 2 using xhci_hcd After a reconnect timeout when we expect the device to be present, force a warm reset of the device. Note that we can not simply look at the link status to determine if a warm reset is required as any of the training states USB_SS_PORT_LS_POLLING, USB_SS_PORT_LS_RX_DETECT, or USB_SS_PORT_LS_COMP_MOD are valid states that do not indicate the need for warm reset by themselves. Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Kukjin Kim <kgene.kim@samsung.com> Cc: Vincent Palatin <vpalatin@chromium.org> Cc: Lan Tianyu <tianyu.lan@intel.com> Cc: Ksenia Ragiadakou <burzalodowa@gmail.com> Cc: Vivek Gautam <gautam.vivek@samsung.com> Cc: Douglas Anderson <dianders@chromium.org> Cc: Felipe Balbi <balbi@ti.com> Cc: Sunil Joshi <joshi@samsung.com> Cc: Hans de Goede <hdegoede@redhat.com> Acked-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-29 12:58:46 -07:00
USB: When hot reset for USB3 fails, try warm reset. When a hot reset (standard USB port reset) fails on a USB 3.0 port, the host controller transitions to the "Error" state. It reports the port link state as "Inactive", sets the link state change flag, and (if the device disconnects) also reports the disconnect and connect change status. It's also supposed to transition the link state to "RxDetect", but the NEC µPD720200 xHCI host does not. Unfortunately, Harald found that the combination of the NEC µPD720200 and a LogiLink USB 3.0 to SATA adapter triggered this issue. The USB core would reset the device, the port would go into this error state, and the device would never be enumerated. This combination works under Windows, but not under Linux. When a hot reset fails on a USB 3.0 port, and the link state is reported as Inactive, fall back to a warm port reset instead. Harald confirms that with a warm port reset (along with all the change bits being correctly cleared), the USB 3.0 device will successfully enumerate. Harald also had to add two other patches ("xhci: Set change bit when warm reset change is set." and "usbcore: refine warm reset logic") to make this setup work. Since the warm reset refinement patch is not destined for the stable kernels (it's too big), this patch should not be backported either. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=41752 Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Harald Brennich <harald.brennich@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-14 14:24:52 -07:00
usb: force warm reset to break link re-connect livelock Resuming a powered down port sometimes results in the port state being stuck in the training sequence. hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0 port1: can't get reconnection after setting port power on, status -110 hub 3-0:1.0: port 1 status 0000.02e0 after resume, -19 usb 3-1: can't resume, status -19 hub 3-0:1.0: logical disconnect on port 1 In the case above we wait for the port re-connect timeout of 2 seconds and observe that the port status is USB_SS_PORT_LS_POLLING (although it is likely toggling between this state and USB_SS_PORT_LS_RX_DETECT). This is indicative of a case where the device is failing to progress the link training state machine. It is resolved by issuing a warm reset to get the hub and device link state machines back in sync. hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0 usb usb3: port1 usb_port_runtime_resume requires warm reset hub 3-0:1.0: port 1 not warm reset yet, waiting 50ms usb 3-1: reset SuperSpeed USB device number 2 using xhci_hcd After a reconnect timeout when we expect the device to be present, force a warm reset of the device. Note that we can not simply look at the link status to determine if a warm reset is required as any of the training states USB_SS_PORT_LS_POLLING, USB_SS_PORT_LS_RX_DETECT, or USB_SS_PORT_LS_COMP_MOD are valid states that do not indicate the need for warm reset by themselves. Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Kukjin Kim <kgene.kim@samsung.com> Cc: Vincent Palatin <vpalatin@chromium.org> Cc: Lan Tianyu <tianyu.lan@intel.com> Cc: Ksenia Ragiadakou <burzalodowa@gmail.com> Cc: Vivek Gautam <gautam.vivek@samsung.com> Cc: Douglas Anderson <dianders@chromium.org> Cc: Felipe Balbi <balbi@ti.com> Cc: Sunil Joshi <joshi@samsung.com> Cc: Hans de Goede <hdegoede@redhat.com> Acked-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-29 12:58:46 -07:00
USB: When hot reset for USB3 fails, try warm reset. When a hot reset (standard USB port reset) fails on a USB 3.0 port, the host controller transitions to the "Error" state. It reports the port link state as "Inactive", sets the link state change flag, and (if the device disconnects) also reports the disconnect and connect change status. It's also supposed to transition the link state to "RxDetect", but the NEC µPD720200 xHCI host does not. Unfortunately, Harald found that the combination of the NEC µPD720200 and a LogiLink USB 3.0 to SATA adapter triggered this issue. The USB core would reset the device, the port would go into this error state, and the device would never be enumerated. This combination works under Windows, but not under Linux. When a hot reset fails on a USB 3.0 port, and the link state is reported as Inactive, fall back to a warm port reset instead. Harald confirms that with a warm port reset (along with all the change bits being correctly cleared), the USB 3.0 device will successfully enumerate. Harald also had to add two other patches ("xhci: Set change bit when warm reset change is set." and "usbcore: refine warm reset logic") to make this setup work. Since the warm reset refinement patch is not destined for the stable kernels (it's too big), this patch should not be backported either. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=41752 Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Harald Brennich <harald.brennich@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-14 14:24:52 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usbcore: refine warm reset logic Current waiting time for warm(BH) reset in hub_port_warm_reset() is too short for xHC host to complete the warm reset and report a BH reset change. This patch increases the waiting time for warm reset and merges the function into hub_port_reset(), so it can handle both cold reset and warm reset, and factor out hub_port_finish_reset() to make the code looks cleaner. This fixes the issue that driver fails to clear BH reset change and port is "dead". Signed-off-by: Andiry Xu <andiry.xu@amd.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-13 16:41:11 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: Support USB 3.1 extended port status request usb 3.1 extend the hub get-port-status request by adding different request types. the new request types return 4 additional bytes called extended port status, these bytes are returned after the regular portstatus and portchange values. The extended port status contains a speed ID for the currently used sublink speed. A table of supported Speed IDs with details about the link is provided by the hub in the device descriptor BOS SuperSpeedPlus device capability Sublink Speed Attributes. Support this new request. Ask for the extended port status after port reset if hub supports USB 3.1. If link is running at SuperSpeedPlus set the device speed to USB_SPEED_SUPER_PLUS Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-10 09:59:29 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: Support USB 3.1 extended port status request usb 3.1 extend the hub get-port-status request by adding different request types. the new request types return 4 additional bytes called extended port status, these bytes are returned after the regular portstatus and portchange values. The extended port status contains a speed ID for the currently used sublink speed. A table of supported Speed IDs with details about the link is provided by the hub in the device descriptor BOS SuperSpeedPlus device capability Sublink Speed Attributes. Support this new request. Ask for the extended port status after port reset if hub supports USB 3.1. If link is running at SuperSpeedPlus set the device speed to USB_SPEED_SUPER_PLUS Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-10 09:59:29 +02:00
usb: hub: port: add sysfs entry to switch port power In some cases the port of an hub needs to be disabled or switched off and on again. E.g. when the connected device needs to be re-enumerated. Or it needs to be explicitly disabled while the rest of the usb tree stays working. For this purpose this patch adds an sysfs switch to enable/disable the port on any hub. In the case the hub is supporting power switching, the power line will be disabled to the connected device. When the port gets disabled, the associated device gets disconnected and removed from the logical usb tree. No further device will be enumerated on that port until the port gets enabled again. Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220607114522.3359148-1-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-07 13:45:22 +02:00
usb: Support USB 3.1 extended port status request usb 3.1 extend the hub get-port-status request by adding different request types. the new request types return 4 additional bytes called extended port status, these bytes are returned after the regular portstatus and portchange values. The extended port status contains a speed ID for the currently used sublink speed. A table of supported Speed IDs with details about the link is provided by the hub in the device descriptor BOS SuperSpeedPlus device capability Sublink Speed Attributes. Support this new request. Ask for the extended port status after port reset if hub supports USB 3.1. If link is running at SuperSpeedPlus set the device speed to USB_SPEED_SUPER_PLUS Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-10 09:59:29 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: Wait for connection to be reestablished after port reset On a system with a defective USB device connected to an USB hub, an endless sequence of port connect events was observed. The sequence of events as observed is as follows: - Port reports connected event (port status=USB_PORT_STAT_CONNECTION). - Event handler debounces port and resets it by calling hub_port_reset(). - hub_port_reset() calls hub_port_wait_reset() to wait for the reset to complete. - The reset completes, but USB_PORT_STAT_CONNECTION is not immediately set in the port status register. - hub_port_wait_reset() returns -ENOTCONN. - Port initialization sequence is aborted. - A few milliseconds later, the port again reports a connected event, and the sequence repeats. This continues either forever or, randomly, stops if the connection is already re-established when the port status is read. It results in a high rate of udev events. This in turn destabilizes userspace since the above sequence holds the device mutex pretty much continuously and prevents userspace from actually reading the device status. To prevent the problem from happening, let's wait for the connection to be re-established after a port reset. If the device was actually disconnected, the code will still return an error, but it will do so only after the long reset timeout. Cc: Douglas Anderson <dianders@chromium.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-12-01 13:49:59 -08:00
USB: Refactor hub_port_wait_reset. Refactor hub_port_wait_reset into a small loop to wait for the port reset to be complete, and then a larger block to deal with the final port status. This patch should not change any current behavior. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu>
2012-12-11 10:14:03 -08:00
USB: Ignore port state until reset completes. The port reset code bails out early if the current connect status is cleared (device disconnected). If we're issuing a hot reset, it may also look at the link state before the reset is finished. Section 10.14.2.6 of the USB 3.0 spec says that when a port enters the Error state or Resetting state, the port connection bit retains the value from the previous state. Therefore we can't trust it until the reset finishes. Also, the xHCI spec section 4.19.1.2.5 says software shall ignore the link state while the port is resetting, as it can be in an unknown state. The port state during reset is also unknown for USB 2.0 hubs. The hub sends a reset signal by driving the bus into an SE0 state. This overwhelms the "connect" signal from the device, so the port can't tell whether anything is connected or not. Fix the port reset code to ignore the port link state and current connect bit until the reset finishes, and USB_PORT_STAT_RESET is cleared. Remove the check for USB_PORT_STAT_C_BH_RESET in the warm reset case, because it's redundant. When the warm reset finishes, the port reset bit will be cleared at the same time USB_PORT_STAT_C_BH_RESET is set. Remove the now-redundant check for a cleared USB_PORT_STAT_RESET bit in the code to deal with the finished reset. This patch should be backported to all stable kernels. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable@vger.kernel.org
2012-11-15 14:58:04 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: Refactor hub_port_wait_reset. Refactor hub_port_wait_reset into a small loop to wait for the port reset to be complete, and then a larger block to deal with the final port status. This patch should not change any current behavior. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu>
2012-12-11 10:14:03 -08:00
usb: force warm reset to break link re-connect livelock Resuming a powered down port sometimes results in the port state being stuck in the training sequence. hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0 port1: can't get reconnection after setting port power on, status -110 hub 3-0:1.0: port 1 status 0000.02e0 after resume, -19 usb 3-1: can't resume, status -19 hub 3-0:1.0: logical disconnect on port 1 In the case above we wait for the port re-connect timeout of 2 seconds and observe that the port status is USB_SS_PORT_LS_POLLING (although it is likely toggling between this state and USB_SS_PORT_LS_RX_DETECT). This is indicative of a case where the device is failing to progress the link training state machine. It is resolved by issuing a warm reset to get the hub and device link state machines back in sync. hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0 usb usb3: port1 usb_port_runtime_resume requires warm reset hub 3-0:1.0: port 1 not warm reset yet, waiting 50ms usb 3-1: reset SuperSpeed USB device number 2 using xhci_hcd After a reconnect timeout when we expect the device to be present, force a warm reset of the device. Note that we can not simply look at the link status to determine if a warm reset is required as any of the training states USB_SS_PORT_LS_POLLING, USB_SS_PORT_LS_RX_DETECT, or USB_SS_PORT_LS_COMP_MOD are valid states that do not indicate the need for warm reset by themselves. Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Kukjin Kim <kgene.kim@samsung.com> Cc: Vincent Palatin <vpalatin@chromium.org> Cc: Lan Tianyu <tianyu.lan@intel.com> Cc: Ksenia Ragiadakou <burzalodowa@gmail.com> Cc: Vivek Gautam <gautam.vivek@samsung.com> Cc: Douglas Anderson <dianders@chromium.org> Cc: Felipe Balbi <balbi@ti.com> Cc: Sunil Joshi <joshi@samsung.com> Cc: Hans de Goede <hdegoede@redhat.com> Acked-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-29 12:58:46 -07:00
USB: Refactor hub_port_wait_reset. Refactor hub_port_wait_reset into a small loop to wait for the port reset to be complete, and then a larger block to deal with the final port status. This patch should not change any current behavior. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu>
2012-12-11 10:14:03 -08:00
usb: hub: Allow reset retry for USB2 devices on connect bounce If the connect status change is set during reset signaling, but the status remains connected just retry port reset. This solves an issue with connecting a 90W HP Thunderbolt 3 dock with a Lenovo Carbon x1 (5th generation) which causes a 30min loop of a high speed device being re-discovererd before usb ports starts working. [...] [ 389.023845] usb 3-1: new high-speed USB device number 55 using xhci_hcd [ 389.491841] usb 3-1: new high-speed USB device number 56 using xhci_hcd [ 389.959928] usb 3-1: new high-speed USB device number 57 using xhci_hcd [...] This is caused by a high speed device that doesn't successfully go to the enabled state after the second port reset. Instead the connection bounces (connected, with connect status change), bailing out completely from enumeration just to restart from scratch. Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1716332 Cc: Stable <stable@vger.kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-17 16:07:33 +03:00
USB: Refactor hub_port_wait_reset. Refactor hub_port_wait_reset into a small loop to wait for the port reset to be complete, and then a larger block to deal with the final port status. This patch should not change any current behavior. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu>
2012-12-11 10:14:03 -08:00
usb: hub: Allow reset retry for USB2 devices on connect bounce If the connect status change is set during reset signaling, but the status remains connected just retry port reset. This solves an issue with connecting a 90W HP Thunderbolt 3 dock with a Lenovo Carbon x1 (5th generation) which causes a 30min loop of a high speed device being re-discovererd before usb ports starts working. [...] [ 389.023845] usb 3-1: new high-speed USB device number 55 using xhci_hcd [ 389.491841] usb 3-1: new high-speed USB device number 56 using xhci_hcd [ 389.959928] usb 3-1: new high-speed USB device number 57 using xhci_hcd [...] This is caused by a high speed device that doesn't successfully go to the enabled state after the second port reset. Instead the connection bounces (connected, with connect status change), bailing out completely from enumeration just to restart from scratch. Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1716332 Cc: Stable <stable@vger.kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-17 16:07:33 +03:00
USB: Refactor hub_port_wait_reset. Refactor hub_port_wait_reset into a small loop to wait for the port reset to be complete, and then a larger block to deal with the final port status. This patch should not change any current behavior. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu>
2012-12-11 10:14:03 -08:00
USB: Add support to store lane count used by USB 3.2 USB 3.2 specification adds Dual-lane support, doubling the maximum SuperSpeedPlus data rate from 10Gbps to 20Gbps. Dual-lane takes into use a second set of rx and tx wires/pins in the Type-C cable and connector. Add "rx_lanes" and "tx_lanes" variables to struct usb_device to store the numer of lanes in use. Number of lanes can be read using the extended port status hub request that was introduced in USB 3.1. Extended port status rx and tx lane count are zero based, maximum lanes supported by non inter-chip (SSIC) USB 3.2 is 2 (dual lane) with rx and tx lane count symmetric. SSIC devices support asymmetric lanes up to 4 lanes per direction. If extended port status is not available then default to one lane. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-04-19 19:05:51 +03:00
usb: core: Track SuperSpeed Plus GenXxY Introduce ssp_rate field to usb_device structure to capture the connected SuperSpeed Plus signaling rate generation and lane count with the corresponding usb_ssp_rate enum. Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/b7805d121e5ae4ad5ae144bd860b6ac04ee47436.1615432770.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-10 19:42:44 -08:00
USB: Add support to store lane count used by USB 3.2 USB 3.2 specification adds Dual-lane support, doubling the maximum SuperSpeedPlus data rate from 10Gbps to 20Gbps. Dual-lane takes into use a second set of rx and tx wires/pins in the Type-C cable and connector. Add "rx_lanes" and "tx_lanes" variables to struct usb_device to store the numer of lanes in use. Number of lanes can be read using the extended port status hub request that was introduced in USB 3.1. Extended port status rx and tx lane count are zero based, maximum lanes supported by non inter-chip (SSIC) USB 3.2 is 2 (dual lane) with rx and tx lane count symmetric. SSIC devices support asymmetric lanes up to 4 lanes per direction. If extended port status is not available then default to one lane. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-04-19 19:05:51 +03:00
usb: core: Track SuperSpeed Plus GenXxY Introduce ssp_rate field to usb_device structure to capture the connected SuperSpeed Plus signaling rate generation and lane count with the corresponding usb_ssp_rate enum. Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/b7805d121e5ae4ad5ae144bd860b6ac04ee47436.1615432770.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-10 19:42:44 -08:00
USB: Add support to store lane count used by USB 3.2 USB 3.2 specification adds Dual-lane support, doubling the maximum SuperSpeedPlus data rate from 10Gbps to 20Gbps. Dual-lane takes into use a second set of rx and tx wires/pins in the Type-C cable and connector. Add "rx_lanes" and "tx_lanes" variables to struct usb_device to store the numer of lanes in use. Number of lanes can be read using the extended port status hub request that was introduced in USB 3.1. Extended port status rx and tx lane count are zero based, maximum lanes supported by non inter-chip (SSIC) USB 3.2 is 2 (dual lane) with rx and tx lane count symmetric. SSIC devices support asymmetric lanes up to 4 lanes per direction. If extended port status is not available then default to one lane. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-04-19 19:05:51 +03:00
USB: Remove remnants of Wireless USB and UWB Wireless USB has long been defunct, and kernel support for it was removed in 2020 by commit caa6772db4c1 ("Staging: remove wusbcore and UWB from the kernel tree."). Nevertheless, some vestiges of the old implementation still clutter up the USB subsystem and one or two other places. Let's get rid of them once and for all. The only parts still left are the user-facing APIs in include/uapi/linux/usb/ch9.h. (There are also a couple of misleading instances, such as the Sierra Wireless USB modem, which is a USB modem made by Sierra Wireless.) Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/b4f2710f-a2de-4fb0-b50f-76776f3a961b@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-08 20:44:18 -04:00
usb: Support USB 3.1 extended port status request usb 3.1 extend the hub get-port-status request by adding different request types. the new request types return 4 additional bytes called extended port status, these bytes are returned after the regular portstatus and portchange values. The extended port status contains a speed ID for the currently used sublink speed. A table of supported Speed IDs with details about the link is provided by the hub in the device descriptor BOS SuperSpeedPlus device capability Sublink Speed Attributes. Support this new request. Ask for the extended port status after port reset if hub supports USB 3.1. If link is running at SuperSpeedPlus set the device speed to USB_SPEED_SUPER_PLUS Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-10 09:59:29 +02:00
USB: Refactor hub_port_wait_reset. Refactor hub_port_wait_reset into a small loop to wait for the port reset to be complete, and then a larger block to deal with the final port status. This patch should not change any current behavior. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu>
2012-12-11 10:14:03 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usbcore: refine warm reset logic Current waiting time for warm(BH) reset in hub_port_warm_reset() is too short for xHC host to complete the warm reset and report a BH reset change. This patch increases the waiting time for warm reset and merges the function into hub_port_reset(), so it can handle both cold reset and warm reset, and factor out hub_port_finish_reset() to make the code looks cleaner. This fixes the issue that driver fails to clear BH reset change and port is "dead". Signed-off-by: Andiry Xu <andiry.xu@amd.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-13 16:41:11 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usbcore: refine warm reset logic Current waiting time for warm(BH) reset in hub_port_warm_reset() is too short for xHC host to complete the warm reset and report a BH reset change. This patch increases the waiting time for warm reset and merges the function into hub_port_reset(), so it can handle both cold reset and warm reset, and factor out hub_port_finish_reset() to make the code looks cleaner. This fixes the issue that driver fails to clear BH reset change and port is "dead". Signed-off-by: Andiry Xu <andiry.xu@amd.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-13 16:41:11 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: Rip out recursive call on warm port reset. When a hot reset fails on a USB 3.0 port, the current port reset code recursively calls hub_port_reset inside hub_port_wait_reset. This isn't ideal, since we should avoid recursive calls in the kernel, and it also doesn't allow us to issue multiple warm resets on reset failures. Rip out the recursive call. Instead, add code to hub_port_reset to issue a warm reset if the hot reset fails, and try multiple warm resets before giving up on the port. In hub_port_wait_reset, remove the recursive call and re-indent. The code is basically the same, except: 1. It bails out early if the port has transitioned to Inactive or Compliance Mode after the reset completed. 2. It doesn't consider a connect status change to be a failed reset. If multiple warm resets needed to be issued, the connect status may have changed, so we need to ignore that and look at the port link state instead. hub_port_reset will now do that. 3. It unconditionally sets udev->speed on all types of successful resets. The old recursive code would set the port speed when the second hub_port_reset returned. The old code did not handle connected devices needing a warm reset well. There were only two situations that the old code handled correctly: an empty port needing a warm reset, and a hot reset that migrated to a warm reset. When an empty port needed a warm reset, hub_port_reset was called with the warm variable set. The code in hub_port_finish_reset would skip telling the USB core and the xHC host that the device was reset, because otherwise that would result in a NULL pointer dereference. When a USB 3.0 device reset migrated to a warm reset, the recursive call made the call stack look like this: hub_port_reset(warm = false) hub_wait_port_reset(warm = false) hub_port_reset(warm = true) hub_wait_port_reset(warm = true) hub_port_finish_reset(warm = true) (return up the call stack to the first wait) hub_port_finish_reset(warm = false) The old code didn't want to notify the USB core or the xHC host of device reset twice, so it only did it in the second call to hub_port_finish_reset, when warm was set to false. This was necessary because before patch two ("USB: Ignore xHCI Reset Device status."), the USB core would pay attention to the xHC Reset Device command error status, and the second call would always fail. Now that we no longer have the recursive call, and warm can change from false to true in hub_port_reset, we need to have hub_port_finish_reset unconditionally notify the USB core and the xHC of the device reset. In hub_port_finish_reset, unconditionally clear the connect status change (CSC) bit for USB 3.0 hubs when the port reset is done. If we had to issue multiple warm resets for a device, that bit may have been set if the device went into SS.Inactive and then was successfully warm reset. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu>
2012-11-01 11:20:44 -07:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
USB: Wait for extra delay time after USB_PORT_FEAT_RESET for quirky hub Devices connected under Terminus Technology Inc. Hub (1a40:0101) may fail to work after the system resumes from suspend: [ 206.063325] usb 3-2.4: reset full-speed USB device number 4 using xhci_hcd [ 206.143691] usb 3-2.4: device descriptor read/64, error -32 [ 206.351671] usb 3-2.4: device descriptor read/64, error -32 Info for this hub: T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=480 MxCh= 4 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1a40 ProdID=0101 Rev=01.11 S: Product=USB 2.0 Hub C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub Some expirements indicate that the USB devices connected to the hub are innocent, it's the hub itself is to blame. The hub needs extra delay time after it resets its port. Hence wait for extra delay, if the device is connected to this quirky hub. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: stable <stable@vger.kernel.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-10-19 16:14:50 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: Don't use EHCI port sempahore for USB 3.0 hubs. The EHCI host controller needs to prevent EHCI initialization when the UHCI or OHCI companion controller is in the middle of a port reset. It uses ehci_cf_port_reset_rwsem to do this. USB 3.0 hubs can't be under an EHCI host controller, so it makes no sense to down the semaphore for USB 3.0 hubs. It also makes the warm port reset code more complex. Don't down ehci_cf_port_reset_rwsem for USB 3.0 hubs. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu>
2012-11-01 11:20:44 -07:00
usbcore: refine warm reset logic Current waiting time for warm(BH) reset in hub_port_warm_reset() is too short for xHC host to complete the warm reset and report a BH reset change. This patch increases the waiting time for warm reset and merges the function into hub_port_reset(), so it can handle both cold reset and warm reset, and factor out hub_port_finish_reset() to make the code looks cleaner. This fixes the issue that driver fails to clear BH reset change and port is "dead". Signed-off-by: Andiry Xu <andiry.xu@amd.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-13 16:41:11 -07:00
USB: Don't use EHCI port sempahore for USB 3.0 hubs. The EHCI host controller needs to prevent EHCI initialization when the UHCI or OHCI companion controller is in the middle of a port reset. It uses ehci_cf_port_reset_rwsem to do this. USB 3.0 hubs can't be under an EHCI host controller, so it makes no sense to down the semaphore for USB 3.0 hubs. It also makes the warm port reset code more complex. Don't down ehci_cf_port_reset_rwsem for USB 3.0 hubs. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu>
2012-11-01 11:20:44 -07:00
USB: Fix connected device switch to Inactive state. A USB 3.0 device can transition to the Inactive state if a U1 or U2 exit transition fails. The current code in hub_events simply issues a warm reset, but does not call any pre-reset or post-reset driver methods (or unbind/rebind drivers without them). Therefore the drivers won't know their device has just been reset. hub_events should instead call usb_reset_device. This means hub_port_reset now needs to figure out whether it should issue a warm reset or a hot reset. Remove the FIXME note about needing disconnect() for a NOTATTACHED device. This patch fixes that. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu>
2012-11-01 11:20:44 -07:00
usb: hub: port: add sysfs entry to switch port power In some cases the port of an hub needs to be disabled or switched off and on again. E.g. when the connected device needs to be re-enumerated. Or it needs to be explicitly disabled while the rest of the usb tree stays working. For this purpose this patch adds an sysfs switch to enable/disable the port on any hub. In the case the hub is supporting power switching, the power line will be disabled to the connected device. When the port gets disabled, the associated device gets disconnected and removed from the logical usb tree. No further device will be enumerated on that port until the port gets enabled again. Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220607114522.3359148-1-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-07 13:45:22 +02:00
usb: core: Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset. Dissolve the function hub_port_finish_reset() completely and divide the actions to be taken into those which need to be done after each reset attempt and those which need to be done after the full procedure is complete, and place them in the appropriate places in hub_port_reset(). Also, remove an unneeded forward declaration of hub_port_reset(). Verbose Problem Description: USB 3.0 devices may be "lost for good" during a hub port reset. This makes Linux unable to boot from USB 3.0 devices in certain constellations of host controllers and devices, because the USB device is lost during initialization, preventing the rootfs from being mounted. The underlying problem is that in the affected constellations, during the processing inside hub_port_reset(), the hub link state goes from 0 to SS.inactive after the initial reset, and back to 0 again only after the following "warm" reset. However, hub_port_finish_reset() is called after each reset attempt and sets the state the connected USB device based on the "preliminary" status of the hot reset to USB_STATE_NOTATTACHED due to SS.inactive, yet when the following warm reset is complete and hub_port_finish_reset() is called again, its call to set the device to USB_STATE_DEFAULT is blocked by usb_set_device_state() which does not allow taking USB devices out of USB_STATE_NOTATTACHED state. Thanks to Alan Stern for guiding me to the proper solution and how to submit it. Link: http://lkml.kernel.org/r/trinity-25981484-72a9-4d46-bf17-9c1cf9301a31-1432073240136%20()%203capp-gmx-bs27 Signed-off-by: Robert Schlabbach <robert_s@gmx.net> Cc: stable <stable@vger.kernel.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-05-26 00:27:30 +02:00
usbcore: refine warm reset logic Current waiting time for warm(BH) reset in hub_port_warm_reset() is too short for xHC host to complete the warm reset and report a BH reset change. This patch increases the waiting time for warm reset and merges the function into hub_port_reset(), so it can handle both cold reset and warm reset, and factor out hub_port_finish_reset() to make the code looks cleaner. This fixes the issue that driver fails to clear BH reset change and port is "dead". Signed-off-by: Andiry Xu <andiry.xu@amd.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-13 16:41:11 -07:00
usb: force warm reset to break link re-connect livelock Resuming a powered down port sometimes results in the port state being stuck in the training sequence. hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0 port1: can't get reconnection after setting port power on, status -110 hub 3-0:1.0: port 1 status 0000.02e0 after resume, -19 usb 3-1: can't resume, status -19 hub 3-0:1.0: logical disconnect on port 1 In the case above we wait for the port re-connect timeout of 2 seconds and observe that the port status is USB_SS_PORT_LS_POLLING (although it is likely toggling between this state and USB_SS_PORT_LS_RX_DETECT). This is indicative of a case where the device is failing to progress the link training state machine. It is resolved by issuing a warm reset to get the hub and device link state machines back in sync. hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0 usb usb3: port1 usb_port_runtime_resume requires warm reset hub 3-0:1.0: port 1 not warm reset yet, waiting 50ms usb 3-1: reset SuperSpeed USB device number 2 using xhci_hcd After a reconnect timeout when we expect the device to be present, force a warm reset of the device. Note that we can not simply look at the link status to determine if a warm reset is required as any of the training states USB_SS_PORT_LS_POLLING, USB_SS_PORT_LS_RX_DETECT, or USB_SS_PORT_LS_COMP_MOD are valid states that do not indicate the need for warm reset by themselves. Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Kukjin Kim <kgene.kim@samsung.com> Cc: Vincent Palatin <vpalatin@chromium.org> Cc: Lan Tianyu <tianyu.lan@intel.com> Cc: Ksenia Ragiadakou <burzalodowa@gmail.com> Cc: Vivek Gautam <gautam.vivek@samsung.com> Cc: Douglas Anderson <dianders@chromium.org> Cc: Felipe Balbi <balbi@ti.com> Cc: Sunil Joshi <joshi@samsung.com> Cc: Hans de Goede <hdegoede@redhat.com> Acked-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-29 12:58:46 -07:00
USB: mutual exclusion for EHCI init and port resets This patch (as999) fixes a problem that sometimes shows up when host controller driver modules are loaded in the wrong order. If ehci-hcd happens to initialize an EHCI controller while the companion OHCI or UHCI controller is in the middle of a port reset, the reset can fail and the companion may get very confused. The patch adds an rw-semaphore and uses it to keep EHCI initialization and port resets mutually exclusive. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: David Brownell <david-b@pacbell.net> Cc: David Miller <davem@davemloft.net> Cc: Dely L Sy <dely.l.sy@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-10-10 16:27:07 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usbcore: refine warm reset logic Current waiting time for warm(BH) reset in hub_port_warm_reset() is too short for xHC host to complete the warm reset and report a BH reset change. This patch increases the waiting time for warm reset and merges the function into hub_port_reset(), so it can handle both cold reset and warm reset, and factor out hub_port_finish_reset() to make the code looks cleaner. This fixes the issue that driver fails to clear BH reset change and port is "dead". Signed-off-by: Andiry Xu <andiry.xu@amd.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-13 16:41:11 -07:00
USB: avoid error messages when a device is disconnected This patch (as1673) reduces the amount of log spew from the hub driver by removing a bunch of error messages in the case where the device in question is already known to have been disconnected. Since the disconnect event itself appears in the log, there's no need for other error messages. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Jenya Y <jy.gerstmaier@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-27 16:14:01 -04:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
usbcore: refine warm reset logic Current waiting time for warm(BH) reset in hub_port_warm_reset() is too short for xHC host to complete the warm reset and report a BH reset change. This patch increases the waiting time for warm reset and merges the function into hub_port_reset(), so it can handle both cold reset and warm reset, and factor out hub_port_finish_reset() to make the code looks cleaner. This fixes the issue that driver fails to clear BH reset change and port is "dead". Signed-off-by: Andiry Xu <andiry.xu@amd.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-13 16:41:11 -07:00
USB: avoid error messages when a device is disconnected This patch (as1673) reduces the amount of log spew from the hub driver by removing a bunch of error messages in the case where the device in question is already known to have been disconnected. Since the disconnect event itself appears in the log, there's no need for other error messages. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Jenya Y <jy.gerstmaier@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-27 16:14:01 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: Bail out when port is stuck in reset loop Unplugging USB device may cause an incorrect warm reset loop and the port can no longer be used: [ 143.039019] xhci_hcd 0000:00:14.0: Port change event, 2-3, id 19, portsc: 0x4202c0 [ 143.039025] xhci_hcd 0000:00:14.0: handle_port_status: starting usb2 port polling. [ 143.039051] hub 2-0:1.0: state 7 ports 10 chg 0000 evt 0008 [ 143.039058] xhci_hcd 0000:00:14.0: Get port status 2-3 read: 0x4202c0, return 0x4102c0 [ 143.039092] xhci_hcd 0000:00:14.0: clear port3 connect change, portsc: 0x4002c0 [ 143.039096] usb usb2-port3: link state change [ 143.039099] xhci_hcd 0000:00:14.0: clear port3 link state change, portsc: 0x2c0 [ 143.039101] usb usb2-port3: do warm reset [ 143.096736] xhci_hcd 0000:00:14.0: Get port status 2-3 read: 0x2b0, return 0x2b0 [ 143.096751] usb usb2-port3: not warm reset yet, waiting 50ms [ 143.131500] xhci_hcd 0000:00:14.0: Can't queue urb, port error, link inactive [ 143.138260] xhci_hcd 0000:00:14.0: Port change event, 2-3, id 19, portsc: 0x2802a0 [ 143.138263] xhci_hcd 0000:00:14.0: handle_port_status: starting usb2 port polling. [ 143.160756] xhci_hcd 0000:00:14.0: Get port status 2-3 read: 0x2802a0, return 0x3002a0 [ 143.160798] usb usb2-port3: not warm reset yet, waiting 200ms The port status is PP=1, CCS=0, PED=0, PLS=Inactive, which is Error state per "USB3 Root Hub Port State Machine". It's reasonable to perform warm reset several times, but if the port is still not enabled after many attempts, consider it's gone and treat it as disconnected. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Link: https://lore.kernel.org/r/20220120070518.1643873-1-kai.heng.feng@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-20 15:05:16 +08:00
usb: core: Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset. Dissolve the function hub_port_finish_reset() completely and divide the actions to be taken into those which need to be done after each reset attempt and those which need to be done after the full procedure is complete, and place them in the appropriate places in hub_port_reset(). Also, remove an unneeded forward declaration of hub_port_reset(). Verbose Problem Description: USB 3.0 devices may be "lost for good" during a hub port reset. This makes Linux unable to boot from USB 3.0 devices in certain constellations of host controllers and devices, because the USB device is lost during initialization, preventing the rootfs from being mounted. The underlying problem is that in the affected constellations, during the processing inside hub_port_reset(), the hub link state goes from 0 to SS.inactive after the initial reset, and back to 0 again only after the following "warm" reset. However, hub_port_finish_reset() is called after each reset attempt and sets the state the connected USB device based on the "preliminary" status of the hot reset to USB_STATE_NOTATTACHED due to SS.inactive, yet when the following warm reset is complete and hub_port_finish_reset() is called again, its call to set the device to USB_STATE_DEFAULT is blocked by usb_set_device_state() which does not allow taking USB devices out of USB_STATE_NOTATTACHED state. Thanks to Alan Stern for guiding me to the proper solution and how to submit it. Link: http://lkml.kernel.org/r/trinity-25981484-72a9-4d46-bf17-9c1cf9301a31-1432073240136%20()%203capp-gmx-bs27 Signed-off-by: Robert Schlabbach <robert_s@gmx.net> Cc: stable <stable@vger.kernel.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-05-26 00:27:30 +02:00
USB: Rip out recursive call on warm port reset. When a hot reset fails on a USB 3.0 port, the current port reset code recursively calls hub_port_reset inside hub_port_wait_reset. This isn't ideal, since we should avoid recursive calls in the kernel, and it also doesn't allow us to issue multiple warm resets on reset failures. Rip out the recursive call. Instead, add code to hub_port_reset to issue a warm reset if the hot reset fails, and try multiple warm resets before giving up on the port. In hub_port_wait_reset, remove the recursive call and re-indent. The code is basically the same, except: 1. It bails out early if the port has transitioned to Inactive or Compliance Mode after the reset completed. 2. It doesn't consider a connect status change to be a failed reset. If multiple warm resets needed to be issued, the connect status may have changed, so we need to ignore that and look at the port link state instead. hub_port_reset will now do that. 3. It unconditionally sets udev->speed on all types of successful resets. The old recursive code would set the port speed when the second hub_port_reset returned. The old code did not handle connected devices needing a warm reset well. There were only two situations that the old code handled correctly: an empty port needing a warm reset, and a hot reset that migrated to a warm reset. When an empty port needed a warm reset, hub_port_reset was called with the warm variable set. The code in hub_port_finish_reset would skip telling the USB core and the xHC host that the device was reset, because otherwise that would result in a NULL pointer dereference. When a USB 3.0 device reset migrated to a warm reset, the recursive call made the call stack look like this: hub_port_reset(warm = false) hub_wait_port_reset(warm = false) hub_port_reset(warm = true) hub_wait_port_reset(warm = true) hub_port_finish_reset(warm = true) (return up the call stack to the first wait) hub_port_finish_reset(warm = false) The old code didn't want to notify the USB core or the xHC host of device reset twice, so it only did it in the second call to hub_port_finish_reset, when warm was set to false. This was necessary because before patch two ("USB: Ignore xHCI Reset Device status."), the USB core would pay attention to the xHC Reset Device command error status, and the second call would always fail. Now that we no longer have the recursive call, and warm can change from false to true in hub_port_reset, we need to have hub_port_finish_reset unconditionally notify the USB core and the xHC of the device reset. In hub_port_finish_reset, unconditionally clear the connect status change (CSC) bit for USB 3.0 hubs when the port reset is done. If we had to issue multiple warm resets for a device, that bit may have been set if the device went into SS.Inactive and then was successfully warm reset. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu>
2012-11-01 11:20:44 -07:00
usb: core: Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset. Dissolve the function hub_port_finish_reset() completely and divide the actions to be taken into those which need to be done after each reset attempt and those which need to be done after the full procedure is complete, and place them in the appropriate places in hub_port_reset(). Also, remove an unneeded forward declaration of hub_port_reset(). Verbose Problem Description: USB 3.0 devices may be "lost for good" during a hub port reset. This makes Linux unable to boot from USB 3.0 devices in certain constellations of host controllers and devices, because the USB device is lost during initialization, preventing the rootfs from being mounted. The underlying problem is that in the affected constellations, during the processing inside hub_port_reset(), the hub link state goes from 0 to SS.inactive after the initial reset, and back to 0 again only after the following "warm" reset. However, hub_port_finish_reset() is called after each reset attempt and sets the state the connected USB device based on the "preliminary" status of the hot reset to USB_STATE_NOTATTACHED due to SS.inactive, yet when the following warm reset is complete and hub_port_finish_reset() is called again, its call to set the device to USB_STATE_DEFAULT is blocked by usb_set_device_state() which does not allow taking USB devices out of USB_STATE_NOTATTACHED state. Thanks to Alan Stern for guiding me to the proper solution and how to submit it. Link: http://lkml.kernel.org/r/trinity-25981484-72a9-4d46-bf17-9c1cf9301a31-1432073240136%20()%203capp-gmx-bs27 Signed-off-by: Robert Schlabbach <robert_s@gmx.net> Cc: stable <stable@vger.kernel.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-05-26 00:27:30 +02:00
usb: core: Fix hub port connection events lost This will clear the USB_PORT_FEAT_C_CONNECTION bit in case of a hub port reset only if a device is was attached to the hub port before resetting the hub port. Using a Lenovo T480s attached to the ultra dock it was not possible to detect some usb-c devices at the dock usb-c ports because the hub_port_reset code will clear the USB_PORT_FEAT_C_CONNECTION bit after the actual hub port reset. Using this device combo the USB_PORT_FEAT_C_CONNECTION bit was set between the actual hub port reset and the clear of the USB_PORT_FEAT_C_CONNECTION bit. This ends up with clearing the USB_PORT_FEAT_C_CONNECTION bit after the new device was attached such that it was not detected. This patch will not clear the USB_PORT_FEAT_C_CONNECTION bit if there is currently no device attached to the port before the hub port reset. This will avoid clearing the connection bit for new attached devices. Signed-off-by: Dennis Wassenberg <dennis.wassenberg@secunet.com> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-11-13 14:40:34 +01:00
usb: core: Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset. Dissolve the function hub_port_finish_reset() completely and divide the actions to be taken into those which need to be done after each reset attempt and those which need to be done after the full procedure is complete, and place them in the appropriate places in hub_port_reset(). Also, remove an unneeded forward declaration of hub_port_reset(). Verbose Problem Description: USB 3.0 devices may be "lost for good" during a hub port reset. This makes Linux unable to boot from USB 3.0 devices in certain constellations of host controllers and devices, because the USB device is lost during initialization, preventing the rootfs from being mounted. The underlying problem is that in the affected constellations, during the processing inside hub_port_reset(), the hub link state goes from 0 to SS.inactive after the initial reset, and back to 0 again only after the following "warm" reset. However, hub_port_finish_reset() is called after each reset attempt and sets the state the connected USB device based on the "preliminary" status of the hot reset to USB_STATE_NOTATTACHED due to SS.inactive, yet when the following warm reset is complete and hub_port_finish_reset() is called again, its call to set the device to USB_STATE_DEFAULT is blocked by usb_set_device_state() which does not allow taking USB devices out of USB_STATE_NOTATTACHED state. Thanks to Alan Stern for guiding me to the proper solution and how to submit it. Link: http://lkml.kernel.org/r/trinity-25981484-72a9-4d46-bf17-9c1cf9301a31-1432073240136%20()%203capp-gmx-bs27 Signed-off-by: Robert Schlabbach <robert_s@gmx.net> Cc: stable <stable@vger.kernel.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-05-26 00:27:30 +02:00
USB: Rip out recursive call on warm port reset. When a hot reset fails on a USB 3.0 port, the current port reset code recursively calls hub_port_reset inside hub_port_wait_reset. This isn't ideal, since we should avoid recursive calls in the kernel, and it also doesn't allow us to issue multiple warm resets on reset failures. Rip out the recursive call. Instead, add code to hub_port_reset to issue a warm reset if the hot reset fails, and try multiple warm resets before giving up on the port. In hub_port_wait_reset, remove the recursive call and re-indent. The code is basically the same, except: 1. It bails out early if the port has transitioned to Inactive or Compliance Mode after the reset completed. 2. It doesn't consider a connect status change to be a failed reset. If multiple warm resets needed to be issued, the connect status may have changed, so we need to ignore that and look at the port link state instead. hub_port_reset will now do that. 3. It unconditionally sets udev->speed on all types of successful resets. The old recursive code would set the port speed when the second hub_port_reset returned. The old code did not handle connected devices needing a warm reset well. There were only two situations that the old code handled correctly: an empty port needing a warm reset, and a hot reset that migrated to a warm reset. When an empty port needed a warm reset, hub_port_reset was called with the warm variable set. The code in hub_port_finish_reset would skip telling the USB core and the xHC host that the device was reset, because otherwise that would result in a NULL pointer dereference. When a USB 3.0 device reset migrated to a warm reset, the recursive call made the call stack look like this: hub_port_reset(warm = false) hub_wait_port_reset(warm = false) hub_port_reset(warm = true) hub_wait_port_reset(warm = true) hub_port_finish_reset(warm = true) (return up the call stack to the first wait) hub_port_finish_reset(warm = false) The old code didn't want to notify the USB core or the xHC host of device reset twice, so it only did it in the second call to hub_port_finish_reset, when warm was set to false. This was necessary because before patch two ("USB: Ignore xHCI Reset Device status."), the USB core would pay attention to the xHC Reset Device command error status, and the second call would always fail. Now that we no longer have the recursive call, and warm can change from false to true in hub_port_reset, we need to have hub_port_finish_reset unconditionally notify the USB core and the xHC of the device reset. In hub_port_finish_reset, unconditionally clear the connect status change (CSC) bit for USB 3.0 hubs when the port reset is done. If we had to issue multiple warm resets for a device, that bit may have been set if the device went into SS.Inactive and then was successfully warm reset. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu>
2012-11-01 11:20:44 -07:00
usb: hub: port: add sysfs entry to switch port power In some cases the port of an hub needs to be disabled or switched off and on again. E.g. when the connected device needs to be re-enumerated. Or it needs to be explicitly disabled while the rest of the usb tree stays working. For this purpose this patch adds an sysfs switch to enable/disable the port on any hub. In the case the hub is supporting power switching, the power line will be disabled to the connected device. When the port gets disabled, the associated device gets disconnected and removed from the logical usb tree. No further device will be enumerated on that port until the port gets enabled again. Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220607114522.3359148-1-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-07 13:45:22 +02:00
USB: Rip out recursive call on warm port reset. When a hot reset fails on a USB 3.0 port, the current port reset code recursively calls hub_port_reset inside hub_port_wait_reset. This isn't ideal, since we should avoid recursive calls in the kernel, and it also doesn't allow us to issue multiple warm resets on reset failures. Rip out the recursive call. Instead, add code to hub_port_reset to issue a warm reset if the hot reset fails, and try multiple warm resets before giving up on the port. In hub_port_wait_reset, remove the recursive call and re-indent. The code is basically the same, except: 1. It bails out early if the port has transitioned to Inactive or Compliance Mode after the reset completed. 2. It doesn't consider a connect status change to be a failed reset. If multiple warm resets needed to be issued, the connect status may have changed, so we need to ignore that and look at the port link state instead. hub_port_reset will now do that. 3. It unconditionally sets udev->speed on all types of successful resets. The old recursive code would set the port speed when the second hub_port_reset returned. The old code did not handle connected devices needing a warm reset well. There were only two situations that the old code handled correctly: an empty port needing a warm reset, and a hot reset that migrated to a warm reset. When an empty port needed a warm reset, hub_port_reset was called with the warm variable set. The code in hub_port_finish_reset would skip telling the USB core and the xHC host that the device was reset, because otherwise that would result in a NULL pointer dereference. When a USB 3.0 device reset migrated to a warm reset, the recursive call made the call stack look like this: hub_port_reset(warm = false) hub_wait_port_reset(warm = false) hub_port_reset(warm = true) hub_wait_port_reset(warm = true) hub_port_finish_reset(warm = true) (return up the call stack to the first wait) hub_port_finish_reset(warm = false) The old code didn't want to notify the USB core or the xHC host of device reset twice, so it only did it in the second call to hub_port_finish_reset, when warm was set to false. This was necessary because before patch two ("USB: Ignore xHCI Reset Device status."), the USB core would pay attention to the xHC Reset Device command error status, and the second call would always fail. Now that we no longer have the recursive call, and warm can change from false to true in hub_port_reset, we need to have hub_port_finish_reset unconditionally notify the USB core and the xHC of the device reset. In hub_port_finish_reset, unconditionally clear the connect status change (CSC) bit for USB 3.0 hubs when the port reset is done. If we had to issue multiple warm resets for a device, that bit may have been set if the device went into SS.Inactive and then was successfully warm reset. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu>
2012-11-01 11:20:44 -07:00
usb: force warm reset to break link re-connect livelock Resuming a powered down port sometimes results in the port state being stuck in the training sequence. hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0 port1: can't get reconnection after setting port power on, status -110 hub 3-0:1.0: port 1 status 0000.02e0 after resume, -19 usb 3-1: can't resume, status -19 hub 3-0:1.0: logical disconnect on port 1 In the case above we wait for the port re-connect timeout of 2 seconds and observe that the port status is USB_SS_PORT_LS_POLLING (although it is likely toggling between this state and USB_SS_PORT_LS_RX_DETECT). This is indicative of a case where the device is failing to progress the link training state machine. It is resolved by issuing a warm reset to get the hub and device link state machines back in sync. hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0 usb usb3: port1 usb_port_runtime_resume requires warm reset hub 3-0:1.0: port 1 not warm reset yet, waiting 50ms usb 3-1: reset SuperSpeed USB device number 2 using xhci_hcd After a reconnect timeout when we expect the device to be present, force a warm reset of the device. Note that we can not simply look at the link status to determine if a warm reset is required as any of the training states USB_SS_PORT_LS_POLLING, USB_SS_PORT_LS_RX_DETECT, or USB_SS_PORT_LS_COMP_MOD are valid states that do not indicate the need for warm reset by themselves. Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Kukjin Kim <kgene.kim@samsung.com> Cc: Vincent Palatin <vpalatin@chromium.org> Cc: Lan Tianyu <tianyu.lan@intel.com> Cc: Ksenia Ragiadakou <burzalodowa@gmail.com> Cc: Vivek Gautam <gautam.vivek@samsung.com> Cc: Douglas Anderson <dianders@chromium.org> Cc: Felipe Balbi <balbi@ti.com> Cc: Sunil Joshi <joshi@samsung.com> Cc: Hans de Goede <hdegoede@redhat.com> Acked-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-29 12:58:46 -07:00
USB: Rip out recursive call on warm port reset. When a hot reset fails on a USB 3.0 port, the current port reset code recursively calls hub_port_reset inside hub_port_wait_reset. This isn't ideal, since we should avoid recursive calls in the kernel, and it also doesn't allow us to issue multiple warm resets on reset failures. Rip out the recursive call. Instead, add code to hub_port_reset to issue a warm reset if the hot reset fails, and try multiple warm resets before giving up on the port. In hub_port_wait_reset, remove the recursive call and re-indent. The code is basically the same, except: 1. It bails out early if the port has transitioned to Inactive or Compliance Mode after the reset completed. 2. It doesn't consider a connect status change to be a failed reset. If multiple warm resets needed to be issued, the connect status may have changed, so we need to ignore that and look at the port link state instead. hub_port_reset will now do that. 3. It unconditionally sets udev->speed on all types of successful resets. The old recursive code would set the port speed when the second hub_port_reset returned. The old code did not handle connected devices needing a warm reset well. There were only two situations that the old code handled correctly: an empty port needing a warm reset, and a hot reset that migrated to a warm reset. When an empty port needed a warm reset, hub_port_reset was called with the warm variable set. The code in hub_port_finish_reset would skip telling the USB core and the xHC host that the device was reset, because otherwise that would result in a NULL pointer dereference. When a USB 3.0 device reset migrated to a warm reset, the recursive call made the call stack look like this: hub_port_reset(warm = false) hub_wait_port_reset(warm = false) hub_port_reset(warm = true) hub_wait_port_reset(warm = true) hub_port_finish_reset(warm = true) (return up the call stack to the first wait) hub_port_finish_reset(warm = false) The old code didn't want to notify the USB core or the xHC host of device reset twice, so it only did it in the second call to hub_port_finish_reset, when warm was set to false. This was necessary because before patch two ("USB: Ignore xHCI Reset Device status."), the USB core would pay attention to the xHC Reset Device command error status, and the second call would always fail. Now that we no longer have the recursive call, and warm can change from false to true in hub_port_reset, we need to have hub_port_finish_reset unconditionally notify the USB core and the xHC of the device reset. In hub_port_finish_reset, unconditionally clear the connect status change (CSC) bit for USB 3.0 hubs when the port reset is done. If we had to issue multiple warm resets for a device, that bit may have been set if the device went into SS.Inactive and then was successfully warm reset. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu>
2012-11-01 11:20:44 -07:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
USB: Rip out recursive call on warm port reset. When a hot reset fails on a USB 3.0 port, the current port reset code recursively calls hub_port_reset inside hub_port_wait_reset. This isn't ideal, since we should avoid recursive calls in the kernel, and it also doesn't allow us to issue multiple warm resets on reset failures. Rip out the recursive call. Instead, add code to hub_port_reset to issue a warm reset if the hot reset fails, and try multiple warm resets before giving up on the port. In hub_port_wait_reset, remove the recursive call and re-indent. The code is basically the same, except: 1. It bails out early if the port has transitioned to Inactive or Compliance Mode after the reset completed. 2. It doesn't consider a connect status change to be a failed reset. If multiple warm resets needed to be issued, the connect status may have changed, so we need to ignore that and look at the port link state instead. hub_port_reset will now do that. 3. It unconditionally sets udev->speed on all types of successful resets. The old recursive code would set the port speed when the second hub_port_reset returned. The old code did not handle connected devices needing a warm reset well. There were only two situations that the old code handled correctly: an empty port needing a warm reset, and a hot reset that migrated to a warm reset. When an empty port needed a warm reset, hub_port_reset was called with the warm variable set. The code in hub_port_finish_reset would skip telling the USB core and the xHC host that the device was reset, because otherwise that would result in a NULL pointer dereference. When a USB 3.0 device reset migrated to a warm reset, the recursive call made the call stack look like this: hub_port_reset(warm = false) hub_wait_port_reset(warm = false) hub_port_reset(warm = true) hub_wait_port_reset(warm = true) hub_port_finish_reset(warm = true) (return up the call stack to the first wait) hub_port_finish_reset(warm = false) The old code didn't want to notify the USB core or the xHC host of device reset twice, so it only did it in the second call to hub_port_finish_reset, when warm was set to false. This was necessary because before patch two ("USB: Ignore xHCI Reset Device status."), the USB core would pay attention to the xHC Reset Device command error status, and the second call would always fail. Now that we no longer have the recursive call, and warm can change from false to true in hub_port_reset, we need to have hub_port_finish_reset unconditionally notify the USB core and the xHC of the device reset. In hub_port_finish_reset, unconditionally clear the connect status change (CSC) bit for USB 3.0 hubs when the port reset is done. If we had to issue multiple warm resets for a device, that bit may have been set if the device went into SS.Inactive and then was successfully warm reset. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu>
2012-11-01 11:20:44 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usbcore: refine warm reset logic Current waiting time for warm(BH) reset in hub_port_warm_reset() is too short for xHC host to complete the warm reset and report a BH reset change. This patch increases the waiting time for warm reset and merges the function into hub_port_reset(), so it can handle both cold reset and warm reset, and factor out hub_port_finish_reset() to make the code looks cleaner. This fixes the issue that driver fails to clear BH reset change and port is "dead". Signed-off-by: Andiry Xu <andiry.xu@amd.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-13 16:41:11 -07:00
usb: core: Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset. Dissolve the function hub_port_finish_reset() completely and divide the actions to be taken into those which need to be done after each reset attempt and those which need to be done after the full procedure is complete, and place them in the appropriate places in hub_port_reset(). Also, remove an unneeded forward declaration of hub_port_reset(). Verbose Problem Description: USB 3.0 devices may be "lost for good" during a hub port reset. This makes Linux unable to boot from USB 3.0 devices in certain constellations of host controllers and devices, because the USB device is lost during initialization, preventing the rootfs from being mounted. The underlying problem is that in the affected constellations, during the processing inside hub_port_reset(), the hub link state goes from 0 to SS.inactive after the initial reset, and back to 0 again only after the following "warm" reset. However, hub_port_finish_reset() is called after each reset attempt and sets the state the connected USB device based on the "preliminary" status of the hot reset to USB_STATE_NOTATTACHED due to SS.inactive, yet when the following warm reset is complete and hub_port_finish_reset() is called again, its call to set the device to USB_STATE_DEFAULT is blocked by usb_set_device_state() which does not allow taking USB devices out of USB_STATE_NOTATTACHED state. Thanks to Alan Stern for guiding me to the proper solution and how to submit it. Link: http://lkml.kernel.org/r/trinity-25981484-72a9-4d46-bf17-9c1cf9301a31-1432073240136%20()%203capp-gmx-bs27 Signed-off-by: Robert Schlabbach <robert_s@gmx.net> Cc: stable <stable@vger.kernel.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-05-26 00:27:30 +02:00
usb: hub: Per-port setting to reduce TRSTRCY to 10 ms Currently, the USB hub core waits for 50 ms after enumerating the device. This was added to help "some high speed devices" to enumerate (b789696af8 "[PATCH] USB: relax usbcore reset timings"). On some devices, the time-to-active is important, so we provide a per-port option to reduce the time to what the USB specification requires: 10 ms. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-28 14:32:19 +08:00
USB: Wait for extra delay time after USB_PORT_FEAT_RESET for quirky hub Devices connected under Terminus Technology Inc. Hub (1a40:0101) may fail to work after the system resumes from suspend: [ 206.063325] usb 3-2.4: reset full-speed USB device number 4 using xhci_hcd [ 206.143691] usb 3-2.4: device descriptor read/64, error -32 [ 206.351671] usb 3-2.4: device descriptor read/64, error -32 Info for this hub: T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=480 MxCh= 4 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1a40 ProdID=0101 Rev=01.11 S: Product=USB 2.0 Hub C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub Some expirements indicate that the USB devices connected to the hub are innocent, it's the hub itself is to blame. The hub needs extra delay time after it resets its port. Hence wait for extra delay, if the device is connected to this quirky hub. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: stable <stable@vger.kernel.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-10-19 16:14:50 +08:00
usb: hub: Per-port setting to reduce TRSTRCY to 10 ms Currently, the USB hub core waits for 50 ms after enumerating the device. This was added to help "some high speed devices" to enumerate (b789696af8 "[PATCH] USB: relax usbcore reset timings"). On some devices, the time-to-active is important, so we provide a per-port option to reduce the time to what the USB specification requires: 10 ms. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-28 14:32:19 +08:00
usb: core: Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset. Dissolve the function hub_port_finish_reset() completely and divide the actions to be taken into those which need to be done after each reset attempt and those which need to be done after the full procedure is complete, and place them in the appropriate places in hub_port_reset(). Also, remove an unneeded forward declaration of hub_port_reset(). Verbose Problem Description: USB 3.0 devices may be "lost for good" during a hub port reset. This makes Linux unable to boot from USB 3.0 devices in certain constellations of host controllers and devices, because the USB device is lost during initialization, preventing the rootfs from being mounted. The underlying problem is that in the affected constellations, during the processing inside hub_port_reset(), the hub link state goes from 0 to SS.inactive after the initial reset, and back to 0 again only after the following "warm" reset. However, hub_port_finish_reset() is called after each reset attempt and sets the state the connected USB device based on the "preliminary" status of the hot reset to USB_STATE_NOTATTACHED due to SS.inactive, yet when the following warm reset is complete and hub_port_finish_reset() is called again, its call to set the device to USB_STATE_DEFAULT is blocked by usb_set_device_state() which does not allow taking USB devices out of USB_STATE_NOTATTACHED state. Thanks to Alan Stern for guiding me to the proper solution and how to submit it. Link: http://lkml.kernel.org/r/trinity-25981484-72a9-4d46-bf17-9c1cf9301a31-1432073240136%20()%203capp-gmx-bs27 Signed-off-by: Robert Schlabbach <robert_s@gmx.net> Cc: stable <stable@vger.kernel.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-05-26 00:27:30 +02:00
USB: Don't use EHCI port sempahore for USB 3.0 hubs. The EHCI host controller needs to prevent EHCI initialization when the UHCI or OHCI companion controller is in the middle of a port reset. It uses ehci_cf_port_reset_rwsem to do this. USB 3.0 hubs can't be under an EHCI host controller, so it makes no sense to down the semaphore for USB 3.0 hubs. It also makes the warm port reset code more complex. Don't down ehci_cf_port_reset_rwsem for USB 3.0 hubs. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu>
2012-11-01 11:20:44 -07:00
usbcore: refine warm reset logic Current waiting time for warm(BH) reset in hub_port_warm_reset() is too short for xHC host to complete the warm reset and report a BH reset change. This patch increases the waiting time for warm reset and merges the function into hub_port_reset(), so it can handle both cold reset and warm reset, and factor out hub_port_finish_reset() to make the code looks cleaner. This fixes the issue that driver fails to clear BH reset change and port is "dead". Signed-off-by: Andiry Xu <andiry.xu@amd.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-13 16:41:11 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: stop USB enumeration if too many retries When a broken USB accessory connects to a USB host, usbcore might keep doing enumeration retries. If the host has a watchdog mechanism, the kernel panic will happen on the host. This patch provides an attribute early_stop to limit the numbers of retries for each port of a hub. If a port was marked with early_stop attribute, unsuccessful connection attempts will fail quickly. In addition, if an early_stop port has failed to initialize, it will ignore all future connection events until early_stop attribute is clear. Signed-off-by: Ray Chi <raychi@google.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20221107072754.3336357-1-raychi@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-11-07 15:27:54 +08:00
xHCI: report USB3.0 portstatus comply with USB3.0 specification USB3.0 specification has different wPortStatus and wPortChange definitions from USB2.0 specification. Since USB3 root hub and USB2 root hub are split now and USB3 hub only has USB3 protocol ports, we should modify the portstatus and portchange report of USB3 ports to comply with USB3.0 specification. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-04-27 18:07:43 +08:00
usb: hub: port: add sysfs entry to switch port power In some cases the port of an hub needs to be disabled or switched off and on again. E.g. when the connected device needs to be re-enumerated. Or it needs to be explicitly disabled while the rest of the usb tree stays working. For this purpose this patch adds an sysfs switch to enable/disable the port on any hub. In the case the hub is supporting power switching, the power line will be disabled to the connected device. When the port gets disabled, the associated device gets disconnected and removed from the logical usb tree. No further device will be enumerated on that port until the port gets enabled again. Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220607114522.3359148-1-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-07 13:45:22 +02:00
xHCI: report USB3.0 portstatus comply with USB3.0 specification USB3.0 specification has different wPortStatus and wPortChange definitions from USB2.0 specification. Since USB3 root hub and USB2 root hub are split now and USB3 hub only has USB3 protocol ports, we should modify the portstatus and portchange report of USB3 ports to comply with USB3.0 specification. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-04-27 18:07:43 +08:00
usb: introduce port status lock In general we do not want khubd to act on port status changes that are the result of in progress resets or USB runtime PM operations. Specifically port power control testing has been able to trigger an unintended disconnect in hub_port_connect_change(), paraphrasing: if ((portstatus & USB_PORT_STAT_CONNECTION) && udev && udev->state != USB_STATE_NOTATTACHED) { if (portstatus & USB_PORT_STAT_ENABLE) { /* Nothing to do */ } else if (udev->state == USB_STATE_SUSPENDED && udev->persist_enabled) { ... } else { /* Don't resuscitate */; } } ...by falling to the "Don't resuscitate" path or missing USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of modifying the port status. So, we want a new lock to hold off khubd for a given port while the child device is being suspended, resumed, or reset. The lock ordering rules are now usb_lock_device() => usb_lock_port(). This is mandated by the device core which may hold the device_lock on the usb_device before invoking usb_port_{suspend|resume} which in turn take the status_lock on the usb_port. We attempt to hold the status_lock for the duration of a port_event() run, and drop/re-acquire it when needing to take the device_lock. The lock is also dropped/re-acquired during hub_port_reconnect(). This patch also deletes hub->busy_bits as all use cases are now covered by port PM runtime synchronization or the port->status_lock and it pushes down usb_device_lock() into usb_remote_wakeup(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:26 -07:00
hub driver: improve use of #ifdef This patch (as736) makes the hub driver more readable by improving the usage of "#ifdef CONFIG_PM" and "#ifdef CONFIG_USB_SUSPEND". Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-07-01 22:14:24 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
xHCI: report USB3.0 portstatus comply with USB3.0 specification USB3.0 specification has different wPortStatus and wPortChange definitions from USB2.0 specification. Since USB3 root hub and USB2 root hub are split now and USB3 hub only has USB3 protocol ports, we should modify the portstatus and portchange report of USB3 ports to comply with USB3.0 specification. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-04-27 18:07:43 +08:00
USB: add new routine for checking port-resume type This patch (as1070) creates a new subroutine to check whether a device can be resumed. This code is needed even when CONFIG_USB_SUSPEND isn't set, because devices do suspend themselves when the root hub (and hence the entire bus) is suspended, and power sessions can get lost during a system sleep even without individual port suspends. The patch also fixes a loose end in USB-Persist reset-resume handling. When a low- or full-speed device is attached to an EHCI's companion controller, the port handoff during resume will cause the companion port's connect-status-change feature to be set. If that flag isn't cleared, the port-reset code will think it indicates that the device has been unplugged and the reset-resume will fail. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:11 -04:00
usb: Retry port status check on resume to work around RH bugs The EHCI controller on the RK3288 SoC is violating basic parts of the USB spec and thereby unable to properly resume a suspended port. It does not start SOF generation within 3ms of finishing resume signaling, so the attached device will drop of the bus again. This is a particular problem with runtime PM, where accessing the device will trigger a resume that immediately makes it unavailable (and reenumerate with a new handle). Thankfully, the persist feature is generally able to work around stuff like that. Unfortunately, it doesn't quite work in this particular case because the controller will turn off the CurrentConnectStatus bit for an instant while the device is reconnecting, which causes the kernel to conclude that it permanently disappeared. This patch adds a tiny retry mechanism to the core port resume code which will catch this case and shouldn't have any notable impact on other controllers. 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>
2015-01-27 13:20:12 -08:00
USB: add new routine for checking port-resume type This patch (as1070) creates a new subroutine to check whether a device can be resumed. This code is needed even when CONFIG_USB_SUSPEND isn't set, because devices do suspend themselves when the root hub (and hence the entire bus) is suspended, and power sessions can get lost during a system sleep even without individual port suspends. The patch also fixes a loose end in USB-Persist reset-resume handling. When a low- or full-speed device is attached to an EHCI's companion controller, the port handoff during resume will cause the companion port's connect-status-change feature to be set. If that flag isn't cleared, the port-reset code will think it indicates that the device has been unplugged and the reset-resume will fail. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:11 -04:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
usb: Retry port status check on resume to work around RH bugs The EHCI controller on the RK3288 SoC is violating basic parts of the USB spec and thereby unable to properly resume a suspended port. It does not start SOF generation within 3ms of finishing resume signaling, so the attached device will drop of the bus again. This is a particular problem with runtime PM, where accessing the device will trigger a resume that immediately makes it unavailable (and reenumerate with a new handle). Thankfully, the persist feature is generally able to work around stuff like that. Unfortunately, it doesn't quite work in this particular case because the controller will turn off the CurrentConnectStatus bit for an instant while the device is reconnecting, which causes the kernel to conclude that it permanently disappeared. This patch adds a tiny retry mechanism to the core port resume code which will catch this case and shouldn't have any notable impact on other controllers. 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>
2015-01-27 13:20:12 -08:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
usb: Retry port status check on resume to work around RH bugs The EHCI controller on the RK3288 SoC is violating basic parts of the USB spec and thereby unable to properly resume a suspended port. It does not start SOF generation within 3ms of finishing resume signaling, so the attached device will drop of the bus again. This is a particular problem with runtime PM, where accessing the device will trigger a resume that immediately makes it unavailable (and reenumerate with a new handle). Thankfully, the persist feature is generally able to work around stuff like that. Unfortunately, it doesn't quite work in this particular case because the controller will turn off the CurrentConnectStatus bit for an instant while the device is reconnecting, which causes the kernel to conclude that it permanently disappeared. This patch adds a tiny retry mechanism to the core port resume code which will catch this case and shouldn't have any notable impact on other controllers. 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>
2015-01-27 13:20:12 -08:00
usb: force warm reset to break link re-connect livelock Resuming a powered down port sometimes results in the port state being stuck in the training sequence. hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0 port1: can't get reconnection after setting port power on, status -110 hub 3-0:1.0: port 1 status 0000.02e0 after resume, -19 usb 3-1: can't resume, status -19 hub 3-0:1.0: logical disconnect on port 1 In the case above we wait for the port re-connect timeout of 2 seconds and observe that the port status is USB_SS_PORT_LS_POLLING (although it is likely toggling between this state and USB_SS_PORT_LS_RX_DETECT). This is indicative of a case where the device is failing to progress the link training state machine. It is resolved by issuing a warm reset to get the hub and device link state machines back in sync. hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0 usb usb3: port1 usb_port_runtime_resume requires warm reset hub 3-0:1.0: port 1 not warm reset yet, waiting 50ms usb 3-1: reset SuperSpeed USB device number 2 using xhci_hcd After a reconnect timeout when we expect the device to be present, force a warm reset of the device. Note that we can not simply look at the link status to determine if a warm reset is required as any of the training states USB_SS_PORT_LS_POLLING, USB_SS_PORT_LS_RX_DETECT, or USB_SS_PORT_LS_COMP_MOD are valid states that do not indicate the need for warm reset by themselves. Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Kukjin Kim <kgene.kim@samsung.com> Cc: Vincent Palatin <vpalatin@chromium.org> Cc: Lan Tianyu <tianyu.lan@intel.com> Cc: Ksenia Ragiadakou <burzalodowa@gmail.com> Cc: Vivek Gautam <gautam.vivek@samsung.com> Cc: Douglas Anderson <dianders@chromium.org> Cc: Felipe Balbi <balbi@ti.com> Cc: Sunil Joshi <joshi@samsung.com> Cc: Hans de Goede <hdegoede@redhat.com> Acked-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-29 12:58:46 -07:00
USB: add new routine for checking port-resume type This patch (as1070) creates a new subroutine to check whether a device can be resumed. This code is needed even when CONFIG_USB_SUSPEND isn't set, because devices do suspend themselves when the root hub (and hence the entire bus) is suspended, and power sessions can get lost during a system sleep even without individual port suspends. The patch also fixes a loose end in USB-Persist reset-resume handling. When a low- or full-speed device is attached to an EHCI's companion controller, the port handoff during resume will cause the companion port's connect-status-change feature to be set. If that flag isn't cleared, the port-reset code will think it indicates that the device has been unplugged and the reset-resume will fail. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:11 -04:00
usb: force warm reset to break link re-connect livelock Resuming a powered down port sometimes results in the port state being stuck in the training sequence. hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0 port1: can't get reconnection after setting port power on, status -110 hub 3-0:1.0: port 1 status 0000.02e0 after resume, -19 usb 3-1: can't resume, status -19 hub 3-0:1.0: logical disconnect on port 1 In the case above we wait for the port re-connect timeout of 2 seconds and observe that the port status is USB_SS_PORT_LS_POLLING (although it is likely toggling between this state and USB_SS_PORT_LS_RX_DETECT). This is indicative of a case where the device is failing to progress the link training state machine. It is resolved by issuing a warm reset to get the hub and device link state machines back in sync. hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0 usb usb3: port1 usb_port_runtime_resume requires warm reset hub 3-0:1.0: port 1 not warm reset yet, waiting 50ms usb 3-1: reset SuperSpeed USB device number 2 using xhci_hcd After a reconnect timeout when we expect the device to be present, force a warm reset of the device. Note that we can not simply look at the link status to determine if a warm reset is required as any of the training states USB_SS_PORT_LS_POLLING, USB_SS_PORT_LS_RX_DETECT, or USB_SS_PORT_LS_COMP_MOD are valid states that do not indicate the need for warm reset by themselves. Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Kukjin Kim <kgene.kim@samsung.com> Cc: Vincent Palatin <vpalatin@chromium.org> Cc: Lan Tianyu <tianyu.lan@intel.com> Cc: Ksenia Ragiadakou <burzalodowa@gmail.com> Cc: Vivek Gautam <gautam.vivek@samsung.com> Cc: Douglas Anderson <dianders@chromium.org> Cc: Felipe Balbi <balbi@ti.com> Cc: Sunil Joshi <joshi@samsung.com> Cc: Hans de Goede <hdegoede@redhat.com> Acked-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-29 12:58:46 -07:00
usb: hub: port: add sysfs entry to switch port power In some cases the port of an hub needs to be disabled or switched off and on again. E.g. when the connected device needs to be re-enumerated. Or it needs to be explicitly disabled while the rest of the usb tree stays working. For this purpose this patch adds an sysfs switch to enable/disable the port on any hub. In the case the hub is supporting power switching, the power line will be disabled to the connected device. When the port gets disabled, the associated device gets disconnected and removed from the logical usb tree. No further device will be enumerated on that port until the port gets enabled again. Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220607114522.3359148-1-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-07 13:45:22 +02:00
USB: add new routine for checking port-resume type This patch (as1070) creates a new subroutine to check whether a device can be resumed. This code is needed even when CONFIG_USB_SUSPEND isn't set, because devices do suspend themselves when the root hub (and hence the entire bus) is suspended, and power sessions can get lost during a system sleep even without individual port suspends. The patch also fixes a loose end in USB-Persist reset-resume handling. When a low- or full-speed device is attached to an EHCI's companion controller, the port handoff during resume will cause the companion port's connect-status-change feature to be set. If that flag isn't cleared, the port-reset code will think it indicates that the device has been unplugged and the reset-resume will fail. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:11 -04:00
usb: Retry port status check on resume to work around RH bugs The EHCI controller on the RK3288 SoC is violating basic parts of the USB spec and thereby unable to properly resume a suspended port. It does not start SOF generation within 3ms of finishing resume signaling, so the attached device will drop of the bus again. This is a particular problem with runtime PM, where accessing the device will trigger a resume that immediately makes it unavailable (and reenumerate with a new handle). Thankfully, the persist feature is generally able to work around stuff like that. Unfortunately, it doesn't quite work in this particular case because the controller will turn off the CurrentConnectStatus bit for an instant while the device is reconnecting, which causes the kernel to conclude that it permanently disappeared. This patch adds a tiny retry mechanism to the core port resume code which will catch this case and shouldn't have any notable impact on other controllers. 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>
2015-01-27 13:20:12 -08:00
usb: hub: port: add sysfs entry to switch port power In some cases the port of an hub needs to be disabled or switched off and on again. E.g. when the connected device needs to be re-enumerated. Or it needs to be explicitly disabled while the rest of the usb tree stays working. For this purpose this patch adds an sysfs switch to enable/disable the port on any hub. In the case the hub is supporting power switching, the power line will be disabled to the connected device. When the port gets disabled, the associated device gets disconnected and removed from the logical usb tree. No further device will be enumerated on that port until the port gets enabled again. Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220607114522.3359148-1-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-07 13:45:22 +02:00
usb: Retry port status check on resume to work around RH bugs The EHCI controller on the RK3288 SoC is violating basic parts of the USB spec and thereby unable to properly resume a suspended port. It does not start SOF generation within 3ms of finishing resume signaling, so the attached device will drop of the bus again. This is a particular problem with runtime PM, where accessing the device will trigger a resume that immediately makes it unavailable (and reenumerate with a new handle). Thankfully, the persist feature is generally able to work around stuff like that. Unfortunately, it doesn't quite work in this particular case because the controller will turn off the CurrentConnectStatus bit for an instant while the device is reconnecting, which causes the kernel to conclude that it permanently disappeared. This patch adds a tiny retry mechanism to the core port resume code which will catch this case and shouldn't have any notable impact on other controllers. 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>
2015-01-27 13:20:12 -08:00
USB: add new routine for checking port-resume type This patch (as1070) creates a new subroutine to check whether a device can be resumed. This code is needed even when CONFIG_USB_SUSPEND isn't set, because devices do suspend themselves when the root hub (and hence the entire bus) is suspended, and power sessions can get lost during a system sleep even without individual port suspends. The patch also fixes a loose end in USB-Persist reset-resume handling. When a low- or full-speed device is attached to an EHCI's companion controller, the port handoff during resume will cause the companion port's connect-status-change feature to be set. If that flag isn't cleared, the port-reset code will think it indicates that the device has been unplugged and the reset-resume will fail. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:11 -04:00
USB: use reset_resume when normal resume fails This patch (as1109b) makes USB-Persist more resilient to errors. With the current code, if a normal resume fails, it's an unrecoverable error. With the patch, if a normal resume fails (and if the device is enabled for USB-Persist) then a reset-resume is tried. This fixes the problem reported in Bugzilla #10977. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-30 11:14:43 -04:00
USB: add new routine for checking port-resume type This patch (as1070) creates a new subroutine to check whether a device can be resumed. This code is needed even when CONFIG_USB_SUSPEND isn't set, because devices do suspend themselves when the root hub (and hence the entire bus) is suspended, and power sessions can get lost during a system sleep even without individual port suspends. The patch also fixes a loose end in USB-Persist reset-resume handling. When a low- or full-speed device is attached to an EHCI's companion controller, the port handoff during resume will cause the companion port's connect-status-change feature to be set. If that flag isn't cleared, the port-reset code will think it indicates that the device has been unplugged and the reset-resume will fail. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:11 -04:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
USB: add new routine for checking port-resume type This patch (as1070) creates a new subroutine to check whether a device can be resumed. This code is needed even when CONFIG_USB_SUSPEND isn't set, because devices do suspend themselves when the root hub (and hence the entire bus) is suspended, and power sessions can get lost during a system sleep even without individual port suspends. The patch also fixes a loose end in USB-Persist reset-resume handling. When a low- or full-speed device is attached to an EHCI's companion controller, the port handoff during resume will cause the companion port's connect-status-change feature to be set. If that flag isn't cleared, the port-reset code will think it indicates that the device has been unplugged and the reset-resume will fail. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:11 -04:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
USB: add new routine for checking port-resume type This patch (as1070) creates a new subroutine to check whether a device can be resumed. This code is needed even when CONFIG_USB_SUSPEND isn't set, because devices do suspend themselves when the root hub (and hence the entire bus) is suspended, and power sessions can get lost during a system sleep even without individual port suspends. The patch also fixes a loose end in USB-Persist reset-resume handling. When a low- or full-speed device is attached to an EHCI's companion controller, the port handoff during resume will cause the companion port's connect-status-change feature to be set. If that flag isn't cleared, the port-reset code will think it indicates that the device has been unplugged and the reset-resume will fail. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:11 -04:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
USB: add new routine for checking port-resume type This patch (as1070) creates a new subroutine to check whether a device can be resumed. This code is needed even when CONFIG_USB_SUSPEND isn't set, because devices do suspend themselves when the root hub (and hence the entire bus) is suspended, and power sessions can get lost during a system sleep even without individual port suspends. The patch also fixes a loose end in USB-Persist reset-resume handling. When a low- or full-speed device is attached to an EHCI's companion controller, the port handoff during resume will cause the companion port's connect-status-change feature to be set. If that flag isn't cleared, the port-reset code will think it indicates that the device has been unplugged and the reset-resume will fail. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:11 -04:00
USB: hub: Fix handling of connect changes during sleep Commit 8099f58f1ecd ("USB: hub: Don't record a connect-change event during reset-resume") wasn't very well conceived. The problem it tried to fix was that if a connect-change event occurred while the system was asleep (such as a device disconnecting itself from the bus when it is suspended and then reconnecting when it resumes) requiring a reset-resume during the system wakeup transition, the hub port's change_bit entry would remain set afterward. This would cause the hub driver to believe another connect-change event had occurred after the reset-resume, which was wrong and would lead the driver to send unnecessary requests to the device (which could interfere with a firmware update). The commit tried to fix this by not setting the change_bit during the wakeup. But this was the wrong thing to do; it means that when a device is unplugged while the system is asleep, the hub driver doesn't realize anything has happened: The change_bit flag which would tell it to handle the disconnect event is clear. The commit needs to be reverted and the problem fixed in a different way. Fortunately an alternative solution was noted in the commit's Changelog: We can continue to set the change_bit entry in hub_activate() but then clear it when a reset-resume occurs. That way the the hub driver will see the change_bit when a device is disconnected but won't see it when the device is still present. That's what this patch does. Reported-and-tested-by: Peter Chen <peter.chen@nxp.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Fixes: 8099f58f1ecd ("USB: hub: Don't record a connect-change event during reset-resume") Tested-by: Paul Zimmerman <pauldzim@gmail.com> CC: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2004221602480.11262-100000@iolanthe.rowland.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-22 16:09:51 -04:00
USB: add new routine for checking port-resume type This patch (as1070) creates a new subroutine to check whether a device can be resumed. This code is needed even when CONFIG_USB_SUSPEND isn't set, because devices do suspend themselves when the root hub (and hence the entire bus) is suspended, and power sessions can get lost during a system sleep even without individual port suspends. The patch also fixes a loose end in USB-Persist reset-resume handling. When a low- or full-speed device is attached to an EHCI's companion controller, the port handoff during resume will cause the companion port's connect-status-change feature to be set. If that flag isn't cleared, the port-reset code will think it indicates that the device has been unplugged and the reset-resume will fail. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:11 -04:00
USB: Enable Latency Tolerance Messaging (LTM). 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-06-25 12:08:08 -07:00
Revert "USB: core: hub.c: use usb_control_msg_send() in a few places" This reverts commit d6a499249543356002a1efbb26254c7272e62f4c. Control messages are needed in contexts when memory allocations are restricted, such as handling device resets and runtime PM. For this reason the control message API internally uses GFP_NOIO. This is a band aid introduced because when we recognized the issue, the call chains were highly convoluted. Continuing this trend is not a good idea. So I am shooting the whole kennel here. Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20200923134348.23862-2-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-23 15:43:35 +02:00
USB: Enable Latency Tolerance Messaging (LTM). 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-06-25 12:08:08 -07:00
Revert "USB: core: hub.c: use usb_control_msg_send() in a few places" This reverts commit d6a499249543356002a1efbb26254c7272e62f4c. Control messages are needed in contexts when memory allocations are restricted, such as handling device resets and runtime PM. For this reason the control message API internally uses GFP_NOIO. This is a band aid introduced because when we recognized the issue, the call chains were highly convoluted. Continuing this trend is not a good idea. So I am shooting the whole kennel here. Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20200923134348.23862-2-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-23 15:43:35 +02:00
USB: Enable Latency Tolerance Messaging (LTM). 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-06-25 12:08:08 -07:00
usb: Using correct way to clear usb3.0 device's remote wakeup feature. Usb3.0 device defines function remote wakeup which is only for interface recipient rather than device recipient. This is different with usb2.0 device's remote wakeup feature which is defined for device recipient. According usb3.0 spec 9.4.5, the function remote wakeup can be modified by the SetFeature() requests using the FUNCTION_SUSPEND feature selector. This patch is to use correct way to disable usb3.0 device's function remote wakeup after suspend error and resuming. This should be backported to kernels as old as 3.4, that contain the commit 623bef9e03a60adc623b09673297ca7a1cdfb367 "USB/xhci: Enable remote wakeup for USB3 devices." Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2013-01-24 10:31:28 +08:00
USB: refactor code for enabling/disabling remote wakeup The hub driver is inconsistent in its organization of code for enabling and disabling remote wakeup. There is a special routine to disable wakeup for SuperSpeed devices but not for slower devices, and there is no special routine to enable wakeup. This patch refactors the code. It renames and changes the existing function to make it handle both SuperSpeed and non-SuperSpeed devices, and it adds a corresponding routine to enable remote wakeup. It also changes the speed determination to look at the device's speed rather than the speed of the parent hub -- this shouldn't make any difference because a SuperSpeed device always has to be attached to a SuperSpeed hub and conversely. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-30 15:37:33 -04:00
usb: Using correct way to clear usb3.0 device's remote wakeup feature. Usb3.0 device defines function remote wakeup which is only for interface recipient rather than device recipient. This is different with usb2.0 device's remote wakeup feature which is defined for device recipient. According usb3.0 spec 9.4.5, the function remote wakeup can be modified by the SetFeature() requests using the FUNCTION_SUSPEND feature selector. This patch is to use correct way to disable usb3.0 device's function remote wakeup after suspend error and resuming. This should be backported to kernels as old as 3.4, that contain the commit 623bef9e03a60adc623b09673297ca7a1cdfb367 "USB/xhci: Enable remote wakeup for USB3 devices." Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2013-01-24 10:31:28 +08:00
USB: refactor code for enabling/disabling remote wakeup The hub driver is inconsistent in its organization of code for enabling and disabling remote wakeup. There is a special routine to disable wakeup for SuperSpeed devices but not for slower devices, and there is no special routine to enable wakeup. This patch refactors the code. It renames and changes the existing function to make it handle both SuperSpeed and non-SuperSpeed devices, and it adds a corresponding routine to enable remote wakeup. It also changes the speed determination to look at the device's speed rather than the speed of the parent hub -- this shouldn't make any difference because a SuperSpeed device always has to be attached to a SuperSpeed hub and conversely. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-30 15:37:33 -04:00
usb: Using correct way to clear usb3.0 device's remote wakeup feature. Usb3.0 device defines function remote wakeup which is only for interface recipient rather than device recipient. This is different with usb2.0 device's remote wakeup feature which is defined for device recipient. According usb3.0 spec 9.4.5, the function remote wakeup can be modified by the SetFeature() requests using the FUNCTION_SUSPEND feature selector. This patch is to use correct way to disable usb3.0 device's function remote wakeup after suspend error and resuming. This should be backported to kernels as old as 3.4, that contain the commit 623bef9e03a60adc623b09673297ca7a1cdfb367 "USB/xhci: Enable remote wakeup for USB3 devices." Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2013-01-24 10:31:28 +08:00
USB: refactor code for enabling/disabling remote wakeup The hub driver is inconsistent in its organization of code for enabling and disabling remote wakeup. There is a special routine to disable wakeup for SuperSpeed devices but not for slower devices, and there is no special routine to enable wakeup. This patch refactors the code. It renames and changes the existing function to make it handle both SuperSpeed and non-SuperSpeed devices, and it adds a corresponding routine to enable remote wakeup. It also changes the speed determination to look at the device's speed rather than the speed of the parent hub -- this shouldn't make any difference because a SuperSpeed device always has to be attached to a SuperSpeed hub and conversely. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-30 15:37:33 -04:00
usb: Using correct way to clear usb3.0 device's remote wakeup feature. Usb3.0 device defines function remote wakeup which is only for interface recipient rather than device recipient. This is different with usb2.0 device's remote wakeup feature which is defined for device recipient. According usb3.0 spec 9.4.5, the function remote wakeup can be modified by the SetFeature() requests using the FUNCTION_SUSPEND feature selector. This patch is to use correct way to disable usb3.0 device's function remote wakeup after suspend error and resuming. This should be backported to kernels as old as 3.4, that contain the commit 623bef9e03a60adc623b09673297ca7a1cdfb367 "USB/xhci: Enable remote wakeup for USB3 devices." Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2013-01-24 10:31:28 +08:00
USB: refactor code for enabling/disabling remote wakeup The hub driver is inconsistent in its organization of code for enabling and disabling remote wakeup. There is a special routine to disable wakeup for SuperSpeed devices but not for slower devices, and there is no special routine to enable wakeup. This patch refactors the code. It renames and changes the existing function to make it handle both SuperSpeed and non-SuperSpeed devices, and it adds a corresponding routine to enable remote wakeup. It also changes the speed determination to look at the device's speed rather than the speed of the parent hub -- this shouldn't make any difference because a SuperSpeed device always has to be attached to a SuperSpeed hub and conversely. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-30 15:37:33 -04:00
Revert "USB: core: hub.c: use usb_control_msg_send() in a few places" This reverts commit d6a499249543356002a1efbb26254c7272e62f4c. Control messages are needed in contexts when memory allocations are restricted, such as handling device resets and runtime PM. For this reason the control message API internally uses GFP_NOIO. This is a band aid introduced because when we recognized the issue, the call chains were highly convoluted. Continuing this trend is not a good idea. So I am shooting the whole kennel here. Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20200923134348.23862-2-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-23 15:43:35 +02:00
USB: refactor code for enabling/disabling remote wakeup The hub driver is inconsistent in its organization of code for enabling and disabling remote wakeup. There is a special routine to disable wakeup for SuperSpeed devices but not for slower devices, and there is no special routine to enable wakeup. This patch refactors the code. It renames and changes the existing function to make it handle both SuperSpeed and non-SuperSpeed devices, and it adds a corresponding routine to enable remote wakeup. It also changes the speed determination to look at the device's speed rather than the speed of the parent hub -- this shouldn't make any difference because a SuperSpeed device always has to be attached to a SuperSpeed hub and conversely. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-30 15:37:33 -04:00
Revert "USB: core: hub.c: use usb_control_msg_send() in a few places" This reverts commit d6a499249543356002a1efbb26254c7272e62f4c. Control messages are needed in contexts when memory allocations are restricted, such as handling device resets and runtime PM. For this reason the control message API internally uses GFP_NOIO. This is a band aid introduced because when we recognized the issue, the call chains were highly convoluted. Continuing this trend is not a good idea. So I am shooting the whole kennel here. Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20200923134348.23862-2-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-23 15:43:35 +02:00
USB: refactor code for enabling/disabling remote wakeup The hub driver is inconsistent in its organization of code for enabling and disabling remote wakeup. There is a special routine to disable wakeup for SuperSpeed devices but not for slower devices, and there is no special routine to enable wakeup. This patch refactors the code. It renames and changes the existing function to make it handle both SuperSpeed and non-SuperSpeed devices, and it adds a corresponding routine to enable remote wakeup. It also changes the speed determination to look at the device's speed rather than the speed of the parent hub -- this shouldn't make any difference because a SuperSpeed device always has to be attached to a SuperSpeed hub and conversely. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-30 15:37:33 -04:00
Revert "USB: core: hub.c: use usb_control_msg_send() in a few places" This reverts commit d6a499249543356002a1efbb26254c7272e62f4c. Control messages are needed in contexts when memory allocations are restricted, such as handling device resets and runtime PM. For this reason the control message API internally uses GFP_NOIO. This is a band aid introduced because when we recognized the issue, the call chains were highly convoluted. Continuing this trend is not a good idea. So I am shooting the whole kennel here. Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20200923134348.23862-2-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-23 15:43:35 +02:00
USB: refactor code for enabling/disabling remote wakeup The hub driver is inconsistent in its organization of code for enabling and disabling remote wakeup. There is a special routine to disable wakeup for SuperSpeed devices but not for slower devices, and there is no special routine to enable wakeup. This patch refactors the code. It renames and changes the existing function to make it handle both SuperSpeed and non-SuperSpeed devices, and it adds a corresponding routine to enable remote wakeup. It also changes the speed determination to look at the device's speed rather than the speed of the parent hub -- this shouldn't make any difference because a SuperSpeed device always has to be attached to a SuperSpeed hub and conversely. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-30 15:37:33 -04:00
Revert "USB: core: hub.c: use usb_control_msg_send() in a few places" This reverts commit d6a499249543356002a1efbb26254c7272e62f4c. Control messages are needed in contexts when memory allocations are restricted, such as handling device resets and runtime PM. For this reason the control message API internally uses GFP_NOIO. This is a band aid introduced because when we recognized the issue, the call chains were highly convoluted. Continuing this trend is not a good idea. So I am shooting the whole kennel here. Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20200923134348.23862-2-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-23 15:43:35 +02:00
usb: Using correct way to clear usb3.0 device's remote wakeup feature. Usb3.0 device defines function remote wakeup which is only for interface recipient rather than device recipient. This is different with usb2.0 device's remote wakeup feature which is defined for device recipient. According usb3.0 spec 9.4.5, the function remote wakeup can be modified by the SetFeature() requests using the FUNCTION_SUSPEND feature selector. This patch is to use correct way to disable usb3.0 device's function remote wakeup after suspend error and resuming. This should be backported to kernels as old as 3.4, that contain the commit 623bef9e03a60adc623b09673297ca7a1cdfb367 "USB/xhci: Enable remote wakeup for USB3 devices." Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2013-01-24 10:31:28 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: global suspend and remote wakeup don't mix The hub driver was recently changed to use "global" suspend for system suspend transitions on non-SuperSpeed buses. This means that we don't suspend devices individually by setting the suspend feature on the upstream hub port; instead devices all go into suspend automatically when the root hub stops transmitting packets. The idea was to save time and to avoid certain kinds of wakeup races. Now it turns out that many hubs are buggy; they don't relay wakeup requests from a downstream port to their upstream port if the downstream port's suspend feature is not set (depending on the speed of the downstream port, whether or not the hub is enabled for remote wakeup, and possibly other factors). We can't have hubs dropping wakeup requests. Therefore this patch goes partway back to the old policy: It sets the suspend feature for a port if the device attached to that port or any of its descendants is enabled for wakeup. People will still be able to benefit from the time savings if they don't care about wakeup and leave it disabled on all their devices. In order to accomplish this, the patch adds a new field to the usb_hub structure: wakeup_enabled_descendants is a count of how many devices below a suspended hub are enabled for remote wakeup. A corresponding new subroutine determines the number of wakeup-enabled devices at or below an arbitrary suspended USB device. This should be applied to the 3.10 stable kernel. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Toralf Förster <toralf.foerster@gmx.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-11 14:58:04 -04:00
USB: Export usb_wakeup_enabled_descendants() In (e583d9d USB: global suspend and remote wakeup don't mix) we introduced wakeup_enabled_descendants() as a static function. We'd like to use this function in USB controller drivers to know if we should keep the controller on during suspend time, since doing so has a power impact. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2019-04-17 17:13:53 -07:00
USB: global suspend and remote wakeup don't mix The hub driver was recently changed to use "global" suspend for system suspend transitions on non-SuperSpeed buses. This means that we don't suspend devices individually by setting the suspend feature on the upstream hub port; instead devices all go into suspend automatically when the root hub stops transmitting packets. The idea was to save time and to avoid certain kinds of wakeup races. Now it turns out that many hubs are buggy; they don't relay wakeup requests from a downstream port to their upstream port if the downstream port's suspend feature is not set (depending on the speed of the downstream port, whether or not the hub is enabled for remote wakeup, and possibly other factors). We can't have hubs dropping wakeup requests. Therefore this patch goes partway back to the old policy: It sets the suspend feature for a port if the device attached to that port or any of its descendants is enabled for wakeup. People will still be able to benefit from the time savings if they don't care about wakeup and leave it disabled on all their devices. In order to accomplish this, the patch adds a new field to the usb_hub structure: wakeup_enabled_descendants is a count of how many devices below a suspended hub are enabled for remote wakeup. A corresponding new subroutine determines the number of wakeup-enabled devices at or below an arbitrary suspended USB device. This should be applied to the 3.10 stable kernel. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Toralf Förster <toralf.foerster@gmx.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-11 14:58:04 -04:00
USB: Export usb_wakeup_enabled_descendants() In (e583d9d USB: global suspend and remote wakeup don't mix) we introduced wakeup_enabled_descendants() as a static function. We'd like to use this function in USB controller drivers to know if we should keep the controller on during suspend time, since doing so has a power impact. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2019-04-17 17:13:53 -07:00
USB: global suspend and remote wakeup don't mix The hub driver was recently changed to use "global" suspend for system suspend transitions on non-SuperSpeed buses. This means that we don't suspend devices individually by setting the suspend feature on the upstream hub port; instead devices all go into suspend automatically when the root hub stops transmitting packets. The idea was to save time and to avoid certain kinds of wakeup races. Now it turns out that many hubs are buggy; they don't relay wakeup requests from a downstream port to their upstream port if the downstream port's suspend feature is not set (depending on the speed of the downstream port, whether or not the hub is enabled for remote wakeup, and possibly other factors). We can't have hubs dropping wakeup requests. Therefore this patch goes partway back to the old policy: It sets the suspend feature for a port if the device attached to that port or any of its descendants is enabled for wakeup. People will still be able to benefit from the time savings if they don't care about wakeup and leave it disabled on all their devices. In order to accomplish this, the patch adds a new field to the usb_hub structure: wakeup_enabled_descendants is a count of how many devices below a suspended hub are enabled for remote wakeup. A corresponding new subroutine determines the number of wakeup-enabled devices at or below an arbitrary suspended USB device. This should be applied to the 3.10 stable kernel. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Toralf Förster <toralf.foerster@gmx.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-11 14:58:04 -04:00
[PATCH] stop exporting two functions The way we're looking at USB suspend lately doesn't expect drivers to call usb_suspend_device() or usb_resume_device() directly; that'll be implicit when no interfaces are in use. This patch removes those APIs from visibility outside usbcore. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> drivers/usb/core/hub.c | 12 ++++-------- drivers/usb/core/usb.h | 4 ++++ include/linux/usb.h | 5 ----- 3 files changed, 8 insertions(+), 13 deletions(-)
2005-09-22 22:45:26 -07:00
usbcore: rename usb_suspend_device to usb_port_suspend This revised patch (as715b) renames usb_suspend_device to usb_port_suspend, usb_resume_device to usb_port_resume, and finish_device_resume to finish_port_resume. There was no objection to the original version of the patch so this should be okay to apply. The revision was needed only because I have re-arranged the order of the earlier patches. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-07-01 22:07:21 -04:00
USB: remove excess code from hub.c This patch (as917) removes a now-unnecessary level of subroutine nesting from hub.c. Since usb_port_suspend() does nothing but call hub_port_suspend(), and usb_port_resume() does nothing but call hub_port_resume(), there's no reason to keep the routines separate. Also included in the patch are a few cosmetic changes involving whitespace and use of braces. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:35:16 -04:00
[PATCH] stop exporting two functions The way we're looking at USB suspend lately doesn't expect drivers to call usb_suspend_device() or usb_resume_device() directly; that'll be implicit when no interfaces are in use. This patch removes those APIs from visibility outside usbcore. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> drivers/usb/core/hub.c | 12 ++++-------- drivers/usb/core/usb.h | 4 ++++ include/linux/usb.h | 5 ----- 3 files changed, 8 insertions(+), 13 deletions(-)
2005-09-22 22:45:26 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usbcore: rename usb_suspend_device to usb_port_suspend This revised patch (as715b) renames usb_suspend_device to usb_port_suspend, usb_resume_device to usb_port_resume, and finish_device_resume to finish_port_resume. There was no objection to the original version of the patch so this should be okay to apply. The revision was needed only because I have re-arranged the order of the earlier patches. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-07-01 22:07:21 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] remove usb_suspend_device() parameter This patch removes the extra usb_suspend_device() parameter. The original reason to pass that parameter was so that this routine could suspend any active children. A previous patch removed that functionality ... leaving no reason to pass the parameter. A close analogy is pci_set_power_state, which doesn't need a pm_message_t either. On the internal code path that comes through the driver model, the parameter is now used to distinguish cases where USB devices need to "freeze" but not suspend. It also checks for an error case that's accessible through sysfs: attempting to suspend a device before its interfaces (or for hubs, ports). Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> drivers/usb/core/hub.c | 34 +++++++++++++++++++++------------- drivers/usb/core/usb.c | 23 +++++++++++++++++++++-- drivers/usb/host/ehci-hcd.c | 2 +- drivers/usb/host/isp116x-hcd.c | 2 +- drivers/usb/host/ohci-pci.c | 2 +- include/linux/usb.h | 2 +- 6 files changed, 46 insertions(+), 19 deletions(-)
2005-09-13 19:57:27 -07:00
USB: remove excess code from hub.c This patch (as917) removes a now-unnecessary level of subroutine nesting from hub.c. Since usb_port_suspend() does nothing but call hub_port_suspend(), and usb_port_resume() does nothing but call hub_port_resume(), there's no reason to keep the routines separate. Also included in the patch are a few cosmetic changes involving whitespace and use of braces. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:35:16 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: remove __usb_port_suspend This patch (as915b) combines the public routine usb_port_suspend() and the private routine __usb_port_suspend() into a single function. By removing the explicit mention of otg_port in the call to __usb_port_suspend(), we prevent a possible error in which the system tries to perform HNP on the wrong port when a non-targeted device is plugged into a non-OTG port. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 16:51:28 -04:00
usb: hub: rename khubd to hub_wq in documentation and comments USB hub has started to use a workqueue instead of kthread. Let's update the documentation and comments here and there. This patch mostly just replaces "khubd" with "hub_wq". There are only few exceptions where the whole sentence was updated. These more complicated changes can be found in the following files: Documentation/usb/hotplug.txt drivers/net/usb/usbnet.c drivers/usb/core/hcd.c drivers/usb/host/ohci-hcd.c drivers/usb/host/xhci.c Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:23 +02:00
USB: remove __usb_port_suspend This patch (as915b) combines the public routine usb_port_suspend() and the private routine __usb_port_suspend() into a single function. By removing the explicit mention of otg_port in the call to __usb_port_suspend(), we prevent a possible error in which the system tries to perform HNP on the wrong port when a non-targeted device is plugged into a non-OTG port. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 16:51:28 -04:00
USB: global suspend and remote wakeup don't mix The hub driver was recently changed to use "global" suspend for system suspend transitions on non-SuperSpeed buses. This means that we don't suspend devices individually by setting the suspend feature on the upstream hub port; instead devices all go into suspend automatically when the root hub stops transmitting packets. The idea was to save time and to avoid certain kinds of wakeup races. Now it turns out that many hubs are buggy; they don't relay wakeup requests from a downstream port to their upstream port if the downstream port's suspend feature is not set (depending on the speed of the downstream port, whether or not the hub is enabled for remote wakeup, and possibly other factors). We can't have hubs dropping wakeup requests. Therefore this patch goes partway back to the old policy: It sets the suspend feature for a port if the device attached to that port or any of its descendants is enabled for wakeup. People will still be able to benefit from the time savings if they don't care about wakeup and leave it disabled on all their devices. In order to accomplish this, the patch adds a new field to the usb_hub structure: wakeup_enabled_descendants is a count of how many devices below a suspended hub are enabled for remote wakeup. A corresponding new subroutine determines the number of wakeup-enabled devices at or below an arbitrary suspended USB device. This should be applied to the 3.10 stable kernel. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Toralf Förster <toralf.foerster@gmx.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-11 14:58:04 -04:00
USB: use "global suspend" for system sleep on USB-2 buses This patch (as1674) speeds up system sleep transitions by not suspending each individual device on a USB-1.1 or USB-2 bus. The devices will automatically go into suspend when their root hubs are suspended (i.e., stop sending out Start-Of-Frame packets) -- this is what the USB spec calls "global suspend". Since this is what we do already when CONFIG_USB_SUSPEND isn't enabled, it shouldn't cause any problems. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-27 16:14:19 -04:00
USB: remove __usb_port_suspend This patch (as915b) combines the public routine usb_port_suspend() and the private routine __usb_port_suspend() into a single function. By removing the explicit mention of otg_port in the call to __usb_port_suspend(), we prevent a possible error in which the system tries to perform HNP on the wrong port when a non-targeted device is plugged into a non-OTG port. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 16:51:28 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: Enhance usage of pm_message_t This patch (as1177) modifies the USB core suspend and resume routines. The resume functions now will take a pm_message_t argument, so they will know what sort of resume is occurring. The new argument is also passed to the port suspend/resume and bus suspend/resume routines (although they don't use it for anything but debugging). In addition, special pm_message_t values are used for user-initiated, device-initiated (i.e., remote wakeup), and automatic suspend/resume. By testing these values, drivers can tell whether or not a particular suspend was an autosuspend. Unfortunately, they can't do the same for resumes -- not until the pm_message_t argument is also passed to the drivers' resume methods. That will require a bigger change. IMO, the whole Power Management framework should have been set up this way in the first place. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-25 16:39:18 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
USB: remove excess code from hub.c This patch (as917) removes a now-unnecessary level of subroutine nesting from hub.c. Since usb_port_suspend() does nothing but call hub_port_suspend(), and usb_port_resume() does nothing but call hub_port_resume(), there's no reason to keep the routines separate. Also included in the patch are a few cosmetic changes involving whitespace and use of braces. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:35:16 -04:00
USB: use "global suspend" for system sleep on USB-2 buses This patch (as1674) speeds up system sleep transitions by not suspending each individual device on a USB-1.1 or USB-2 bus. The devices will automatically go into suspend when their root hubs are suspended (i.e., stop sending out Start-Of-Frame packets) -- this is what the USB spec calls "global suspend". Since this is what we do already when CONFIG_USB_SUSPEND isn't enabled, it shouldn't cause any problems. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-27 16:14:19 -04:00
USB: remove __usb_port_suspend This patch (as915b) combines the public routine usb_port_suspend() and the private routine __usb_port_suspend() into a single function. By removing the explicit mention of otg_port in the call to __usb_port_suspend(), we prevent a possible error in which the system tries to perform HNP on the wrong port when a non-targeted device is plugged into a non-OTG port. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 16:51:28 -04:00
usb: introduce port status lock In general we do not want khubd to act on port status changes that are the result of in progress resets or USB runtime PM operations. Specifically port power control testing has been able to trigger an unintended disconnect in hub_port_connect_change(), paraphrasing: if ((portstatus & USB_PORT_STAT_CONNECTION) && udev && udev->state != USB_STATE_NOTATTACHED) { if (portstatus & USB_PORT_STAT_ENABLE) { /* Nothing to do */ } else if (udev->state == USB_STATE_SUSPENDED && udev->persist_enabled) { ... } else { /* Don't resuscitate */; } } ...by falling to the "Don't resuscitate" path or missing USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of modifying the port status. So, we want a new lock to hold off khubd for a given port while the child device is being suspended, resumed, or reset. The lock ordering rules are now usb_lock_device() => usb_lock_port(). This is mandated by the device core which may hold the device_lock on the usb_device before invoking usb_port_{suspend|resume} which in turn take the status_lock on the usb_port. We attempt to hold the status_lock for the duration of a port_event() run, and drop/re-acquire it when needing to take the device_lock. The lock is also dropped/re-acquired during hub_port_reconnect(). This patch also deletes hub->busy_bits as all use cases are now covered by port PM runtime synchronization or the port->status_lock and it pushes down usb_device_lock() into usb_remote_wakeup(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:26 -07:00
USB: remove excess code from hub.c This patch (as917) removes a now-unnecessary level of subroutine nesting from hub.c. Since usb_port_suspend() does nothing but call hub_port_suspend(), and usb_port_resume() does nothing but call hub_port_resume(), there's no reason to keep the routines separate. Also included in the patch are a few cosmetic changes involving whitespace and use of braces. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:35:16 -04:00
USB: refactor code for enabling/disabling remote wakeup The hub driver is inconsistent in its organization of code for enabling and disabling remote wakeup. There is a special routine to disable wakeup for SuperSpeed devices but not for slower devices, and there is no special routine to enable wakeup. This patch refactors the code. It renames and changes the existing function to make it handle both SuperSpeed and non-SuperSpeed devices, and it adds a corresponding routine to enable remote wakeup. It also changes the speed determination to look at the device's speed rather than the speed of the parent hub -- this shouldn't make any difference because a SuperSpeed device always has to be attached to a SuperSpeed hub and conversely. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-30 15:37:33 -04:00
USB: improved error handling in usb_port_suspend() usb: better error handling in usb_port_suspend - disable remote wakeup only if it was enabled - refuse to autosuspend if remote wakeup fails to be enabled Signed-off-by: Oliver Neukum <oliver@neukum.org> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-19 13:19:41 +02:00
USB: remove excess code from hub.c This patch (as917) removes a now-unnecessary level of subroutine nesting from hub.c. Since usb_port_suspend() does nothing but call hub_port_suspend(), and usb_port_resume() does nothing but call hub_port_resume(), there's no reason to keep the routines separate. Also included in the patch are a few cosmetic changes involving whitespace and use of braces. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:35:16 -04:00
USB: improved error handling in usb_port_suspend() usb: better error handling in usb_port_suspend - disable remote wakeup only if it was enabled - refuse to autosuspend if remote wakeup fails to be enabled Signed-off-by: Oliver Neukum <oliver@neukum.org> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-19 13:19:41 +02:00
PM / Runtime: Add macro to test for runtime PM events This patch (as1482) adds a macro for testing whether or not a pm_message value represents an autosuspend or autoresume (i.e., a runtime PM) event. Encapsulating this notion seems preferable to open-coding the test all over the place. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-08-19 23:49:48 +02:00
USB: handle LPM errors during device suspend correctly The hub driver's usb_port_suspend() routine doesn't handle errors related to Link Power Management properly. It always returns failure, it doesn't try to clean up the wakeup setting, (in the case of system sleep) it doesn't try to go ahead with the port suspend regardless, and it doesn't try to apply the new power-off mechanism. This patch fixes these problems. Signed-off-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>
2013-07-30 15:39:02 -04:00
USB: improved error handling in usb_port_suspend() usb: better error handling in usb_port_suspend - disable remote wakeup only if it was enabled - refuse to autosuspend if remote wakeup fails to be enabled Signed-off-by: Oliver Neukum <oliver@neukum.org> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-19 13:19:41 +02:00
USB: remove excess code from hub.c This patch (as917) removes a now-unnecessary level of subroutine nesting from hub.c. Since usb_port_suspend() does nothing but call hub_port_suspend(), and usb_port_resume() does nothing but call hub_port_resume(), there's no reason to keep the routines separate. Also included in the patch are a few cosmetic changes involving whitespace and use of braces. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:35:16 -04:00
xHCI: set USB2 hardware LPM If the device pass the USB2 software LPM and the host supports hardware LPM, enable hardware LPM for the device to let the host decide when to put the link into lower power state. If hardware LPM is enabled for a port and driver wants to put it into suspend, it must first disable hardware LPM, resume the port into U0, and then suspend the port. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-23 14:19:52 -07:00
USB: Consolidate LPM checks to avoid enabling LPM twice USB Bluetooth controller QCA ROME (0cf3:e007) sometimes stops working after S3: [ 165.110742] Bluetooth: hci0: using NVM file: qca/nvm_usb_00000302.bin [ 168.432065] Bluetooth: hci0: Failed to send body at 4 of 1953 (-110) After some experiments, I found that disabling LPM can workaround the issue. On some platforms, the USB power is cut during S3, so the driver uses reset-resume to resume the device. During port resume, LPM gets enabled twice, by usb_reset_and_verify_device() and usb_port_resume(). Consolidate all checks into new LPM helpers to make sure LPM only gets enabled once. Fixes: de68bab4fa96 ("usb: Don't enable USB 2.0 Link PM by default.”) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: stable <stable@vger.kernel.org> # after much soaking Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-12 03:54:25 +08:00
xHCI: set USB2 hardware LPM If the device pass the USB2 software LPM and the host supports hardware LPM, enable hardware LPM for the device to let the host decide when to put the link into lower power state. If hardware LPM is enabled for a port and driver wants to put it into suspend, it must first disable hardware LPM, resume the port into U0, and then suspend the port. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-23 14:19:52 -07:00
USB: Enable Latency Tolerance Messaging (LTM). 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-06-25 12:08:08 -07:00
usb: core: Fix logging messages with spurious periods after newlines Using a period after a newline causes bad output. Miscellanea: o Coalesce formats too Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-05 22:22:05 -08:00
USB: handle LPM errors during device suspend correctly The hub driver's usb_port_suspend() routine doesn't handle errors related to Link Power Management properly. It always returns failure, it doesn't try to clean up the wakeup setting, (in the case of system sleep) it doesn't try to go ahead with the port suspend regardless, and it doesn't try to apply the new power-off mechanism. This patch fixes these problems. Signed-off-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>
2013-07-30 15:39:02 -04:00
USB: Enable Latency Tolerance Messaging (LTM). 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-06-25 12:08:08 -07:00
USB: Disable USB 3.0 LPM in critical sections. 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-02 14:25:52 -07:00
USB: remove excess code from hub.c This patch (as917) removes a now-unnecessary level of subroutine nesting from hub.c. Since usb_port_suspend() does nothing but call hub_port_suspend(), and usb_port_resume() does nothing but call hub_port_resume(), there's no reason to keep the routines separate. Also included in the patch are a few cosmetic changes involving whitespace and use of braces. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:35:16 -04:00
usbcore: Refine USB3.0 device suspend and resume In the past, we use USB2.0 request to suspend and resume a USB3.0 device. Actually, USB3.0 hub does not support Set/Clear PORT_SUSPEND request, instead, it uses Set PORT_LINK_STATE request. This patch makes USB3.0 device suspend/resume comply with USB3.0 specification. This patch fixes the issue that USB3.0 device can not be suspended when connected to a USB3.0 external hub. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-04-27 18:07:50 +08:00
USB: Use helper function hub_set_port_link_state Change the code that manually issues a Set Port Feature(Link State) to use the new helper function hub_set_port_link_state(). Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu>
2012-12-10 15:43:08 -08:00
USB: global suspend and remote wakeup don't mix The hub driver was recently changed to use "global" suspend for system suspend transitions on non-SuperSpeed buses. This means that we don't suspend devices individually by setting the suspend feature on the upstream hub port; instead devices all go into suspend automatically when the root hub stops transmitting packets. The idea was to save time and to avoid certain kinds of wakeup races. Now it turns out that many hubs are buggy; they don't relay wakeup requests from a downstream port to their upstream port if the downstream port's suspend feature is not set (depending on the speed of the downstream port, whether or not the hub is enabled for remote wakeup, and possibly other factors). We can't have hubs dropping wakeup requests. Therefore this patch goes partway back to the old policy: It sets the suspend feature for a port if the device attached to that port or any of its descendants is enabled for wakeup. People will still be able to benefit from the time savings if they don't care about wakeup and leave it disabled on all their devices. In order to accomplish this, the patch adds a new field to the usb_hub structure: wakeup_enabled_descendants is a count of how many devices below a suspended hub are enabled for remote wakeup. A corresponding new subroutine determines the number of wakeup-enabled devices at or below an arbitrary suspended USB device. This should be applied to the 3.10 stable kernel. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Toralf Förster <toralf.foerster@gmx.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-11 14:58:04 -04:00
USB: use "global suspend" for system sleep on USB-2 buses This patch (as1674) speeds up system sleep transitions by not suspending each individual device on a USB-1.1 or USB-2 bus. The devices will automatically go into suspend when their root hubs are suspended (i.e., stop sending out Start-Of-Frame packets) -- this is what the USB spec calls "global suspend". Since this is what we do already when CONFIG_USB_SUSPEND isn't enabled, it shouldn't cause any problems. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-27 16:14:19 -04:00
USB: global suspend and remote wakeup don't mix The hub driver was recently changed to use "global" suspend for system suspend transitions on non-SuperSpeed buses. This means that we don't suspend devices individually by setting the suspend feature on the upstream hub port; instead devices all go into suspend automatically when the root hub stops transmitting packets. The idea was to save time and to avoid certain kinds of wakeup races. Now it turns out that many hubs are buggy; they don't relay wakeup requests from a downstream port to their upstream port if the downstream port's suspend feature is not set (depending on the speed of the downstream port, whether or not the hub is enabled for remote wakeup, and possibly other factors). We can't have hubs dropping wakeup requests. Therefore this patch goes partway back to the old policy: It sets the suspend feature for a port if the device attached to that port or any of its descendants is enabled for wakeup. People will still be able to benefit from the time savings if they don't care about wakeup and leave it disabled on all their devices. In order to accomplish this, the patch adds a new field to the usb_hub structure: wakeup_enabled_descendants is a count of how many devices below a suspended hub are enabled for remote wakeup. A corresponding new subroutine determines the number of wakeup-enabled devices at or below an arbitrary suspended USB device. This should be applied to the 3.10 stable kernel. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Toralf Förster <toralf.foerster@gmx.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-11 14:58:04 -04:00
USB: use "global suspend" for system sleep on USB-2 buses This patch (as1674) speeds up system sleep transitions by not suspending each individual device on a USB-1.1 or USB-2 bus. The devices will automatically go into suspend when their root hubs are suspended (i.e., stop sending out Start-Of-Frame packets) -- this is what the USB spec calls "global suspend". Since this is what we do already when CONFIG_USB_SUSPEND isn't enabled, it shouldn't cause any problems. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-27 16:14:19 -04:00
USB: Export usb_wakeup_enabled_descendants() In (e583d9d USB: global suspend and remote wakeup don't mix) we introduced wakeup_enabled_descendants() as a static function. We'd like to use this function in USB controller drivers to know if we should keep the controller on during suspend time, since doing so has a power impact. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2019-04-17 17:13:53 -07:00
USB: global suspend and remote wakeup don't mix The hub driver was recently changed to use "global" suspend for system suspend transitions on non-SuperSpeed buses. This means that we don't suspend devices individually by setting the suspend feature on the upstream hub port; instead devices all go into suspend automatically when the root hub stops transmitting packets. The idea was to save time and to avoid certain kinds of wakeup races. Now it turns out that many hubs are buggy; they don't relay wakeup requests from a downstream port to their upstream port if the downstream port's suspend feature is not set (depending on the speed of the downstream port, whether or not the hub is enabled for remote wakeup, and possibly other factors). We can't have hubs dropping wakeup requests. Therefore this patch goes partway back to the old policy: It sets the suspend feature for a port if the device attached to that port or any of its descendants is enabled for wakeup. People will still be able to benefit from the time savings if they don't care about wakeup and leave it disabled on all their devices. In order to accomplish this, the patch adds a new field to the usb_hub structure: wakeup_enabled_descendants is a count of how many devices below a suspended hub are enabled for remote wakeup. A corresponding new subroutine determines the number of wakeup-enabled devices at or below an arbitrary suspended USB device. This should be applied to the 3.10 stable kernel. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Toralf Förster <toralf.foerster@gmx.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-11 14:58:04 -04:00
USB: use "global suspend" for system sleep on USB-2 buses This patch (as1674) speeds up system sleep transitions by not suspending each individual device on a USB-1.1 or USB-2 bus. The devices will automatically go into suspend when their root hubs are suspended (i.e., stop sending out Start-Of-Frame packets) -- this is what the USB spec calls "global suspend". Since this is what we do already when CONFIG_USB_SUSPEND isn't enabled, it shouldn't cause any problems. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-27 16:14:19 -04:00
USB: remove excess code from hub.c This patch (as917) removes a now-unnecessary level of subroutine nesting from hub.c. Since usb_port_suspend() does nothing but call hub_port_suspend(), and usb_port_resume() does nothing but call hub_port_resume(), there's no reason to keep the routines separate. Also included in the patch are a few cosmetic changes involving whitespace and use of braces. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:35:16 -04:00
USB: Verify the port status when timeout happens during port suspend On the Realtek high-speed Hub(0bda:5487), the port which has wakeup enabled_descendants will sometimes timeout when setting PORT_SUSPEND feature. After checking the PORT_SUSPEND bit in wPortStatus, it is already set which means the port has been suspended. We should treat it suspended to make sure it will be resumed correctly. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Chris Chiu <chris.chiu@canonical.com> Link: https://lore.kernel.org/r/20210514045405.5261-2-chris.chiu@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-14 12:54:04 +08:00
usb: hub: port: add sysfs entry to switch port power In some cases the port of an hub needs to be disabled or switched off and on again. E.g. when the connected device needs to be re-enumerated. Or it needs to be explicitly disabled while the rest of the usb tree stays working. For this purpose this patch adds an sysfs switch to enable/disable the port on any hub. In the case the hub is supporting power switching, the power line will be disabled to the connected device. When the port gets disabled, the associated device gets disconnected and removed from the logical usb tree. No further device will be enumerated on that port until the port gets enabled again. Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220607114522.3359148-1-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-07 13:45:22 +02:00
USB: Verify the port status when timeout happens during port suspend On the Realtek high-speed Hub(0bda:5487), the port which has wakeup enabled_descendants will sometimes timeout when setting PORT_SUSPEND feature. After checking the PORT_SUSPEND bit in wPortStatus, it is already set which means the port has been suspended. We should treat it suspended to make sure it will be resumed correctly. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Chris Chiu <chris.chiu@canonical.com> Link: https://lore.kernel.org/r/20210514045405.5261-2-chris.chiu@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-14 12:54:04 +08:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
USB: don't let the hub driver prevent system sleep This patch (as1465) continues implementation of the policy that errors during suspend or hibernation should not prevent the system from going to sleep. In this case, failure to turn on the Suspend feature for a hub port shouldn't be reported as an error. There are situations where this does actually occur (such as when the device plugged into that port was disconnected in the recent past), and it turns out to be harmless. There's no reason for it to prevent a system sleep. Also, don't allow the hub driver to fail a system suspend if the downstream ports aren't all suspended. This is also harmless (and should never happen, given the change mentioned above); printing a warning message in the kernel log is all we really need to do. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-06-15 16:29:16 -04:00
usb: Avoid unnecessary LPM enabling and disabling during suspend and resume The original motivation for disabling/enabling Link PM at device suspend/resume was to force link state to go via U0 before suspend sets the link state to U3. Going directly from U2 to U3 is not allowed. Disabling LPM will forced the link state to U0, but will send a lot of Set port feature requests for evert suspend and resume. This is not needed as Hub hardware will take care of going via U0 when a U2 -> U3 transition is requested [1] [1] USB 3.1 specification section 10.16.2.10 Set Port Feature: "If the value is 3, then host software wants to selectively suspend the device connected to this port. The hub shall transition the link to U3 from any of the other U states using allowed link state transitions. If the port is not already in the U0 state, then it shall transition the port to the U0 state and then initiate the transition to U3. While this state is active, the hub does not propagate downstream-directed traffic to this port, but the hub will respond to resume signaling from the port" Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-06-15 11:55:41 +03:00
USB: handle LPM errors during device suspend correctly The hub driver's usb_port_suspend() routine doesn't handle errors related to Link Power Management properly. It always returns failure, it doesn't try to clean up the wakeup setting, (in the case of system sleep) it doesn't try to go ahead with the port suspend regardless, and it doesn't try to apply the new power-off mechanism. This patch fixes these problems. Signed-off-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>
2013-07-30 15:39:02 -04:00
usbcore: enable USB2 LPM if port suspend fails 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-05 00:50:10 +08:00
USB: Consolidate LPM checks to avoid enabling LPM twice USB Bluetooth controller QCA ROME (0cf3:e007) sometimes stops working after S3: [ 165.110742] Bluetooth: hci0: using NVM file: qca/nvm_usb_00000302.bin [ 168.432065] Bluetooth: hci0: Failed to send body at 4 of 1953 (-110) After some experiments, I found that disabling LPM can workaround the issue. On some platforms, the USB power is cut during S3, so the driver uses reset-resume to resume the device. During port resume, LPM gets enabled twice, by usb_reset_and_verify_device() and usb_port_resume(). Consolidate all checks into new LPM helpers to make sure LPM only gets enabled once. Fixes: de68bab4fa96 ("usb: Don't enable USB 2.0 Link PM by default.”) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: stable <stable@vger.kernel.org> # after much soaking Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-12 03:54:25 +08:00
usbcore: enable USB2 LPM if port suspend fails 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-05 00:50:10 +08:00
USB: handle LPM errors during device suspend correctly The hub driver's usb_port_suspend() routine doesn't handle errors related to Link Power Management properly. It always returns failure, it doesn't try to clean up the wakeup setting, (in the case of system sleep) it doesn't try to go ahead with the port suspend regardless, and it doesn't try to apply the new power-off mechanism. This patch fixes these problems. Signed-off-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>
2013-07-30 15:39:02 -04:00
USB: Disable USB 3.0 LPM in critical sections. 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-02 14:25:52 -07:00
USB: don't let the hub driver prevent system sleep This patch (as1465) continues implementation of the policy that errors during suspend or hibernation should not prevent the system from going to sleep. In this case, failure to turn on the Suspend feature for a hub port shouldn't be reported as an error. There are situations where this does actually occur (such as when the device plugged into that port was disconnected in the recent past), and it turns out to be harmless. There's no reason for it to prevent a system sleep. Also, don't allow the hub driver to fail a system suspend if the downstream ports aren't all suspended. This is also harmless (and should never happen, given the change mentioned above); printing a warning message in the kernel log is all we really need to do. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-06-15 16:29:16 -04:00
PM / Runtime: Add macro to test for runtime PM events This patch (as1482) adds a macro for testing whether or not a pm_message value represents an autosuspend or autoresume (i.e., a runtime PM) event. Encapsulating this notion seems preferable to open-coding the test all over the place. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-08-19 23:49:48 +02:00
USB: don't let the hub driver prevent system sleep This patch (as1465) continues implementation of the policy that errors during suspend or hibernation should not prevent the system from going to sleep. In this case, failure to turn on the Suspend feature for a hub port shouldn't be reported as an error. There are situations where this does actually occur (such as when the device plugged into that port was disconnected in the recent past), and it turns out to be harmless. There's no reason for it to prevent a system sleep. Also, don't allow the hub driver to fail a system suspend if the downstream ports aren't all suspended. This is also harmless (and should never happen, given the change mentioned above); printing a warning message in the kernel log is all we really need to do. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-06-15 16:29:16 -04:00
USB: remove excess code from hub.c This patch (as917) removes a now-unnecessary level of subroutine nesting from hub.c. Since usb_port_suspend() does nothing but call hub_port_suspend(), and usb_port_resume() does nothing but call hub_port_resume(), there's no reason to keep the routines separate. Also included in the patch are a few cosmetic changes involving whitespace and use of braces. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:35:16 -04:00
USB: Verify the port status when timeout happens during port suspend On the Realtek high-speed Hub(0bda:5487), the port which has wakeup enabled_descendants will sometimes timeout when setting PORT_SUSPEND feature. After checking the PORT_SUSPEND bit in wPortStatus, it is already set which means the port has been suspended. We should treat it suspended to make sure it will be resumed correctly. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Chris Chiu <chris.chiu@canonical.com> Link: https://lore.kernel.org/r/20210514045405.5261-2-chris.chiu@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-14 12:54:04 +08:00
USB: Add wakeup info to debugging messages This patch (as1487) improves the usbcore debugging output for port suspend and bus suspend, by stating whether or not remote wakeup is enabled. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-09-27 21:54:22 +02:00
USB: use "global suspend" for system sleep on USB-2 buses This patch (as1674) speeds up system sleep transitions by not suspending each individual device on a USB-1.1 or USB-2 bus. The devices will automatically go into suspend when their root hubs are suspended (i.e., stop sending out Start-Of-Frame packets) -- this is what the USB spec calls "global suspend". Since this is what we do already when CONFIG_USB_SUSPEND isn't enabled, it shouldn't cause any problems. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-27 16:14:19 -04:00
USB: global suspend and remote wakeup don't mix The hub driver was recently changed to use "global" suspend for system suspend transitions on non-SuperSpeed buses. This means that we don't suspend devices individually by setting the suspend feature on the upstream hub port; instead devices all go into suspend automatically when the root hub stops transmitting packets. The idea was to save time and to avoid certain kinds of wakeup races. Now it turns out that many hubs are buggy; they don't relay wakeup requests from a downstream port to their upstream port if the downstream port's suspend feature is not set (depending on the speed of the downstream port, whether or not the hub is enabled for remote wakeup, and possibly other factors). We can't have hubs dropping wakeup requests. Therefore this patch goes partway back to the old policy: It sets the suspend feature for a port if the device attached to that port or any of its descendants is enabled for wakeup. People will still be able to benefit from the time savings if they don't care about wakeup and leave it disabled on all their devices. In order to accomplish this, the patch adds a new field to the usb_hub structure: wakeup_enabled_descendants is a count of how many devices below a suspended hub are enabled for remote wakeup. A corresponding new subroutine determines the number of wakeup-enabled devices at or below an arbitrary suspended USB device. This should be applied to the 3.10 stable kernel. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Toralf Förster <toralf.foerster@gmx.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-11 14:58:04 -04:00
USB: use "global suspend" for system sleep on USB-2 buses This patch (as1674) speeds up system sleep transitions by not suspending each individual device on a USB-1.1 or USB-2 bus. The devices will automatically go into suspend when their root hubs are suspended (i.e., stop sending out Start-Of-Frame packets) -- this is what the USB spec calls "global suspend". Since this is what we do already when CONFIG_USB_SUSPEND isn't enabled, it shouldn't cause any problems. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-27 16:14:19 -04:00
USB: global suspend and remote wakeup don't mix The hub driver was recently changed to use "global" suspend for system suspend transitions on non-SuperSpeed buses. This means that we don't suspend devices individually by setting the suspend feature on the upstream hub port; instead devices all go into suspend automatically when the root hub stops transmitting packets. The idea was to save time and to avoid certain kinds of wakeup races. Now it turns out that many hubs are buggy; they don't relay wakeup requests from a downstream port to their upstream port if the downstream port's suspend feature is not set (depending on the speed of the downstream port, whether or not the hub is enabled for remote wakeup, and possibly other factors). We can't have hubs dropping wakeup requests. Therefore this patch goes partway back to the old policy: It sets the suspend feature for a port if the device attached to that port or any of its descendants is enabled for wakeup. People will still be able to benefit from the time savings if they don't care about wakeup and leave it disabled on all their devices. In order to accomplish this, the patch adds a new field to the usb_hub structure: wakeup_enabled_descendants is a count of how many devices below a suspended hub are enabled for remote wakeup. A corresponding new subroutine determines the number of wakeup-enabled devices at or below an arbitrary suspended USB device. This should be applied to the 3.10 stable kernel. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Toralf Förster <toralf.foerster@gmx.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-11 14:58:04 -04:00
USB: remove excess code from hub.c This patch (as917) removes a now-unnecessary level of subroutine nesting from hub.c. Since usb_port_suspend() does nothing but call hub_port_suspend(), and usb_port_resume() does nothing but call hub_port_resume(), there's no reason to keep the routines separate. Also included in the patch are a few cosmetic changes involving whitespace and use of braces. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:35:16 -04:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
usb: make usb_port flags atomic, rename did_runtime_put to child_usage We want to manipulate ->did_runtime_put in usb_port_runtime_resume(), but we don't want that to collide with other updates. Move usb_port flags to new port-bitmap fields in usb_hub. "did_runtime_put" is renamed "child_usage_bits" to reflect that it is strictly standing in for the fact that usb_devices are not the device_model children of their parent port. Signed-off-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:52 -07:00
usb: don't check pm qos NO_POWER_OFF flag in usb_port_suspend() The pm qos NO_POWER_OFF flag is checked twice during usb device suspend to see if the usb port power off condition is met. This is redundant and also will prevent the port from being powered off if the NO_POWER_OFF flag is changed to 1 from 0 after the device was already suspended. More detail in the following link. http://marc.info/?l=linux-usb&m=136543949130865&w=2 This patch should be backported to kernels as old as 3.7, that contain the commit f7ac7787ad361e31a7972e2854ed8dc2eedfac3b "usb/acpi: Use ACPI methods to power off ports." Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2013-07-03 22:17:54 +08:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
USB: improve uses of usb_mark_last_busy This patch (as1434) cleans up the uses of usb_mark_last_busy() in usbcore. The function will be called when a device is resumed and whenever a usage count is decremented. A call that was missing from the hub driver is added: A hub is used whenever one of its ports gets suspended (this prevents hubs from suspending immediately after their last child). In addition, the call to disable autosuspend support for new devices by default is moved from usb_detect_quirks() (where it doesn't really belong) into usb_new_device() along with all the other runtime-PM initializations. Finally, an extra pm_runtime_get_noresume() is added to prevent new devices from autosuspending while they are being registered. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-15 15:57:58 -05:00
usb: introduce port status lock In general we do not want khubd to act on port status changes that are the result of in progress resets or USB runtime PM operations. Specifically port power control testing has been able to trigger an unintended disconnect in hub_port_connect_change(), paraphrasing: if ((portstatus & USB_PORT_STAT_CONNECTION) && udev && udev->state != USB_STATE_NOTATTACHED) { if (portstatus & USB_PORT_STAT_ENABLE) { /* Nothing to do */ } else if (udev->state == USB_STATE_SUSPENDED && udev->persist_enabled) { ... } else { /* Don't resuscitate */; } } ...by falling to the "Don't resuscitate" path or missing USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of modifying the port status. So, we want a new lock to hold off khubd for a given port while the child device is being suspended, resumed, or reset. The lock ordering rules are now usb_lock_device() => usb_lock_port(). This is mandated by the device core which may hold the device_lock on the usb_device before invoking usb_port_{suspend|resume} which in turn take the status_lock on the usb_port. We attempt to hold the status_lock for the duration of a port_event() run, and drop/re-acquire it when needing to take the device_lock. The lock is also dropped/re-acquired during hub_port_reconnect(). This patch also deletes hub->busy_bits as all use cases are now covered by port PM runtime synchronization or the port->status_lock and it pushes down usb_device_lock() into usb_remote_wakeup(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:26 -07:00
USB: remove __usb_port_suspend This patch (as915b) combines the public routine usb_port_suspend() and the private routine __usb_port_suspend() into a single function. By removing the explicit mention of otg_port in the call to __usb_port_suspend(), we prevent a possible error in which the system tries to perform HNP on the wrong port when a non-targeted device is plugged into a non-OTG port. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 16:51:28 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] root hub updates (greater half) This patch associates hub suspend and resume logic (including for root hubs) with CONFIG_PM -- instead of CONFIG_USB_SUSPEND as before -- thereby unifying two troublesome versions of suspend logic into just one. It'll be easier to keep things right from now on. - Now usbcore _always_ calls hcd->hub_suspend as needed, instead of only when USB_SUSPEND is enabled: * Those root hub methods are now called from hub suspend/resume; no more skipping between layers during device suspend/resume; * It now handles cases allowed by sysfs or autosuspended root hubs, by forcing the hub interface to resume too. - All devices, including virtual root hubs, now get the same treatment on their resume paths ... including re-activating all their interfaces. Plus it gets rid of those stub copies of usb_{suspend,resume}_device(), and updates the Kconfig to match the new definition of USB_SUSPEND: it provides (a) selective suspend, downstream from hubs; and (b) remote wakeup, upstream from any device configuration which supports it. This calls for minor followup patches for most HCDs (and their PCI glue). Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> drivers/usb/core/Kconfig | 11 ++- drivers/usb/core/hub.c | 163 +++++++++++++++++++++++++---------------------- 2 files changed, 97 insertions(+), 77 deletions(-)
2005-09-22 22:37:29 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] remove usb_suspend_device() parameter This patch removes the extra usb_suspend_device() parameter. The original reason to pass that parameter was so that this routine could suspend any active children. A previous patch removed that functionality ... leaving no reason to pass the parameter. A close analogy is pci_set_power_state, which doesn't need a pm_message_t either. On the internal code path that comes through the driver model, the parameter is now used to distinguish cases where USB devices need to "freeze" but not suspend. It also checks for an error case that's accessible through sysfs: attempting to suspend a device before its interfaces (or for hubs, ports). Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> drivers/usb/core/hub.c | 34 +++++++++++++++++++++------------- drivers/usb/core/usb.c | 23 +++++++++++++++++++++-- drivers/usb/host/ehci-hcd.c | 2 +- drivers/usb/host/isp116x-hcd.c | 2 +- drivers/usb/host/ohci-pci.c | 2 +- include/linux/usb.h | 2 +- 6 files changed, 46 insertions(+), 19 deletions(-)
2005-09-13 19:57:27 -07:00
USB: unify reset_resume and normal resume This patch (as919) unifies the code paths used for normal resume and for reset-resume. Earlier I had failed to note a section in the USB spec which requires the host to resume a suspended port before resetting it if the attached device is enabled for remote wakeup. Since the port has to be resumed anyway, we might as well reuse the existing code. The main changes are: usb_reset_suspended_device() is eliminated. usb_root_hub_lost_power() is moved down next to the hub_reset_resume() routine, to which it is logically related. finish_port_resume() does a port reset() if the device's reset_resume flag is set. usb_port_resume() doesn't check whether the port is initially enabled if this is a USB-Persist sort of resume. Code to perform the port reset is added to the resume pathway for the non-CONFIG_USB_SUSPEND case. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:38:58 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: unify reset_resume and normal resume This patch (as919) unifies the code paths used for normal resume and for reset-resume. Earlier I had failed to note a section in the USB spec which requires the host to resume a suspended port before resetting it if the attached device is enabled for remote wakeup. Since the port has to be resumed anyway, we might as well reuse the existing code. The main changes are: usb_reset_suspended_device() is eliminated. usb_root_hub_lost_power() is moved down next to the hub_reset_resume() routine, to which it is logically related. finish_port_resume() does a port reset() if the device's reset_resume flag is set. usb_port_resume() doesn't check whether the port is initially enabled if this is a USB-Persist sort of resume. Code to perform the port reset is added to the resume pathway for the non-CONFIG_USB_SUSPEND case. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:38:58 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usbcore: rename usb_suspend_device to usb_port_suspend This revised patch (as715b) renames usb_suspend_device to usb_port_suspend, usb_resume_device to usb_port_resume, and finish_device_resume to finish_port_resume. There was no objection to the original version of the patch so this should be okay to apply. The revision was needed only because I have re-arranged the order of the earlier patches. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-07-01 22:07:21 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: unify reset_resume and normal resume This patch (as919) unifies the code paths used for normal resume and for reset-resume. Earlier I had failed to note a section in the USB spec which requires the host to resume a suspended port before resetting it if the attached device is enabled for remote wakeup. Since the port has to be resumed anyway, we might as well reuse the existing code. The main changes are: usb_reset_suspended_device() is eliminated. usb_root_hub_lost_power() is moved down next to the hub_reset_resume() routine, to which it is logically related. finish_port_resume() does a port reset() if the device's reset_resume flag is set. usb_port_resume() doesn't check whether the port is initially enabled if this is a USB-Persist sort of resume. Code to perform the port reset is added to the resume pathway for the non-CONFIG_USB_SUSPEND case. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:38:58 -04:00
USB: hub: handle claim of enabled remote wakeup after reset Some touchscreens have buggy firmware which claims remote wakeup to be enabled after a reset. They nevertheless crash if the feature is cleared by the host. Add a check for reset resume before checking for an enabled remote wakeup feature. On compliant devices the feature must be cleared after a reset anyway. Signed-off-by: Oliver Neukum <oneukum@suse.de> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-29 15:05:57 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: make printk messages more searchable USB: make printk messages more searchable Make USB printk messages long and straightforward. One of these decorated USB error messages cost me non-trivial efforts to locate. Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-15 15:32:01 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: rename khubd to hub_wq in documentation and comments USB hub has started to use a workqueue instead of kthread. Let's update the documentation and comments here and there. This patch mostly just replaces "khubd" with "hub_wq". There are only few exceptions where the whole sentence was updated. These more complicated changes can be found in the following files: Documentation/usb/hotplug.txt drivers/net/usb/usbnet.c drivers/usb/core/hcd.c drivers/usb/host/ohci-hcd.c drivers/usb/host/xhci.c Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:23 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: unify reset_resume and normal resume This patch (as919) unifies the code paths used for normal resume and for reset-resume. Earlier I had failed to note a section in the USB spec which requires the host to resume a suspended port before resetting it if the attached device is enabled for remote wakeup. Since the port has to be resumed anyway, we might as well reuse the existing code. The main changes are: usb_reset_suspended_device() is eliminated. usb_root_hub_lost_power() is moved down next to the hub_reset_resume() routine, to which it is logically related. finish_port_resume() does a port reset() if the device's reset_resume flag is set. usb_port_resume() doesn't check whether the port is initially enabled if this is a USB-Persist sort of resume. Code to perform the port reset is added to the resume pathway for the non-CONFIG_USB_SUSPEND case. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:38:58 -04:00
USB: disable reset-resume when USB_QUIRK_RESET is set The USB_QUIRK_RESET flag indicates that a USB device changes its identity in some way when it is reset. It may lose its firmware, its descriptors may change, or it may switch back to a default mode of operation. If a device does this, the kernel needs to avoid resetting it. Resets are likely to fail, or worse, succeed while changing the device's state in a way the system can't detect. This means we should disable the reset-resume mechanism whenever this quirk flag is present. An attempted reset-resume will fail, the device will be logically disconnected, and later on the hub driver will rediscover and re-enumerate the device. This will cause the appropriate udev events to be generated, so that userspace will have a chance to switch the device into its normal operating mode, if necessary. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Oliver Neukum <oliver@neukum.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-18 10:39:05 -04:00
USB: use reset_resume when normal resume fails This patch (as1109b) makes USB-Persist more resilient to errors. With the current code, if a normal resume fails, it's an unrecoverable error. With the patch, if a normal resume fails (and if the device is enabled for USB-Persist) then a reset-resume is tried. This fixes the problem reported in Bugzilla #10977. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-30 11:14:43 -04:00
USB: disable reset-resume when USB_QUIRK_RESET is set The USB_QUIRK_RESET flag indicates that a USB device changes its identity in some way when it is reset. It may lose its firmware, its descriptors may change, or it may switch back to a default mode of operation. If a device does this, the kernel needs to avoid resetting it. Resets are likely to fail, or worse, succeed while changing the device's state in a way the system can't detect. This means we should disable the reset-resume mechanism whenever this quirk flag is present. An attempted reset-resume will fail, the device will be logically disconnected, and later on the hub driver will rediscover and re-enumerate the device. This will cause the appropriate udev events to be generated, so that userspace will have a chance to switch the device into its normal operating mode, if necessary. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Oliver Neukum <oliver@neukum.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-18 10:39:05 -04:00
USB: unify reset_resume and normal resume This patch (as919) unifies the code paths used for normal resume and for reset-resume. Earlier I had failed to note a section in the USB spec which requires the host to resume a suspended port before resetting it if the attached device is enabled for remote wakeup. Since the port has to be resumed anyway, we might as well reuse the existing code. The main changes are: usb_reset_suspended_device() is eliminated. usb_root_hub_lost_power() is moved down next to the hub_reset_resume() routine, to which it is logically related. finish_port_resume() does a port reset() if the device's reset_resume flag is set. usb_port_resume() doesn't check whether the port is initially enabled if this is a USB-Persist sort of resume. Code to perform the port reset is added to the resume pathway for the non-CONFIG_USB_SUSPEND case. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:38:58 -04:00
drivers: usb: core: {file,hub,sysfs,usb}.c: Whitespace fixes including: - removing of trailing whitespace - removing spaces before array indexing (foo [] to foo[]) - reindention of a switch-case block - spaces to tabs Signed-off-by: Matthias Beyer <mail@beyermatthias.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-10 23:41:27 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: unify reset_resume and normal resume This patch (as919) unifies the code paths used for normal resume and for reset-resume. Earlier I had failed to note a section in the USB spec which requires the host to resume a suspended port before resetting it if the attached device is enabled for remote wakeup. Since the port has to be resumed anyway, we might as well reuse the existing code. The main changes are: usb_reset_suspended_device() is eliminated. usb_root_hub_lost_power() is moved down next to the hub_reset_resume() routine, to which it is logically related. finish_port_resume() does a port reset() if the device's reset_resume flag is set. usb_port_resume() doesn't check whether the port is initially enabled if this is a USB-Persist sort of resume. Code to perform the port reset is added to the resume pathway for the non-CONFIG_USB_SUSPEND case. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:38:58 -04:00
USB: accept 1-byte Device Status replies, fixing some b0rken devices Some devices have a bug which causes them to send a 1-byte reply to Get-Device-Status requests instead of 2 bytes as required by the spec. This doesn't play well with autosuspend, since we look for a valid status reply to make sure the device is still present when it resumes. Without both bytes, we assume the device has been disconnected. Lack of the second byte shouldn't matter much, since the spec requires it always to be equal to 0. Hence this patch (as959) causes finish_port_resume() to accept a 1-byte reply as valid. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: David Brownell <david-b@pacbell.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-08-14 10:56:10 -04:00
usb: core: introduce a new usb_get_std_status() helper This new helper is a simple wrapper around usb_get_status(). This patch is in preparation to adding support for fetching PTM_STATUS types. No functional changes. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-02 10:57:40 +02:00
USB: use reset_resume when normal resume fails This patch (as1109b) makes USB-Persist more resilient to errors. With the current code, if a normal resume fails, it's an unrecoverable error. With the patch, if a normal resume fails (and if the device is enabled for USB-Persist) then a reset-resume is tried. This fixes the problem reported in Bugzilla #10977. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-30 11:14:43 -04:00
USB: unify reset_resume and normal resume This patch (as919) unifies the code paths used for normal resume and for reset-resume. Earlier I had failed to note a section in the USB spec which requires the host to resume a suspended port before resetting it if the attached device is enabled for remote wakeup. Since the port has to be resumed anyway, we might as well reuse the existing code. The main changes are: usb_reset_suspended_device() is eliminated. usb_root_hub_lost_power() is moved down next to the hub_reset_resume() routine, to which it is logically related. finish_port_resume() does a port reset() if the device's reset_resume flag is set. usb_port_resume() doesn't check whether the port is initially enabled if this is a USB-Persist sort of resume. Code to perform the port reset is added to the resume pathway for the non-CONFIG_USB_SUSPEND case. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:38:58 -04:00
[PATCH] USB hub: don't return status > 0 from resume finish_device_resume() in the hub driver isn't careful always to return a negative code in all the error pathways. It also doesn't return 0 in all the success pathways. This patch (as724) fixes the behavior. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-19 15:12:38 -04:00
USB: remove excess code from hub.c This patch (as917) removes a now-unnecessary level of subroutine nesting from hub.c. Since usb_port_suspend() does nothing but call hub_port_suspend(), and usb_port_resume() does nothing but call hub_port_resume(), there's no reason to keep the routines separate. Also included in the patch are a few cosmetic changes involving whitespace and use of braces. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:35:16 -04:00
USB: hub: handle claim of enabled remote wakeup after reset Some touchscreens have buggy firmware which claims remote wakeup to be enabled after a reset. They nevertheless crash if the feature is cleared by the host. Add a check for reset resume before checking for an enabled remote wakeup feature. On compliant devices the feature must be cleared after a reset anyway. Signed-off-by: Oliver Neukum <oneukum@suse.de> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-29 15:05:57 +01:00
USB: refactor code for enabling/disabling remote wakeup The hub driver is inconsistent in its organization of code for enabling and disabling remote wakeup. There is a special routine to disable wakeup for SuperSpeed devices but not for slower devices, and there is no special routine to enable wakeup. This patch refactors the code. It renames and changes the existing function to make it handle both SuperSpeed and non-SuperSpeed devices, and it adds a corresponding routine to enable remote wakeup. It also changes the speed determination to look at the device's speed rather than the speed of the parent hub -- this shouldn't make any difference because a SuperSpeed device always has to be attached to a SuperSpeed hub and conversely. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-30 15:37:33 -04:00
usb: Using correct way to clear usb3.0 device's remote wakeup feature. Usb3.0 device defines function remote wakeup which is only for interface recipient rather than device recipient. This is different with usb2.0 device's remote wakeup feature which is defined for device recipient. According usb3.0 spec 9.4.5, the function remote wakeup can be modified by the SetFeature() requests using the FUNCTION_SUSPEND feature selector. This patch is to use correct way to disable usb3.0 device's function remote wakeup after suspend error and resuming. This should be backported to kernels as old as 3.4, that contain the commit 623bef9e03a60adc623b09673297ca7a1cdfb367 "USB/xhci: Enable remote wakeup for USB3 devices." Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2013-01-24 10:31:28 +08:00
USB: refactor code for enabling/disabling remote wakeup The hub driver is inconsistent in its organization of code for enabling and disabling remote wakeup. There is a special routine to disable wakeup for SuperSpeed devices but not for slower devices, and there is no special routine to enable wakeup. This patch refactors the code. It renames and changes the existing function to make it handle both SuperSpeed and non-SuperSpeed devices, and it adds a corresponding routine to enable remote wakeup. It also changes the speed determination to look at the device's speed rather than the speed of the parent hub -- this shouldn't make any difference because a SuperSpeed device always has to be attached to a SuperSpeed hub and conversely. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-30 15:37:33 -04:00
usb: Using correct way to clear usb3.0 device's remote wakeup feature. Usb3.0 device defines function remote wakeup which is only for interface recipient rather than device recipient. This is different with usb2.0 device's remote wakeup feature which is defined for device recipient. According usb3.0 spec 9.4.5, the function remote wakeup can be modified by the SetFeature() requests using the FUNCTION_SUSPEND feature selector. This patch is to use correct way to disable usb3.0 device's function remote wakeup after suspend error and resuming. This should be backported to kernels as old as 3.4, that contain the commit 623bef9e03a60adc623b09673297ca7a1cdfb367 "USB/xhci: Enable remote wakeup for USB3 devices." Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2013-01-24 10:31:28 +08:00
usb: core: introduce a new usb_get_std_status() helper This new helper is a simple wrapper around usb_get_status(). This patch is in preparation to adding support for fetching PTM_STATUS types. No functional changes. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-02 10:57:40 +02:00
usb: Using correct way to clear usb3.0 device's remote wakeup feature. Usb3.0 device defines function remote wakeup which is only for interface recipient rather than device recipient. This is different with usb2.0 device's remote wakeup feature which is defined for device recipient. According usb3.0 spec 9.4.5, the function remote wakeup can be modified by the SetFeature() requests using the FUNCTION_SUSPEND feature selector. This patch is to use correct way to disable usb3.0 device's function remote wakeup after suspend error and resuming. This should be backported to kernels as old as 3.4, that contain the commit 623bef9e03a60adc623b09673297ca7a1cdfb367 "USB/xhci: Enable remote wakeup for USB3 devices." Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2013-01-24 10:31:28 +08:00
USB: refactor code for enabling/disabling remote wakeup The hub driver is inconsistent in its organization of code for enabling and disabling remote wakeup. There is a special routine to disable wakeup for SuperSpeed devices but not for slower devices, and there is no special routine to enable wakeup. This patch refactors the code. It renames and changes the existing function to make it handle both SuperSpeed and non-SuperSpeed devices, and it adds a corresponding routine to enable remote wakeup. It also changes the speed determination to look at the device's speed rather than the speed of the parent hub -- this shouldn't make any difference because a SuperSpeed device always has to be attached to a SuperSpeed hub and conversely. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-30 15:37:33 -04:00
[PATCH] USB: Fix locking for USB suspend/resume The earlier USB locking updates didn't touch the suspend/resume routines. They need updating as well, since now the caller holds the device semaphore. This patch (as608) makes the necessary changes. It also adds a line to store the correct power state when a device is resumed, something which was unaccountably missing. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-21 11:58:07 -05:00
usb: Using correct way to clear usb3.0 device's remote wakeup feature. Usb3.0 device defines function remote wakeup which is only for interface recipient rather than device recipient. This is different with usb2.0 device's remote wakeup feature which is defined for device recipient. According usb3.0 spec 9.4.5, the function remote wakeup can be modified by the SetFeature() requests using the FUNCTION_SUSPEND feature selector. This patch is to use correct way to disable usb3.0 device's function remote wakeup after suspend error and resuming. This should be backported to kernels as old as 3.4, that contain the commit 623bef9e03a60adc623b09673297ca7a1cdfb367 "USB/xhci: Enable remote wakeup for USB3 devices." Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2013-01-24 10:31:28 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: Fix persist resume of some SS USB devices Problem Summary: Problem has been observed generally with PM states where VBUS goes off during suspend. There are some SS USB devices which take longer time for link training compared to many others. Such devices fail to reconnect with same old address which was associated with it before suspend. When system resumes, at some point of time (dpm_run_callback-> usb_dev_resume->usb_resume->usb_resume_both->usb_resume_device-> usb_port_resume) SW reads hub status. If device is present, then it finishes port resume and re-enumerates device with same address. If device is not present then, SW thinks that device was removed during suspend and therefore does logical disconnection and removes all the resource allocated for this device. Now, if I put sufficient delay just before root hub status read in usb_resume_device then, SW sees always that device is present. In normal course(without any delay) SW sees that no device is present and then SW removes all resource associated with the device at this port. In the latter case, after sometime, device says that hey I am here, now host enumerates it, but with new address. Problem had been reproduced when I connect verbatim USB3.0 hard disc with my STiH407 XHCI host running with 3.10 kernel. I see that similar problem has been reported here. https://bugzilla.kernel.org/show_bug.cgi?id=53211 Reading above it seems that bug was not in 3.6.6 and was present in 3.8 and again it was not present for some in 3.12.6, while it was present for few others. I tested with 3.13-FC19 running at i686 desktop, problem was still there. However, I was failed to reproduce it with 3.16-RC4 running at same i686 machine. I would say it is just a random observation. Problem for few devices is always there, as I am unable to find a proper fix for the issue. So, now question is what should be the amount of delay so that host is always able to recognize suspended device after resume. XHCI specs 4.19.4 says that when Link training is successful, port sets CSC bit to 1. So if SW reads port status before successful link training, then it will not find device to be present. USB Analyzer log with such buggy devices show that in some cases device switch on the RX termination after long delay of host enabling the VBUS. In few other cases it has been seen that device fails to negotiate link training in first attempt. It has been reported till now that few devices take as long as 2000 ms to train the link after host enabling its VBUS and RX termination. This patch implements a 2000 ms timeout for CSC bit to set ie for link training. If in a case link trains before timeout, loop will exit earlier. This patch implements above delay, but only for SS device and when persist is enabled. So, for the good device overhead is almost none. While for the bad devices penalty could be the time which it take for link training. But, If a device was connected before suspend, and was removed while system was asleep, then the penalty would be the timeout ie 2000 ms. Results: Verbatim USB SS hard disk connected with STiH407 USB host running 3.10 Kernel resumes in 461 msecs without this patch, but hard disk is assigned a new device address. Same system resumes in 790 msecs with this patch, but with old device address. Cc: <stable@vger.kernel.org> Signed-off-by: Pratyush Anand <pratyush.anand@st.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-18 12:37:10 +05:30
usb: Add connected retry on resume for non SS devices Currently usb_port_resume waits for up to 2 seconds for CONNECT status for SS devices only. This change will do the same thing for non-SS devices even though the reason is a little different. This will fix an issue where VBUS is turned off during system wide "suspend to ram" and some 2.0 devices take greater than the current max of 100ms to show connected after VBUS is enabled. This is most commonly seen on hard drive based devices and USB3.0 devices plugged into a 2.0 only port. Signed-off-by: Al Cooper <alcooperx@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-02 14:55:07 -05:00
USB: Fix persist resume of some SS USB devices Problem Summary: Problem has been observed generally with PM states where VBUS goes off during suspend. There are some SS USB devices which take longer time for link training compared to many others. Such devices fail to reconnect with same old address which was associated with it before suspend. When system resumes, at some point of time (dpm_run_callback-> usb_dev_resume->usb_resume->usb_resume_both->usb_resume_device-> usb_port_resume) SW reads hub status. If device is present, then it finishes port resume and re-enumerates device with same address. If device is not present then, SW thinks that device was removed during suspend and therefore does logical disconnection and removes all the resource allocated for this device. Now, if I put sufficient delay just before root hub status read in usb_resume_device then, SW sees always that device is present. In normal course(without any delay) SW sees that no device is present and then SW removes all resource associated with the device at this port. In the latter case, after sometime, device says that hey I am here, now host enumerates it, but with new address. Problem had been reproduced when I connect verbatim USB3.0 hard disc with my STiH407 XHCI host running with 3.10 kernel. I see that similar problem has been reported here. https://bugzilla.kernel.org/show_bug.cgi?id=53211 Reading above it seems that bug was not in 3.6.6 and was present in 3.8 and again it was not present for some in 3.12.6, while it was present for few others. I tested with 3.13-FC19 running at i686 desktop, problem was still there. However, I was failed to reproduce it with 3.16-RC4 running at same i686 machine. I would say it is just a random observation. Problem for few devices is always there, as I am unable to find a proper fix for the issue. So, now question is what should be the amount of delay so that host is always able to recognize suspended device after resume. XHCI specs 4.19.4 says that when Link training is successful, port sets CSC bit to 1. So if SW reads port status before successful link training, then it will not find device to be present. USB Analyzer log with such buggy devices show that in some cases device switch on the RX termination after long delay of host enabling the VBUS. In few other cases it has been seen that device fails to negotiate link training in first attempt. It has been reported till now that few devices take as long as 2000 ms to train the link after host enabling its VBUS and RX termination. This patch implements a 2000 ms timeout for CSC bit to set ie for link training. If in a case link trains before timeout, loop will exit earlier. This patch implements above delay, but only for SS device and when persist is enabled. So, for the good device overhead is almost none. While for the bad devices penalty could be the time which it take for link training. But, If a device was connected before suspend, and was removed while system was asleep, then the penalty would be the timeout ie 2000 ms. Results: Verbatim USB SS hard disk connected with STiH407 USB host running 3.10 Kernel resumes in 461 msecs without this patch, but hard disk is assigned a new device address. Same system resumes in 790 msecs with this patch, but with old device address. Cc: <stable@vger.kernel.org> Signed-off-by: Pratyush Anand <pratyush.anand@st.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-18 12:37:10 +05:30
usb: Add connected retry on resume for non SS devices Currently usb_port_resume waits for up to 2 seconds for CONNECT status for SS devices only. This change will do the same thing for non-SS devices even though the reason is a little different. This will fix an issue where VBUS is turned off during system wide "suspend to ram" and some 2.0 devices take greater than the current max of 100ms to show connected after VBUS is enabled. This is most commonly seen on hard drive based devices and USB3.0 devices plugged into a 2.0 only port. Signed-off-by: Al Cooper <alcooperx@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-02 14:55:07 -05:00
USB: Fix persist resume of some SS USB devices Problem Summary: Problem has been observed generally with PM states where VBUS goes off during suspend. There are some SS USB devices which take longer time for link training compared to many others. Such devices fail to reconnect with same old address which was associated with it before suspend. When system resumes, at some point of time (dpm_run_callback-> usb_dev_resume->usb_resume->usb_resume_both->usb_resume_device-> usb_port_resume) SW reads hub status. If device is present, then it finishes port resume and re-enumerates device with same address. If device is not present then, SW thinks that device was removed during suspend and therefore does logical disconnection and removes all the resource allocated for this device. Now, if I put sufficient delay just before root hub status read in usb_resume_device then, SW sees always that device is present. In normal course(without any delay) SW sees that no device is present and then SW removes all resource associated with the device at this port. In the latter case, after sometime, device says that hey I am here, now host enumerates it, but with new address. Problem had been reproduced when I connect verbatim USB3.0 hard disc with my STiH407 XHCI host running with 3.10 kernel. I see that similar problem has been reported here. https://bugzilla.kernel.org/show_bug.cgi?id=53211 Reading above it seems that bug was not in 3.6.6 and was present in 3.8 and again it was not present for some in 3.12.6, while it was present for few others. I tested with 3.13-FC19 running at i686 desktop, problem was still there. However, I was failed to reproduce it with 3.16-RC4 running at same i686 machine. I would say it is just a random observation. Problem for few devices is always there, as I am unable to find a proper fix for the issue. So, now question is what should be the amount of delay so that host is always able to recognize suspended device after resume. XHCI specs 4.19.4 says that when Link training is successful, port sets CSC bit to 1. So if SW reads port status before successful link training, then it will not find device to be present. USB Analyzer log with such buggy devices show that in some cases device switch on the RX termination after long delay of host enabling the VBUS. In few other cases it has been seen that device fails to negotiate link training in first attempt. It has been reported till now that few devices take as long as 2000 ms to train the link after host enabling its VBUS and RX termination. This patch implements a 2000 ms timeout for CSC bit to set ie for link training. If in a case link trains before timeout, loop will exit earlier. This patch implements above delay, but only for SS device and when persist is enabled. So, for the good device overhead is almost none. While for the bad devices penalty could be the time which it take for link training. But, If a device was connected before suspend, and was removed while system was asleep, then the penalty would be the timeout ie 2000 ms. Results: Verbatim USB SS hard disk connected with STiH407 USB host running 3.10 Kernel resumes in 461 msecs without this patch, but hard disk is assigned a new device address. Same system resumes in 790 msecs with this patch, but with old device address. Cc: <stable@vger.kernel.org> Signed-off-by: Pratyush Anand <pratyush.anand@st.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-18 12:37:10 +05:30
usb: Add connected retry on resume for non SS devices Currently usb_port_resume waits for up to 2 seconds for CONNECT status for SS devices only. This change will do the same thing for non-SS devices even though the reason is a little different. This will fix an issue where VBUS is turned off during system wide "suspend to ram" and some 2.0 devices take greater than the current max of 100ms to show connected after VBUS is enabled. This is most commonly seen on hard drive based devices and USB3.0 devices plugged into a 2.0 only port. Signed-off-by: Al Cooper <alcooperx@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-02 14:55:07 -05:00
USB: Fix persist resume of some SS USB devices Problem Summary: Problem has been observed generally with PM states where VBUS goes off during suspend. There are some SS USB devices which take longer time for link training compared to many others. Such devices fail to reconnect with same old address which was associated with it before suspend. When system resumes, at some point of time (dpm_run_callback-> usb_dev_resume->usb_resume->usb_resume_both->usb_resume_device-> usb_port_resume) SW reads hub status. If device is present, then it finishes port resume and re-enumerates device with same address. If device is not present then, SW thinks that device was removed during suspend and therefore does logical disconnection and removes all the resource allocated for this device. Now, if I put sufficient delay just before root hub status read in usb_resume_device then, SW sees always that device is present. In normal course(without any delay) SW sees that no device is present and then SW removes all resource associated with the device at this port. In the latter case, after sometime, device says that hey I am here, now host enumerates it, but with new address. Problem had been reproduced when I connect verbatim USB3.0 hard disc with my STiH407 XHCI host running with 3.10 kernel. I see that similar problem has been reported here. https://bugzilla.kernel.org/show_bug.cgi?id=53211 Reading above it seems that bug was not in 3.6.6 and was present in 3.8 and again it was not present for some in 3.12.6, while it was present for few others. I tested with 3.13-FC19 running at i686 desktop, problem was still there. However, I was failed to reproduce it with 3.16-RC4 running at same i686 machine. I would say it is just a random observation. Problem for few devices is always there, as I am unable to find a proper fix for the issue. So, now question is what should be the amount of delay so that host is always able to recognize suspended device after resume. XHCI specs 4.19.4 says that when Link training is successful, port sets CSC bit to 1. So if SW reads port status before successful link training, then it will not find device to be present. USB Analyzer log with such buggy devices show that in some cases device switch on the RX termination after long delay of host enabling the VBUS. In few other cases it has been seen that device fails to negotiate link training in first attempt. It has been reported till now that few devices take as long as 2000 ms to train the link after host enabling its VBUS and RX termination. This patch implements a 2000 ms timeout for CSC bit to set ie for link training. If in a case link trains before timeout, loop will exit earlier. This patch implements above delay, but only for SS device and when persist is enabled. So, for the good device overhead is almost none. While for the bad devices penalty could be the time which it take for link training. But, If a device was connected before suspend, and was removed while system was asleep, then the penalty would be the timeout ie 2000 ms. Results: Verbatim USB SS hard disk connected with STiH407 USB host running 3.10 Kernel resumes in 461 msecs without this patch, but hard disk is assigned a new device address. Same system resumes in 790 msecs with this patch, but with old device address. Cc: <stable@vger.kernel.org> Signed-off-by: Pratyush Anand <pratyush.anand@st.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-18 12:37:10 +05:30
usb: Add connected retry on resume for non SS devices Currently usb_port_resume waits for up to 2 seconds for CONNECT status for SS devices only. This change will do the same thing for non-SS devices even though the reason is a little different. This will fix an issue where VBUS is turned off during system wide "suspend to ram" and some 2.0 devices take greater than the current max of 100ms to show connected after VBUS is enabled. This is most commonly seen on hard drive based devices and USB3.0 devices plugged into a 2.0 only port. Signed-off-by: Al Cooper <alcooperx@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-02 14:55:07 -05:00
usb: hub: make wait_for_connected() take an int instead of a pointer to int The wait_for_connected() function doesn't modify "*port1" and there is no need to pass a pointer. Just pass the int itself. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20211210142028.GB18906@kili Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-10 17:20:28 +03:00
USB: Fix persist resume of some SS USB devices Problem Summary: Problem has been observed generally with PM states where VBUS goes off during suspend. There are some SS USB devices which take longer time for link training compared to many others. Such devices fail to reconnect with same old address which was associated with it before suspend. When system resumes, at some point of time (dpm_run_callback-> usb_dev_resume->usb_resume->usb_resume_both->usb_resume_device-> usb_port_resume) SW reads hub status. If device is present, then it finishes port resume and re-enumerates device with same address. If device is not present then, SW thinks that device was removed during suspend and therefore does logical disconnection and removes all the resource allocated for this device. Now, if I put sufficient delay just before root hub status read in usb_resume_device then, SW sees always that device is present. In normal course(without any delay) SW sees that no device is present and then SW removes all resource associated with the device at this port. In the latter case, after sometime, device says that hey I am here, now host enumerates it, but with new address. Problem had been reproduced when I connect verbatim USB3.0 hard disc with my STiH407 XHCI host running with 3.10 kernel. I see that similar problem has been reported here. https://bugzilla.kernel.org/show_bug.cgi?id=53211 Reading above it seems that bug was not in 3.6.6 and was present in 3.8 and again it was not present for some in 3.12.6, while it was present for few others. I tested with 3.13-FC19 running at i686 desktop, problem was still there. However, I was failed to reproduce it with 3.16-RC4 running at same i686 machine. I would say it is just a random observation. Problem for few devices is always there, as I am unable to find a proper fix for the issue. So, now question is what should be the amount of delay so that host is always able to recognize suspended device after resume. XHCI specs 4.19.4 says that when Link training is successful, port sets CSC bit to 1. So if SW reads port status before successful link training, then it will not find device to be present. USB Analyzer log with such buggy devices show that in some cases device switch on the RX termination after long delay of host enabling the VBUS. In few other cases it has been seen that device fails to negotiate link training in first attempt. It has been reported till now that few devices take as long as 2000 ms to train the link after host enabling its VBUS and RX termination. This patch implements a 2000 ms timeout for CSC bit to set ie for link training. If in a case link trains before timeout, loop will exit earlier. This patch implements above delay, but only for SS device and when persist is enabled. So, for the good device overhead is almost none. While for the bad devices penalty could be the time which it take for link training. But, If a device was connected before suspend, and was removed while system was asleep, then the penalty would be the timeout ie 2000 ms. Results: Verbatim USB SS hard disk connected with STiH407 USB host running 3.10 Kernel resumes in 461 msecs without this patch, but hard disk is assigned a new device address. Same system resumes in 790 msecs with this patch, but with old device address. Cc: <stable@vger.kernel.org> Signed-off-by: Pratyush Anand <pratyush.anand@st.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-18 12:37:10 +05:30
usb: hub: port: add sysfs entry to switch port power In some cases the port of an hub needs to be disabled or switched off and on again. E.g. when the connected device needs to be re-enumerated. Or it needs to be explicitly disabled while the rest of the usb tree stays working. For this purpose this patch adds an sysfs switch to enable/disable the port on any hub. In the case the hub is supporting power switching, the power line will be disabled to the connected device. When the port gets disabled, the associated device gets disconnected and removed from the logical usb tree. No further device will be enumerated on that port until the port gets enabled again. Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220607114522.3359148-1-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-07 13:45:22 +02:00
usb: hub: Don't wait for connect state at resume for powered-off ports wait_for_connected() wait till a port change status to USB_PORT_STAT_CONNECTION, but this is not possible if the port is unpowered. The loop will only exit at timeout. Such case take place if an over-current incident happen while system is in S3. Then during resume wait_for_connected() will wait 2s, which may be noticeable by the user. Signed-off-by: Dominik Bozek <dominikx.bozek@intel.com> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-04-13 10:42:31 -07:00
USB: Fix persist resume of some SS USB devices Problem Summary: Problem has been observed generally with PM states where VBUS goes off during suspend. There are some SS USB devices which take longer time for link training compared to many others. Such devices fail to reconnect with same old address which was associated with it before suspend. When system resumes, at some point of time (dpm_run_callback-> usb_dev_resume->usb_resume->usb_resume_both->usb_resume_device-> usb_port_resume) SW reads hub status. If device is present, then it finishes port resume and re-enumerates device with same address. If device is not present then, SW thinks that device was removed during suspend and therefore does logical disconnection and removes all the resource allocated for this device. Now, if I put sufficient delay just before root hub status read in usb_resume_device then, SW sees always that device is present. In normal course(without any delay) SW sees that no device is present and then SW removes all resource associated with the device at this port. In the latter case, after sometime, device says that hey I am here, now host enumerates it, but with new address. Problem had been reproduced when I connect verbatim USB3.0 hard disc with my STiH407 XHCI host running with 3.10 kernel. I see that similar problem has been reported here. https://bugzilla.kernel.org/show_bug.cgi?id=53211 Reading above it seems that bug was not in 3.6.6 and was present in 3.8 and again it was not present for some in 3.12.6, while it was present for few others. I tested with 3.13-FC19 running at i686 desktop, problem was still there. However, I was failed to reproduce it with 3.16-RC4 running at same i686 machine. I would say it is just a random observation. Problem for few devices is always there, as I am unable to find a proper fix for the issue. So, now question is what should be the amount of delay so that host is always able to recognize suspended device after resume. XHCI specs 4.19.4 says that when Link training is successful, port sets CSC bit to 1. So if SW reads port status before successful link training, then it will not find device to be present. USB Analyzer log with such buggy devices show that in some cases device switch on the RX termination after long delay of host enabling the VBUS. In few other cases it has been seen that device fails to negotiate link training in first attempt. It has been reported till now that few devices take as long as 2000 ms to train the link after host enabling its VBUS and RX termination. This patch implements a 2000 ms timeout for CSC bit to set ie for link training. If in a case link trains before timeout, loop will exit earlier. This patch implements above delay, but only for SS device and when persist is enabled. So, for the good device overhead is almost none. While for the bad devices penalty could be the time which it take for link training. But, If a device was connected before suspend, and was removed while system was asleep, then the penalty would be the timeout ie 2000 ms. Results: Verbatim USB SS hard disk connected with STiH407 USB host running 3.10 Kernel resumes in 461 msecs without this patch, but hard disk is assigned a new device address. Same system resumes in 790 msecs with this patch, but with old device address. Cc: <stable@vger.kernel.org> Signed-off-by: Pratyush Anand <pratyush.anand@st.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-18 12:37:10 +05:30
usb: hub: port: add sysfs entry to switch port power In some cases the port of an hub needs to be disabled or switched off and on again. E.g. when the connected device needs to be re-enumerated. Or it needs to be explicitly disabled while the rest of the usb tree stays working. For this purpose this patch adds an sysfs switch to enable/disable the port on any hub. In the case the hub is supporting power switching, the power line will be disabled to the connected device. When the port gets disabled, the associated device gets disconnected and removed from the logical usb tree. No further device will be enumerated on that port until the port gets enabled again. Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220607114522.3359148-1-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-07 13:45:22 +02:00
USB: Fix persist resume of some SS USB devices Problem Summary: Problem has been observed generally with PM states where VBUS goes off during suspend. There are some SS USB devices which take longer time for link training compared to many others. Such devices fail to reconnect with same old address which was associated with it before suspend. When system resumes, at some point of time (dpm_run_callback-> usb_dev_resume->usb_resume->usb_resume_both->usb_resume_device-> usb_port_resume) SW reads hub status. If device is present, then it finishes port resume and re-enumerates device with same address. If device is not present then, SW thinks that device was removed during suspend and therefore does logical disconnection and removes all the resource allocated for this device. Now, if I put sufficient delay just before root hub status read in usb_resume_device then, SW sees always that device is present. In normal course(without any delay) SW sees that no device is present and then SW removes all resource associated with the device at this port. In the latter case, after sometime, device says that hey I am here, now host enumerates it, but with new address. Problem had been reproduced when I connect verbatim USB3.0 hard disc with my STiH407 XHCI host running with 3.10 kernel. I see that similar problem has been reported here. https://bugzilla.kernel.org/show_bug.cgi?id=53211 Reading above it seems that bug was not in 3.6.6 and was present in 3.8 and again it was not present for some in 3.12.6, while it was present for few others. I tested with 3.13-FC19 running at i686 desktop, problem was still there. However, I was failed to reproduce it with 3.16-RC4 running at same i686 machine. I would say it is just a random observation. Problem for few devices is always there, as I am unable to find a proper fix for the issue. So, now question is what should be the amount of delay so that host is always able to recognize suspended device after resume. XHCI specs 4.19.4 says that when Link training is successful, port sets CSC bit to 1. So if SW reads port status before successful link training, then it will not find device to be present. USB Analyzer log with such buggy devices show that in some cases device switch on the RX termination after long delay of host enabling the VBUS. In few other cases it has been seen that device fails to negotiate link training in first attempt. It has been reported till now that few devices take as long as 2000 ms to train the link after host enabling its VBUS and RX termination. This patch implements a 2000 ms timeout for CSC bit to set ie for link training. If in a case link trains before timeout, loop will exit earlier. This patch implements above delay, but only for SS device and when persist is enabled. So, for the good device overhead is almost none. While for the bad devices penalty could be the time which it take for link training. But, If a device was connected before suspend, and was removed while system was asleep, then the penalty would be the timeout ie 2000 ms. Results: Verbatim USB SS hard disk connected with STiH407 USB host running 3.10 Kernel resumes in 461 msecs without this patch, but hard disk is assigned a new device address. Same system resumes in 790 msecs with this patch, but with old device address. Cc: <stable@vger.kernel.org> Signed-off-by: Pratyush Anand <pratyush.anand@st.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-18 12:37:10 +05:30
usb: Add connected retry on resume for non SS devices Currently usb_port_resume waits for up to 2 seconds for CONNECT status for SS devices only. This change will do the same thing for non-SS devices even though the reason is a little different. This will fix an issue where VBUS is turned off during system wide "suspend to ram" and some 2.0 devices take greater than the current max of 100ms to show connected after VBUS is enabled. This is most commonly seen on hard drive based devices and USB3.0 devices plugged into a 2.0 only port. Signed-off-by: Al Cooper <alcooperx@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-02 14:55:07 -05:00
USB: Fix persist resume of some SS USB devices Problem Summary: Problem has been observed generally with PM states where VBUS goes off during suspend. There are some SS USB devices which take longer time for link training compared to many others. Such devices fail to reconnect with same old address which was associated with it before suspend. When system resumes, at some point of time (dpm_run_callback-> usb_dev_resume->usb_resume->usb_resume_both->usb_resume_device-> usb_port_resume) SW reads hub status. If device is present, then it finishes port resume and re-enumerates device with same address. If device is not present then, SW thinks that device was removed during suspend and therefore does logical disconnection and removes all the resource allocated for this device. Now, if I put sufficient delay just before root hub status read in usb_resume_device then, SW sees always that device is present. In normal course(without any delay) SW sees that no device is present and then SW removes all resource associated with the device at this port. In the latter case, after sometime, device says that hey I am here, now host enumerates it, but with new address. Problem had been reproduced when I connect verbatim USB3.0 hard disc with my STiH407 XHCI host running with 3.10 kernel. I see that similar problem has been reported here. https://bugzilla.kernel.org/show_bug.cgi?id=53211 Reading above it seems that bug was not in 3.6.6 and was present in 3.8 and again it was not present for some in 3.12.6, while it was present for few others. I tested with 3.13-FC19 running at i686 desktop, problem was still there. However, I was failed to reproduce it with 3.16-RC4 running at same i686 machine. I would say it is just a random observation. Problem for few devices is always there, as I am unable to find a proper fix for the issue. So, now question is what should be the amount of delay so that host is always able to recognize suspended device after resume. XHCI specs 4.19.4 says that when Link training is successful, port sets CSC bit to 1. So if SW reads port status before successful link training, then it will not find device to be present. USB Analyzer log with such buggy devices show that in some cases device switch on the RX termination after long delay of host enabling the VBUS. In few other cases it has been seen that device fails to negotiate link training in first attempt. It has been reported till now that few devices take as long as 2000 ms to train the link after host enabling its VBUS and RX termination. This patch implements a 2000 ms timeout for CSC bit to set ie for link training. If in a case link trains before timeout, loop will exit earlier. This patch implements above delay, but only for SS device and when persist is enabled. So, for the good device overhead is almost none. While for the bad devices penalty could be the time which it take for link training. But, If a device was connected before suspend, and was removed while system was asleep, then the penalty would be the timeout ie 2000 ms. Results: Verbatim USB SS hard disk connected with STiH407 USB host running 3.10 Kernel resumes in 461 msecs without this patch, but hard disk is assigned a new device address. Same system resumes in 790 msecs with this patch, but with old device address. Cc: <stable@vger.kernel.org> Signed-off-by: Pratyush Anand <pratyush.anand@st.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-18 12:37:10 +05:30
USB: remove excess code from hub.c This patch (as917) removes a now-unnecessary level of subroutine nesting from hub.c. Since usb_port_suspend() does nothing but call hub_port_suspend(), and usb_port_resume() does nothing but call hub_port_resume(), there's no reason to keep the routines separate. Also included in the patch are a few cosmetic changes involving whitespace and use of braces. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:35:16 -04:00
USB: remove CONFIG_USB_PERSIST setting This patch (as1047) removes the USB_PERSIST Kconfig option, enabling it permanently. It also prevents the power/persist attribute from being created for hub devices; there's no point in having it since USB-PERSIST is always turned on for hubs. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-03 15:15:59 -05:00
USB: unify reset_resume and normal resume This patch (as919) unifies the code paths used for normal resume and for reset-resume. Earlier I had failed to note a section in the USB spec which requires the host to resume a suspended port before resetting it if the attached device is enabled for remote wakeup. Since the port has to be resumed anyway, we might as well reuse the existing code. The main changes are: usb_reset_suspended_device() is eliminated. usb_root_hub_lost_power() is moved down next to the hub_reset_resume() routine, to which it is logically related. finish_port_resume() does a port reset() if the device's reset_resume flag is set. usb_port_resume() doesn't check whether the port is initially enabled if this is a USB-Persist sort of resume. Code to perform the port reset is added to the resume pathway for the non-CONFIG_USB_SUSPEND case. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:38:58 -04:00
USB: fix usb_reset_device and usb_reset_composite_device(take 3) This patch renames the existing usb_reset_device in hub.c to usb_reset_and_verify_device and renames the existing usb_reset_composite_device to usb_reset_device. Also the new usb_reset_and_verify_device does't need to be EXPORTED . The idea of the patch is that external interface driver should warn the other interfaces' driver of the same device before and after reseting the usb device. One interface driver shoud call _old_ usb_reset_composite_device instead of _old_ usb_reset_device since it can't assume the device contains only one interface. The _old_ usb_reset_composite_device is safe for single interface device also. we rename the two functions to make the change easily. This patch is under guideline from Alan Stern. Signed-off-by: Ming Lei <tom.leiming@gmail.com>
2008-06-18 22:00:29 +08:00
USB: remove CONFIG_USB_PERSIST setting This patch (as1047) removes the USB_PERSIST Kconfig option, enabling it permanently. It also prevents the power/persist attribute from being created for hub devices; there's no point in having it since USB-PERSIST is always turned on for hubs. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-03 15:15:59 -05:00
USB: unify reset_resume and normal resume This patch (as919) unifies the code paths used for normal resume and for reset-resume. Earlier I had failed to note a section in the USB spec which requires the host to resume a suspended port before resetting it if the attached device is enabled for remote wakeup. Since the port has to be resumed anyway, we might as well reuse the existing code. The main changes are: usb_reset_suspended_device() is eliminated. usb_root_hub_lost_power() is moved down next to the hub_reset_resume() routine, to which it is logically related. finish_port_resume() does a port reset() if the device's reset_resume flag is set. usb_port_resume() doesn't check whether the port is initially enabled if this is a USB-Persist sort of resume. Code to perform the port reset is added to the resume pathway for the non-CONFIG_USB_SUSPEND case. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:38:58 -04:00
USB: remove excess code from hub.c This patch (as917) removes a now-unnecessary level of subroutine nesting from hub.c. Since usb_port_suspend() does nothing but call hub_port_suspend(), and usb_port_resume() does nothing but call hub_port_resume(), there's no reason to keep the routines separate. Also included in the patch are a few cosmetic changes involving whitespace and use of braces. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:35:16 -04:00
USB: Enhance usage of pm_message_t This patch (as1177) modifies the USB core suspend and resume routines. The resume functions now will take a pm_message_t argument, so they will know what sort of resume is occurring. The new argument is also passed to the port suspend/resume and bus suspend/resume routines (although they don't use it for anything but debugging). In addition, special pm_message_t values are used for user-initiated, device-initiated (i.e., remote wakeup), and automatic suspend/resume. By testing these values, drivers can tell whether or not a particular suspend was an autosuspend. Unfortunately, they can't do the same for resumes -- not until the pm_message_t argument is also passed to the drivers' resume methods. That will require a bigger change. IMO, the whole Power Management framework should have been set up this way in the first place. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-25 16:39:18 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
USB: remove excess code from hub.c This patch (as917) removes a now-unnecessary level of subroutine nesting from hub.c. Since usb_port_suspend() does nothing but call hub_port_suspend(), and usb_port_resume() does nothing but call hub_port_resume(), there's no reason to keep the routines separate. Also included in the patch are a few cosmetic changes involving whitespace and use of braces. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:35:16 -04:00
USB hub: simplify remote-wakeup handling This patch (as817) simplifies the remote-wakeup processing in the hub driver. Now instead of using a specialized code path, it relies on the standard USB resume routines. The hub_port_resume() function does an initial get_port_status() to see whether the port has already resumed itself (as it does when a remote-wakeup request is sent). This will slow down handling of other resume events slightly, but not enough to matter. The patch also changes the hub_port_status() routine, making it return an error if a short reply is received. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-11-20 11:14:30 -05:00
usb: make usb_port flags atomic, rename did_runtime_put to child_usage We want to manipulate ->did_runtime_put in usb_port_runtime_resume(), but we don't want that to collide with other updates. Move usb_port flags to new port-bitmap fields in usb_hub. "did_runtime_put" is renamed "child_usage_bits" to reflect that it is strictly standing in for the fact that usb_devices are not the device_model children of their parent port. Signed-off-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:52 -07:00
usb: core: hub: Fix PM reference leak in usb_port_resume() pm_runtime_get_sync will increment pm usage counter even it failed. thus a pairing decrement is needed. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Bixuan Cui <cuibixuan@huawei.com> Link: https://lore.kernel.org/r/20210408130831.56239-1-cuibixuan@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-08 21:08:31 +08:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
usb: introduce port status lock In general we do not want khubd to act on port status changes that are the result of in progress resets or USB runtime PM operations. Specifically port power control testing has been able to trigger an unintended disconnect in hub_port_connect_change(), paraphrasing: if ((portstatus & USB_PORT_STAT_CONNECTION) && udev && udev->state != USB_STATE_NOTATTACHED) { if (portstatus & USB_PORT_STAT_ENABLE) { /* Nothing to do */ } else if (udev->state == USB_STATE_SUSPENDED && udev->persist_enabled) { ... } else { /* Don't resuscitate */; } } ...by falling to the "Don't resuscitate" path or missing USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of modifying the port status. So, we want a new lock to hold off khubd for a given port while the child device is being suspended, resumed, or reset. The lock ordering rules are now usb_lock_device() => usb_lock_port(). This is mandated by the device core which may hold the device_lock on the usb_device before invoking usb_port_{suspend|resume} which in turn take the status_lock on the usb_port. We attempt to hold the status_lock for the duration of a port_event() run, and drop/re-acquire it when needing to take the device_lock. The lock is also dropped/re-acquired during hub_port_reconnect(). This patch also deletes hub->busy_bits as all use cases are now covered by port PM runtime synchronization or the port->status_lock and it pushes down usb_device_lock() into usb_remote_wakeup(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:26 -07:00
USB hub: simplify remote-wakeup handling This patch (as817) simplifies the remote-wakeup processing in the hub driver. Now instead of using a specialized code path, it relies on the standard USB resume routines. The hub_port_resume() function does an initial get_port_status() to see whether the port has already resumed itself (as it does when a remote-wakeup request is sent). This will slow down handling of other resume events slightly, but not enough to matter. The patch also changes the hub_port_status() routine, making it return an error if a short reply is received. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-11-20 11:14:30 -05:00
usb: hub: port: add sysfs entry to switch port power In some cases the port of an hub needs to be disabled or switched off and on again. E.g. when the connected device needs to be re-enumerated. Or it needs to be explicitly disabled while the rest of the usb tree stays working. For this purpose this patch adds an sysfs switch to enable/disable the port on any hub. In the case the hub is supporting power switching, the power line will be disabled to the connected device. When the port gets disabled, the associated device gets disconnected and removed from the logical usb tree. No further device will be enumerated on that port until the port gets enabled again. Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220607114522.3359148-1-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-07 13:45:22 +02:00
USB: Increment wakeup count on remote wakeup. On chromebooks we depend on wakeup count to identify the wakeup source. But currently USB devices do not increment the wakeup count when they trigger the remote wake. This patch addresses the same. Resume condition is reported differently on USB 2.0 and USB 3.0 devices. On USB 2.0 devices, a wake capable device, if wake enabled, drives resume signal to indicate a remote wake (USB 2.0 spec section 7.1.7.7). The upstream facing port then sets C_PORT_SUSPEND bit and reports a port change event (USB 2.0 spec section 11.24.2.7.2.3). Thus if a port has resumed before driving the resume signal from the host and C_PORT_SUSPEND is set, then the device attached to the given port might be the reason for the last system wakeup. Increment the wakeup count for the same. On USB 3.0 devices, a function may signal that it wants to exit from device suspend by sending a Function Wake Device Notification to the host (USB3.0 spec section 8.5.6.4) Thus on receiving the Function Wake, increment the wakeup count. Signed-off-by: Ravi Chandra Sadineni <ravisadineni@chromium.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-04-20 11:08:21 -07:00
USB hub: simplify remote-wakeup handling This patch (as817) simplifies the remote-wakeup processing in the hub driver. Now instead of using a specialized code path, it relies on the standard USB resume routines. The hub_port_resume() function does an initial get_port_status() to see whether the port has already resumed itself (as it does when a remote-wakeup request is sent). This will slow down handling of other resume events slightly, but not enough to matter. The patch also changes the hub_port_status() routine, making it return an error if a short reply is received. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-11-20 11:14:30 -05:00
USB: Increment wakeup count on remote wakeup. On chromebooks we depend on wakeup count to identify the wakeup source. But currently USB devices do not increment the wakeup count when they trigger the remote wake. This patch addresses the same. Resume condition is reported differently on USB 2.0 and USB 3.0 devices. On USB 2.0 devices, a wake capable device, if wake enabled, drives resume signal to indicate a remote wake (USB 2.0 spec section 7.1.7.7). The upstream facing port then sets C_PORT_SUSPEND bit and reports a port change event (USB 2.0 spec section 11.24.2.7.2.3). Thus if a port has resumed before driving the resume signal from the host and C_PORT_SUSPEND is set, then the device attached to the given port might be the reason for the last system wakeup. Increment the wakeup count for the same. On USB 3.0 devices, a function may signal that it wants to exit from device suspend by sending a Function Wake Device Notification to the host (USB3.0 spec section 8.5.6.4) Thus on receiving the Function Wake, increment the wakeup count. Signed-off-by: Ravi Chandra Sadineni <ravisadineni@chromium.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-04-20 11:08:21 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usbcore: Refine USB3.0 device suspend and resume In the past, we use USB2.0 request to suspend and resume a USB3.0 device. Actually, USB3.0 hub does not support Set/Clear PORT_SUSPEND request, instead, it uses Set PORT_LINK_STATE request. This patch makes USB3.0 device suspend/resume comply with USB3.0 specification. This patch fixes the issue that USB3.0 device can not be suspended when connected to a USB3.0 external hub. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-04-27 18:07:50 +08:00
USB: Use helper function hub_set_port_link_state Change the code that manually issues a Set Port Feature(Link State) to use the new helper function hub_set_port_link_state(). Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu>
2012-12-10 15:43:08 -08:00
usbcore: Refine USB3.0 device suspend and resume In the past, we use USB2.0 request to suspend and resume a USB3.0 device. Actually, USB3.0 hub does not support Set/Clear PORT_SUSPEND request, instead, it uses Set PORT_LINK_STATE request. This patch makes USB3.0 device suspend/resume comply with USB3.0 specification. This patch fixes the issue that USB3.0 device can not be suspended when connected to a USB3.0 external hub. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-04-27 18:07:50 +08:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
usbcore: Refine USB3.0 device suspend and resume In the past, we use USB2.0 request to suspend and resume a USB3.0 device. Actually, USB3.0 hub does not support Set/Clear PORT_SUSPEND request, instead, it uses Set PORT_LINK_STATE request. This patch makes USB3.0 device suspend/resume comply with USB3.0 specification. This patch fixes the issue that USB3.0 device can not be suspended when connected to a USB3.0 external hub. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-04-27 18:07:50 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: hub: use new USB_RESUME_TIMEOUT Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-02-13 15:38:33 -06:00
USB: separate root and non-root suspend/resume This patch (as916) completes the separation of code paths for suspend and resume of root hubs as opposed to non-root devices. Root hubs will be power-managed through their bus_suspend and bus_resume methods, whereas normal devices will use usb_port_suspend() and usb_port_resume(). Changes to the hcd_bus_{suspend,resume} routines mostly represent motion of code that was already present elsewhere. They include: Adding debugging log messages, Setting the device state appropriately, and Adding a resume recovery time delay. Changes to the port-suspend and port-resume routines in hub.c include: Removal of checks for root devices (since they will never be triggered), and Removal of checks for NULL or invalid device pointers (these were left over from earlier kernel versions and aren't needed at all). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:34:36 -04:00
PM / Runtime: Add macro to test for runtime PM events This patch (as1482) adds a macro for testing whether or not a pm_message value represents an autosuspend or autoresume (i.e., a runtime PM) event. Encapsulating this notion seems preferable to open-coding the test all over the place. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-08-19 23:49:48 +02:00
usb: core: hub: use new USB_RESUME_TIMEOUT Make sure we're using the new macro, so our resume signaling will always pass certification. Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-02-13 15:38:33 -06:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: port: add sysfs entry to switch port power In some cases the port of an hub needs to be disabled or switched off and on again. E.g. when the connected device needs to be re-enumerated. Or it needs to be explicitly disabled while the rest of the usb tree stays working. For this purpose this patch adds an sysfs switch to enable/disable the port on any hub. In the case the hub is supporting power switching, the power line will be disabled to the connected device. When the port gets disabled, the associated device gets disconnected and removed from the logical usb tree. No further device will be enumerated on that port until the port gets enabled again. Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220607114522.3359148-1-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-07 13:45:22 +02:00
USB: add new routine for checking port-resume type This patch (as1070) creates a new subroutine to check whether a device can be resumed. This code is needed even when CONFIG_USB_SUSPEND isn't set, because devices do suspend themselves when the root hub (and hence the entire bus) is suspended, and power sessions can get lost during a system sleep even without individual port suspends. The patch also fixes a loose end in USB-Persist reset-resume handling. When a low- or full-speed device is attached to an EHCI's companion controller, the port handoff during resume will cause the companion port's connect-status-change feature to be set. If that flag isn't cleared, the port-reset code will think it indicates that the device has been unplugged and the reset-resume will fail. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:11 -04:00
USB: unify reset_resume and normal resume This patch (as919) unifies the code paths used for normal resume and for reset-resume. Earlier I had failed to note a section in the USB spec which requires the host to resume a suspended port before resetting it if the attached device is enabled for remote wakeup. Since the port has to be resumed anyway, we might as well reuse the existing code. The main changes are: usb_reset_suspended_device() is eliminated. usb_root_hub_lost_power() is moved down next to the hub_reset_resume() routine, to which it is logically related. finish_port_resume() does a port reset() if the device's reset_resume flag is set. usb_port_resume() doesn't check whether the port is initially enabled if this is a USB-Persist sort of resume. Code to perform the port reset is added to the resume pathway for the non-CONFIG_USB_SUSPEND case. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:38:58 -04:00
USB: add new routine for checking port-resume type This patch (as1070) creates a new subroutine to check whether a device can be resumed. This code is needed even when CONFIG_USB_SUSPEND isn't set, because devices do suspend themselves when the root hub (and hence the entire bus) is suspended, and power sessions can get lost during a system sleep even without individual port suspends. The patch also fixes a loose end in USB-Persist reset-resume handling. When a low- or full-speed device is attached to an EHCI's companion controller, the port handoff during resume will cause the companion port's connect-status-change feature to be set. If that flag isn't cleared, the port-reset code will think it indicates that the device has been unplugged and the reset-resume will fail. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:11 -04:00
USB: speed up usb_bus_resume() This patch (as1620) speeds up USB root-hub resumes in the common case where every enabled port has its suspend feature set (which currently will be true for every runtime resume of the root hub). If all the enabled ports are suspended then resuming the root hub won't resume any of the downstream devices. In this case there's no need for a Resume Recovery delay, because that delay is meant to give devices a chance to get ready for active use. To keep track of the port suspend features, the patch adds a "port_is_suspended" flag to struct usb_device. This has to be tracked separately from the device's state; it's entirely possible for a USB-2 device to be suspended while the suspend feature on its parent port is clear. The reason is that devices will go into suspend whenever their parent hub does. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reviewed-by: Peter Chen <peter.chen@freescale.com> Tested-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-19 11:03:39 -04:00
usbcore: Refine USB3.0 device suspend and resume In the past, we use USB2.0 request to suspend and resume a USB3.0 device. Actually, USB3.0 hub does not support Set/Clear PORT_SUSPEND request, instead, it uses Set PORT_LINK_STATE request. This patch makes USB3.0 device suspend/resume comply with USB3.0 specification. This patch fixes the issue that USB3.0 device can not be suspended when connected to a USB3.0 external hub. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-04-27 18:07:50 +08:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
usbcore: Refine USB3.0 device suspend and resume In the past, we use USB2.0 request to suspend and resume a USB3.0 device. Actually, USB3.0 hub does not support Set/Clear PORT_SUSPEND request, instead, it uses Set PORT_LINK_STATE request. This patch makes USB3.0 device suspend/resume comply with USB3.0 specification. This patch fixes the issue that USB3.0 device can not be suspended when connected to a USB3.0 external hub. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-04-27 18:07:50 +08:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
usbcore: Refine USB3.0 device suspend and resume In the past, we use USB2.0 request to suspend and resume a USB3.0 device. Actually, USB3.0 hub does not support Set/Clear PORT_SUSPEND request, instead, it uses Set PORT_LINK_STATE request. This patch makes USB3.0 device suspend/resume comply with USB3.0 specification. This patch fixes the issue that USB3.0 device can not be suspended when connected to a USB3.0 external hub. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-04-27 18:07:50 +08:00
usb: core: hub: fix race condition about TRSMRCY of resume This may happen if the port becomes resume status exactly when usb_port_resume() gets port status, it still need provide a TRSMCRY time before access the device. CC: <stable@vger.kernel.org> Reported-by: Tianping Fang <tianping.fang@mediatek.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/20210512020738.52961-1-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-12 10:07:38 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: Add connected retry on resume for non SS devices Currently usb_port_resume waits for up to 2 seconds for CONNECT status for SS devices only. This change will do the same thing for non-SS devices even though the reason is a little different. This will fix an issue where VBUS is turned off during system wide "suspend to ram" and some 2.0 devices take greater than the current max of 100ms to show connected after VBUS is enabled. This is most commonly seen on hard drive based devices and USB3.0 devices plugged into a 2.0 only port. Signed-off-by: Al Cooper <alcooperx@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-02 14:55:07 -05:00
usb: hub: make wait_for_connected() take an int instead of a pointer to int The wait_for_connected() function doesn't modify "*port1" and there is no need to pass a pointer. Just pass the int itself. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20211210142028.GB18906@kili Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-10 17:20:28 +03:00
USB: Fix persist resume of some SS USB devices Problem Summary: Problem has been observed generally with PM states where VBUS goes off during suspend. There are some SS USB devices which take longer time for link training compared to many others. Such devices fail to reconnect with same old address which was associated with it before suspend. When system resumes, at some point of time (dpm_run_callback-> usb_dev_resume->usb_resume->usb_resume_both->usb_resume_device-> usb_port_resume) SW reads hub status. If device is present, then it finishes port resume and re-enumerates device with same address. If device is not present then, SW thinks that device was removed during suspend and therefore does logical disconnection and removes all the resource allocated for this device. Now, if I put sufficient delay just before root hub status read in usb_resume_device then, SW sees always that device is present. In normal course(without any delay) SW sees that no device is present and then SW removes all resource associated with the device at this port. In the latter case, after sometime, device says that hey I am here, now host enumerates it, but with new address. Problem had been reproduced when I connect verbatim USB3.0 hard disc with my STiH407 XHCI host running with 3.10 kernel. I see that similar problem has been reported here. https://bugzilla.kernel.org/show_bug.cgi?id=53211 Reading above it seems that bug was not in 3.6.6 and was present in 3.8 and again it was not present for some in 3.12.6, while it was present for few others. I tested with 3.13-FC19 running at i686 desktop, problem was still there. However, I was failed to reproduce it with 3.16-RC4 running at same i686 machine. I would say it is just a random observation. Problem for few devices is always there, as I am unable to find a proper fix for the issue. So, now question is what should be the amount of delay so that host is always able to recognize suspended device after resume. XHCI specs 4.19.4 says that when Link training is successful, port sets CSC bit to 1. So if SW reads port status before successful link training, then it will not find device to be present. USB Analyzer log with such buggy devices show that in some cases device switch on the RX termination after long delay of host enabling the VBUS. In few other cases it has been seen that device fails to negotiate link training in first attempt. It has been reported till now that few devices take as long as 2000 ms to train the link after host enabling its VBUS and RX termination. This patch implements a 2000 ms timeout for CSC bit to set ie for link training. If in a case link trains before timeout, loop will exit earlier. This patch implements above delay, but only for SS device and when persist is enabled. So, for the good device overhead is almost none. While for the bad devices penalty could be the time which it take for link training. But, If a device was connected before suspend, and was removed while system was asleep, then the penalty would be the timeout ie 2000 ms. Results: Verbatim USB SS hard disk connected with STiH407 USB host running 3.10 Kernel resumes in 461 msecs without this patch, but hard disk is assigned a new device address. Same system resumes in 790 msecs with this patch, but with old device address. Cc: <stable@vger.kernel.org> Signed-off-by: Pratyush Anand <pratyush.anand@st.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-18 12:37:10 +05:30
USB: add new routine for checking port-resume type This patch (as1070) creates a new subroutine to check whether a device can be resumed. This code is needed even when CONFIG_USB_SUSPEND isn't set, because devices do suspend themselves when the root hub (and hence the entire bus) is suspended, and power sessions can get lost during a system sleep even without individual port suspends. The patch also fixes a loose end in USB-Persist reset-resume handling. When a low- or full-speed device is attached to an EHCI's companion controller, the port handoff during resume will cause the companion port's connect-status-change feature to be set. If that flag isn't cleared, the port-reset code will think it indicates that the device has been unplugged and the reset-resume will fail. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:11 -04:00
USB: unify reset_resume and normal resume This patch (as919) unifies the code paths used for normal resume and for reset-resume. Earlier I had failed to note a section in the USB spec which requires the host to resume a suspended port before resetting it if the attached device is enabled for remote wakeup. Since the port has to be resumed anyway, we might as well reuse the existing code. The main changes are: usb_reset_suspended_device() is eliminated. usb_root_hub_lost_power() is moved down next to the hub_reset_resume() routine, to which it is logically related. finish_port_resume() does a port reset() if the device's reset_resume flag is set. usb_port_resume() doesn't check whether the port is initially enabled if this is a USB-Persist sort of resume. Code to perform the port reset is added to the resume pathway for the non-CONFIG_USB_SUSPEND case. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:38:58 -04:00
xHCI: set USB2 hardware LPM If the device pass the USB2 software LPM and the host supports hardware LPM, enable hardware LPM for the device to let the host decide when to put the link into lower power state. If hardware LPM is enabled for a port and driver wants to put it into suspend, it must first disable hardware LPM, resume the port into U0, and then suspend the port. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-23 14:19:52 -07:00
USB: Consolidate LPM checks to avoid enabling LPM twice USB Bluetooth controller QCA ROME (0cf3:e007) sometimes stops working after S3: [ 165.110742] Bluetooth: hci0: using NVM file: qca/nvm_usb_00000302.bin [ 168.432065] Bluetooth: hci0: Failed to send body at 4 of 1953 (-110) After some experiments, I found that disabling LPM can workaround the issue. On some platforms, the USB power is cut during S3, so the driver uses reset-resume to resume the device. During port resume, LPM gets enabled twice, by usb_reset_and_verify_device() and usb_port_resume(). Consolidate all checks into new LPM helpers to make sure LPM only gets enabled once. Fixes: de68bab4fa96 ("usb: Don't enable USB 2.0 Link PM by default.”) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: stable <stable@vger.kernel.org> # after much soaking Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-12 03:54:25 +08:00
USB: Disable USB 3.0 LPM in critical sections. 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-02 14:25:52 -07:00
usb: Avoid unnecessary LPM enabling and disabling during suspend and resume The original motivation for disabling/enabling Link PM at device suspend/resume was to force link state to go via U0 before suspend sets the link state to U3. Going directly from U2 to U3 is not allowed. Disabling LPM will forced the link state to U0, but will send a lot of Set port feature requests for evert suspend and resume. This is not needed as Hub hardware will take care of going via U0 when a U2 -> U3 transition is requested [1] [1] USB 3.1 specification section 10.16.2.10 Set Port Feature: "If the value is 3, then host software wants to selectively suspend the device connected to this port. The hub shall transition the link to U3 from any of the other U states using allowed link state transitions. If the port is not already in the U0 state, then it shall transition the port to the U0 state and then initiate the transition to U3. While this state is active, the hub does not propagate downstream-directed traffic to this port, but the hub will respond to resume signaling from the port" Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-06-15 11:55:41 +03:00
USB: Enable Latency Tolerance Messaging (LTM). 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-06-25 12:08:08 -07:00
USB: unify reset_resume and normal resume This patch (as919) unifies the code paths used for normal resume and for reset-resume. Earlier I had failed to note a section in the USB spec which requires the host to resume a suspended port before resetting it if the attached device is enabled for remote wakeup. Since the port has to be resumed anyway, we might as well reuse the existing code. The main changes are: usb_reset_suspended_device() is eliminated. usb_root_hub_lost_power() is moved down next to the hub_reset_resume() routine, to which it is logically related. finish_port_resume() does a port reset() if the device's reset_resume flag is set. usb_port_resume() doesn't check whether the port is initially enabled if this is a USB-Persist sort of resume. Code to perform the port reset is added to the resume pathway for the non-CONFIG_USB_SUSPEND case. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:38:58 -04:00
xHCI: set USB2 hardware LPM If the device pass the USB2 software LPM and the host supports hardware LPM, enable hardware LPM for the device to let the host decide when to put the link into lower power state. If hardware LPM is enabled for a port and driver wants to put it into suspend, it must first disable hardware LPM, resume the port into U0, and then suspend the port. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-23 14:19:52 -07:00
usb: introduce port status lock In general we do not want khubd to act on port status changes that are the result of in progress resets or USB runtime PM operations. Specifically port power control testing has been able to trigger an unintended disconnect in hub_port_connect_change(), paraphrasing: if ((portstatus & USB_PORT_STAT_CONNECTION) && udev && udev->state != USB_STATE_NOTATTACHED) { if (portstatus & USB_PORT_STAT_ENABLE) { /* Nothing to do */ } else if (udev->state == USB_STATE_SUSPENDED && udev->persist_enabled) { ... } else { /* Don't resuscitate */; } } ...by falling to the "Don't resuscitate" path or missing USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of modifying the port status. So, we want a new lock to hold off khubd for a given port while the child device is being suspended, resumed, or reset. The lock ordering rules are now usb_lock_device() => usb_lock_port(). This is mandated by the device core which may hold the device_lock on the usb_device before invoking usb_port_{suspend|resume} which in turn take the status_lock on the usb_port. We attempt to hold the status_lock for the duration of a port_event() run, and drop/re-acquire it when needing to take the device_lock. The lock is also dropped/re-acquired during hub_port_reconnect(). This patch also deletes hub->busy_bits as all use cases are now covered by port PM runtime synchronization or the port->status_lock and it pushes down usb_device_lock() into usb_remote_wakeup(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:26 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: consolidate remote wakeup routines This patch (as1324) makes a small change to the code used for remote wakeup of root hubs. hcd_resume_work() now calls the hub driver's remote-wakeup routine instead of implementing its own version. The patch is complicated by the need to rename remote_wakeup() to usb_remote_wakeup(), make it non-static, and declare it in a header file. There's also the additional complication required to make everything work when CONFIG_PM isn't set; the do-nothing inline routine had to be moved into the header file. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-08 12:56:30 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: introduce port status lock In general we do not want khubd to act on port status changes that are the result of in progress resets or USB runtime PM operations. Specifically port power control testing has been able to trigger an unintended disconnect in hub_port_connect_change(), paraphrasing: if ((portstatus & USB_PORT_STAT_CONNECTION) && udev && udev->state != USB_STATE_NOTATTACHED) { if (portstatus & USB_PORT_STAT_ENABLE) { /* Nothing to do */ } else if (udev->state == USB_STATE_SUSPENDED && udev->persist_enabled) { ... } else { /* Don't resuscitate */; } } ...by falling to the "Don't resuscitate" path or missing USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of modifying the port status. So, we want a new lock to hold off khubd for a given port while the child device is being suspended, resumed, or reset. The lock ordering rules are now usb_lock_device() => usb_lock_port(). This is mandated by the device core which may hold the device_lock on the usb_device before invoking usb_port_{suspend|resume} which in turn take the status_lock on the usb_port. We attempt to hold the status_lock for the duration of a port_event() run, and drop/re-acquire it when needing to take the device_lock. The lock is also dropped/re-acquired during hub_port_reconnect(). This patch also deletes hub->busy_bits as all use cases are now covered by port PM runtime synchronization or the port->status_lock and it pushes down usb_device_lock() into usb_remote_wakeup(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:26 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usbcore: add autosuspend/autoresume infrastructure This patch (as739) adds the basic infrastructure for USB autosuspend and autoresume. The main features are: PM usage counters added to struct usb_device and struct usb_interface, indicating whether it's okay to autosuspend them or they are currently in use. Flag added to usb_device indicating whether the current suspend/resume operation originated from outside or as an autosuspend/autoresume. Flag added to usb_driver indicating whether the driver supports autosuspend. If not, no device bound to the driver will be autosuspended. Mutex added to usb_device for protecting PM operations. Unlike the device semaphore, the locking rule for the pm_mutex is that you must acquire the locks going _up_ the device tree. New routines handling autosuspend/autoresume requests for interfaces and devices. Suspend and resume requests are propagated up the device tree (but not outside the USB subsystem). work_struct added to usb_device, for carrying out delayed autosuspend requests. Autoresume added (and autosuspend prevented) during probe and disconnect. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-08-30 15:47:02 -04:00
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>
2010-01-08 12:57:28 -05:00
USB hub: simplify remote-wakeup handling This patch (as817) simplifies the remote-wakeup processing in the hub driver. Now instead of using a specialized code path, it relies on the standard USB resume routines. The hub_port_resume() function does an initial get_port_status() to see whether the port has already resumed itself (as it does when a remote-wakeup request is sent). This will slow down handling of other resume events slightly, but not enough to matter. The patch also changes the hub_port_status() routine, making it return an error if a short reply is received. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-11-20 11:14:30 -05:00
usb: introduce port status lock In general we do not want khubd to act on port status changes that are the result of in progress resets or USB runtime PM operations. Specifically port power control testing has been able to trigger an unintended disconnect in hub_port_connect_change(), paraphrasing: if ((portstatus & USB_PORT_STAT_CONNECTION) && udev && udev->state != USB_STATE_NOTATTACHED) { if (portstatus & USB_PORT_STAT_ENABLE) { /* Nothing to do */ } else if (udev->state == USB_STATE_SUSPENDED && udev->persist_enabled) { ... } else { /* Don't resuscitate */; } } ...by falling to the "Don't resuscitate" path or missing USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of modifying the port status. So, we want a new lock to hold off khubd for a given port while the child device is being suspended, resumed, or reset. The lock ordering rules are now usb_lock_device() => usb_lock_port(). This is mandated by the device core which may hold the device_lock on the usb_device before invoking usb_port_{suspend|resume} which in turn take the status_lock on the usb_port. We attempt to hold the status_lock for the duration of a port_event() run, and drop/re-acquire it when needing to take the device_lock. The lock is also dropped/re-acquired during hub_port_reconnect(). This patch also deletes hub->busy_bits as all use cases are now covered by port PM runtime synchronization or the port->status_lock and it pushes down usb_device_lock() into usb_remote_wakeup(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:26 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub_handle_remote_wakeup() depends on CONFIG_PM_RUNTIME=y Per Alan: "You mean from within hub_handle_remote_wakeup()? That routine will never get called if CONFIG_PM_RUNTIME isn't enabled, because khubd never sees wakeup requests if they arise during system suspend. In fact, that routine ought to go inside the "#ifdef CONFIG_PM_RUNTIME" portion of hub.c, along with the other suspend/resume code." Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:31 -07:00
usb: Handle USB3 remote wakeup for LPM enabled devices correctly With Link Power Management (LPM) enabled USB3 links transition to low power U1/U2 link states from U0 state automatically. Current hub code detects USB3 remote wakeups by checking if the software state still shows suspended, but the link has transitioned from suspended U3 to enabled U0 state. As it takes some time before the hub thread reads the port link state after a USB3 wake notification, the link may have transitioned from U0 to U1/U2, and wake is not detected by hub code. Fix this by handling U1/U2 states in the same way as U0 in USB3 wakeup handling This patch should be added to stable kernels since 4.13 where LPM was kept enabled during suspend/resume Cc: <stable@vger.kernel.org> # v4.13+ Signed-off-by: Lee, Chiasheng <chiasheng.lee@intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-20 10:56:04 +03:00
usb: hub_handle_remote_wakeup() depends on CONFIG_PM_RUNTIME=y Per Alan: "You mean from within hub_handle_remote_wakeup()? That routine will never get called if CONFIG_PM_RUNTIME isn't enabled, because khubd never sees wakeup requests if they arise during system suspend. In fact, that routine ought to go inside the "#ifdef CONFIG_PM_RUNTIME" portion of hub.c, along with the other suspend/resume code." Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:31 -07:00
usb: Handle USB3 remote wakeup for LPM enabled devices correctly With Link Power Management (LPM) enabled USB3 links transition to low power U1/U2 link states from U0 state automatically. Current hub code detects USB3 remote wakeups by checking if the software state still shows suspended, but the link has transitioned from suspended U3 to enabled U0 state. As it takes some time before the hub thread reads the port link state after a USB3 wake notification, the link may have transitioned from U0 to U1/U2, and wake is not detected by hub code. Fix this by handling U1/U2 states in the same way as U0 in USB3 wakeup handling This patch should be added to stable kernels since 4.13 where LPM was kept enabled during suspend/resume Cc: <stable@vger.kernel.org> # v4.13+ Signed-off-by: Lee, Chiasheng <chiasheng.lee@intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-20 10:56:04 +03:00
usb: hub_handle_remote_wakeup() depends on CONFIG_PM_RUNTIME=y Per Alan: "You mean from within hub_handle_remote_wakeup()? That routine will never get called if CONFIG_PM_RUNTIME isn't enabled, because khubd never sees wakeup requests if they arise during system suspend. In fact, that routine ought to go inside the "#ifdef CONFIG_PM_RUNTIME" portion of hub.c, along with the other suspend/resume code." Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:31 -07:00
usb: Handle USB3 remote wakeup for LPM enabled devices correctly With Link Power Management (LPM) enabled USB3 links transition to low power U1/U2 link states from U0 state automatically. Current hub code detects USB3 remote wakeups by checking if the software state still shows suspended, but the link has transitioned from suspended U3 to enabled U0 state. As it takes some time before the hub thread reads the port link state after a USB3 wake notification, the link may have transitioned from U0 to U1/U2, and wake is not detected by hub code. Fix this by handling U1/U2 states in the same way as U0 in USB3 wakeup handling This patch should be added to stable kernels since 4.13 where LPM was kept enabled during suspend/resume Cc: <stable@vger.kernel.org> # v4.13+ Signed-off-by: Lee, Chiasheng <chiasheng.lee@intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-20 10:56:04 +03:00
usb: hub_handle_remote_wakeup() depends on CONFIG_PM_RUNTIME=y Per Alan: "You mean from within hub_handle_remote_wakeup()? That routine will never get called if CONFIG_PM_RUNTIME isn't enabled, because khubd never sees wakeup requests if they arise during system suspend. In fact, that routine ought to go inside the "#ifdef CONFIG_PM_RUNTIME" portion of hub.c, along with the other suspend/resume code." Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:31 -07:00
USB: check port changes before hub runtime suspend for some bug device The hub status endpoint has a long 'bInterval', which is 255ms for FS/LS device and 256ms for HS device according to USB 2.0 spec, so the device connection change may be reported later more than 255ms via status pipe. The connection change in hub may have been happened already on the downstream ports, but no status URB completes when it is killed in hub_suspend(auto), so the connection change may be missed by some buggy hub devices, which won't generate remote wakeup signal after their remote wakeup is enabled and they are put into suspend state. The problem can be observed at least on the below Genesys Logic, Inc. hub devices: 0x05e3,0x0606 0x05e3,0x0608 In theory, there is no way to fix the problem completely, but we can make it less likely to occur by this patch. This patch introduces one quirk of HUB_QUIRK_CHECK_PORTS_AUTOSUSPEND to check ports' change during hub_suspend(auto) for the buggy devices. If ports' change is found, terminate the auto suspend and return to working state. So for the buggy hubs, if the connection change happend before the ports' check, it can be handled correctly. If it happens between the ports' check and enabling remote wakeup/entering suspend, it will be missed. Considered the interval is quite short, it is very less likely to happen during the window. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-24 11:59:24 +08:00
usb: hub: port: add sysfs entry to switch port power In some cases the port of an hub needs to be disabled or switched off and on again. E.g. when the connected device needs to be re-enumerated. Or it needs to be explicitly disabled while the rest of the usb tree stays working. For this purpose this patch adds an sysfs switch to enable/disable the port on any hub. In the case the hub is supporting power switching, the power line will be disabled to the connected device. When the port gets disabled, the associated device gets disconnected and removed from the logical usb tree. No further device will be enumerated on that port until the port gets enabled again. Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220607114522.3359148-1-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-07 13:45:22 +02:00
USB: check port changes before hub runtime suspend for some bug device The hub status endpoint has a long 'bInterval', which is 255ms for FS/LS device and 256ms for HS device according to USB 2.0 spec, so the device connection change may be reported later more than 255ms via status pipe. The connection change in hub may have been happened already on the downstream ports, but no status URB completes when it is killed in hub_suspend(auto), so the connection change may be missed by some buggy hub devices, which won't generate remote wakeup signal after their remote wakeup is enabled and they are put into suspend state. The problem can be observed at least on the below Genesys Logic, Inc. hub devices: 0x05e3,0x0606 0x05e3,0x0608 In theory, there is no way to fix the problem completely, but we can make it less likely to occur by this patch. This patch introduces one quirk of HUB_QUIRK_CHECK_PORTS_AUTOSUSPEND to check ports' change during hub_suspend(auto) for the buggy devices. If ports' change is found, terminate the auto suspend and return to working state. So for the buggy hubs, if the connection change happend before the ports' check, it can be handled correctly. If it happens between the ports' check and enabling remote wakeup/entering suspend, it will be missed. Considered the interval is quite short, it is very less likely to happen during the window. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-24 11:59:24 +08:00
[PATCH] usb_interface power state This updates the handling of power state for USB interfaces. - Formalizes an existing invariant: interface "power state" is a boolean: ON when I/O is allowed, and FREEZE otherwise. It does so by defining some inlined helpers, then using them. - Adds a useful invariant: the only interfaces marked active are those bound to non-suspended drivers. Later patches build on this invariant. - Simplifies the interface driver API (and removes some error paths) by removing the requirement that they record power state changes during suspend and resume callbacks. Now usbcore does that. A few drivers were simplified to address that last change. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> drivers/usb/core/hub.c | 33 +++++++++------------ drivers/usb/core/message.c | 1 drivers/usb/core/usb.c | 65 +++++++++++++++++++++++++++++++++---------- drivers/usb/core/usb.h | 18 +++++++++++ drivers/usb/input/hid-core.c | 2 - drivers/usb/misc/usbtest.c | 10 ------ drivers/usb/net/pegasus.c | 2 - drivers/usb/net/usbnet.c | 2 - 8 files changed, 85 insertions(+), 48 deletions(-)
2005-09-13 19:56:33 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: hub: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-11 21:34:37 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: global suspend and remote wakeup don't mix The hub driver was recently changed to use "global" suspend for system suspend transitions on non-SuperSpeed buses. This means that we don't suspend devices individually by setting the suspend feature on the upstream hub port; instead devices all go into suspend automatically when the root hub stops transmitting packets. The idea was to save time and to avoid certain kinds of wakeup races. Now it turns out that many hubs are buggy; they don't relay wakeup requests from a downstream port to their upstream port if the downstream port's suspend feature is not set (depending on the speed of the downstream port, whether or not the hub is enabled for remote wakeup, and possibly other factors). We can't have hubs dropping wakeup requests. Therefore this patch goes partway back to the old policy: It sets the suspend feature for a port if the device attached to that port or any of its descendants is enabled for wakeup. People will still be able to benefit from the time savings if they don't care about wakeup and leave it disabled on all their devices. In order to accomplish this, the patch adds a new field to the usb_hub structure: wakeup_enabled_descendants is a count of how many devices below a suspended hub are enabled for remote wakeup. A corresponding new subroutine determines the number of wakeup-enabled devices at or below an arbitrary suspended USB device. This should be applied to the 3.10 stable kernel. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Toralf Förster <toralf.foerster@gmx.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-11 14:58:04 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: flush outstanding URBs when suspending This patch (as989) makes usbcore flush all outstanding URBs for each device as the device is suspended. This will be true even when CONFIG_USB_SUSPEND is not enabled. In addition, an extra can_submit flag is added to the usb_device structure. That flag will be turned off whenever a suspend request has been received for the device, even if the device isn't actually suspended because CONFIG_USB_SUSPEND isn't set. It's no longer necessary to check for the device state being equal to USB_STATE_SUSPENDED during URB submission; that check can be replaced by a check of the can_submit flag. This also permits us to remove some questionable references to the deprecated power.power_state field. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-09-10 11:34:26 -04:00
usb: improve "not suspended yet" message in hub_suspend() Reading through a recent bug report [1], Alan notes: "Dan, the warning message in hub_suspend() should mention that the child device isn't suspended yet." ...update the warning from: "usb usb3-port4: not suspended yet" ...to: "usb usb3-port4: device 3-4: not suspended yet" [1]: http://marc.info/?l=linux-usb&m=140290586301336&w=2 Reported-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-17 16:16:22 -07:00
PM / Runtime: Add macro to test for runtime PM events This patch (as1482) adds a macro for testing whether or not a pm_message value represents an autosuspend or autoresume (i.e., a runtime PM) event. Encapsulating this notion seems preferable to open-coding the test all over the place. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-08-19 23:49:48 +02:00
USB: don't let the hub driver prevent system sleep This patch (as1465) continues implementation of the policy that errors during suspend or hibernation should not prevent the system from going to sleep. In this case, failure to turn on the Suspend feature for a hub port shouldn't be reported as an error. There are situations where this does actually occur (such as when the device plugged into that port was disconnected in the recent past), and it turns out to be harmless. There's no reason for it to prevent a system sleep. Also, don't allow the hub driver to fail a system suspend if the downstream ports aren't all suspended. This is also harmless (and should never happen, given the change mentioned above); printing a warning message in the kernel log is all we really need to do. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-06-15 16:29:16 -04:00
[PATCH] remove suspend-path recursion This patch removes some recursion in the CONFIG_USB_SUSPEND logic, which suspended children (of devices or hubs) that weren't already suspended. When it sees such cases, suspend now just fails cleanly. That logic was not needed during system-wide sleep state transitions; and given the current notions of how to manage selective suspend transitions, we don't want it there either. Where it was particularly handy was coping with various limitations of the sysfs "echo -n N > power/state" support. (These include assuming that "N" is always meaningful to the driver; and that drivers can only transition to state N from state zero.) Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-13 19:57:04 -07:00
USB: global suspend and remote wakeup don't mix The hub driver was recently changed to use "global" suspend for system suspend transitions on non-SuperSpeed buses. This means that we don't suspend devices individually by setting the suspend feature on the upstream hub port; instead devices all go into suspend automatically when the root hub stops transmitting packets. The idea was to save time and to avoid certain kinds of wakeup races. Now it turns out that many hubs are buggy; they don't relay wakeup requests from a downstream port to their upstream port if the downstream port's suspend feature is not set (depending on the speed of the downstream port, whether or not the hub is enabled for remote wakeup, and possibly other factors). We can't have hubs dropping wakeup requests. Therefore this patch goes partway back to the old policy: It sets the suspend feature for a port if the device attached to that port or any of its descendants is enabled for wakeup. People will still be able to benefit from the time savings if they don't care about wakeup and leave it disabled on all their devices. In order to accomplish this, the patch adds a new field to the usb_hub structure: wakeup_enabled_descendants is a count of how many devices below a suspended hub are enabled for remote wakeup. A corresponding new subroutine determines the number of wakeup-enabled devices at or below an arbitrary suspended USB device. This should be applied to the 3.10 stable kernel. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Toralf Förster <toralf.foerster@gmx.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-11 14:58:04 -04:00
USB: Export usb_wakeup_enabled_descendants() In (e583d9d USB: global suspend and remote wakeup don't mix) we introduced wakeup_enabled_descendants() as a static function. We'd like to use this function in USB controller drivers to know if we should keep the controller on during suspend time, since doing so has a power impact. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2019-04-17 17:13:53 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: check port changes before hub runtime suspend for some bug device The hub status endpoint has a long 'bInterval', which is 255ms for FS/LS device and 256ms for HS device according to USB 2.0 spec, so the device connection change may be reported later more than 255ms via status pipe. The connection change in hub may have been happened already on the downstream ports, but no status URB completes when it is killed in hub_suspend(auto), so the connection change may be missed by some buggy hub devices, which won't generate remote wakeup signal after their remote wakeup is enabled and they are put into suspend state. The problem can be observed at least on the below Genesys Logic, Inc. hub devices: 0x05e3,0x0606 0x05e3,0x0608 In theory, there is no way to fix the problem completely, but we can make it less likely to occur by this patch. This patch introduces one quirk of HUB_QUIRK_CHECK_PORTS_AUTOSUSPEND to check ports' change during hub_suspend(auto) for the buggy devices. If ports' change is found, terminate the auto suspend and return to working state. So for the buggy hubs, if the connection change happend before the ports' check, it can be handled correctly. If it happens between the ports' check and enabling remote wakeup/entering suspend, it will be missed. Considered the interval is quite short, it is very less likely to happen during the window. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-24 11:59:24 +08:00
USB/xHCI: Enable USB 3.0 hub remote wakeup. USB 3.0 hubs have a different remote wakeup policy than USB 2.0 hubs. USB 2.0 hubs, once they have remote wakeup enabled, will always send remote wakes when anything changes on a port. However, USB 3.0 hubs have a per-port remote wake up policy that is off by default. The Set Feature remote wake mask can be changed for any port, enabling remote wakeup for a connect, disconnect, or overcurrent event, much like EHCI and xHCI host controller "wake on" port status bits. The bits are cleared to zero on the initial hub power on, or after the hub has been reset. Without this patch, when a USB 3.0 hub gets suspended, it will not send a remote wakeup on device connect or disconnect. This would show up to the user as "dead ports" unless they ran lsusb -v (since newer versions of lsusb use the sysfs files, rather than sending control transfers). Change the hub driver's suspend method to enable remote wake up for disconnect, connect, and overcurrent for all ports on the hub. Modify the xHCI driver's roothub code to handle that request, and set the "wake on" bits in the port status registers accordingly. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-01-06 10:34:31 -08:00
USB: hub: Remove returned value 'status' since never used The returned value in status has never been used since commit 4296c70a5ec3 ("USB/xHCI: Enable USB 3.0 hub remote wakeup.") So remove 'status' completely. Remove warning (W=1): drivers/usb/core/hub.c:3671:8: warning: variable 'status' set but not used [-Wunused-but-set-variable] Signed-off-by: Mathieu Malaterre <malat@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-27 20:40:34 +01:00
USB/xHCI: Enable USB 3.0 hub remote wakeup. USB 3.0 hubs have a different remote wakeup policy than USB 2.0 hubs. USB 2.0 hubs, once they have remote wakeup enabled, will always send remote wakes when anything changes on a port. However, USB 3.0 hubs have a per-port remote wake up policy that is off by default. The Set Feature remote wake mask can be changed for any port, enabling remote wakeup for a connect, disconnect, or overcurrent event, much like EHCI and xHCI host controller "wake on" port status bits. The bits are cleared to zero on the initial hub power on, or after the hub has been reset. Without this patch, when a USB 3.0 hub gets suspended, it will not send a remote wakeup on device connect or disconnect. This would show up to the user as "dead ports" unless they ran lsusb -v (since newer versions of lsusb use the sysfs files, rather than sending control transfers). Change the hub driver's suspend method to enable remote wake up for disconnect, connect, and overcurrent for all ports on the hub. Modify the xHCI driver's roothub code to handle that request, and set the "wake on" bits in the port status registers accordingly. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-01-06 10:34:31 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: replace remaining __FUNCTION__ occurrences __FUNCTION__ is gcc-specific, use __func__ Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-03 16:08:34 -08:00
USB: Add autosuspend support to the hub driver This patch (as742b) adds autosuspend/autoresume support to the USB hub driver. The largest aspect of the change is that we no longer need a special flag for root hubs that want to be resumed. Now every hub is autoresumed whenever khubd needs to access it. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-11-09 14:44:33 -05:00
usb: hub: rename khubd to hub_wq in documentation and comments USB hub has started to use a workqueue instead of kthread. Let's update the documentation and comments here and there. This patch mostly just replaces "khubd" with "hub_wq". There are only few exceptions where the whole sentence was updated. These more complicated changes can be found in the following files: Documentation/usb/hotplug.txt drivers/net/usb/usbnet.c drivers/usb/core/hcd.c drivers/usb/host/ohci-hcd.c drivers/usb/host/xhci.c Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:23 +02:00
USB: combine hub_quiesce and hub_stop This patch (as1083) combines hub_quiesce() and hub_stop() into a single routine. There's no point keeping them separate since they are usually called together. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:31 -04:00
USB: move bus_suspend and bus_resume method calls This patch (as885) moves the root-hub bus_suspend() and bus_resume() method calls from the hub driver's suspend and resume methods into the usb_generic driver methods, where they make just as much sense. Their old locations were not fully correct. For example, in a kernel compiled without CONFIG_USB_SUSPEND, if one were to do: echo -n 1-0:1.0 >/sys/bus/usb/drivers/hub/unbind to unbind the hub driver from a root hub, there would then be no way to suspend that root hub. Attempts to put the system to sleep would fail; the USB controller driver would refuse to suspend because the root hub was still active. The patch also makes a very slight change in the way devices with no driver are handled during suspend. Rather than doing a standard USB port-suspend directly, now the suspend routine in usb_generic is called. In practice this should never affect anyone. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-04 11:51:54 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: Report wakeup events on root-hub ports When a USB device attached to a root-hub port sends a wakeup request to a sleeping system, we do not report the wakeup event to the PM core. This is because a system resume involves waking up all suspended USB ports as quickly as possible; without the normal USB_RESUME_TIMEOUT delay, the host controller driver doesn't set the USB_PORT_STAT_C_SUSPEND flag and so usb_port_resume() doesn't realize that a wakeup request was received. However, some environments (such as Chrome OS) want to have all wakeup events reported so they can be ascribed to the appropriate device. To accommodate these environments, this patch adds a new routine to the hub driver and a corresponding new HCD method to be used when a root hub resumes. The HCD method returns a bitmap of ports that have initiated a wakeup signal but not yet completed resuming. The hub driver can then report to the PM core that the child devices attached to these ports initiated a wakeup event. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Suggested-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-06-08 16:59:37 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: make USB-PERSIST work after every system sleep This patch (as1046) makes USB-PERSIST work more in accordance with the documentation. Currently it takes effect only in cases where the root hub has lost power or been reset, but it is supposed to operate whenever a power session was dropped during a system sleep. A new hub_restart() routine carries out the duties required during a reset or a reset-resume. It checks to see whether occupied ports are still enabled, and if they aren't then it clears the enable-change and connect-change features (to prevent interference by khubd) and sets the child device's reset_resume flag. It also checks ports that are supposed to be unoccupied to verify that the firmware hasn't left the port in an enabled state. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-03 15:15:51 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: make USB-PERSIST work after every system sleep This patch (as1046) makes USB-PERSIST work more in accordance with the documentation. Currently it takes effect only in cases where the root hub has lost power or been reset, but it is supposed to operate whenever a power session was dropped during a system sleep. A new hub_restart() routine carries out the duties required during a reset or a reset-resume. It checks to see whether occupied ports are still enabled, and if they aren't then it clears the enable-change and connect-change features (to prevent interference by khubd) and sets the child device's reset_resume flag. It also checks ports that are supposed to be unoccupied to verify that the firmware hasn't left the port in an enabled state. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-03 15:15:51 -05:00
USB: combine hub_activate and hub_restart This patch (as1071) combines hub_activate() and hub_restart() into a single routine. There's no point keeping them separate, since they are always called together. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:17 -04:00
USB: Report wakeup events on root-hub ports When a USB device attached to a root-hub port sends a wakeup request to a sleeping system, we do not report the wakeup event to the PM core. This is because a system resume involves waking up all suspended USB ports as quickly as possible; without the normal USB_RESUME_TIMEOUT delay, the host controller driver doesn't set the USB_PORT_STAT_C_SUSPEND flag and so usb_port_resume() doesn't realize that a wakeup request was received. However, some environments (such as Chrome OS) want to have all wakeup events reported so they can be ascribed to the appropriate device. To accommodate these environments, this patch adds a new routine to the hub driver and a corresponding new HCD method to be used when a root hub resumes. The HCD method returns a bitmap of ports that have initiated a wakeup signal but not yet completed resuming. The hub driver can then report to the PM core that the child devices attached to these ports initiated a wakeup event. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Suggested-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-06-08 16:59:37 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: add power/persist device attribute This patch (as920) adds an extra level of protection to the USB-Persist facility. Now it will apply by default only to hubs; for all other devices the user must enable it explicitly by setting the power/persist device attribute. The disconnect_all_children() routine in hub.c has been removed and its code placed inline. This is the way it was originally as part of hub_pre_reset(); the revised usage in hub_reset_resume() is sufficiently different that the code can no longer be shared. Likewise, mark_children_for_reset() is now inline as part of hub_reset_resume(). The end result looks much cleaner than before. The sysfs interface is updated to add the new attribute file, and there are corresponding documentation updates. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:39:33 -04:00
USB: add reset_resume method This patch (as918) introduces a new USB driver method: reset_resume. It is called when a device needs to be reset as part of a resume procedure (whether because of a device quirk or because of the USB-Persist facility), thereby taking over a role formerly assigned to the post_reset method. As a consequence, post_reset no longer needs an argument indicating whether it is being called as part of a reset-resume. This separation of functions makes the code clearer. In addition, the pre_reset and post_reset method return types are changed; they now must return an error code. The return value is unused at present, but at some later time we may unbind drivers and re-probe if they encounter an error during reset handling. The existing pre_reset and post_reset methods in the usbhid, usb-storage, and hub drivers are updated to match the new requirements. For usbhid the post_reset routine is also used for reset_resume (duplicate method pointers); for the other drivers a new reset_resume routine is added. The change to hub.c looks bigger than it really is, because mark_children_for_reset_resume() gets moved down next to the new hub_reset_resume() routine. A minor change to usb-storage makes the usb_stor_report_bus_reset() routine acquire the host lock instead of requiring the caller to hold it already. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Jiri Kosina <jkosina@suse.cz> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:38:16 -04:00
USB: add power/persist device attribute This patch (as920) adds an extra level of protection to the USB-Persist facility. Now it will apply by default only to hubs; for all other devices the user must enable it explicitly by setting the power/persist device attribute. The disconnect_all_children() routine in hub.c has been removed and its code placed inline. This is the way it was originally as part of hub_pre_reset(); the revised usage in hub_reset_resume() is sufficiently different that the code can no longer be shared. Likewise, mark_children_for_reset() is now inline as part of hub_reset_resume(). The end result looks much cleaner than before. The sysfs interface is updated to add the new attribute file, and there are corresponding documentation updates. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:39:33 -04:00
USB: add reset_resume method This patch (as918) introduces a new USB driver method: reset_resume. It is called when a device needs to be reset as part of a resume procedure (whether because of a device quirk or because of the USB-Persist facility), thereby taking over a role formerly assigned to the post_reset method. As a consequence, post_reset no longer needs an argument indicating whether it is being called as part of a reset-resume. This separation of functions makes the code clearer. In addition, the pre_reset and post_reset method return types are changed; they now must return an error code. The return value is unused at present, but at some later time we may unbind drivers and re-probe if they encounter an error during reset handling. The existing pre_reset and post_reset methods in the usbhid, usb-storage, and hub drivers are updated to match the new requirements. For usbhid the post_reset routine is also used for reset_resume (duplicate method pointers); for the other drivers a new reset_resume routine is added. The change to hub.c looks bigger than it really is, because mark_children_for_reset_resume() gets moved down next to the new hub_reset_resume() routine. A minor change to usb-storage makes the usb_stor_report_bus_reset() routine acquire the host lock instead of requiring the caller to hold it already. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Jiri Kosina <jkosina@suse.cz> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:38:16 -04:00
USB: make USB-PERSIST work after every system sleep This patch (as1046) makes USB-PERSIST work more in accordance with the documentation. Currently it takes effect only in cases where the root hub has lost power or been reset, but it is supposed to operate whenever a power session was dropped during a system sleep. A new hub_restart() routine carries out the duties required during a reset or a reset-resume. It checks to see whether occupied ports are still enabled, and if they aren't then it clears the enable-change and connect-change features (to prevent interference by khubd) and sets the child device's reset_resume flag. It also checks ports that are supposed to be unoccupied to verify that the firmware hasn't left the port in an enabled state. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-03 15:15:51 -05:00
USB: combine hub_activate and hub_restart This patch (as1071) combines hub_activate() and hub_restart() into a single routine. There's no point keeping them separate, since they are always called together. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:07:17 -04:00
USB: add reset_resume method This patch (as918) introduces a new USB driver method: reset_resume. It is called when a device needs to be reset as part of a resume procedure (whether because of a device quirk or because of the USB-Persist facility), thereby taking over a role formerly assigned to the post_reset method. As a consequence, post_reset no longer needs an argument indicating whether it is being called as part of a reset-resume. This separation of functions makes the code clearer. In addition, the pre_reset and post_reset method return types are changed; they now must return an error code. The return value is unused at present, but at some later time we may unbind drivers and re-probe if they encounter an error during reset handling. The existing pre_reset and post_reset methods in the usbhid, usb-storage, and hub drivers are updated to match the new requirements. For usbhid the post_reset routine is also used for reset_resume (duplicate method pointers); for the other drivers a new reset_resume routine is added. The change to hub.c looks bigger than it really is, because mark_children_for_reset_resume() gets moved down next to the new hub_reset_resume() routine. A minor change to usb-storage makes the usb_stor_report_bus_reset() routine acquire the host lock instead of requiring the caller to hold it already. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Jiri Kosina <jkosina@suse.cz> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:38:16 -04:00
USB: unify reset_resume and normal resume This patch (as919) unifies the code paths used for normal resume and for reset-resume. Earlier I had failed to note a section in the USB spec which requires the host to resume a suspended port before resetting it if the attached device is enabled for remote wakeup. Since the port has to be resumed anyway, we might as well reuse the existing code. The main changes are: usb_reset_suspended_device() is eliminated. usb_root_hub_lost_power() is moved down next to the hub_reset_resume() routine, to which it is logically related. finish_port_resume() does a port reset() if the device's reset_resume flag is set. usb_port_resume() doesn't check whether the port is initially enabled if this is a USB-Persist sort of resume. Code to perform the port reset is added to the resume pathway for the non-CONFIG_USB_SUSPEND case. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:38:58 -04:00
USB: remove CONFIG_USB_PERSIST setting This patch (as1047) removes the USB_PERSIST Kconfig option, enabling it permanently. It also prevents the power/persist attribute from being created for hub devices; there's no point in having it since USB-PERSIST is always turned on for hubs. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-03 15:15:59 -05:00
USB: unify reset_resume and normal resume This patch (as919) unifies the code paths used for normal resume and for reset-resume. Earlier I had failed to note a section in the USB spec which requires the host to resume a suspended port before resetting it if the attached device is enabled for remote wakeup. Since the port has to be resumed anyway, we might as well reuse the existing code. The main changes are: usb_reset_suspended_device() is eliminated. usb_root_hub_lost_power() is moved down next to the hub_reset_resume() routine, to which it is logically related. finish_port_resume() does a port reset() if the device's reset_resume flag is set. usb_port_resume() doesn't check whether the port is initially enabled if this is a USB-Persist sort of resume. Code to perform the port reset is added to the resume pathway for the non-CONFIG_USB_SUSPEND case. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:38:58 -04:00
usb: hub: Reduce warning to notice on power loss Currently we warn the user when the root hub lost power after resume, but the user cannot do anything about it so it should probably be a notice. This will reduce the noise in the console during suspend and resume, which is already quite significant in many systems. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-03-22 16:18:32 +01:00
USB: unify reset_resume and normal resume This patch (as919) unifies the code paths used for normal resume and for reset-resume. Earlier I had failed to note a section in the USB spec which requires the host to resume a suspended port before resetting it if the attached device is enabled for remote wakeup. Since the port has to be resumed anyway, we might as well reuse the existing code. The main changes are: usb_reset_suspended_device() is eliminated. usb_root_hub_lost_power() is moved down next to the hub_reset_resume() routine, to which it is logically related. finish_port_resume() does a port reset() if the device's reset_resume flag is set. usb_port_resume() doesn't check whether the port is initially enabled if this is a USB-Persist sort of resume. Code to perform the port reset is added to the resume pathway for the non-CONFIG_USB_SUSPEND case. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:38:58 -04:00
USB: Add support to enable/disable USB3 link states. 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-04-24 17:21:50 -07:00
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>
2022-05-06 19:18:07 +03:00
USB: Add support to enable/disable USB3 link states. 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-04-24 17:21:50 -07:00
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>
2022-05-06 19:18:07 +03:00
usbcore: check usb device's state before sending a Set SEL control transfer Set SEL control urbs cannot be sent to a device in unconfigured state. This patch adds a check in usb_req_set_sel() to ensure the usb device's state is USB_STATE_CONFIGURED. Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com> Reported-by: Martin MOKREJS <mmokrejs@gmail.com> Suggested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-09-04 17:24:45 +03:00
USB: Add support to enable/disable USB3 link states. 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-04-24 17:21:50 -07:00
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>
2022-05-06 19:18:07 +03:00
USB: Add support to enable/disable USB3 link states. 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-04-24 17:21:50 -07:00
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>
2022-05-06 19:18:07 +03:00
USB: Add support to enable/disable USB3 link states. 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-04-24 17:21:50 -07:00
USB: Use str_enable_disable-like helpers Replace ternary (condition ? "enable" : "disable") syntax with helpers from string_choices.h because: 1. Simple function call with one argument is easier to read. Ternary operator has three arguments and with wrapping might lead to quite long code. 2. Is slightly shorter thus also easier to read. 3. It brings uniformity in the text - same string. 4. Allows deduping by the linker, which results in a smaller binary file. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250114-str-enable-disable-usb-v1-6-c8405df47c19@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-14 21:05:39 +01:00
USB: Add support to enable/disable USB3 link states. 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-04-24 17:21:50 -07:00
USB: Use str_enable_disable-like helpers Replace ternary (condition ? "enable" : "disable") syntax with helpers from string_choices.h because: 1. Simple function call with one argument is easier to read. Ternary operator has three arguments and with wrapping might lead to quite long code. 2. Is slightly shorter thus also easier to read. 3. It brings uniformity in the text - same string. 4. Allows deduping by the linker, which results in a smaller binary file. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250114-str-enable-disable-usb-v1-6-c8405df47c19@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-14 21:05:39 +01:00
USB: Add support to enable/disable USB3 link states. 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-04-24 17:21:50 -07:00
USB: Use str_enable_disable-like helpers Replace ternary (condition ? "enable" : "disable") syntax with helpers from string_choices.h because: 1. Simple function call with one argument is easier to read. Ternary operator has three arguments and with wrapping might lead to quite long code. 2. Is slightly shorter thus also easier to read. 3. It brings uniformity in the text - same string. 4. Allows deduping by the linker, which results in a smaller binary file. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250114-str-enable-disable-usb-v1-6-c8405df47c19@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-14 21:05:39 +01:00
USB: Add support to enable/disable USB3 link states. 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-04-24 17:21:50 -07:00
usb: hub: Disable USB 3 device initiated lpm if exit latency is too high The device initiated link power management U1/U2 states should not be enabled in case the system exit latency plus one bus interval (125us) is greater than the shortest service interval of any periodic endpoint. This is the case for both U1 and U2 sytstem exit latencies and link states. See USB 3.2 section 9.4.9 "Set Feature" for more details Note, before this patch the host and device initiated U1/U2 lpm states were both enabled with lpm. After this patch it's possible to end up with only host inititated U1/U2 lpm in case the exit latencies won't allow device initiated lpm. If this case we still want to set the udev->usb3_lpm_ux_enabled flag so that sysfs users can see the link may go to U1/U2. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210715150122.1995966-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-15 18:01:22 +03:00
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>
2022-05-06 19:18:07 +03:00
usb: hub: Disable USB 3 device initiated lpm if exit latency is too high The device initiated link power management U1/U2 states should not be enabled in case the system exit latency plus one bus interval (125us) is greater than the shortest service interval of any periodic endpoint. This is the case for both U1 and U2 sytstem exit latencies and link states. See USB 3.2 section 9.4.9 "Set Feature" for more details Note, before this patch the host and device initiated U1/U2 lpm states were both enabled with lpm. After this patch it's possible to end up with only host inititated U1/U2 lpm in case the exit latencies won't allow device initiated lpm. If this case we still want to set the udev->usb3_lpm_ux_enabled flag so that sysfs users can see the link may go to U1/U2. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210715150122.1995966-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-15 18:01:22 +03:00
USB: Add support to enable/disable USB3 link states. 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-04-24 17:21:50 -07:00
usb: core: hub: Disable hub-initiated U1/U2 If the device rejects the control transfer to enable device-initiated U1/U2 entry, then the device will not initiate U1/U2 transition. To improve the performance, the downstream port should not initate transition to U1/U2 to avoid the delay from the device link command response (no packet can be transmitted while waiting for a response from the device). If the device has some quirks and does not implement U1/U2, it may reject all the link state change requests, and the downstream port may resend and flood the bus with more requests. This will affect the device performance even further. This patch disables the hub-initated U1/U2 if the device-initiated U1/U2 entry fails. Reference: USB 3.2 spec 7.2.4.2.3 Signed-off-by: Thinh Nguyen <thinhn@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-14 14:38:38 -07:00
USB: Add support to enable/disable USB3 link states. 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-04-24 17:21:50 -07:00
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>
2022-05-06 19:18:07 +03:00
usb: hub: Guard against accesses to uninitialized BOS descriptors Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h access fields inside udev->bos without checking if it was allocated and initialized. If usb_get_bos_descriptor() fails for whatever reason, udev->bos will be NULL and those accesses will result in a crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1> Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:hub_port_reset+0x193/0x788 Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9 RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310 RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840 RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0 Call Trace: hub_event+0x73f/0x156e ? hub_activate+0x5b7/0x68f process_one_work+0x1a2/0x487 worker_thread+0x11a/0x288 kthread+0x13a/0x152 ? process_one_work+0x487/0x487 ? kthread_associate_blkcg+0x70/0x70 ret_from_fork+0x1f/0x30 Fall back to a default behavior if the BOS descriptor isn't accessible and skip all the functionalities that depend on it: LPM support checks, Super Speed capabilitiy checks, U1/U2 states setup. Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20230830100418.1952143-1-ricardo.canuelo@collabora.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-30 12:04:18 +02:00
usb: Don't enable LPM if the exit latency is zero. Some USB 3.0 devices signal that they don't implement Link PM by having all zeroes in the U1/U2 exit latencies in their SuperSpeed BOS descriptor. Don found that a Western Digital device he has experiences transfer errors when LPM is enabled. The lsusb shows the U1/U2 exit latencies are set to zero: Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 22 bNumDeviceCaps 2 SuperSpeed USB Device Capability: bLength 10 bDescriptorType 16 bDevCapabilityType 3 bmAttributes 0x00 Latency Tolerance Messages (LTM) Supported wSpeedsSupported 0x000e Device can operate at Full Speed (12Mbps) Device can operate at High Speed (480Mbps) Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 1 Lowest fully-functional device speed is Full Speed (12Mbps) bU1DevExitLat 0 micro seconds bU2DevExitLat 0 micro seconds The fix is to not enable LPM for a particular link state if we find its corresponding exit latency is zero. This patch should be backported to kernels as old as 3.5, that contain the commit 1ea7e0e8e3d0f50901d335ea4178ab2aa8c88201 "USB: Add support to enable/disable USB3 link states." Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Don Zickus <dzickus@redhat.com> Tested-by: Don Zickus <dzickus@redhat.com> Cc: stable@vger.kernel.org
2012-10-03 11:18:05 -07:00
USB: Add support to enable/disable USB3 link states. 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-04-24 17:21:50 -07:00
usb: core: lpm: fix usb3_hardware_lpm sysfs node Commit 655fe4effe0f ("usbcore: add sysfs support to xHCI usb3 hardware LPM") introduced usb3_hardware_lpm sysfs node. This doesn't show the correct status of USB3 U1 and U2 LPM status. This patch fixes this by replacing usb3_hardware_lpm with two nodes, usb3_hardware_lpm_u1 (for U1) and usb3_hardware_lpm_u2 (for U2), and recording the U1/U2 LPM status in right places. This patch should be back-ported to kernels as old as 4.3, that contains Commit 655fe4effe0f ("usbcore: add sysfs support to xHCI usb3 hardware LPM"). Cc: stable@vger.kernel.org Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-11-14 16:26:32 +08:00
USB: Add support to enable/disable USB3 link states. 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-04-24 17:21:50 -07:00
usb: core: hub: Disable hub-initiated U1/U2 If the device rejects the control transfer to enable device-initiated U1/U2 entry, then the device will not initiate U1/U2 transition. To improve the performance, the downstream port should not initate transition to U1/U2 to avoid the delay from the device link command response (no packet can be transmitted while waiting for a response from the device). If the device has some quirks and does not implement U1/U2, it may reject all the link state change requests, and the downstream port may resend and flood the bus with more requests. This will affect the device performance even further. This patch disables the hub-initated U1/U2 if the device-initiated U1/U2 entry fails. Reference: USB 3.2 spec 7.2.4.2.3 Signed-off-by: Thinh Nguyen <thinhn@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-14 14:38:38 -07:00
USB: Add support to enable/disable USB3 link states. 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-04-24 17:21:50 -07:00
usb: core: hub: Disable hub-initiated U1/U2 If the device rejects the control transfer to enable device-initiated U1/U2 entry, then the device will not initiate U1/U2 transition. To improve the performance, the downstream port should not initate transition to U1/U2 to avoid the delay from the device link command response (no packet can be transmitted while waiting for a response from the device). If the device has some quirks and does not implement U1/U2, it may reject all the link state change requests, and the downstream port may resend and flood the bus with more requests. This will affect the device performance even further. This patch disables the hub-initated U1/U2 if the device-initiated U1/U2 entry fails. Reference: USB 3.2 spec 7.2.4.2.3 Signed-off-by: Thinh Nguyen <thinhn@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-14 14:38:38 -07:00
usb: hub: Disable USB 3 device initiated lpm if exit latency is too high The device initiated link power management U1/U2 states should not be enabled in case the system exit latency plus one bus interval (125us) is greater than the shortest service interval of any periodic endpoint. This is the case for both U1 and U2 sytstem exit latencies and link states. See USB 3.2 section 9.4.9 "Set Feature" for more details Note, before this patch the host and device initiated U1/U2 lpm states were both enabled with lpm. After this patch it's possible to end up with only host inititated U1/U2 lpm in case the exit latencies won't allow device initiated lpm. If this case we still want to set the udev->usb3_lpm_ux_enabled flag so that sysfs users can see the link may go to U1/U2. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210715150122.1995966-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-15 18:01:22 +03:00
usb: core: lpm: fix usb3_hardware_lpm sysfs node Commit 655fe4effe0f ("usbcore: add sysfs support to xHCI usb3 hardware LPM") introduced usb3_hardware_lpm sysfs node. This doesn't show the correct status of USB3 U1 and U2 LPM status. This patch fixes this by replacing usb3_hardware_lpm with two nodes, usb3_hardware_lpm_u1 (for U1) and usb3_hardware_lpm_u2 (for U2), and recording the U1/U2 LPM status in right places. This patch should be back-ported to kernels as old as 4.3, that contains Commit 655fe4effe0f ("usbcore: add sysfs support to xHCI usb3 hardware LPM"). Cc: stable@vger.kernel.org Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-11-14 16:26:32 +08:00
USB: Add support to enable/disable USB3 link states. 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-04-24 17:21:50 -07:00
usb: hub: Disable USB 3 device initiated lpm if exit latency is too high The device initiated link power management U1/U2 states should not be enabled in case the system exit latency plus one bus interval (125us) is greater than the shortest service interval of any periodic endpoint. This is the case for both U1 and U2 sytstem exit latencies and link states. See USB 3.2 section 9.4.9 "Set Feature" for more details Note, before this patch the host and device initiated U1/U2 lpm states were both enabled with lpm. After this patch it's possible to end up with only host inititated U1/U2 lpm in case the exit latencies won't allow device initiated lpm. If this case we still want to set the udev->usb3_lpm_ux_enabled flag so that sysfs users can see the link may go to U1/U2. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210715150122.1995966-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-15 18:01:22 +03:00
USB: Add support to enable/disable USB3 link states. 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-04-24 17:21:50 -07:00
usb: core: lpm: fix usb3_hardware_lpm sysfs node Commit 655fe4effe0f ("usbcore: add sysfs support to xHCI usb3 hardware LPM") introduced usb3_hardware_lpm sysfs node. This doesn't show the correct status of USB3 U1 and U2 LPM status. This patch fixes this by replacing usb3_hardware_lpm with two nodes, usb3_hardware_lpm_u1 (for U1) and usb3_hardware_lpm_u2 (for U2), and recording the U1/U2 LPM status in right places. This patch should be back-ported to kernels as old as 4.3, that contains Commit 655fe4effe0f ("usbcore: add sysfs support to xHCI usb3 hardware LPM"). Cc: stable@vger.kernel.org Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-11-14 16:26:32 +08:00
USB: Add support to enable/disable USB3 link states. 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-04-24 17:21:50 -07:00
usb: define USB_SPEED_SUPER_PLUS speed for SuperSpeedPlus USB3.1 devices Add a new USB_SPEED_SUPER_PLUS device speed, and make sure usb core can handle the new speed. In most cases the behaviour is the same as with USB_SPEED_SUPER SuperSpeed devices. In a few places we add a "Plus" string to inform the user of the new speed. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-10 09:59:25 +02:00
usb: allow lpm (en/dis)able only if device is atleast in default state When a USB device is disconnected, usb_unbind_interface is called, which tries to enable and disable LPM. usb_enable_lpm also try to send a control command SET SEL to the device. Since device is already disconnected, therefore it does not make sense to execute usb_(en/dis)able_lpm. This patch returns from usb_(en/dis)able_lpm, if device was not in default state atleast. Signed-off-by: Pratyush Anand <pratyush.anand@st.com> Tested-by: Aymen Bouattay <aymen.bouattay@st.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-04 17:01:27 +03:00
usb: core: hub: Enable/disable U1/U2 in configured state SET_FEATURE(U1/U2_ENABLE) and CLEAR_FEATURE(U1/U2) only apply while the device is in configured state. Add proper check in usb_disable_lpm() and usb_enable_lpm() for enabling/disabling device-initiated U1/U2. Signed-off-by: Thinh Nguyen <thinhn@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-14 14:38:31 -07:00
USB: Add support to enable/disable USB3 link states. 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-04-24 17:21:50 -07:00
USB: Checking the wrong variable in usb_disable_lpm() 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-05-22 20:54:34 +03:00
USB: Add support to enable/disable USB3 link states. 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-04-24 17:21:50 -07:00
usb: core: lpm: add sysfs node for usb3 lpm permit USB3 LPM is default on in Linux kernel if both xHCI host controller and the USB devices declare to be LPM-capable. Unfortunately, some devices are known to work well with LPM disabled, but to be broken if LPM is enabled, although it declares the LPM capability. Users won't be able to use this kind of devices, until someone puts them in the kernel blacklist and gets the kernel upgraded. This patch adds a sysfs node to permit or forbit USB3 LPM U1 or U2 entry for a port. The settings apply to both before and after device enumeration. Supported values are "0" - neither u1 nor u2 permitted, "u1" - only u1 is permitted, "u2" - only u2 is permitted, "u1_u2" - both u1 and u2 are permitted. With this interface, users can use an LPM-unfriendly USB device on a released Linux kernel. Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Zhuang Jin Can <jin.can.zhuang@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-11-14 16:26:33 +08:00
USB: Add support to enable/disable USB3 link states. 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-04-24 17:21:50 -07:00
usb: define USB_SPEED_SUPER_PLUS speed for SuperSpeedPlus USB3.1 devices Add a new USB_SPEED_SUPER_PLUS device speed, and make sure usb core can handle the new speed. In most cases the behaviour is the same as with USB_SPEED_SUPER SuperSpeed devices. In a few places we add a "Plus" string to inform the user of the new speed. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-10 09:59:25 +02:00
usb: allow lpm (en/dis)able only if device is atleast in default state When a USB device is disconnected, usb_unbind_interface is called, which tries to enable and disable LPM. usb_enable_lpm also try to send a control command SET SEL to the device. Since device is already disconnected, therefore it does not make sense to execute usb_(en/dis)able_lpm. This patch returns from usb_(en/dis)able_lpm, if device was not in default state atleast. Signed-off-by: Pratyush Anand <pratyush.anand@st.com> Tested-by: Aymen Bouattay <aymen.bouattay@st.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-04 17:01:27 +03:00
usb: core: hub: Enable/disable U1/U2 in configured state SET_FEATURE(U1/U2_ENABLE) and CLEAR_FEATURE(U1/U2) only apply while the device is in configured state. Add proper check in usb_disable_lpm() and usb_enable_lpm() for enabling/disabling device-initiated U1/U2. Signed-off-by: Thinh Nguyen <thinhn@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-14 14:38:31 -07:00
USB: Add support to enable/disable USB3 link states. 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-04-24 17:21:50 -07:00
usb: core: lpm: add sysfs node for usb3 lpm permit USB3 LPM is default on in Linux kernel if both xHCI host controller and the USB devices declare to be LPM-capable. Unfortunately, some devices are known to work well with LPM disabled, but to be broken if LPM is enabled, although it declares the LPM capability. Users won't be able to use this kind of devices, until someone puts them in the kernel blacklist and gets the kernel upgraded. This patch adds a sysfs node to permit or forbit USB3 LPM U1 or U2 entry for a port. The settings apply to both before and after device enumeration. Supported values are "0" - neither u1 nor u2 permitted, "u1" - only u1 is permitted, "u2" - only u2 is permitted, "u1_u2" - both u1 and u2 are permitted. With this interface, users can use an LPM-unfriendly USB device on a released Linux kernel. Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Zhuang Jin Can <jin.can.zhuang@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-11-14 16:26:33 +08:00
USB: Add support to enable/disable USB3 link states. 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-04-24 17:21:50 -07:00
usb: hub: Fix auto-remount of safely removed or ejected USB-3 devices USB-3 does not have any link state that will avoid negotiating a connection with a plugged-in cable but will signal the host when the cable is unplugged. For USB-3 we used to first set the link to Disabled, then to RxDdetect to be able to detect cable connects or disconnects. But in RxDetect the connected device is detected again and eventually enabled. Instead set the link into U3 and disable remote wakeups for the device. This is what Windows does, and what Alan Stern suggested. Cc: stable@vger.kernel.org Cc: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-17 11:14:14 +02:00
USB: Add support to enable/disable USB3 link states. 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-04-24 17:21:50 -07:00
hub driver: improve use of #ifdef This patch (as736) makes the hub driver more readable by improving the usage of "#ifdef CONFIG_PM" and "#ifdef CONFIG_USB_SUSPEND". Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-07-01 22:14:24 -04:00
USB: add reset_resume method This patch (as918) introduces a new USB driver method: reset_resume. It is called when a device needs to be reset as part of a resume procedure (whether because of a device quirk or because of the USB-Persist facility), thereby taking over a role formerly assigned to the post_reset method. As a consequence, post_reset no longer needs an argument indicating whether it is being called as part of a reset-resume. This separation of functions makes the code clearer. In addition, the pre_reset and post_reset method return types are changed; they now must return an error code. The return value is unused at present, but at some later time we may unbind drivers and re-probe if they encounter an error during reset handling. The existing pre_reset and post_reset methods in the usbhid, usb-storage, and hub drivers are updated to match the new requirements. For usbhid the post_reset routine is also used for reset_resume (duplicate method pointers); for the other drivers a new reset_resume routine is added. The change to hub.c looks bigger than it really is, because mark_children_for_reset_resume() gets moved down next to the new hub_reset_resume() routine. A minor change to usb-storage makes the usb_stor_report_bus_reset() routine acquire the host lock instead of requiring the caller to hold it already. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Jiri Kosina <jkosina@suse.cz> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:38:16 -04:00
USB: Add support to enable/disable USB3 link states. 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-04-24 17:21:50 -07:00
usb: hub: Fix auto-remount of safely removed or ejected USB-3 devices USB-3 does not have any link state that will avoid negotiating a connection with a plugged-in cable but will signal the host when the cable is unplugged. For USB-3 we used to first set the link to Disabled, then to RxDdetect to be able to detect cable connects or disconnects. But in RxDetect the connected device is detected again and eventually enabled. Instead set the link into U3 and disable remote wakeups for the device. This is what Windows does, and what Alan Stern suggested. Cc: stable@vger.kernel.org Cc: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-17 11:14:14 +02:00
USB: Add support to enable/disable USB3 link states. 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-04-24 17:21:50 -07:00
USB: Fix core compile with CONFIG_USB_SUSPEND=n 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-21 08:29:01 -07:00
USB: Add support to enable/disable USB3 link states. 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-04-24 17:21:50 -07:00
USB: Fix core compile with CONFIG_USB_SUSPEND=n 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-21 08:29:01 -07:00
USB: Add support to enable/disable USB3 link states. 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-04-24 17:21:50 -07:00
USB: Fix core compile with CONFIG_USB_SUSPEND=n 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-21 08:29:01 -07:00
USB: Add support to enable/disable USB3 link states. 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-04-24 17:21:50 -07:00
USB: Fix core compile with CONFIG_USB_SUSPEND=n 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-21 08:29:01 -07:00
USB: Enable Latency Tolerance Messaging (LTM). 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-06-25 12:08:08 -07:00
USB: remove redundant "#if" This patch removes a redundant nested "#ifdef CONFIG_PM" from the hub driver. It also adds a label to the "#endif" line corresponding to the outer "#ifdef CONFIG_PM". Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-11 14:58:23 -04:00
usb: hub_handle_remote_wakeup() only exists for CONFIG_PM=y Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Acked-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-29 18:55:06 +10:00
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>
2022-05-06 19:18:07 +03:00
USB: remove redundant "#if" This patch removes a redundant nested "#ifdef CONFIG_PM" from the hub driver. It also adds a label to the "#endif" line corresponding to the outer "#ifdef CONFIG_PM". Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-11 14:58:23 -04:00
hub driver: improve use of #ifdef This patch (as736) makes the hub driver more readable by improving the usage of "#ifdef CONFIG_PM" and "#ifdef CONFIG_USB_SUSPEND". Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-07-01 22:14:24 -04:00
usb: hub: Move hub_port_disable() to fix warning if PM is disabled If CONFIG_PM=n: drivers/usb/core/hub.c:107: warning: ‘hub_usb3_port_prepare_disable’ declared inline after being called drivers/usb/core/hub.c:107: warning: previous declaration of ‘hub_usb3_port_prepare_disable’ was here To fix this, move hub_port_disable() after hub_usb3_port_prepare_disable(), and adjust forward declarations. Fixes: 37be66767e3cae4f ("usb: hub: Fix auto-remount of safely removed or ejected USB-3 devices") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-12-14 15:37:30 +01:00
USB: Force disconnect Huawei 4G modem during suspend When going into S3 suspend, the Acer TravelMate P648-M and P648-G3 laptops immediately wake up 3-4 seconds later for no obvious reason. Unbinding the integrated Huawei 4G LTE modem before suspend avoids the issue, even though we are not using the modem at all (checked from rescue.target/runlevel1). The problem also occurs when the option and cdc-ether modem drivers aren't loaded; it reproduces just with the base usb driver. Under Windows the system can suspend fine. Seeking a better fix, we've tried a lot of things, including: - Check that the device's power/wakeup is disabled - Check that remote wakeup is off at the USB level - All the quirks in drivers/usb/core/quirks.c e.g. USB_QUIRK_RESET_RESUME, USB_QUIRK_RESET, USB_QUIRK_IGNORE_REMOTE_WAKEUP, USB_QUIRK_NO_LPM. but none of that makes any difference. There are no errors in the logs showing any suspend/resume-related issues. When the system wakes up due to the modem, log-wise it appears to be a normal resume. Introduce a quirk to disable the port during suspend when the modem is detected. The modem from the P648-G3 model is: T: Bus=01 Lev=01 Prnt=01 Port=08 Cnt=04 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=ff MxPS=64 #Cfgs= 3 P: Vendor=12d1 ProdID=15c3 Rev= 1.02 S: Manufacturer=Huawei Technologies Co., Ltd. S: Product=HUAWEI Mobile S: SerialNumber=0123456789ABCDEF C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr= 2mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=06 Prot=10 Driver= E: Ad=82(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=13 Driver= E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=12 Driver= E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=06 Prot=16 Driver= E: Ad=86(I) Atr=03(Int.) MxPS= 16 Ivl=2ms I: If#= 3 Alt= 1 #EPs= 3 Cls=ff(vend.) Sub=06 Prot=16 Driver= E: Ad=86(I) Atr=03(Int.) MxPS= 16 Ivl=2ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=1b Driver= E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms C:* #Ifs= 6 Cfg#= 2 Atr=a0 MxPwr= 2mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl=2ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=06 Prot=00 Driver=cdc_ether E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=06 Prot=10 Driver=option E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=13 Driver=option E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=12 Driver=option E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=1b Driver=option E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms C: #Ifs= 2 Cfg#= 3 Atr=a0 MxPwr= 2mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00 I: If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver= E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl=2ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver= I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver= E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Based on an earlier patch by Chris Chiu. Signed-off-by: Daniel Drake <drake@endlessm.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-18 15:15:01 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
drivers: usb: core: {file,hub,sysfs,usb}.c: Whitespace fixes including: - removing of trailing whitespace - removing spaces before array indexing (foo [] to foo[]) - reindention of a switch-case block - spaces to tabs Signed-off-by: Matthias Beyer <mail@beyermatthias.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-10 23:41:27 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: port: add sysfs entry to switch port power In some cases the port of an hub needs to be disabled or switched off and on again. E.g. when the connected device needs to be re-enumerated. Or it needs to be explicitly disabled while the rest of the usb tree stays working. For this purpose this patch adds an sysfs switch to enable/disable the port on any hub. In the case the hub is supporting power switching, the power line will be disabled to the connected device. When the port gets disabled, the associated device gets disconnected and removed from the logical usb tree. No further device will be enumerated on that port until the port gets enabled again. Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220607114522.3359148-1-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-07 13:45:22 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
wusb: make ep0_reinit available for modules We need to be able to call ep0_reinit() [renamed to usb_ep0_reinit()] from the WUSB security code. The reason is that when we authenticate the device, it's address changes (from having bit 7 set to having it cleared). Thus, we need to signal the USB stack to reinitialize EP0, so the status with the previous address kept at the HCD layer is cleared and properly reinitialized. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-08 13:24:46 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: fix toggle mismatch in disable_endpoint paths This patch (as1200) finishes some fixes that were left incomplete by an earlier patch. Although nobody has addressed this issue in the past, it turns out that we need to distinguish between two different modes of disabling and enabling endpoints. In one mode only the data structures in usbcore are affected, and in the other mode the host controller and device hardware states are affected as well. The earlier patch added an extra argument to the routines in the enable_endpoint pathways to reflect this difference. This patch adds corresponding arguments to the disable_endpoint pathways. Without this change, the endpoint toggle state can get out of sync between the host and the device. The exact mechanism depends on the details of the host controller (whether or not it stores its own copy of the toggle values). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Dan Streetman <ddstreet@ieee.org> Tested-by: Dan Streetman <ddstreet@ieee.org> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-15 17:03:33 -05:00
USB: re-enable interface after driver unbinds This patch (as1197) fixes an error introduced recently. Since a significant number of devices can't handle Set-Interface requests, we no longer call usb_set_interface() when a driver unbinds from an interface, provided the interface is already in altsetting 0. However the interface still does get disabled, and the call to usb_set_interface() was the only thing re-enabling it. Since the interface doesn't get re-enabled, further attempts to use it fail. So the patch adds a call to usb_enable_interface() when a driver unbinds and the interface is in altsetting 0. For this to work right, the interface's endpoints have to be re-enabled but their toggles have to be left alone. Therefore an additional argument is added to usb_enable_endpoint() and usb_enable_interface(), a flag indicating whether or not the endpoint toggles should be reset. This is a forward-ported version of a patch which fixes Bugzilla #12301. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: David Roka <roka@dawid.hu> Reported-by: Erik Ekman <erik@kryo.se> Tested-by: Erik Ekman <erik@kryo.se> Tested-by: Alon Bar-Lev <alon.barlev@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-31 11:31:33 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
wusb: make ep0_reinit available for modules We need to be able to call ep0_reinit() [renamed to usb_ep0_reinit()] from the WUSB security code. The reason is that when we authenticate the device, it's address changes (from having bit 7 set to having it cleared). Thus, we need to signal the USB stack to reinitialize EP0, so the status with the previous address kept at the HCD layer is cleared and properly reinitialized. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-08 13:24:46 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: address-0 handling during device initialization This patch (as947) changes the device initialization and enumeration code in hub.c; now udev->devnum will be set to 0 while the device is being accessed at address 0. Until now this wasn't needed because the address value was passed as part of urb->pipe; without that field the device address must be stored elsewhere. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-30 17:08:43 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: new quirk to reduce the SET_ADDRESS request timeout This patch introduces a new USB quirk, USB_QUIRK_SHORT_SET_ADDRESS_REQ_TIMEOUT, which modifies the timeout value for the SET_ADDRESS request. The standard timeout for USB request/command is 5000 ms, as recommended in the USB 3.2 specification (section 9.2.6.1). However, certain scenarios, such as connecting devices through an APTIV hub, can lead to timeout errors when the device enumerates as full speed initially and later switches to high speed during chirp negotiation. In such cases, USB analyzer logs reveal that the bus suspends for 5 seconds due to incorrect chirp parsing and resumes only after two consecutive timeout errors trigger a hub driver reset. Packet(54) Dir(?) Full Speed J(997.100 us) Idle( 2.850 us) _______| Time Stamp(28 . 105 910 682) _______|_____________________________________________________________Ch0 Packet(55) Dir(?) Full Speed J(997.118 us) Idle( 2.850 us) _______| Time Stamp(28 . 106 910 632) _______|_____________________________________________________________Ch0 Packet(56) Dir(?) Full Speed J(399.650 us) Idle(222.582 us) _______| Time Stamp(28 . 107 910 600) _______|_____________________________________________________________Ch0 Packet(57) Dir Chirp J( 23.955 ms) Idle(115.169 ms) _______| Time Stamp(28 . 108 532 832) _______|_____________________________________________________________Ch0 Packet(58) Dir(?) Full Speed J (Suspend)( 5.347 sec) Idle( 5.366 us) _______| Time Stamp(28 . 247 657 600) _______|_____________________________________________________________Ch0 This 5-second delay in device enumeration is undesirable, particularly in automotive applications where quick enumeration is crucial (ideally within 3 seconds). The newly introduced quirks provide the flexibility to align with a 3-second time limit, as required in specific contexts like automotive applications. By reducing the SET_ADDRESS request timeout to 500 ms, the system can respond more swiftly to errors, initiate rapid recovery, and ensure efficient device enumeration. This change is vital for scenarios where rapid smartphone enumeration and screen projection are essential. To use the quirk, please write "vendor_id:product_id:p" to /sys/bus/usb/drivers/hub/module/parameter/quirks For example, echo "0x2c48:0x0132:p" > /sys/bus/usb/drivers/hub/module/parameters/quirks" Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20231027152029.104363-2-hgajjar@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-27 17:20:29 +02:00
USB: Support for addressing a USB device under xHCI Add host controller driver API and a slot_id variable to struct usb_device. This allows the xHCI host controller driver to ask the hardware to allocate a slot for the device when a struct usb_device is allocated. The slot needs to be allocated at that point because the hardware can run out of internal resources, and we want to know that very early in the device connection process. Don't call this new API for root hubs, since they aren't real devices. Add HCD API to let the host controller choose the device address. This is especially important for xHCI hardware running in a virtualized environment. The guests running under the VM don't need to know which addresses on the bus are taken, because the hardware picks the address for them. Announce SuperSpeed USB devices after the address has been assigned by the hardware. Don't use the new get descriptor/set address scheme with xHCI. Unless special handling is done in the host controller driver, the xHC can't issue control transfers before you set the device address. Support for the older addressing scheme will be added when the xHCI driver supports the Block Set Address Request (BSR) flag in the Address Device command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-27 19:57:26 -07:00
usb: new quirk to reduce the SET_ADDRESS request timeout This patch introduces a new USB quirk, USB_QUIRK_SHORT_SET_ADDRESS_REQ_TIMEOUT, which modifies the timeout value for the SET_ADDRESS request. The standard timeout for USB request/command is 5000 ms, as recommended in the USB 3.2 specification (section 9.2.6.1). However, certain scenarios, such as connecting devices through an APTIV hub, can lead to timeout errors when the device enumerates as full speed initially and later switches to high speed during chirp negotiation. In such cases, USB analyzer logs reveal that the bus suspends for 5 seconds due to incorrect chirp parsing and resumes only after two consecutive timeout errors trigger a hub driver reset. Packet(54) Dir(?) Full Speed J(997.100 us) Idle( 2.850 us) _______| Time Stamp(28 . 105 910 682) _______|_____________________________________________________________Ch0 Packet(55) Dir(?) Full Speed J(997.118 us) Idle( 2.850 us) _______| Time Stamp(28 . 106 910 632) _______|_____________________________________________________________Ch0 Packet(56) Dir(?) Full Speed J(399.650 us) Idle(222.582 us) _______| Time Stamp(28 . 107 910 600) _______|_____________________________________________________________Ch0 Packet(57) Dir Chirp J( 23.955 ms) Idle(115.169 ms) _______| Time Stamp(28 . 108 532 832) _______|_____________________________________________________________Ch0 Packet(58) Dir(?) Full Speed J (Suspend)( 5.347 sec) Idle( 5.366 us) _______| Time Stamp(28 . 247 657 600) _______|_____________________________________________________________Ch0 This 5-second delay in device enumeration is undesirable, particularly in automotive applications where quick enumeration is crucial (ideally within 3 seconds). The newly introduced quirks provide the flexibility to align with a 3-second time limit, as required in specific contexts like automotive applications. By reducing the SET_ADDRESS request timeout to 500 ms, the system can respond more swiftly to errors, initiate rapid recovery, and ensure efficient device enumeration. This change is vital for scenarios where rapid smartphone enumeration and screen projection are essential. To use the quirk, please write "vendor_id:product_id:p" to /sys/bus/usb/drivers/hub/module/parameter/quirks For example, echo "0x2c48:0x0132:p" > /sys/bus/usb/drivers/hub/module/parameters/quirks" Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20231027152029.104363-2-hgajjar@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-27 17:20:29 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: Support for addressing a USB device under xHCI Add host controller driver API and a slot_id variable to struct usb_device. This allows the xHCI host controller driver to ask the hardware to allocate a slot for the device when a struct usb_device is allocated. The slot needs to be allocated at that point because the hardware can run out of internal resources, and we want to know that very early in the device connection process. Don't call this new API for root hubs, since they aren't real devices. Add HCD API to let the host controller choose the device address. This is especially important for xHCI hardware running in a virtualized environment. The guests running under the VM don't need to know which addresses on the bus are taken, because the hardware picks the address for them. Announce SuperSpeed USB devices after the address has been assigned by the hardware. Don't use the new get descriptor/set address scheme with xHCI. Unless special handling is done in the host controller driver, the xHC can't issue control transfers before you set the device address. Support for the older addressing scheme will be added when the xHCI driver supports the Block Set Address Request (BSR) flag in the Address Device command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-27 19:57:26 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: core: use kernel assigned address for devices under xHCI xHCI driver uses hardware assigned device address. This may cause device address conflict in certain cases. Use kernel assigned address for devices under xHCI. Store the xHC assigned address locally in xHCI driver. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-10-14 07:22:51 -07:00
usb: new quirk to reduce the SET_ADDRESS request timeout This patch introduces a new USB quirk, USB_QUIRK_SHORT_SET_ADDRESS_REQ_TIMEOUT, which modifies the timeout value for the SET_ADDRESS request. The standard timeout for USB request/command is 5000 ms, as recommended in the USB 3.2 specification (section 9.2.6.1). However, certain scenarios, such as connecting devices through an APTIV hub, can lead to timeout errors when the device enumerates as full speed initially and later switches to high speed during chirp negotiation. In such cases, USB analyzer logs reveal that the bus suspends for 5 seconds due to incorrect chirp parsing and resumes only after two consecutive timeout errors trigger a hub driver reset. Packet(54) Dir(?) Full Speed J(997.100 us) Idle( 2.850 us) _______| Time Stamp(28 . 105 910 682) _______|_____________________________________________________________Ch0 Packet(55) Dir(?) Full Speed J(997.118 us) Idle( 2.850 us) _______| Time Stamp(28 . 106 910 632) _______|_____________________________________________________________Ch0 Packet(56) Dir(?) Full Speed J(399.650 us) Idle(222.582 us) _______| Time Stamp(28 . 107 910 600) _______|_____________________________________________________________Ch0 Packet(57) Dir Chirp J( 23.955 ms) Idle(115.169 ms) _______| Time Stamp(28 . 108 532 832) _______|_____________________________________________________________Ch0 Packet(58) Dir(?) Full Speed J (Suspend)( 5.347 sec) Idle( 5.366 us) _______| Time Stamp(28 . 247 657 600) _______|_____________________________________________________________Ch0 This 5-second delay in device enumeration is undesirable, particularly in automotive applications where quick enumeration is crucial (ideally within 3 seconds). The newly introduced quirks provide the flexibility to align with a 3-second time limit, as required in specific contexts like automotive applications. By reducing the SET_ADDRESS request timeout to 500 ms, the system can respond more swiftly to errors, initiate rapid recovery, and ensure efficient device enumeration. This change is vital for scenarios where rapid smartphone enumeration and screen projection are essential. To use the quirk, please write "vendor_id:product_id:p" to /sys/bus/usb/drivers/hub/module/parameter/quirks For example, echo "0x2c48:0x0132:p" > /sys/bus/usb/drivers/hub/module/parameters/quirks" Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20231027152029.104363-2-hgajjar@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-27 17:20:29 +02:00
USB: core: use kernel assigned address for devices under xHCI xHCI driver uses hardware assigned device address. This may cause device address conflict in certain cases. Use kernel assigned address for devices under xHCI. Store the xHC assigned address locally in xHCI driver. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-10-14 07:22:51 -07:00
USB: Support for addressing a USB device under xHCI Add host controller driver API and a slot_id variable to struct usb_device. This allows the xHCI host controller driver to ask the hardware to allocate a slot for the device when a struct usb_device is allocated. The slot needs to be allocated at that point because the hardware can run out of internal resources, and we want to know that very early in the device connection process. Don't call this new API for root hubs, since they aren't real devices. Add HCD API to let the host controller choose the device address. This is especially important for xHCI hardware running in a virtualized environment. The guests running under the VM don't need to know which addresses on the bus are taken, because the hardware picks the address for them. Announce SuperSpeed USB devices after the address has been assigned by the hardware. Don't use the new get descriptor/set address scheme with xHCI. Unless special handling is done in the host controller driver, the xHC can't issue control transfers before you set the device address. Support for the older addressing scheme will be added when the xHCI driver supports the Block Set Address Request (BSR) flag in the Address Device command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-27 19:57:26 -07:00
usb: new quirk to reduce the SET_ADDRESS request timeout This patch introduces a new USB quirk, USB_QUIRK_SHORT_SET_ADDRESS_REQ_TIMEOUT, which modifies the timeout value for the SET_ADDRESS request. The standard timeout for USB request/command is 5000 ms, as recommended in the USB 3.2 specification (section 9.2.6.1). However, certain scenarios, such as connecting devices through an APTIV hub, can lead to timeout errors when the device enumerates as full speed initially and later switches to high speed during chirp negotiation. In such cases, USB analyzer logs reveal that the bus suspends for 5 seconds due to incorrect chirp parsing and resumes only after two consecutive timeout errors trigger a hub driver reset. Packet(54) Dir(?) Full Speed J(997.100 us) Idle( 2.850 us) _______| Time Stamp(28 . 105 910 682) _______|_____________________________________________________________Ch0 Packet(55) Dir(?) Full Speed J(997.118 us) Idle( 2.850 us) _______| Time Stamp(28 . 106 910 632) _______|_____________________________________________________________Ch0 Packet(56) Dir(?) Full Speed J(399.650 us) Idle(222.582 us) _______| Time Stamp(28 . 107 910 600) _______|_____________________________________________________________Ch0 Packet(57) Dir Chirp J( 23.955 ms) Idle(115.169 ms) _______| Time Stamp(28 . 108 532 832) _______|_____________________________________________________________Ch0 Packet(58) Dir(?) Full Speed J (Suspend)( 5.347 sec) Idle( 5.366 us) _______| Time Stamp(28 . 247 657 600) _______|_____________________________________________________________Ch0 This 5-second delay in device enumeration is undesirable, particularly in automotive applications where quick enumeration is crucial (ideally within 3 seconds). The newly introduced quirks provide the flexibility to align with a 3-second time limit, as required in specific contexts like automotive applications. By reducing the SET_ADDRESS request timeout to 500 ms, the system can respond more swiftly to errors, initiate rapid recovery, and ensure efficient device enumeration. This change is vital for scenarios where rapid smartphone enumeration and screen projection are essential. To use the quirk, please write "vendor_id:product_id:p" to /sys/bus/usb/drivers/hub/module/parameter/quirks For example, echo "0x2c48:0x0132:p" > /sys/bus/usb/drivers/hub/module/parameters/quirks" Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20231027152029.104363-2-hgajjar@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-27 17:20:29 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: use "device number" instead of "address" The USB stack historically has conflated device numbers (i.e., the value of udev->devnum) with device addresses. This is understandable, because until recently the two values were always the same. But with USB-3.0 they aren't the same, so we should start calling these things by their correct names. This patch (as1449b) changes many of the references to "address" in the hub driver to "device number" or "devnum". The patch also removes some unnecessary or misleading comments. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Luben Tuikov <ltuikov@yahoo.com> Reviewed-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-22 09:53:41 -05:00
usb: don't update devnum for wusb devices For WUSB devices, usb_dev.devnum is a device index and not the real device address (which is managed by wusbcore). Therefore, only set devnum once (in choose_address()) and never change it. Signed-off-by: David Vrabel <david.vrabel@csr.com> Cc: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-08 13:24:46 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
wusb: make ep0_reinit available for modules We need to be able to call ep0_reinit() [renamed to usb_ep0_reinit()] from the WUSB security code. The reason is that when we authenticate the device, it's address changes (from having bit 7 set to having it cleared). Thus, we need to signal the USB stack to reinitialize EP0, so the status with the previous address kept at the HCD layer is cleared and properly reinitialized. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-08 13:24:46 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
xhci: Enable LPM support only for hardwired or BESL devices Some usb3 devices falsely claim they support usb2 hardware Link PM when connected to a usb2 port. We only trust hardwired devices or devices with the later BESL LPM support to be LPM enabled as default. [Note: Sarah re-worked the original patch to move the code into the USB core, and updated it to check whether the USB device supports BESL, instead of checking if the xHCI port it's connected to supports BESL encoding.] This patch should be backported to kernels as old as 3.11, that contain the commit a558ccdcc71c7770c5e80c926a31cfe8a3892a09 "usb: xhci: add USB2 Link power management BESL support". Without this fix, some USB 3.0 devices will not enumerate or work properly under USB 2.0 ports on Haswell-ULT systems. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2013-09-30 17:26:31 +03:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
xhci: Enable LPM support only for hardwired or BESL devices Some usb3 devices falsely claim they support usb2 hardware Link PM when connected to a usb2 port. We only trust hardwired devices or devices with the later BESL LPM support to be LPM enabled as default. [Note: Sarah re-worked the original patch to move the code into the USB core, and updated it to check whether the USB device supports BESL, instead of checking if the xHCI port it's connected to supports BESL encoding.] This patch should be backported to kernels as old as 3.11, that contain the commit a558ccdcc71c7770c5e80c926a31cfe8a3892a09 "usb: xhci: add USB2 Link power management BESL support". Without this fix, some USB 3.0 devices will not enumerate or work properly under USB 2.0 ports on Haswell-ULT systems. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2013-09-30 17:26:31 +03:00
usb: hub: Fix crash after failure to read BOS descriptor If usb_get_bos_descriptor() returns an error, usb->bos will be NULL. Nevertheless, it is dereferenced unconditionally in hub_set_initial_usb2_lpm_policy() if usb2_hw_lpm_capable is set. This results in a crash. usb 5-1: unable to get BOS descriptor ... Unable to handle kernel NULL pointer dereference at virtual address 00000008 pgd = ffffffc00165f000 [00000008] *pgd=000000000174f003, *pud=000000000174f003, *pmd=0000000001750003, *pte=00e8000001751713 Internal error: Oops: 96000005 [#1] PREEMPT SMP Modules linked in: uinput uvcvideo videobuf2_vmalloc cmac [ ... ] CPU: 5 PID: 3353 Comm: kworker/5:3 Tainted: G B 4.4.52 #480 Hardware name: Google Kevin (DT) Workqueue: events driver_set_config_work task: ffffffc0c3690000 ti: ffffffc0ae9a8000 task.ti: ffffffc0ae9a8000 PC is at hub_port_init+0xc3c/0xd10 LR is at hub_port_init+0xc3c/0xd10 ... Call trace: [<ffffffc0007fbbfc>] hub_port_init+0xc3c/0xd10 [<ffffffc0007fbe2c>] usb_reset_and_verify_device+0x15c/0x82c [<ffffffc0007fc5e0>] usb_reset_device+0xe4/0x298 [<ffffffbffc0e3fcc>] rtl8152_probe+0x84/0x9b0 [r8152] [<ffffffc00080ca8c>] usb_probe_interface+0x244/0x2f8 [<ffffffc000774a24>] driver_probe_device+0x180/0x3b4 [<ffffffc000774e48>] __device_attach_driver+0xb4/0xe0 [<ffffffc000772168>] bus_for_each_drv+0xb4/0xe4 [<ffffffc0007747ec>] __device_attach+0xd0/0x158 [<ffffffc000775080>] device_initial_probe+0x24/0x30 [<ffffffc0007739d4>] bus_probe_device+0x50/0xe4 [<ffffffc000770bd0>] device_add+0x414/0x738 [<ffffffc000809fe8>] usb_set_configuration+0x89c/0x914 [<ffffffc00080a120>] driver_set_config_work+0xc0/0xf0 [<ffffffc000249bb8>] process_one_work+0x390/0x6b8 [<ffffffc00024abcc>] worker_thread+0x480/0x610 [<ffffffc000251a80>] kthread+0x164/0x178 [<ffffffc0002045d0>] ret_from_fork+0x10/0x40 Since we don't know anything about LPM capabilities without BOS descriptor, don't attempt to enable LPM if it is not available. Fixes: 890dae886721 ("xhci: Enable LPM support only for hardwired ...") Cc: stable <stable@vger.kernel.org> Cc: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-03-08 10:19:36 -08:00
xhci: Enable LPM support only for hardwired or BESL devices Some usb3 devices falsely claim they support usb2 hardware Link PM when connected to a usb2 port. We only trust hardwired devices or devices with the later BESL LPM support to be LPM enabled as default. [Note: Sarah re-worked the original patch to move the code into the USB core, and updated it to check whether the USB device supports BESL, instead of checking if the xHCI port it's connected to supports BESL encoding.] This patch should be backported to kernels as old as 3.11, that contain the commit a558ccdcc71c7770c5e80c926a31cfe8a3892a09 "usb: xhci: add USB2 Link power management BESL support". Without this fix, some USB 3.0 devices will not enumerate or work properly under USB 2.0 ports on Haswell-ULT systems. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2013-09-30 17:26:31 +03:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
xhci: Enable LPM support only for hardwired or BESL devices Some usb3 devices falsely claim they support usb2 hardware Link PM when connected to a usb2 port. We only trust hardwired devices or devices with the later BESL LPM support to be LPM enabled as default. [Note: Sarah re-worked the original patch to move the code into the USB core, and updated it to check whether the USB device supports BESL, instead of checking if the xHCI port it's connected to supports BESL encoding.] This patch should be backported to kernels as old as 3.11, that contain the commit a558ccdcc71c7770c5e80c926a31cfe8a3892a09 "usb: xhci: add USB2 Link power management BESL support". Without this fix, some USB 3.0 devices will not enumerate or work properly under USB 2.0 ports on Haswell-ULT systems. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2013-09-30 17:26:31 +03:00
usb: hub: usb_ext_cap_descriptor.bmAttributes is le32 Better check the correct bit on big endian systems too. Shuts up the following sparse __CHECK_ENDIAN__ warning: .../hub.c:3965:32: warning: restricted __le32 degrades to integer Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-27 14:23:55 +01:00
xhci: Enable LPM support only for hardwired or BESL devices Some usb3 devices falsely claim they support usb2 hardware Link PM when connected to a usb2 port. We only trust hardwired devices or devices with the later BESL LPM support to be LPM enabled as default. [Note: Sarah re-worked the original patch to move the code into the USB core, and updated it to check whether the USB device supports BESL, instead of checking if the xHCI port it's connected to supports BESL encoding.] This patch should be backported to kernels as old as 3.11, that contain the commit a558ccdcc71c7770c5e80c926a31cfe8a3892a09 "usb: xhci: add USB2 Link power management BESL support". Without this fix, some USB 3.0 devices will not enumerate or work properly under USB 2.0 ports on Haswell-ULT systems. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2013-09-30 17:26:31 +03:00
USB: Add new USB LPM helpers Use new helpers to make LPM enabling/disabling more clear. This is a preparation to subsequent patch. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: stable <stable@vger.kernel.org> # after much soaking Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-12 03:54:24 +08:00
xhci: Enable LPM support only for hardwired or BESL devices Some usb3 devices falsely claim they support usb2 hardware Link PM when connected to a usb2 port. We only trust hardwired devices or devices with the later BESL LPM support to be LPM enabled as default. [Note: Sarah re-worked the original patch to move the code into the USB core, and updated it to check whether the USB device supports BESL, instead of checking if the xHCI port it's connected to supports BESL encoding.] This patch should be backported to kernels as old as 3.11, that contain the commit a558ccdcc71c7770c5e80c926a31cfe8a3892a09 "usb: xhci: add USB2 Link power management BESL support". Without this fix, some USB 3.0 devices will not enumerate or work properly under USB 2.0 ports on Haswell-ULT systems. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2013-09-30 17:26:31 +03:00
usb: xhci: change enumeration scheme to 'new scheme' by default Change the default enumeration scheme for xhci attached non-SuperSpeed devices from: Reset SetAddress [xhci address-device BSR = 0] GetDescriptor(8) GetDescriptor(18) ...to: Reset [xhci address-device BSR = 1] GetDescriptor(64) Reset SetAddress [xhci address-device BSR = 0] GetDescriptor(18) ...as some devices misbehave when encountering a SetAddress command prior to GetDescriptor. There are known legacy devices that require this scheme, but testing has found at least one USB3 device that fails enumeration when presented with this ordering. For now, follow the ehci case and enable 'new scheme' by default for non-SuperSpeed devices. To support this enumeration scheme on xhci the AddressDevice operation needs to be performed twice. The first instance of the command enables the HC's device and slot context info for the device, but omits sending the device a SetAddress command (BSR == block set address request). Then, after GetDescriptor completes, follow up with the full AddressDevice+SetAddress operation. As mentioned before, this ordering of events with USB3 devices causes an extra state transition to be exposed to xhci. Previously USB3 devices would transition directly from 'enabled' to 'addressed' and never need to underrun responses to 'get descriptor'. We do see the 64-byte descriptor fetch the correct data, but the following 18-byte descriptor read after the reset gets: bLength = 0 bDescriptorType = 0 bcdUSB = 0 bDeviceClass = 0 bDeviceSubClass = 0 bDeviceProtocol = 0 bMaxPacketSize0 = 9 instead of: bLength = 12 bDescriptorType = 1 bcdUSB = 300 bDeviceClass = 0 bDeviceSubClass = 0 bDeviceProtocol = 0 bMaxPacketSize0 = 9 which results in the discovery process looping until falling back to 'old scheme' enumeration. Acked-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: David Moore <david.moore@gmail.com> Suggested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-12-05 17:07:27 -08:00
USB: core: Unite old scheme and new scheme descriptor reads In preparation for reworking the usb_get_device_descriptor() routine, it is desirable to unite the two different code paths responsible for initially determining endpoint 0's maximum packet size in a newly discovered USB device. Making this determination presents a chicken-and-egg sort of problem, in that the only way to learn the maxpacket value is to get it from the device descriptor retrieved from the device, but communicating with the device to retrieve a descriptor requires us to know beforehand the ep0 maxpacket size. In practice this problem is solved in two different ways, referred to in hub.c as the "old scheme" and the "new scheme". The old scheme (which is the approach recommended by the USB-2 spec) involves asking the device to send just the first eight bytes of its device descriptor. Such a transfer uses packets containing no more than eight bytes each, and every USB device must have an ep0 maxpacket size >= 8, so this should succeed. Since the bMaxPacketSize0 field of the device descriptor lies within the first eight bytes, this is all we need. The new scheme is an imitation of the technique used in an early Windows USB implementation, giving it the happy advantage of working with a wide variety of devices (some of them at the time would not work with the old scheme, although that's probably less true now). It involves making an initial guess of the ep0 maxpacket size, asking the device to send up to 64 bytes worth of its device descriptor (which is only 18 bytes long), and then resetting the device to clear any error condition that might have resulted from the guess being wrong. The initial guess is determined by the connection speed; it should be correct in all cases other than full speed, for which the allowed values are 8, 16, 32, and 64 (in this case the initial guess is 64). The reason for this patch is that the old- and new-scheme parts of hub_port_init() use different code paths, one involving usb_get_device_descriptor() and one not, for their initial reads of the device descriptor. Since these reads have essentially the same purpose and are made under essentially the same circumstances, this is illogical. It makes more sense to have both of them use a common subroutine. This subroutine does basically what the new scheme's code did, because that approach is more general than the one used by the old scheme. It only needs to know how many bytes to transfer and whether or not it is being called for the first iteration of a retry loop (in case of certain time-out errors). There are two main differences from the former code: We initialize the bDescriptorType field of the transfer buffer to 0 before performing the transfer, to avoid possibly accessing an uninitialized value afterward. We read the device descriptor into a temporary buffer rather than storing it directly into udev->descriptor, which the old scheme implementation used to do. Since the whole point of this first read of the device descriptor is to determine the bMaxPacketSize0 value, that is what the new routine returns (or an error code). The value is stored in a local variable rather than in udev->descriptor. As a side effect, this necessitates moving a section of code that checks the bcdUSB field for SuperSpeed devices until after the full device descriptor has been retrieved. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/495cb5d4-f956-4f4a-a875-1e67e9489510@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:10:59 -04:00
USB: core: Fix oversight in SuperSpeed initialization Commit 85d07c556216 ("USB: core: Unite old scheme and new scheme descriptor reads") altered the way USB devices are enumerated following detection, and in the process it messed up the initialization of SuperSpeed (or faster) devices: [ 31.650759] usb 2-1: new SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd [ 31.663107] usb 2-1: device descriptor read/8, error -71 [ 31.952697] usb 2-1: new SuperSpeed Plus Gen 2x1 USB device number 3 using xhci_hcd [ 31.965122] usb 2-1: device descriptor read/8, error -71 [ 32.080991] usb usb2-port1: attempt power cycle ... The problem was caused by the commit forgetting that in SuperSpeed or faster devices, the device descriptor uses a logarithmic encoding of the bMaxPacketSize0 value. (For some reason I thought the 255 case in the switch statement was meant for these devices, but it isn't -- it was meant for Wireless USB and is no longer needed.) We can fix the oversight by testing for buf->bMaxPacketSize0 = 9 (meaning 512, the actual maxpacket size for ep0 on all SuperSpeed devices) and straightening out the logic that checks and adjusts our initial guesses of the maxpacket value. Reported-and-tested-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Closes: https://lore.kernel.org/linux-usb/20230810002257.nadxmfmrobkaxgnz@synopsys.com/ Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Fixes: 85d07c556216 ("USB: core: Unite old scheme and new scheme descriptor reads") Link: https://lore.kernel.org/r/8809e6c5-59d5-4d2d-ac8f-6d106658ad73@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-11 13:38:46 -04:00
USB: core: Unite old scheme and new scheme descriptor reads In preparation for reworking the usb_get_device_descriptor() routine, it is desirable to unite the two different code paths responsible for initially determining endpoint 0's maximum packet size in a newly discovered USB device. Making this determination presents a chicken-and-egg sort of problem, in that the only way to learn the maxpacket value is to get it from the device descriptor retrieved from the device, but communicating with the device to retrieve a descriptor requires us to know beforehand the ep0 maxpacket size. In practice this problem is solved in two different ways, referred to in hub.c as the "old scheme" and the "new scheme". The old scheme (which is the approach recommended by the USB-2 spec) involves asking the device to send just the first eight bytes of its device descriptor. Such a transfer uses packets containing no more than eight bytes each, and every USB device must have an ep0 maxpacket size >= 8, so this should succeed. Since the bMaxPacketSize0 field of the device descriptor lies within the first eight bytes, this is all we need. The new scheme is an imitation of the technique used in an early Windows USB implementation, giving it the happy advantage of working with a wide variety of devices (some of them at the time would not work with the old scheme, although that's probably less true now). It involves making an initial guess of the ep0 maxpacket size, asking the device to send up to 64 bytes worth of its device descriptor (which is only 18 bytes long), and then resetting the device to clear any error condition that might have resulted from the guess being wrong. The initial guess is determined by the connection speed; it should be correct in all cases other than full speed, for which the allowed values are 8, 16, 32, and 64 (in this case the initial guess is 64). The reason for this patch is that the old- and new-scheme parts of hub_port_init() use different code paths, one involving usb_get_device_descriptor() and one not, for their initial reads of the device descriptor. Since these reads have essentially the same purpose and are made under essentially the same circumstances, this is illogical. It makes more sense to have both of them use a common subroutine. This subroutine does basically what the new scheme's code did, because that approach is more general than the one used by the old scheme. It only needs to know how many bytes to transfer and whether or not it is being called for the first iteration of a retry loop (in case of certain time-out errors). There are two main differences from the former code: We initialize the bDescriptorType field of the transfer buffer to 0 before performing the transfer, to avoid possibly accessing an uninitialized value afterward. We read the device descriptor into a temporary buffer rather than storing it directly into udev->descriptor, which the old scheme implementation used to do. Since the whole point of this first read of the device descriptor is to determine the bMaxPacketSize0 value, that is what the new routine returns (or an error code). The value is stored in a local variable rather than in udev->descriptor. As a side effect, this necessitates moving a section of code that checks the bcdUSB field for SuperSpeed devices until after the full device descriptor has been retrieved. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/495cb5d4-f956-4f4a-a875-1e67e9489510@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:10:59 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: introduce port status lock In general we do not want khubd to act on port status changes that are the result of in progress resets or USB runtime PM operations. Specifically port power control testing has been able to trigger an unintended disconnect in hub_port_connect_change(), paraphrasing: if ((portstatus & USB_PORT_STAT_CONNECTION) && udev && udev->state != USB_STATE_NOTATTACHED) { if (portstatus & USB_PORT_STAT_ENABLE) { /* Nothing to do */ } else if (udev->state == USB_STATE_SUSPENDED && udev->persist_enabled) { ... } else { /* Don't resuscitate */; } } ...by falling to the "Don't resuscitate" path or missing USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of modifying the port status. So, we want a new lock to hold off khubd for a given port while the child device is being suspended, resumed, or reset. The lock ordering rules are now usb_lock_device() => usb_lock_port(). This is mandated by the device core which may hold the device_lock on the usb_device before invoking usb_port_{suspend|resume} which in turn take the status_lock on the usb_port. We attempt to hold the status_lock for the duration of a port_event() run, and drop/re-acquire it when needing to take the device_lock. The lock is also dropped/re-acquired during hub_port_reconnect(). This patch also deletes hub->busy_bits as all use cases are now covered by port PM runtime synchronization or the port->status_lock and it pushes down usb_device_lock() into usb_remote_wakeup(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:26 -07:00
USB: core: Fix race by not overwriting udev->descriptor in hub_port_init() Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors(): BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011 CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351 print_report mm/kasan/report.c:462 [inline] kasan_report+0x11c/0x130 mm/kasan/report.c:572 read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 ... Allocated by task 758: ... __do_kmalloc_node mm/slab_common.c:966 [inline] __kmalloc+0x5e/0x190 mm/slab_common.c:979 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:680 [inline] usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887 usb_enumerate_device drivers/usb/core/hub.c:2407 [inline] usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545 As analyzed by Khazhy Kumykov, the cause of this bug is a race between read_descriptors() and hub_port_init(): The first routine uses a field in udev->descriptor, not expecting it to change, while the second overwrites it. Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") this race couldn't occur, because the routines were mutually exclusive thanks to the device locking. Removing that locking from read_descriptors() exposed it to the race. The best way to fix the bug is to keep hub_port_init() from changing udev->descriptor once udev has been initialized and registered. Drivers expect the descriptors stored in the kernel to be immutable; we should not undermine this expectation. In fact, this change should have been made long ago. So now hub_port_init() will take an additional argument, specifying a buffer in which to store the device descriptor it reads. (If udev has not yet been initialized, the buffer pointer will be NULL and then hub_port_init() will store the device descriptor in udev as before.) This eliminates the data race responsible for the out-of-bounds read. The changes to hub_port_init() appear more extensive than they really are, because of indentation changes resulting from an attempt to avoid writing to other parts of the usb_device structure after it has been initialized. Similar changes should be made to the code that reads the BOS descriptor, but that can be handled in a separate patch later on. This patch is sufficient to fix the bug found by syzbot. Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Khazhy Kumykov <khazhy@google.com> Fixes: 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:14:14 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: hub: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-18 20:36:58 -07:00
USB: core: Fix race by not overwriting udev->descriptor in hub_port_init() Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors(): BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011 CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351 print_report mm/kasan/report.c:462 [inline] kasan_report+0x11c/0x130 mm/kasan/report.c:572 read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 ... Allocated by task 758: ... __do_kmalloc_node mm/slab_common.c:966 [inline] __kmalloc+0x5e/0x190 mm/slab_common.c:979 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:680 [inline] usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887 usb_enumerate_device drivers/usb/core/hub.c:2407 [inline] usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545 As analyzed by Khazhy Kumykov, the cause of this bug is a race between read_descriptors() and hub_port_init(): The first routine uses a field in udev->descriptor, not expecting it to change, while the second overwrites it. Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") this race couldn't occur, because the routines were mutually exclusive thanks to the device locking. Removing that locking from read_descriptors() exposed it to the race. The best way to fix the bug is to keep hub_port_init() from changing udev->descriptor once udev has been initialized and registered. Drivers expect the descriptors stored in the kernel to be immutable; we should not undermine this expectation. In fact, this change should have been made long ago. So now hub_port_init() will take an additional argument, specifying a buffer in which to store the device descriptor it reads. (If udev has not yet been initialized, the buffer pointer will be NULL and then hub_port_init() will store the device descriptor in udev as before.) This eliminates the data race responsible for the out-of-bounds read. The changes to hub_port_init() appear more extensive than they really are, because of indentation changes resulting from an attempt to avoid writing to other parts of the usb_device structure after it has been initialized. Similar changes should be made to the code that reads the BOS descriptor, but that can be handled in a separate patch later on. This patch is sufficient to fix the bug found by syzbot. Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Khazhy Kumykov <khazhy@google.com> Fixes: 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:14:14 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: Don't reset USB 3.0 devices on port change detection. The USB 3.0 bus specification defines a new connection sequence for USB 3.0 hubs and roothubs. USB 3.0 devices are reset and link trained by the hub before the port status change notification is sent to the host OS. This means that an entire tree of devices can be trained in parallel on power up, and the OS no longer needs to reset USB 3.0 devices. Change the USB core's hub port init sequence so that it does not reset USB 3.0 devices. The port status change from the roothub and from the USB 3.0 hub will report the SuperSpeed connect correctly. This patch currently only handles the roothub case. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-27 19:54:26 -07:00
usb: hub: Per-port setting to use old enumeration scheme The "old" enumeration scheme is considerably faster (it takes ~244ms instead of ~356ms to get the descriptor). It is currently only possible to use the old scheme globally (/sys/module/usbcore/parameters/old_scheme_first), which is not desirable as the new scheme was introduced to increase compatibility with more devices. However, in our case, we care about time-to-active for a specific USB device (which we make the firmware for), on a specific port (that is pogo-pin based: not a standard USB port). This new sysfs option makes it possible to use the old scheme on a single port only. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-28 14:32:18 +08:00
usb: hub: fix a typo in hub_port_init() leading to wrong logic A typo of j for i led to a logic bug. To rule out future confusion, the variable names are made meaningful. Signed-off-by: Oliver Neukum <ONeukum@suse.com> CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-17 11:52:43 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: Provide usb_speed_string() function In a few places in the kernel, the code prints a human-readable USB device speed (eg. "high speed"). This involves a switch statement sometimes wrapped around in ({ ... }) block leading to code repetition. To mitigate this issue, this commit introduces usb_speed_string() function, which returns a human-readable name of provided speed. It also changes a few places switch was used to use this new function. This changes a bit the way the speed is printed in few instances at the same time standardising it. Signed-off-by: Michal Nazarewicz <mina86@mina86.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-08-30 17:11:19 +02:00
USB: address-0 handling during device initialization This patch (as947) changes the device initialization and enumeration code in hub.c; now udev->devnum will be set to 0 while the device is being accessed at address 0. Until now this wasn't needed because the address value was passed as part of urb->pipe; without that field the device address must be stored elsewhere. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-30 17:08:43 -04:00
usb: core: hub: controller driver name may be NULL The controller driver may be NULL if the controller device is the middle device between platform device and roothub. This middle device may not need a device driver due to all hardware control can be at platform device driver, this platform device is usually a dual-role USB controller device. The benefit of using this middle device is we can keep both controller device's private data (known as struct usb_hcd) for USB core use, and platform device's private data for platform driver use. Signed-off-by: Peter Chen <peter.chen@nxp.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-19 14:40:53 +08:00
USB: hub: Clean up use of port initialization schemes and retries The SET_CONFIG_TRIES macro in hub.c is badly named; it controls the number of port-initialization retry attempts rather than the number of Set-Configuration attempts. Furthermore, the USE_NEW_SCHEME macro and use_new_scheme() function are written in a very confusing manner, making it almost impossible to figure out exactly what they do or check that they are correct. This patch renames SET_CONFIG_TRIES to PORT_INIT_TRIES, removes USE_NEW_SCHEME entirely, and rewrites use_new_scheme() to be much more transparent, with added comments explaining how it works. The patch also pulls the single call site of use_new_scheme() out from the Get-Descriptor retry loop (where it returns the same value each time) and renames the local variable used to store the result. The overall effect is a minor cleanup. However, there is one functional change: If the "use_both_schemes" module parameter isn't set (by default it is set), the existing code does only two retry iterations. After this patch it will always perform four, regardless of the parameter's value. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200928152050.GA134701@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-28 11:20:50 -04:00
USB: core: Fix race by not overwriting udev->descriptor in hub_port_init() Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors(): BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011 CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351 print_report mm/kasan/report.c:462 [inline] kasan_report+0x11c/0x130 mm/kasan/report.c:572 read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 ... Allocated by task 758: ... __do_kmalloc_node mm/slab_common.c:966 [inline] __kmalloc+0x5e/0x190 mm/slab_common.c:979 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:680 [inline] usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887 usb_enumerate_device drivers/usb/core/hub.c:2407 [inline] usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545 As analyzed by Khazhy Kumykov, the cause of this bug is a race between read_descriptors() and hub_port_init(): The first routine uses a field in udev->descriptor, not expecting it to change, while the second overwrites it. Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") this race couldn't occur, because the routines were mutually exclusive thanks to the device locking. Removing that locking from read_descriptors() exposed it to the race. The best way to fix the bug is to keep hub_port_init() from changing udev->descriptor once udev has been initialized and registered. Drivers expect the descriptors stored in the kernel to be immutable; we should not undermine this expectation. In fact, this change should have been made long ago. So now hub_port_init() will take an additional argument, specifying a buffer in which to store the device descriptor it reads. (If udev has not yet been initialized, the buffer pointer will be NULL and then hub_port_init() will store the device descriptor in udev as before.) This eliminates the data race responsible for the out-of-bounds read. The changes to hub_port_init() appear more extensive than they really are, because of indentation changes resulting from an attempt to avoid writing to other parts of the usb_device structure after it has been initialized. Similar changes should be made to the code that reads the BOS descriptor, but that can be handled in a separate patch later on. This patch is sufficient to fix the bug found by syzbot. Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Khazhy Kumykov <khazhy@google.com> Fixes: 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:14:14 -04:00
USB: core: Unite old scheme and new scheme descriptor reads In preparation for reworking the usb_get_device_descriptor() routine, it is desirable to unite the two different code paths responsible for initially determining endpoint 0's maximum packet size in a newly discovered USB device. Making this determination presents a chicken-and-egg sort of problem, in that the only way to learn the maxpacket value is to get it from the device descriptor retrieved from the device, but communicating with the device to retrieve a descriptor requires us to know beforehand the ep0 maxpacket size. In practice this problem is solved in two different ways, referred to in hub.c as the "old scheme" and the "new scheme". The old scheme (which is the approach recommended by the USB-2 spec) involves asking the device to send just the first eight bytes of its device descriptor. Such a transfer uses packets containing no more than eight bytes each, and every USB device must have an ep0 maxpacket size >= 8, so this should succeed. Since the bMaxPacketSize0 field of the device descriptor lies within the first eight bytes, this is all we need. The new scheme is an imitation of the technique used in an early Windows USB implementation, giving it the happy advantage of working with a wide variety of devices (some of them at the time would not work with the old scheme, although that's probably less true now). It involves making an initial guess of the ep0 maxpacket size, asking the device to send up to 64 bytes worth of its device descriptor (which is only 18 bytes long), and then resetting the device to clear any error condition that might have resulted from the guess being wrong. The initial guess is determined by the connection speed; it should be correct in all cases other than full speed, for which the allowed values are 8, 16, 32, and 64 (in this case the initial guess is 64). The reason for this patch is that the old- and new-scheme parts of hub_port_init() use different code paths, one involving usb_get_device_descriptor() and one not, for their initial reads of the device descriptor. Since these reads have essentially the same purpose and are made under essentially the same circumstances, this is illogical. It makes more sense to have both of them use a common subroutine. This subroutine does basically what the new scheme's code did, because that approach is more general than the one used by the old scheme. It only needs to know how many bytes to transfer and whether or not it is being called for the first iteration of a retry loop (in case of certain time-out errors). There are two main differences from the former code: We initialize the bDescriptorType field of the transfer buffer to 0 before performing the transfer, to avoid possibly accessing an uninitialized value afterward. We read the device descriptor into a temporary buffer rather than storing it directly into udev->descriptor, which the old scheme implementation used to do. Since the whole point of this first read of the device descriptor is to determine the bMaxPacketSize0 value, that is what the new routine returns (or an error code). The value is stored in a local variable rather than in udev->descriptor. As a side effect, this necessitates moving a section of code that checks the bcdUSB field for SuperSpeed devices until after the full device descriptor has been retrieved. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/495cb5d4-f956-4f4a-a875-1e67e9489510@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:10:59 -04:00
USB: core: Change usb_get_device_descriptor() API The usb_get_device_descriptor() routine reads the device descriptor from the udev device and stores it directly in udev->descriptor. This interface is error prone, because the USB subsystem expects in-memory copies of a device's descriptors to be immutable once the device has been initialized. The interface is changed so that the device descriptor is left in a kmalloc-ed buffer, not copied into the usb_device structure. A pointer to the buffer is returned to the caller, who is then responsible for kfree-ing it. The corresponding changes needed in the various callers are fairly small. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/d0111bb6-56c1-4f90-adf2-6cfe152f6561@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:12:21 -04:00
USB: core: Unite old scheme and new scheme descriptor reads In preparation for reworking the usb_get_device_descriptor() routine, it is desirable to unite the two different code paths responsible for initially determining endpoint 0's maximum packet size in a newly discovered USB device. Making this determination presents a chicken-and-egg sort of problem, in that the only way to learn the maxpacket value is to get it from the device descriptor retrieved from the device, but communicating with the device to retrieve a descriptor requires us to know beforehand the ep0 maxpacket size. In practice this problem is solved in two different ways, referred to in hub.c as the "old scheme" and the "new scheme". The old scheme (which is the approach recommended by the USB-2 spec) involves asking the device to send just the first eight bytes of its device descriptor. Such a transfer uses packets containing no more than eight bytes each, and every USB device must have an ep0 maxpacket size >= 8, so this should succeed. Since the bMaxPacketSize0 field of the device descriptor lies within the first eight bytes, this is all we need. The new scheme is an imitation of the technique used in an early Windows USB implementation, giving it the happy advantage of working with a wide variety of devices (some of them at the time would not work with the old scheme, although that's probably less true now). It involves making an initial guess of the ep0 maxpacket size, asking the device to send up to 64 bytes worth of its device descriptor (which is only 18 bytes long), and then resetting the device to clear any error condition that might have resulted from the guess being wrong. The initial guess is determined by the connection speed; it should be correct in all cases other than full speed, for which the allowed values are 8, 16, 32, and 64 (in this case the initial guess is 64). The reason for this patch is that the old- and new-scheme parts of hub_port_init() use different code paths, one involving usb_get_device_descriptor() and one not, for their initial reads of the device descriptor. Since these reads have essentially the same purpose and are made under essentially the same circumstances, this is illogical. It makes more sense to have both of them use a common subroutine. This subroutine does basically what the new scheme's code did, because that approach is more general than the one used by the old scheme. It only needs to know how many bytes to transfer and whether or not it is being called for the first iteration of a retry loop (in case of certain time-out errors). There are two main differences from the former code: We initialize the bDescriptorType field of the transfer buffer to 0 before performing the transfer, to avoid possibly accessing an uninitialized value afterward. We read the device descriptor into a temporary buffer rather than storing it directly into udev->descriptor, which the old scheme implementation used to do. Since the whole point of this first read of the device descriptor is to determine the bMaxPacketSize0 value, that is what the new routine returns (or an error code). The value is stored in a local variable rather than in udev->descriptor. As a side effect, this necessitates moving a section of code that checks the bcdUSB field for SuperSpeed devices until after the full device descriptor has been retrieved. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/495cb5d4-f956-4f4a-a875-1e67e9489510@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:10:59 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: Reset USB 3.0 devices on (re)discovery If the device isn't reset, the XHCI HCD sends SET ADDRESS to address 0 while the device is already in Addressed state, and the request is dropped on the floor as it is addressed to the default address. This sequence of events, which this patch fixes looks like this: usb_reset_and_verify_device() hub_port_init() hub_set_address() SET_ADDRESS to 0 with 1 usb_get_device_descriptor(udev, 8) usb_get_device_descriptor(udev, 18) descriptors_changed() --> goto re_enumerate: hub_port_logical_disconnect() kick_khubd() And then: hub_events() hub_port_connect_change() usb_disconnect() usb_disable_device() new device struct sets device state to Powered choose_address() hub_port_init() <-- no reset, but SET ADDRESS to 0 with 1, timeout! The solution is to always reset the device in hub_port_init() to put it in a known state. Note from Sarah Sharp: This patch should be queued for stable trees all the way back to 2.6.34, since that was the first kernel that supported configured device reset. The code this patch touches has been there since 2.6.32, but the bug would never be hit before 2.6.34 because the xHCI driver would completely reject an attempt to reset a configured device under xHCI. Signed-off-by: Luben Tuikov <ltuikov@yahoo.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@kernel.org
2011-02-11 11:33:10 -08:00
usbcore: refine warm reset logic Current waiting time for warm(BH) reset in hub_port_warm_reset() is too short for xHC host to complete the warm reset and report a BH reset change. This patch increases the waiting time for warm reset and merges the function into hub_port_reset(), so it can handle both cold reset and warm reset, and factor out hub_port_finish_reset() to make the code looks cleaner. This fixes the issue that driver fails to clear BH reset change and port is "dead". Signed-off-by: Andiry Xu <andiry.xu@amd.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-13 16:41:11 -07:00
USB: Reset USB 3.0 devices on (re)discovery If the device isn't reset, the XHCI HCD sends SET ADDRESS to address 0 while the device is already in Addressed state, and the request is dropped on the floor as it is addressed to the default address. This sequence of events, which this patch fixes looks like this: usb_reset_and_verify_device() hub_port_init() hub_set_address() SET_ADDRESS to 0 with 1 usb_get_device_descriptor(udev, 8) usb_get_device_descriptor(udev, 18) descriptors_changed() --> goto re_enumerate: hub_port_logical_disconnect() kick_khubd() And then: hub_events() hub_port_connect_change() usb_disconnect() usb_disable_device() new device struct sets device state to Powered choose_address() hub_port_init() <-- no reset, but SET ADDRESS to 0 with 1, timeout! The solution is to always reset the device in hub_port_init() to put it in a known state. Note from Sarah Sharp: This patch should be queued for stable trees all the way back to 2.6.34, since that was the first kernel that supported configured device reset. The code this patch touches has been there since 2.6.32, but the bug would never be hit before 2.6.34 because the xHCI driver would completely reject an attempt to reset a configured device under xHCI. Signed-off-by: Luben Tuikov <ltuikov@yahoo.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@kernel.org
2011-02-11 11:33:10 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: define USB_SPEED_SUPER_PLUS speed for SuperSpeedPlus USB3.1 devices Add a new USB_SPEED_SUPER_PLUS device speed, and make sure usb core can handle the new speed. In most cases the behaviour is the same as with USB_SPEED_SUPER SuperSpeed devices. In a few places we add a "Plus" string to inform the user of the new speed. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-10 09:59:25 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: address-0 handling during device initialization This patch (as947) changes the device initialization and enumeration code in hub.c; now udev->devnum will be set to 0 while the device is being accessed at address 0. Until now this wasn't needed because the address value was passed as part of urb->pipe; without that field the device address must be stored elsewhere. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-30 17:08:43 -04:00
USB: core: Fix race by not overwriting udev->descriptor in hub_port_init() Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors(): BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011 CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351 print_report mm/kasan/report.c:462 [inline] kasan_report+0x11c/0x130 mm/kasan/report.c:572 read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 ... Allocated by task 758: ... __do_kmalloc_node mm/slab_common.c:966 [inline] __kmalloc+0x5e/0x190 mm/slab_common.c:979 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:680 [inline] usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887 usb_enumerate_device drivers/usb/core/hub.c:2407 [inline] usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545 As analyzed by Khazhy Kumykov, the cause of this bug is a race between read_descriptors() and hub_port_init(): The first routine uses a field in udev->descriptor, not expecting it to change, while the second overwrites it. Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") this race couldn't occur, because the routines were mutually exclusive thanks to the device locking. Removing that locking from read_descriptors() exposed it to the race. The best way to fix the bug is to keep hub_port_init() from changing udev->descriptor once udev has been initialized and registered. Drivers expect the descriptors stored in the kernel to be immutable; we should not undermine this expectation. In fact, this change should have been made long ago. So now hub_port_init() will take an additional argument, specifying a buffer in which to store the device descriptor it reads. (If udev has not yet been initialized, the buffer pointer will be NULL and then hub_port_init() will store the device descriptor in udev as before.) This eliminates the data race responsible for the out-of-bounds read. The changes to hub_port_init() appear more extensive than they really are, because of indentation changes resulting from an attempt to avoid writing to other parts of the usb_device structure after it has been initialized. Similar changes should be made to the code that reads the BOS descriptor, but that can be handled in a separate patch later on. This patch is sufficient to fix the bug found by syzbot. Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Khazhy Kumykov <khazhy@google.com> Fixes: 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:14:14 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: core: Fix race by not overwriting udev->descriptor in hub_port_init() Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors(): BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011 CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351 print_report mm/kasan/report.c:462 [inline] kasan_report+0x11c/0x130 mm/kasan/report.c:572 read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 ... Allocated by task 758: ... __do_kmalloc_node mm/slab_common.c:966 [inline] __kmalloc+0x5e/0x190 mm/slab_common.c:979 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:680 [inline] usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887 usb_enumerate_device drivers/usb/core/hub.c:2407 [inline] usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545 As analyzed by Khazhy Kumykov, the cause of this bug is a race between read_descriptors() and hub_port_init(): The first routine uses a field in udev->descriptor, not expecting it to change, while the second overwrites it. Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") this race couldn't occur, because the routines were mutually exclusive thanks to the device locking. Removing that locking from read_descriptors() exposed it to the race. The best way to fix the bug is to keep hub_port_init() from changing udev->descriptor once udev has been initialized and registered. Drivers expect the descriptors stored in the kernel to be immutable; we should not undermine this expectation. In fact, this change should have been made long ago. So now hub_port_init() will take an additional argument, specifying a buffer in which to store the device descriptor it reads. (If udev has not yet been initialized, the buffer pointer will be NULL and then hub_port_init() will store the device descriptor in udev as before.) This eliminates the data race responsible for the out-of-bounds read. The changes to hub_port_init() appear more extensive than they really are, because of indentation changes resulting from an attempt to avoid writing to other parts of the usb_device structure after it has been initialized. Similar changes should be made to the code that reads the BOS descriptor, but that can be handled in a separate patch later on. This patch is sufficient to fix the bug found by syzbot. Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Khazhy Kumykov <khazhy@google.com> Fixes: 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:14:14 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: Provide usb_speed_string() function In a few places in the kernel, the code prints a human-readable USB device speed (eg. "high speed"). This involves a switch statement sometimes wrapped around in ({ ... }) block leading to code repetition. To mitigate this issue, this commit introduces usb_speed_string() function, which returns a human-readable name of provided speed. It also changes a few places switch was used to use this new function. This changes a bit the way the speed is printed in few instances at the same time standardising it. Signed-off-by: Michal Nazarewicz <mina86@mina86.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-08-30 17:11:19 +02:00
USB: Remove remnants of Wireless USB and UWB Wireless USB has long been defunct, and kernel support for it was removed in 2020 by commit caa6772db4c1 ("Staging: remove wusbcore and UWB from the kernel tree."). Nevertheless, some vestiges of the old implementation still clutter up the USB subsystem and one or two other places. Let's get rid of them once and for all. The only parts still left are the user-facing APIs in include/uapi/linux/usb/ch9.h. (There are also a couple of misleading instances, such as the Sierra Wireless USB modem, which is a USB modem made by Sierra Wireless.) Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/b4f2710f-a2de-4fb0-b50f-76776f3a961b@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-08 20:44:18 -04:00
usb: Provide usb_speed_string() function In a few places in the kernel, the code prints a human-readable USB device speed (eg. "high speed"). This involves a switch statement sometimes wrapped around in ({ ... }) block leading to code repetition. To mitigate this issue, this commit introduces usb_speed_string() function, which returns a human-readable name of provided speed. It also changes a few places switch was used to use this new function. This changes a bit the way the speed is printed in few instances at the same time standardising it. Signed-off-by: Michal Nazarewicz <mina86@mina86.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-08-30 17:11:19 +02:00
usb: core: hub: controller driver name may be NULL The controller driver may be NULL if the controller device is the middle device between platform device and roothub. This middle device may not need a device driver due to all hardware control can be at platform device driver, this platform device is usually a dual-role USB controller device. The benefit of using this middle device is we can keep both controller device's private data (known as struct usb_hcd) for USB core use, and platform device's private data for platform driver use. Signed-off-by: Peter Chen <peter.chen@nxp.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-19 14:40:53 +08:00
usb: define USB_SPEED_SUPER_PLUS speed for SuperSpeedPlus USB3.1 devices Add a new USB_SPEED_SUPER_PLUS device speed, and make sure usb core can handle the new speed. In most cases the behaviour is the same as with USB_SPEED_SUPER SuperSpeed devices. In a few places we add a "Plus" string to inform the user of the new speed. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-10 09:59:25 +02:00
USB: Support for addressing a USB device under xHCI Add host controller driver API and a slot_id variable to struct usb_device. This allows the xHCI host controller driver to ask the hardware to allocate a slot for the device when a struct usb_device is allocated. The slot needs to be allocated at that point because the hardware can run out of internal resources, and we want to know that very early in the device connection process. Don't call this new API for root hubs, since they aren't real devices. Add HCD API to let the host controller choose the device address. This is especially important for xHCI hardware running in a virtualized environment. The guests running under the VM don't need to know which addresses on the bus are taken, because the hardware picks the address for them. Announce SuperSpeed USB devices after the address has been assigned by the hardware. Don't use the new get descriptor/set address scheme with xHCI. Unless special handling is done in the host controller driver, the xHC can't issue control transfers before you set the device address. Support for the older addressing scheme will be added when the xHCI driver supports the Block Set Address Request (BSR) flag in the Address Device command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-27 19:57:26 -07:00
usb: Provide usb_speed_string() function In a few places in the kernel, the code prints a human-readable USB device speed (eg. "high speed"). This involves a switch statement sometimes wrapped around in ({ ... }) block leading to code repetition. To mitigate this issue, this commit introduces usb_speed_string() function, which returns a human-readable name of provided speed. It also changes a few places switch was used to use this new function. This changes a bit the way the speed is printed in few instances at the same time standardising it. Signed-off-by: Michal Nazarewicz <mina86@mina86.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-08-30 17:11:19 +02:00
USB: core: Fix race by not overwriting udev->descriptor in hub_port_init() Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors(): BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011 CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351 print_report mm/kasan/report.c:462 [inline] kasan_report+0x11c/0x130 mm/kasan/report.c:572 read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 ... Allocated by task 758: ... __do_kmalloc_node mm/slab_common.c:966 [inline] __kmalloc+0x5e/0x190 mm/slab_common.c:979 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:680 [inline] usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887 usb_enumerate_device drivers/usb/core/hub.c:2407 [inline] usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545 As analyzed by Khazhy Kumykov, the cause of this bug is a race between read_descriptors() and hub_port_init(): The first routine uses a field in udev->descriptor, not expecting it to change, while the second overwrites it. Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") this race couldn't occur, because the routines were mutually exclusive thanks to the device locking. Removing that locking from read_descriptors() exposed it to the race. The best way to fix the bug is to keep hub_port_init() from changing udev->descriptor once udev has been initialized and registered. Drivers expect the descriptors stored in the kernel to be immutable; we should not undermine this expectation. In fact, this change should have been made long ago. So now hub_port_init() will take an additional argument, specifying a buffer in which to store the device descriptor it reads. (If udev has not yet been initialized, the buffer pointer will be NULL and then hub_port_init() will store the device descriptor in udev as before.) This eliminates the data race responsible for the out-of-bounds read. The changes to hub_port_init() appear more extensive than they really are, because of indentation changes resulting from an attempt to avoid writing to other parts of the usb_device structure after it has been initialized. Similar changes should be made to the code that reads the BOS descriptor, but that can be handled in a separate patch later on. This patch is sufficient to fix the bug found by syzbot. Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Khazhy Kumykov <khazhy@google.com> Fixes: 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:14:14 -04:00
usb: core: hub: controller driver name may be NULL The controller driver may be NULL if the controller device is the middle device between platform device and roothub. This middle device may not need a device driver due to all hardware control can be at platform device driver, this platform device is usually a dual-role USB controller device. The benefit of using this middle device is we can keep both controller device's private data (known as struct usb_hcd) for USB core use, and platform device's private data for platform driver use. Signed-off-by: Peter Chen <peter.chen@nxp.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-19 14:40:53 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: core: Fix race by not overwriting udev->descriptor in hub_port_init() Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors(): BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011 CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351 print_report mm/kasan/report.c:462 [inline] kasan_report+0x11c/0x130 mm/kasan/report.c:572 read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 ... Allocated by task 758: ... __do_kmalloc_node mm/slab_common.c:966 [inline] __kmalloc+0x5e/0x190 mm/slab_common.c:979 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:680 [inline] usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887 usb_enumerate_device drivers/usb/core/hub.c:2407 [inline] usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545 As analyzed by Khazhy Kumykov, the cause of this bug is a race between read_descriptors() and hub_port_init(): The first routine uses a field in udev->descriptor, not expecting it to change, while the second overwrites it. Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") this race couldn't occur, because the routines were mutually exclusive thanks to the device locking. Removing that locking from read_descriptors() exposed it to the race. The best way to fix the bug is to keep hub_port_init() from changing udev->descriptor once udev has been initialized and registered. Drivers expect the descriptors stored in the kernel to be immutable; we should not undermine this expectation. In fact, this change should have been made long ago. So now hub_port_init() will take an additional argument, specifying a buffer in which to store the device descriptor it reads. (If udev has not yet been initialized, the buffer pointer will be NULL and then hub_port_init() will store the device descriptor in udev as before.) This eliminates the data race responsible for the out-of-bounds read. The changes to hub_port_init() appear more extensive than they really are, because of indentation changes resulting from an attempt to avoid writing to other parts of the usb_device structure after it has been initialized. Similar changes should be made to the code that reads the BOS descriptor, but that can be handled in a separate patch later on. This patch is sufficient to fix the bug found by syzbot. Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Khazhy Kumykov <khazhy@google.com> Fixes: 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:14:14 -04:00
USB: prevent buggy hubs from crashing the USB stack If anyone comes across a high-speed hub that (by mistake or by design) claims to have no Transaction Translators, plugging a full- or low-speed device into it will cause the USB stack to crash. This patch (as1446) prevents the problem by ignoring such devices, since the kernel has no way to communicate with them. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Perry Neben <neben@vmware.com> CC: <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-01-31 10:56:37 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
drivers: usb: core: {file,hub,sysfs,usb}.c: Whitespace fixes including: - removing of trailing whitespace - removing spaces before array indexing (foo [] to foo[]) - reindention of a switch-case block - spaces to tabs Signed-off-by: Matthias Beyer <mail@beyermatthias.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-10 23:41:27 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: xhci: change enumeration scheme to 'new scheme' by default Change the default enumeration scheme for xhci attached non-SuperSpeed devices from: Reset SetAddress [xhci address-device BSR = 0] GetDescriptor(8) GetDescriptor(18) ...to: Reset [xhci address-device BSR = 1] GetDescriptor(64) Reset SetAddress [xhci address-device BSR = 0] GetDescriptor(18) ...as some devices misbehave when encountering a SetAddress command prior to GetDescriptor. There are known legacy devices that require this scheme, but testing has found at least one USB3 device that fails enumeration when presented with this ordering. For now, follow the ehci case and enable 'new scheme' by default for non-SuperSpeed devices. To support this enumeration scheme on xhci the AddressDevice operation needs to be performed twice. The first instance of the command enables the HC's device and slot context info for the device, but omits sending the device a SetAddress command (BSR == block set address request). Then, after GetDescriptor completes, follow up with the full AddressDevice+SetAddress operation. As mentioned before, this ordering of events with USB3 devices causes an extra state transition to be exposed to xhci. Previously USB3 devices would transition directly from 'enabled' to 'addressed' and never need to underrun responses to 'get descriptor'. We do see the 64-byte descriptor fetch the correct data, but the following 18-byte descriptor read after the reset gets: bLength = 0 bDescriptorType = 0 bcdUSB = 0 bDeviceClass = 0 bDeviceSubClass = 0 bDeviceProtocol = 0 bMaxPacketSize0 = 9 instead of: bLength = 12 bDescriptorType = 1 bcdUSB = 300 bDeviceClass = 0 bDeviceSubClass = 0 bDeviceProtocol = 0 bMaxPacketSize0 = 9 which results in the discovery process looping until falling back to 'old scheme' enumeration. Acked-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: David Moore <david.moore@gmail.com> Suggested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-12-05 17:07:27 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: hub: Clean up use of port initialization schemes and retries The SET_CONFIG_TRIES macro in hub.c is badly named; it controls the number of port-initialization retry attempts rather than the number of Set-Configuration attempts. Furthermore, the USE_NEW_SCHEME macro and use_new_scheme() function are written in a very confusing manner, making it almost impossible to figure out exactly what they do or check that they are correct. This patch renames SET_CONFIG_TRIES to PORT_INIT_TRIES, removes USE_NEW_SCHEME entirely, and rewrites use_new_scheme() to be much more transparent, with added comments explaining how it works. The patch also pulls the single call site of use_new_scheme() out from the Get-Descriptor retry loop (where it returns the same value each time) and renames the local variable used to store the result. The overall effect is a minor cleanup. However, there is one functional change: If the "use_both_schemes" module parameter isn't set (by default it is set), the existing code does only two retry iterations. After this patch it will always perform four, regardless of the parameter's value. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200928152050.GA134701@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-28 11:20:50 -04:00
usb: xhci: change enumeration scheme to 'new scheme' by default Change the default enumeration scheme for xhci attached non-SuperSpeed devices from: Reset SetAddress [xhci address-device BSR = 0] GetDescriptor(8) GetDescriptor(18) ...to: Reset [xhci address-device BSR = 1] GetDescriptor(64) Reset SetAddress [xhci address-device BSR = 0] GetDescriptor(18) ...as some devices misbehave when encountering a SetAddress command prior to GetDescriptor. There are known legacy devices that require this scheme, but testing has found at least one USB3 device that fails enumeration when presented with this ordering. For now, follow the ehci case and enable 'new scheme' by default for non-SuperSpeed devices. To support this enumeration scheme on xhci the AddressDevice operation needs to be performed twice. The first instance of the command enables the HC's device and slot context info for the device, but omits sending the device a SetAddress command (BSR == block set address request). Then, after GetDescriptor completes, follow up with the full AddressDevice+SetAddress operation. As mentioned before, this ordering of events with USB3 devices causes an extra state transition to be exposed to xhci. Previously USB3 devices would transition directly from 'enabled' to 'addressed' and never need to underrun responses to 'get descriptor'. We do see the 64-byte descriptor fetch the correct data, but the following 18-byte descriptor read after the reset gets: bLength = 0 bDescriptorType = 0 bcdUSB = 0 bDeviceClass = 0 bDeviceSubClass = 0 bDeviceProtocol = 0 bMaxPacketSize0 = 9 instead of: bLength = 12 bDescriptorType = 1 bcdUSB = 300 bDeviceClass = 0 bDeviceSubClass = 0 bDeviceProtocol = 0 bMaxPacketSize0 = 9 which results in the discovery process looping until falling back to 'old scheme' enumeration. Acked-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: David Moore <david.moore@gmail.com> Suggested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-12-05 17:07:27 -08:00
USB: hub: Clean up use of port initialization schemes and retries The SET_CONFIG_TRIES macro in hub.c is badly named; it controls the number of port-initialization retry attempts rather than the number of Set-Configuration attempts. Furthermore, the USE_NEW_SCHEME macro and use_new_scheme() function are written in a very confusing manner, making it almost impossible to figure out exactly what they do or check that they are correct. This patch renames SET_CONFIG_TRIES to PORT_INIT_TRIES, removes USE_NEW_SCHEME entirely, and rewrites use_new_scheme() to be much more transparent, with added comments explaining how it works. The patch also pulls the single call site of use_new_scheme() out from the Get-Descriptor retry loop (where it returns the same value each time) and renames the local variable used to store the result. The overall effect is a minor cleanup. However, there is one functional change: If the "use_both_schemes" module parameter isn't set (by default it is set), the existing code does only two retry iterations. After this patch it will always perform four, regardless of the parameter's value. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200928152050.GA134701@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-28 11:20:50 -04:00
usb: core: stop USB enumeration if too many retries When a broken USB accessory connects to a USB host, usbcore might keep doing enumeration retries. If the host has a watchdog mechanism, the kernel panic will happen on the host. This patch provides an attribute early_stop to limit the numbers of retries for each port of a hub. If a port was marked with early_stop attribute, unsuccessful connection attempts will fail quickly. In addition, if an early_stop port has failed to initialize, it will ignore all future connection events until early_stop attribute is clear. Signed-off-by: Ray Chi <raychi@google.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20221107072754.3336357-1-raychi@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-11-07 15:27:54 +08:00
USB: hub: Clean up use of port initialization schemes and retries The SET_CONFIG_TRIES macro in hub.c is badly named; it controls the number of port-initialization retry attempts rather than the number of Set-Configuration attempts. Furthermore, the USE_NEW_SCHEME macro and use_new_scheme() function are written in a very confusing manner, making it almost impossible to figure out exactly what they do or check that they are correct. This patch renames SET_CONFIG_TRIES to PORT_INIT_TRIES, removes USE_NEW_SCHEME entirely, and rewrites use_new_scheme() to be much more transparent, with added comments explaining how it works. The patch also pulls the single call site of use_new_scheme() out from the Get-Descriptor retry loop (where it returns the same value each time) and renames the local variable used to store the result. The overall effect is a minor cleanup. However, there is one functional change: If the "use_both_schemes" module parameter isn't set (by default it is set), the existing code does only two retry iterations. After this patch it will always perform four, regardless of the parameter's value. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200928152050.GA134701@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-28 11:20:50 -04:00
usb: xhci: change enumeration scheme to 'new scheme' by default Change the default enumeration scheme for xhci attached non-SuperSpeed devices from: Reset SetAddress [xhci address-device BSR = 0] GetDescriptor(8) GetDescriptor(18) ...to: Reset [xhci address-device BSR = 1] GetDescriptor(64) Reset SetAddress [xhci address-device BSR = 0] GetDescriptor(18) ...as some devices misbehave when encountering a SetAddress command prior to GetDescriptor. There are known legacy devices that require this scheme, but testing has found at least one USB3 device that fails enumeration when presented with this ordering. For now, follow the ehci case and enable 'new scheme' by default for non-SuperSpeed devices. To support this enumeration scheme on xhci the AddressDevice operation needs to be performed twice. The first instance of the command enables the HC's device and slot context info for the device, but omits sending the device a SetAddress command (BSR == block set address request). Then, after GetDescriptor completes, follow up with the full AddressDevice+SetAddress operation. As mentioned before, this ordering of events with USB3 devices causes an extra state transition to be exposed to xhci. Previously USB3 devices would transition directly from 'enabled' to 'addressed' and never need to underrun responses to 'get descriptor'. We do see the 64-byte descriptor fetch the correct data, but the following 18-byte descriptor read after the reset gets: bLength = 0 bDescriptorType = 0 bcdUSB = 0 bDeviceClass = 0 bDeviceSubClass = 0 bDeviceProtocol = 0 bMaxPacketSize0 = 9 instead of: bLength = 12 bDescriptorType = 1 bcdUSB = 300 bDeviceClass = 0 bDeviceSubClass = 0 bDeviceProtocol = 0 bMaxPacketSize0 = 9 which results in the discovery process looping until falling back to 'old scheme' enumeration. Acked-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: David Moore <david.moore@gmail.com> Suggested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-12-05 17:07:27 -08:00
hub: debug message for failing to enable device This error case isn't reported during enumeration. Signed-off-by: Oliver Neukum <oliver@neukum.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-27 10:57:10 +01:00
usb: xhci: change enumeration scheme to 'new scheme' by default Change the default enumeration scheme for xhci attached non-SuperSpeed devices from: Reset SetAddress [xhci address-device BSR = 0] GetDescriptor(8) GetDescriptor(18) ...to: Reset [xhci address-device BSR = 1] GetDescriptor(64) Reset SetAddress [xhci address-device BSR = 0] GetDescriptor(18) ...as some devices misbehave when encountering a SetAddress command prior to GetDescriptor. There are known legacy devices that require this scheme, but testing has found at least one USB3 device that fails enumeration when presented with this ordering. For now, follow the ehci case and enable 'new scheme' by default for non-SuperSpeed devices. To support this enumeration scheme on xhci the AddressDevice operation needs to be performed twice. The first instance of the command enables the HC's device and slot context info for the device, but omits sending the device a SetAddress command (BSR == block set address request). Then, after GetDescriptor completes, follow up with the full AddressDevice+SetAddress operation. As mentioned before, this ordering of events with USB3 devices causes an extra state transition to be exposed to xhci. Previously USB3 devices would transition directly from 'enabled' to 'addressed' and never need to underrun responses to 'get descriptor'. We do see the 64-byte descriptor fetch the correct data, but the following 18-byte descriptor read after the reset gets: bLength = 0 bDescriptorType = 0 bcdUSB = 0 bDeviceClass = 0 bDeviceSubClass = 0 bDeviceProtocol = 0 bMaxPacketSize0 = 9 instead of: bLength = 12 bDescriptorType = 1 bcdUSB = 300 bDeviceClass = 0 bDeviceSubClass = 0 bDeviceProtocol = 0 bMaxPacketSize0 = 9 which results in the discovery process looping until falling back to 'old scheme' enumeration. Acked-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: David Moore <david.moore@gmail.com> Suggested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-12-05 17:07:27 -08:00
hub: debug message for failing to enable device This error case isn't reported during enumeration. Signed-off-by: Oliver Neukum <oliver@neukum.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-27 10:57:10 +01:00
usb: xhci: change enumeration scheme to 'new scheme' by default Change the default enumeration scheme for xhci attached non-SuperSpeed devices from: Reset SetAddress [xhci address-device BSR = 0] GetDescriptor(8) GetDescriptor(18) ...to: Reset [xhci address-device BSR = 1] GetDescriptor(64) Reset SetAddress [xhci address-device BSR = 0] GetDescriptor(18) ...as some devices misbehave when encountering a SetAddress command prior to GetDescriptor. There are known legacy devices that require this scheme, but testing has found at least one USB3 device that fails enumeration when presented with this ordering. For now, follow the ehci case and enable 'new scheme' by default for non-SuperSpeed devices. To support this enumeration scheme on xhci the AddressDevice operation needs to be performed twice. The first instance of the command enables the HC's device and slot context info for the device, but omits sending the device a SetAddress command (BSR == block set address request). Then, after GetDescriptor completes, follow up with the full AddressDevice+SetAddress operation. As mentioned before, this ordering of events with USB3 devices causes an extra state transition to be exposed to xhci. Previously USB3 devices would transition directly from 'enabled' to 'addressed' and never need to underrun responses to 'get descriptor'. We do see the 64-byte descriptor fetch the correct data, but the following 18-byte descriptor read after the reset gets: bLength = 0 bDescriptorType = 0 bcdUSB = 0 bDeviceClass = 0 bDeviceSubClass = 0 bDeviceProtocol = 0 bMaxPacketSize0 = 9 instead of: bLength = 12 bDescriptorType = 1 bcdUSB = 300 bDeviceClass = 0 bDeviceSubClass = 0 bDeviceProtocol = 0 bMaxPacketSize0 = 9 which results in the discovery process looping until falling back to 'old scheme' enumeration. Acked-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: David Moore <david.moore@gmail.com> Suggested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-12-05 17:07:27 -08:00
USB: core: Unite old scheme and new scheme descriptor reads In preparation for reworking the usb_get_device_descriptor() routine, it is desirable to unite the two different code paths responsible for initially determining endpoint 0's maximum packet size in a newly discovered USB device. Making this determination presents a chicken-and-egg sort of problem, in that the only way to learn the maxpacket value is to get it from the device descriptor retrieved from the device, but communicating with the device to retrieve a descriptor requires us to know beforehand the ep0 maxpacket size. In practice this problem is solved in two different ways, referred to in hub.c as the "old scheme" and the "new scheme". The old scheme (which is the approach recommended by the USB-2 spec) involves asking the device to send just the first eight bytes of its device descriptor. Such a transfer uses packets containing no more than eight bytes each, and every USB device must have an ep0 maxpacket size >= 8, so this should succeed. Since the bMaxPacketSize0 field of the device descriptor lies within the first eight bytes, this is all we need. The new scheme is an imitation of the technique used in an early Windows USB implementation, giving it the happy advantage of working with a wide variety of devices (some of them at the time would not work with the old scheme, although that's probably less true now). It involves making an initial guess of the ep0 maxpacket size, asking the device to send up to 64 bytes worth of its device descriptor (which is only 18 bytes long), and then resetting the device to clear any error condition that might have resulted from the guess being wrong. The initial guess is determined by the connection speed; it should be correct in all cases other than full speed, for which the allowed values are 8, 16, 32, and 64 (in this case the initial guess is 64). The reason for this patch is that the old- and new-scheme parts of hub_port_init() use different code paths, one involving usb_get_device_descriptor() and one not, for their initial reads of the device descriptor. Since these reads have essentially the same purpose and are made under essentially the same circumstances, this is illogical. It makes more sense to have both of them use a common subroutine. This subroutine does basically what the new scheme's code did, because that approach is more general than the one used by the old scheme. It only needs to know how many bytes to transfer and whether or not it is being called for the first iteration of a retry loop (in case of certain time-out errors). There are two main differences from the former code: We initialize the bDescriptorType field of the transfer buffer to 0 before performing the transfer, to avoid possibly accessing an uninitialized value afterward. We read the device descriptor into a temporary buffer rather than storing it directly into udev->descriptor, which the old scheme implementation used to do. Since the whole point of this first read of the device descriptor is to determine the bMaxPacketSize0 value, that is what the new routine returns (or an error code). The value is stored in a local variable rather than in udev->descriptor. As a side effect, this necessitates moving a section of code that checks the bcdUSB field for SuperSpeed devices until after the full device descriptor has been retrieved. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/495cb5d4-f956-4f4a-a875-1e67e9489510@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:10:59 -04:00
USB: core: Fix race by not overwriting udev->descriptor in hub_port_init() Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors(): BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011 CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351 print_report mm/kasan/report.c:462 [inline] kasan_report+0x11c/0x130 mm/kasan/report.c:572 read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 ... Allocated by task 758: ... __do_kmalloc_node mm/slab_common.c:966 [inline] __kmalloc+0x5e/0x190 mm/slab_common.c:979 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:680 [inline] usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887 usb_enumerate_device drivers/usb/core/hub.c:2407 [inline] usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545 As analyzed by Khazhy Kumykov, the cause of this bug is a race between read_descriptors() and hub_port_init(): The first routine uses a field in udev->descriptor, not expecting it to change, while the second overwrites it. Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") this race couldn't occur, because the routines were mutually exclusive thanks to the device locking. Removing that locking from read_descriptors() exposed it to the race. The best way to fix the bug is to keep hub_port_init() from changing udev->descriptor once udev has been initialized and registered. Drivers expect the descriptors stored in the kernel to be immutable; we should not undermine this expectation. In fact, this change should have been made long ago. So now hub_port_init() will take an additional argument, specifying a buffer in which to store the device descriptor it reads. (If udev has not yet been initialized, the buffer pointer will be NULL and then hub_port_init() will store the device descriptor in udev as before.) This eliminates the data race responsible for the out-of-bounds read. The changes to hub_port_init() appear more extensive than they really are, because of indentation changes resulting from an attempt to avoid writing to other parts of the usb_device structure after it has been initialized. Similar changes should be made to the code that reads the BOS descriptor, but that can be handled in a separate patch later on. This patch is sufficient to fix the bug found by syzbot. Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Khazhy Kumykov <khazhy@google.com> Fixes: 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:14:14 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usbcore: refine warm reset logic Current waiting time for warm(BH) reset in hub_port_warm_reset() is too short for xHC host to complete the warm reset and report a BH reset change. This patch increases the waiting time for warm reset and merges the function into hub_port_reset(), so it can handle both cold reset and warm reset, and factor out hub_port_finish_reset() to make the code looks cleaner. This fixes the issue that driver fails to clear BH reset change and port is "dead". Signed-off-by: Andiry Xu <andiry.xu@amd.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-13 16:41:11 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: core: Unite old scheme and new scheme descriptor reads In preparation for reworking the usb_get_device_descriptor() routine, it is desirable to unite the two different code paths responsible for initially determining endpoint 0's maximum packet size in a newly discovered USB device. Making this determination presents a chicken-and-egg sort of problem, in that the only way to learn the maxpacket value is to get it from the device descriptor retrieved from the device, but communicating with the device to retrieve a descriptor requires us to know beforehand the ep0 maxpacket size. In practice this problem is solved in two different ways, referred to in hub.c as the "old scheme" and the "new scheme". The old scheme (which is the approach recommended by the USB-2 spec) involves asking the device to send just the first eight bytes of its device descriptor. Such a transfer uses packets containing no more than eight bytes each, and every USB device must have an ep0 maxpacket size >= 8, so this should succeed. Since the bMaxPacketSize0 field of the device descriptor lies within the first eight bytes, this is all we need. The new scheme is an imitation of the technique used in an early Windows USB implementation, giving it the happy advantage of working with a wide variety of devices (some of them at the time would not work with the old scheme, although that's probably less true now). It involves making an initial guess of the ep0 maxpacket size, asking the device to send up to 64 bytes worth of its device descriptor (which is only 18 bytes long), and then resetting the device to clear any error condition that might have resulted from the guess being wrong. The initial guess is determined by the connection speed; it should be correct in all cases other than full speed, for which the allowed values are 8, 16, 32, and 64 (in this case the initial guess is 64). The reason for this patch is that the old- and new-scheme parts of hub_port_init() use different code paths, one involving usb_get_device_descriptor() and one not, for their initial reads of the device descriptor. Since these reads have essentially the same purpose and are made under essentially the same circumstances, this is illogical. It makes more sense to have both of them use a common subroutine. This subroutine does basically what the new scheme's code did, because that approach is more general than the one used by the old scheme. It only needs to know how many bytes to transfer and whether or not it is being called for the first iteration of a retry loop (in case of certain time-out errors). There are two main differences from the former code: We initialize the bDescriptorType field of the transfer buffer to 0 before performing the transfer, to avoid possibly accessing an uninitialized value afterward. We read the device descriptor into a temporary buffer rather than storing it directly into udev->descriptor, which the old scheme implementation used to do. Since the whole point of this first read of the device descriptor is to determine the bMaxPacketSize0 value, that is what the new routine returns (or an error code). The value is stored in a local variable rather than in udev->descriptor. As a side effect, this necessitates moving a section of code that checks the bcdUSB field for SuperSpeed devices until after the full device descriptor has been retrieved. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/495cb5d4-f956-4f4a-a875-1e67e9489510@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:10:59 -04:00
USB: avoid error messages when a device is disconnected This patch (as1673) reduces the amount of log spew from the hub driver by removing a bunch of error messages in the case where the device in question is already known to have been disconnected. Since the disconnect event itself appears in the log, there's no need for other error messages. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Jenya Y <jy.gerstmaier@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-27 16:14:01 -04:00
USB: core: Unite old scheme and new scheme descriptor reads In preparation for reworking the usb_get_device_descriptor() routine, it is desirable to unite the two different code paths responsible for initially determining endpoint 0's maximum packet size in a newly discovered USB device. Making this determination presents a chicken-and-egg sort of problem, in that the only way to learn the maxpacket value is to get it from the device descriptor retrieved from the device, but communicating with the device to retrieve a descriptor requires us to know beforehand the ep0 maxpacket size. In practice this problem is solved in two different ways, referred to in hub.c as the "old scheme" and the "new scheme". The old scheme (which is the approach recommended by the USB-2 spec) involves asking the device to send just the first eight bytes of its device descriptor. Such a transfer uses packets containing no more than eight bytes each, and every USB device must have an ep0 maxpacket size >= 8, so this should succeed. Since the bMaxPacketSize0 field of the device descriptor lies within the first eight bytes, this is all we need. The new scheme is an imitation of the technique used in an early Windows USB implementation, giving it the happy advantage of working with a wide variety of devices (some of them at the time would not work with the old scheme, although that's probably less true now). It involves making an initial guess of the ep0 maxpacket size, asking the device to send up to 64 bytes worth of its device descriptor (which is only 18 bytes long), and then resetting the device to clear any error condition that might have resulted from the guess being wrong. The initial guess is determined by the connection speed; it should be correct in all cases other than full speed, for which the allowed values are 8, 16, 32, and 64 (in this case the initial guess is 64). The reason for this patch is that the old- and new-scheme parts of hub_port_init() use different code paths, one involving usb_get_device_descriptor() and one not, for their initial reads of the device descriptor. Since these reads have essentially the same purpose and are made under essentially the same circumstances, this is illogical. It makes more sense to have both of them use a common subroutine. This subroutine does basically what the new scheme's code did, because that approach is more general than the one used by the old scheme. It only needs to know how many bytes to transfer and whether or not it is being called for the first iteration of a retry loop (in case of certain time-out errors). There are two main differences from the former code: We initialize the bDescriptorType field of the transfer buffer to 0 before performing the transfer, to avoid possibly accessing an uninitialized value afterward. We read the device descriptor into a temporary buffer rather than storing it directly into udev->descriptor, which the old scheme implementation used to do. Since the whole point of this first read of the device descriptor is to determine the bMaxPacketSize0 value, that is what the new routine returns (or an error code). The value is stored in a local variable rather than in udev->descriptor. As a side effect, this necessitates moving a section of code that checks the bcdUSB field for SuperSpeed devices until after the full device descriptor has been retrieved. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/495cb5d4-f956-4f4a-a875-1e67e9489510@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:10:59 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: Remove remnants of Wireless USB and UWB Wireless USB has long been defunct, and kernel support for it was removed in 2020 by commit caa6772db4c1 ("Staging: remove wusbcore and UWB from the kernel tree."). Nevertheless, some vestiges of the old implementation still clutter up the USB subsystem and one or two other places. Let's get rid of them once and for all. The only parts still left are the user-facing APIs in include/uapi/linux/usb/ch9.h. (There are also a couple of misleading instances, such as the Sierra Wireless USB modem, which is a USB modem made by Sierra Wireless.) Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/b4f2710f-a2de-4fb0-b50f-76776f3a961b@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-08 20:44:18 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: Remove remnants of Wireless USB and UWB Wireless USB has long been defunct, and kernel support for it was removed in 2020 by commit caa6772db4c1 ("Staging: remove wusbcore and UWB from the kernel tree."). Nevertheless, some vestiges of the old implementation still clutter up the USB subsystem and one or two other places. Let's get rid of them once and for all. The only parts still left are the user-facing APIs in include/uapi/linux/usb/ch9.h. (There are also a couple of misleading instances, such as the Sierra Wireless USB modem, which is a USB modem made by Sierra Wireless.) Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/b4f2710f-a2de-4fb0-b50f-76776f3a961b@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-08 20:44:18 -04:00
drivers: usb: core: {file,hub,sysfs,usb}.c: Whitespace fixes including: - removing of trailing whitespace - removing spaces before array indexing (foo [] to foo[]) - reindention of a switch-case block - spaces to tabs Signed-off-by: Matthias Beyer <mail@beyermatthias.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-10 23:41:27 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: Remove remnants of Wireless USB and UWB Wireless USB has long been defunct, and kernel support for it was removed in 2020 by commit caa6772db4c1 ("Staging: remove wusbcore and UWB from the kernel tree."). Nevertheless, some vestiges of the old implementation still clutter up the USB subsystem and one or two other places. Let's get rid of them once and for all. The only parts still left are the user-facing APIs in include/uapi/linux/usb/ch9.h. (There are also a couple of misleading instances, such as the Sierra Wireless USB modem, which is a USB modem made by Sierra Wireless.) Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/b4f2710f-a2de-4fb0-b50f-76776f3a961b@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-08 20:44:18 -04:00
USB: core: Unite old scheme and new scheme descriptor reads In preparation for reworking the usb_get_device_descriptor() routine, it is desirable to unite the two different code paths responsible for initially determining endpoint 0's maximum packet size in a newly discovered USB device. Making this determination presents a chicken-and-egg sort of problem, in that the only way to learn the maxpacket value is to get it from the device descriptor retrieved from the device, but communicating with the device to retrieve a descriptor requires us to know beforehand the ep0 maxpacket size. In practice this problem is solved in two different ways, referred to in hub.c as the "old scheme" and the "new scheme". The old scheme (which is the approach recommended by the USB-2 spec) involves asking the device to send just the first eight bytes of its device descriptor. Such a transfer uses packets containing no more than eight bytes each, and every USB device must have an ep0 maxpacket size >= 8, so this should succeed. Since the bMaxPacketSize0 field of the device descriptor lies within the first eight bytes, this is all we need. The new scheme is an imitation of the technique used in an early Windows USB implementation, giving it the happy advantage of working with a wide variety of devices (some of them at the time would not work with the old scheme, although that's probably less true now). It involves making an initial guess of the ep0 maxpacket size, asking the device to send up to 64 bytes worth of its device descriptor (which is only 18 bytes long), and then resetting the device to clear any error condition that might have resulted from the guess being wrong. The initial guess is determined by the connection speed; it should be correct in all cases other than full speed, for which the allowed values are 8, 16, 32, and 64 (in this case the initial guess is 64). The reason for this patch is that the old- and new-scheme parts of hub_port_init() use different code paths, one involving usb_get_device_descriptor() and one not, for their initial reads of the device descriptor. Since these reads have essentially the same purpose and are made under essentially the same circumstances, this is illogical. It makes more sense to have both of them use a common subroutine. This subroutine does basically what the new scheme's code did, because that approach is more general than the one used by the old scheme. It only needs to know how many bytes to transfer and whether or not it is being called for the first iteration of a retry loop (in case of certain time-out errors). There are two main differences from the former code: We initialize the bDescriptorType field of the transfer buffer to 0 before performing the transfer, to avoid possibly accessing an uninitialized value afterward. We read the device descriptor into a temporary buffer rather than storing it directly into udev->descriptor, which the old scheme implementation used to do. Since the whole point of this first read of the device descriptor is to determine the bMaxPacketSize0 value, that is what the new routine returns (or an error code). The value is stored in a local variable rather than in udev->descriptor. As a side effect, this necessitates moving a section of code that checks the bcdUSB field for SuperSpeed devices until after the full device descriptor has been retrieved. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/495cb5d4-f956-4f4a-a875-1e67e9489510@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:10:59 -04:00
USB: avoid error messages when a device is disconnected This patch (as1673) reduces the amount of log spew from the hub driver by removing a bunch of error messages in the case where the device in question is already known to have been disconnected. Since the disconnect event itself appears in the log, there's no need for other error messages. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Jenya Y <jy.gerstmaier@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-27 16:14:01 -04:00
USB: make printk messages more searchable USB: make printk messages more searchable Make USB printk messages long and straightforward. One of these decorated USB error messages cost me non-trivial efforts to locate. Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-15 15:32:01 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: add support for USB_REQ_SET_ISOCH_DELAY USB SS and SSP hubs provide wHubDelay values on their hub descriptor which we should inform the USB Device about. The USB Specification 3.0 explains, on section 9.4.11, how to calculate the value and how to issue the request. Note that a USB_REQ_SET_ISOCH_DELAY is valid on all device states (Default, Address, Configured), we just *chose* to issue it from Address state right after successfully fetching the USB Device Descriptor. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-14 09:50:39 +02:00
USB: core: Fix race by not overwriting udev->descriptor in hub_port_init() Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors(): BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011 CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351 print_report mm/kasan/report.c:462 [inline] kasan_report+0x11c/0x130 mm/kasan/report.c:572 read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 ... Allocated by task 758: ... __do_kmalloc_node mm/slab_common.c:966 [inline] __kmalloc+0x5e/0x190 mm/slab_common.c:979 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:680 [inline] usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887 usb_enumerate_device drivers/usb/core/hub.c:2407 [inline] usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545 As analyzed by Khazhy Kumykov, the cause of this bug is a race between read_descriptors() and hub_port_init(): The first routine uses a field in udev->descriptor, not expecting it to change, while the second overwrites it. Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") this race couldn't occur, because the routines were mutually exclusive thanks to the device locking. Removing that locking from read_descriptors() exposed it to the race. The best way to fix the bug is to keep hub_port_init() from changing udev->descriptor once udev has been initialized and registered. Drivers expect the descriptors stored in the kernel to be immutable; we should not undermine this expectation. In fact, this change should have been made long ago. So now hub_port_init() will take an additional argument, specifying a buffer in which to store the device descriptor it reads. (If udev has not yet been initialized, the buffer pointer will be NULL and then hub_port_init() will store the device descriptor in udev as before.) This eliminates the data race responsible for the out-of-bounds read. The changes to hub_port_init() appear more extensive than they really are, because of indentation changes resulting from an attempt to avoid writing to other parts of the usb_device structure after it has been initialized. Similar changes should be made to the code that reads the BOS descriptor, but that can be handled in a separate patch later on. This patch is sufficient to fix the bug found by syzbot. Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Khazhy Kumykov <khazhy@google.com> Fixes: 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:14:14 -04:00
usb: core: add support for USB_REQ_SET_ISOCH_DELAY USB SS and SSP hubs provide wHubDelay values on their hub descriptor which we should inform the USB Device about. The USB Specification 3.0 explains, on section 9.4.11, how to calculate the value and how to issue the request. Note that a USB_REQ_SET_ISOCH_DELAY is valid on all device states (Default, Address, Configured), we just *chose* to issue it from Address state right after successfully fetching the USB Device Descriptor. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-14 09:50:39 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: core: Fix oversight in SuperSpeed initialization Commit 85d07c556216 ("USB: core: Unite old scheme and new scheme descriptor reads") altered the way USB devices are enumerated following detection, and in the process it messed up the initialization of SuperSpeed (or faster) devices: [ 31.650759] usb 2-1: new SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd [ 31.663107] usb 2-1: device descriptor read/8, error -71 [ 31.952697] usb 2-1: new SuperSpeed Plus Gen 2x1 USB device number 3 using xhci_hcd [ 31.965122] usb 2-1: device descriptor read/8, error -71 [ 32.080991] usb usb2-port1: attempt power cycle ... The problem was caused by the commit forgetting that in SuperSpeed or faster devices, the device descriptor uses a logarithmic encoding of the bMaxPacketSize0 value. (For some reason I thought the 255 case in the switch statement was meant for these devices, but it isn't -- it was meant for Wireless USB and is no longer needed.) We can fix the oversight by testing for buf->bMaxPacketSize0 = 9 (meaning 512, the actual maxpacket size for ep0 on all SuperSpeed devices) and straightening out the logic that checks and adjusts our initial guesses of the maxpacket value. Reported-and-tested-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Closes: https://lore.kernel.org/linux-usb/20230810002257.nadxmfmrobkaxgnz@synopsys.com/ Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Fixes: 85d07c556216 ("USB: core: Unite old scheme and new scheme descriptor reads") Link: https://lore.kernel.org/r/8809e6c5-59d5-4d2d-ac8f-6d106658ad73@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-11 13:38:46 -04:00
usb: Fix regression caused by invalid ep0 maxpacket in virtual SuperSpeed device A virtual SuperSpeed device in the FreeBSD BVCP package (https://bhyve.npulse.net/) presents an invalid ep0 maxpacket size of 256. It stopped working with Linux following a recent commit because now we check these sizes more carefully than before. Fix this regression by using the bMaxpacketSize0 value in the device descriptor for SuperSpeed or faster devices, even if it is invalid. This is a very simple-minded change; we might want to check more carefully for values that actually make some sense (for instance, no smaller than 64). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Roger Whittaker <roger.whittaker@suse.com> Closes: https://bugzilla.suse.com/show_bug.cgi?id=1220569 Link: https://lore.kernel.org/linux-usb/9efbd569-7059-4575-983f-0ea30df41871@suse.com/ Fixes: 59cf44575456 ("USB: core: Fix oversight in SuperSpeed initialization") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/4058ac05-237c-4db4-9ecc-5af42bdb4501@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-30 10:33:48 -04:00
USB: core: Fix oversight in SuperSpeed initialization Commit 85d07c556216 ("USB: core: Unite old scheme and new scheme descriptor reads") altered the way USB devices are enumerated following detection, and in the process it messed up the initialization of SuperSpeed (or faster) devices: [ 31.650759] usb 2-1: new SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd [ 31.663107] usb 2-1: device descriptor read/8, error -71 [ 31.952697] usb 2-1: new SuperSpeed Plus Gen 2x1 USB device number 3 using xhci_hcd [ 31.965122] usb 2-1: device descriptor read/8, error -71 [ 32.080991] usb usb2-port1: attempt power cycle ... The problem was caused by the commit forgetting that in SuperSpeed or faster devices, the device descriptor uses a logarithmic encoding of the bMaxPacketSize0 value. (For some reason I thought the 255 case in the switch statement was meant for these devices, but it isn't -- it was meant for Wireless USB and is no longer needed.) We can fix the oversight by testing for buf->bMaxPacketSize0 = 9 (meaning 512, the actual maxpacket size for ep0 on all SuperSpeed devices) and straightening out the logic that checks and adjusts our initial guesses of the maxpacket value. Reported-and-tested-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Closes: https://lore.kernel.org/linux-usb/20230810002257.nadxmfmrobkaxgnz@synopsys.com/ Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Fixes: 85d07c556216 ("USB: core: Unite old scheme and new scheme descriptor reads") Link: https://lore.kernel.org/r/8809e6c5-59d5-4d2d-ac8f-6d106658ad73@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-11 13:38:46 -04:00
usb: Fix regression caused by invalid ep0 maxpacket in virtual SuperSpeed device A virtual SuperSpeed device in the FreeBSD BVCP package (https://bhyve.npulse.net/) presents an invalid ep0 maxpacket size of 256. It stopped working with Linux following a recent commit because now we check these sizes more carefully than before. Fix this regression by using the bMaxpacketSize0 value in the device descriptor for SuperSpeed or faster devices, even if it is invalid. This is a very simple-minded change; we might want to check more carefully for values that actually make some sense (for instance, no smaller than 64). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Roger Whittaker <roger.whittaker@suse.com> Closes: https://bugzilla.suse.com/show_bug.cgi?id=1220569 Link: https://lore.kernel.org/linux-usb/9efbd569-7059-4575-983f-0ea30df41871@suse.com/ Fixes: 59cf44575456 ("USB: core: Fix oversight in SuperSpeed initialization") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/4058ac05-237c-4db4-9ecc-5af42bdb4501@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-30 10:33:48 -04:00
USB: core: Fix oversight in SuperSpeed initialization Commit 85d07c556216 ("USB: core: Unite old scheme and new scheme descriptor reads") altered the way USB devices are enumerated following detection, and in the process it messed up the initialization of SuperSpeed (or faster) devices: [ 31.650759] usb 2-1: new SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd [ 31.663107] usb 2-1: device descriptor read/8, error -71 [ 31.952697] usb 2-1: new SuperSpeed Plus Gen 2x1 USB device number 3 using xhci_hcd [ 31.965122] usb 2-1: device descriptor read/8, error -71 [ 32.080991] usb usb2-port1: attempt power cycle ... The problem was caused by the commit forgetting that in SuperSpeed or faster devices, the device descriptor uses a logarithmic encoding of the bMaxPacketSize0 value. (For some reason I thought the 255 case in the switch statement was meant for these devices, but it isn't -- it was meant for Wireless USB and is no longer needed.) We can fix the oversight by testing for buf->bMaxPacketSize0 = 9 (meaning 512, the actual maxpacket size for ep0 on all SuperSpeed devices) and straightening out the logic that checks and adjusts our initial guesses of the maxpacket value. Reported-and-tested-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Closes: https://lore.kernel.org/linux-usb/20230810002257.nadxmfmrobkaxgnz@synopsys.com/ Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Fixes: 85d07c556216 ("USB: core: Unite old scheme and new scheme descriptor reads") Link: https://lore.kernel.org/r/8809e6c5-59d5-4d2d-ac8f-6d106658ad73@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-11 13:38:46 -04:00
USB: accept some invalid ep0-maxpacket values A few devices (such as the RCA VR5220 voice recorder) are so non-compliant with the USB spec that they have invalid maxpacket sizes for endpoint 0. Nevertheless, as long as we can safely use them, we may as well do so. This patch (as1432) softens our acceptance criterion by allowing high-speed devices to have ep0-maxpacket sizes other than 64. A warning is printed in the system log when this happens, and the existing error message is clarified. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: James <bjlockie@lockie.ca> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-10-14 15:25:21 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
wusb: make ep0_reinit available for modules We need to be able to call ep0_reinit() [renamed to usb_ep0_reinit()] from the WUSB security code. The reason is that when we authenticate the device, it's address changes (from having bit 7 set to having it cleared). Thus, we need to signal the USB stack to reinitialize EP0, so the status with the previous address kept at the HCD layer is cleared and properly reinitialized. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-08 13:24:46 -07:00
USB: core: Fix oversight in SuperSpeed initialization Commit 85d07c556216 ("USB: core: Unite old scheme and new scheme descriptor reads") altered the way USB devices are enumerated following detection, and in the process it messed up the initialization of SuperSpeed (or faster) devices: [ 31.650759] usb 2-1: new SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd [ 31.663107] usb 2-1: device descriptor read/8, error -71 [ 31.952697] usb 2-1: new SuperSpeed Plus Gen 2x1 USB device number 3 using xhci_hcd [ 31.965122] usb 2-1: device descriptor read/8, error -71 [ 32.080991] usb usb2-port1: attempt power cycle ... The problem was caused by the commit forgetting that in SuperSpeed or faster devices, the device descriptor uses a logarithmic encoding of the bMaxPacketSize0 value. (For some reason I thought the 255 case in the switch statement was meant for these devices, but it isn't -- it was meant for Wireless USB and is no longer needed.) We can fix the oversight by testing for buf->bMaxPacketSize0 = 9 (meaning 512, the actual maxpacket size for ep0 on all SuperSpeed devices) and straightening out the logic that checks and adjusts our initial guesses of the maxpacket value. Reported-and-tested-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Closes: https://lore.kernel.org/linux-usb/20230810002257.nadxmfmrobkaxgnz@synopsys.com/ Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Fixes: 85d07c556216 ("USB: core: Unite old scheme and new scheme descriptor reads") Link: https://lore.kernel.org/r/8809e6c5-59d5-4d2d-ac8f-6d106658ad73@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-11 13:38:46 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
drivers: usb: core: {file,hub,sysfs,usb}.c: Whitespace fixes including: - removing of trailing whitespace - removing spaces before array indexing (foo [] to foo[]) - reindention of a switch-case block - spaces to tabs Signed-off-by: Matthias Beyer <mail@beyermatthias.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-10 23:41:27 +02:00
USB: core: Change usb_get_device_descriptor() API The usb_get_device_descriptor() routine reads the device descriptor from the udev device and stores it directly in udev->descriptor. This interface is error prone, because the USB subsystem expects in-memory copies of a device's descriptors to be immutable once the device has been initialized. The interface is changed so that the device descriptor is left in a kmalloc-ed buffer, not copied into the usb_device structure. A pointer to the buffer is returned to the caller, who is then responsible for kfree-ing it. The corresponding changes needed in the various callers are fairly small. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/d0111bb6-56c1-4f90-adf2-6cfe152f6561@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:12:21 -04:00
USB: avoid error messages when a device is disconnected This patch (as1673) reduces the amount of log spew from the hub driver by removing a bunch of error messages in the case where the device in question is already known to have been disconnected. Since the disconnect event itself appears in the log, there's no need for other error messages. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Jenya Y <jy.gerstmaier@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-27 16:14:01 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: core: Fix race by not overwriting udev->descriptor in hub_port_init() Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors(): BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011 CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351 print_report mm/kasan/report.c:462 [inline] kasan_report+0x11c/0x130 mm/kasan/report.c:572 read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 ... Allocated by task 758: ... __do_kmalloc_node mm/slab_common.c:966 [inline] __kmalloc+0x5e/0x190 mm/slab_common.c:979 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:680 [inline] usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887 usb_enumerate_device drivers/usb/core/hub.c:2407 [inline] usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545 As analyzed by Khazhy Kumykov, the cause of this bug is a race between read_descriptors() and hub_port_init(): The first routine uses a field in udev->descriptor, not expecting it to change, while the second overwrites it. Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") this race couldn't occur, because the routines were mutually exclusive thanks to the device locking. Removing that locking from read_descriptors() exposed it to the race. The best way to fix the bug is to keep hub_port_init() from changing udev->descriptor once udev has been initialized and registered. Drivers expect the descriptors stored in the kernel to be immutable; we should not undermine this expectation. In fact, this change should have been made long ago. So now hub_port_init() will take an additional argument, specifying a buffer in which to store the device descriptor it reads. (If udev has not yet been initialized, the buffer pointer will be NULL and then hub_port_init() will store the device descriptor in udev as before.) This eliminates the data race responsible for the out-of-bounds read. The changes to hub_port_init() appear more extensive than they really are, because of indentation changes resulting from an attempt to avoid writing to other parts of the usb_device structure after it has been initialized. Similar changes should be made to the code that reads the BOS descriptor, but that can be handled in a separate patch later on. This patch is sufficient to fix the bug found by syzbot. Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Khazhy Kumykov <khazhy@google.com> Fixes: 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:14:14 -04:00
USB: core: Change usb_get_device_descriptor() API The usb_get_device_descriptor() routine reads the device descriptor from the udev device and stores it directly in udev->descriptor. This interface is error prone, because the USB subsystem expects in-memory copies of a device's descriptors to be immutable once the device has been initialized. The interface is changed so that the device descriptor is left in a kmalloc-ed buffer, not copied into the usb_device structure. A pointer to the buffer is returned to the caller, who is then responsible for kfree-ing it. The corresponding changes needed in the various callers are fairly small. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/d0111bb6-56c1-4f90-adf2-6cfe152f6561@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:12:21 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: core: Unite old scheme and new scheme descriptor reads In preparation for reworking the usb_get_device_descriptor() routine, it is desirable to unite the two different code paths responsible for initially determining endpoint 0's maximum packet size in a newly discovered USB device. Making this determination presents a chicken-and-egg sort of problem, in that the only way to learn the maxpacket value is to get it from the device descriptor retrieved from the device, but communicating with the device to retrieve a descriptor requires us to know beforehand the ep0 maxpacket size. In practice this problem is solved in two different ways, referred to in hub.c as the "old scheme" and the "new scheme". The old scheme (which is the approach recommended by the USB-2 spec) involves asking the device to send just the first eight bytes of its device descriptor. Such a transfer uses packets containing no more than eight bytes each, and every USB device must have an ep0 maxpacket size >= 8, so this should succeed. Since the bMaxPacketSize0 field of the device descriptor lies within the first eight bytes, this is all we need. The new scheme is an imitation of the technique used in an early Windows USB implementation, giving it the happy advantage of working with a wide variety of devices (some of them at the time would not work with the old scheme, although that's probably less true now). It involves making an initial guess of the ep0 maxpacket size, asking the device to send up to 64 bytes worth of its device descriptor (which is only 18 bytes long), and then resetting the device to clear any error condition that might have resulted from the guess being wrong. The initial guess is determined by the connection speed; it should be correct in all cases other than full speed, for which the allowed values are 8, 16, 32, and 64 (in this case the initial guess is 64). The reason for this patch is that the old- and new-scheme parts of hub_port_init() use different code paths, one involving usb_get_device_descriptor() and one not, for their initial reads of the device descriptor. Since these reads have essentially the same purpose and are made under essentially the same circumstances, this is illogical. It makes more sense to have both of them use a common subroutine. This subroutine does basically what the new scheme's code did, because that approach is more general than the one used by the old scheme. It only needs to know how many bytes to transfer and whether or not it is being called for the first iteration of a retry loop (in case of certain time-out errors). There are two main differences from the former code: We initialize the bDescriptorType field of the transfer buffer to 0 before performing the transfer, to avoid possibly accessing an uninitialized value afterward. We read the device descriptor into a temporary buffer rather than storing it directly into udev->descriptor, which the old scheme implementation used to do. Since the whole point of this first read of the device descriptor is to determine the bMaxPacketSize0 value, that is what the new routine returns (or an error code). The value is stored in a local variable rather than in udev->descriptor. As a side effect, this necessitates moving a section of code that checks the bcdUSB field for SuperSpeed devices until after the full device descriptor has been retrieved. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/495cb5d4-f956-4f4a-a875-1e67e9489510@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:10:59 -04:00
USB: add quirk for devices with broken LPM Some USB device / host controller combinations seem to have problems with Link Power Management. For example, Steinar found that his xHCI controller wouldn't handle bandwidth calculations correctly for two video cards simultaneously when LPM was enabled, even though the bus had plenty of bandwidth available. This patch introduces a new quirk flag for devices that should remain disabled for LPM, and creates quirk entries for Steinar's devices. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Steinar H. Gunderson <sgunderson@bigfoot.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-10 15:27:21 -05:00
USB: Remove remnants of Wireless USB and UWB Wireless USB has long been defunct, and kernel support for it was removed in 2020 by commit caa6772db4c1 ("Staging: remove wusbcore and UWB from the kernel tree."). Nevertheless, some vestiges of the old implementation still clutter up the USB subsystem and one or two other places. Let's get rid of them once and for all. The only parts still left are the user-facing APIs in include/uapi/linux/usb/ch9.h. (There are also a couple of misleading instances, such as the Sierra Wireless USB modem, which is a USB modem made by Sierra Wireless.) Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/b4f2710f-a2de-4fb0-b50f-76776f3a961b@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-08 20:44:18 -04:00
usbcore: check device's LPM capability Check device's LPM capability by examining the bmAttibutes field of the USB2.0 Extension Descriptor. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-23 14:19:48 -07:00
USB: Calculate USB 3.0 exit latencies for LPM. 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-02-20 12:02:19 -08:00
USB: Refactor code to set LPM support flag. 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-02-20 08:31:26 -08:00
usb: remove Link Powermanagement (LPM) disable before port reset. Trying to disable Link Powermanagement (LPM) before port reset is unnecessary and can cause additional delay if host can't communicate with the device, which is often the reason why device is reset in the first place. usb_disable_lpm() will - zero usb U1/U2 timeouts for the hub downstream port - send ENABLE U1/U2 clear feature requests to the connected device. - increase internal reference count for udev->lpm_disable_count There is no need to zero U1/U2 hub port timeouts, or clearing the U1/U2 enable for the connected device before reset. These are set to default by the reset. USB 3.1 section 10.2.2 "HUB Downstream port U1/U2 timers" states that: "the U1 and U2 timeout values for a downstream port reset to the default values when the port receives a SetPortFeature request for a port reset" Set the udev->lpm_disable_count to "1" after port reset, which is the default lpm_disable_count value when allocating udev, representing disabled LPM. Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20220216095153.1303105-8-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-16 11:51:51 +02:00
USB: Calculate USB 3.0 exit latencies for LPM. 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-02-20 12:02:19 -08:00
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>
2022-05-06 19:18:07 +03:00
USB: Calculate USB 3.0 exit latencies for LPM. 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-02-20 12:02:19 -08:00
usbcore: check device's LPM capability Check device's LPM capability by examining the bmAttibutes field of the USB2.0 Extension Descriptor. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-23 14:19:48 -07:00
usbcore: get BOS descriptor set This commit gets BOS(Binary Device Object Store) descriptor set for Super Speed devices and High Speed devices which support BOS descriptor. BOS descriptor is used to report additional USB device-level capabilities that are not reported via the Device descriptor. By getting BOS descriptor set, driver can check device's device-level capability such as LPM capability. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-23 14:19:47 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: EHCI: EHCI 1.1 addendum: Basic LPM feature support With this patch, the LPM capable EHCI host controller can put device into L1 sleep state which is a mode that can enter/exit quickly, and reduce power consumption. Signed-off-by: Jacob Pan <jacob.jun.pan@intel.com> Signed-off-by: Alek Du <alek.du@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-06-04 15:47:55 +08:00
xhci: Enable LPM support only for hardwired or BESL devices Some usb3 devices falsely claim they support usb2 hardware Link PM when connected to a usb2 port. We only trust hardwired devices or devices with the later BESL LPM support to be LPM enabled as default. [Note: Sarah re-worked the original patch to move the code into the USB core, and updated it to check whether the USB device supports BESL, instead of checking if the xHCI port it's connected to supports BESL encoding.] This patch should be backported to kernels as old as 3.11, that contain the commit a558ccdcc71c7770c5e80c926a31cfe8a3892a09 "usb: xhci: add USB2 Link power management BESL support". Without this fix, some USB 3.0 devices will not enumerate or work properly under USB 2.0 ports on Haswell-ULT systems. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2013-09-30 17:26:31 +03:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: address-0 handling during device initialization This patch (as947) changes the device initialization and enumeration code in hub.c; now udev->devnum will be set to 0 while the device is being accessed at address 0. Until now this wasn't needed because the address value was passed as part of urb->pipe; without that field the device address must be stored elsewhere. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-30 17:08:43 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: use "device number" instead of "address" The USB stack historically has conflated device numbers (i.e., the value of udev->devnum) with device addresses. This is understandable, because until recently the two values were always the same. But with USB-3.0 they aren't the same, so we should start calling these things by their correct names. This patch (as1449b) changes many of the references to "address" in the hub driver to "device number" or "devnum". The patch also removes some unnecessary or misleading comments. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Luben Tuikov <ltuikov@yahoo.com> Reviewed-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-22 09:53:41 -05:00
USB: address-0 handling during device initialization This patch (as947) changes the device initialization and enumeration code in hub.c; now udev->devnum will be set to 0 while the device is being accessed at address 0. Until now this wasn't needed because the address value was passed as part of urb->pipe; without that field the device address must be stored elsewhere. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-30 17:08:43 -04:00
USB: core: Unite old scheme and new scheme descriptor reads In preparation for reworking the usb_get_device_descriptor() routine, it is desirable to unite the two different code paths responsible for initially determining endpoint 0's maximum packet size in a newly discovered USB device. Making this determination presents a chicken-and-egg sort of problem, in that the only way to learn the maxpacket value is to get it from the device descriptor retrieved from the device, but communicating with the device to retrieve a descriptor requires us to know beforehand the ep0 maxpacket size. In practice this problem is solved in two different ways, referred to in hub.c as the "old scheme" and the "new scheme". The old scheme (which is the approach recommended by the USB-2 spec) involves asking the device to send just the first eight bytes of its device descriptor. Such a transfer uses packets containing no more than eight bytes each, and every USB device must have an ep0 maxpacket size >= 8, so this should succeed. Since the bMaxPacketSize0 field of the device descriptor lies within the first eight bytes, this is all we need. The new scheme is an imitation of the technique used in an early Windows USB implementation, giving it the happy advantage of working with a wide variety of devices (some of them at the time would not work with the old scheme, although that's probably less true now). It involves making an initial guess of the ep0 maxpacket size, asking the device to send up to 64 bytes worth of its device descriptor (which is only 18 bytes long), and then resetting the device to clear any error condition that might have resulted from the guess being wrong. The initial guess is determined by the connection speed; it should be correct in all cases other than full speed, for which the allowed values are 8, 16, 32, and 64 (in this case the initial guess is 64). The reason for this patch is that the old- and new-scheme parts of hub_port_init() use different code paths, one involving usb_get_device_descriptor() and one not, for their initial reads of the device descriptor. Since these reads have essentially the same purpose and are made under essentially the same circumstances, this is illogical. It makes more sense to have both of them use a common subroutine. This subroutine does basically what the new scheme's code did, because that approach is more general than the one used by the old scheme. It only needs to know how many bytes to transfer and whether or not it is being called for the first iteration of a retry loop (in case of certain time-out errors). There are two main differences from the former code: We initialize the bDescriptorType field of the transfer buffer to 0 before performing the transfer, to avoid possibly accessing an uninitialized value afterward. We read the device descriptor into a temporary buffer rather than storing it directly into udev->descriptor, which the old scheme implementation used to do. Since the whole point of this first read of the device descriptor is to determine the bMaxPacketSize0 value, that is what the new routine returns (or an error code). The value is stored in a local variable rather than in udev->descriptor. As a side effect, this necessitates moving a section of code that checks the bcdUSB field for SuperSpeed devices until after the full device descriptor has been retrieved. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/495cb5d4-f956-4f4a-a875-1e67e9489510@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:10:59 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: hub: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-18 20:36:58 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: core: add device-qualifier quirk Add new quirk for devices that cannot handle requests for the device_qualifier descriptor. A USB-2.0 compliant device must respond to requests for the device_qualifier descriptor (even if it's with a request error), but at least one device is known to misbehave after such a request. Suggested-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-08-25 17:51:26 +02:00
usb: core: hub: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-18 20:36:58 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: hub: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-18 20:36:58 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: move hub init and LED blink work to power efficient workqueue Allow the scheduler to select the best CPU to handle hub initalization and LED blinking work. This extends idle residency times on idle CPUs and conserves power. This functionality is enabled when CONFIG_WQ_POWER_EFFICIENT is selected. [zoran.markovic@linaro.org: Rebased to latest kernel. Added commit message. Changed reference from system to power efficient workqueue for LEDs in check_highspeed() and hub_port_connect_change().] Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Xenia Ragiadakou <burzalodowa@gmail.com> Cc: Julius Werner <jwerner@chromium.org> Cc: Krzysztof Mazur <krzysiek@podlesie.net> Cc: Matthias Beyer <mail@beyermatthias.de> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Mathias Nyman <mathias.nyman@linux.intel.com> Cc: Thomas Pugliese <thomas.pugliese@gmail.com> Signed-off-by: Shaibal Dutta <shaibal.dutta@broadcom.com> Signed-off-by: Zoran Markovic <zoran.markovic@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-01 19:16:46 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] USB: kfree cleanup for drivers/usb/* - no need to check for NULL Get rid of a bunch of redundant NULL pointer checks in drivers/usb/*, there's no need to check a pointer for NULL before calling kfree() on it. Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Index: gregkh-2.6/drivers/usb/class/audio.c ===================================================================
2005-04-18 17:39:34 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: hub: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-18 20:36:58 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] USB: Consider power budget when choosing configuration This patch (as609) changes the way we keep track of power budgeting for USB hubs and devices, and it updates the choose_configuration routine to take this information into account. (This is something we should have been doing all along.) A new field in struct usb_device holds the amount of bus current available from the upstream port, and the usb_hub structure keeps track of the current available for each downstream port. Two new rules for configuration selection are added: Don't select a self-powered configuration when only bus power is available. Don't select a configuration requiring more bus power than is available. However the first rule is #if-ed out, because I found that the internal hub in my HP USB keyboard claims that its only configuration is self-powered. The rule would prevent the configuration from being chosen, leaving the hub & keyboard unconfigured. Since similar descriptor errors may turn out to be fairly common, it seemed wise not to include a rule that would break automatic configuration unnecessarily for such devices. The second rule may also trigger unnecessarily, although this should be less common. More likely it will annoy people by sometimes failing to accept configurations that should never have been chosen in the first place. The patch also changes usbcore's reaction when no configuration is suitable. Instead of raising an error and rejecting the device, now the core will simply leave the device unconfigured. People can always work around such problems by installing configurations manually through sysfs. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-23 12:03:12 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] USB: Consider power budget when choosing configuration This patch (as609) changes the way we keep track of power budgeting for USB hubs and devices, and it updates the choose_configuration routine to take this information into account. (This is something we should have been doing all along.) A new field in struct usb_device holds the amount of bus current available from the upstream port, and the usb_hub structure keeps track of the current available for each downstream port. Two new rules for configuration selection are added: Don't select a self-powered configuration when only bus power is available. Don't select a configuration requiring more bus power than is available. However the first rule is #if-ed out, because I found that the internal hub in my HP USB keyboard claims that its only configuration is self-powered. The rule would prevent the configuration from being chosen, leaving the hub & keyboard unconfigured. Since similar descriptor errors may turn out to be fairly common, it seemed wise not to include a rule that would break automatic configuration unnecessarily for such devices. The second rule may also trigger unnecessarily, although this should be less common. More likely it will annoy people by sometimes failing to accept configurations that should never have been chosen in the first place. The patch also changes usbcore's reaction when no configuration is suitable. Instead of raising an error and rejecting the device, now the core will simply leave the device unconfigured. People can always work around such problems by installing configurations manually through sysfs. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-23 12:03:12 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] USB: Consider power budget when choosing configuration This patch (as609) changes the way we keep track of power budgeting for USB hubs and devices, and it updates the choose_configuration routine to take this information into account. (This is something we should have been doing all along.) A new field in struct usb_device holds the amount of bus current available from the upstream port, and the usb_hub structure keeps track of the current available for each downstream port. Two new rules for configuration selection are added: Don't select a self-powered configuration when only bus power is available. Don't select a configuration requiring more bus power than is available. However the first rule is #if-ed out, because I found that the internal hub in my HP USB keyboard claims that its only configuration is self-powered. The rule would prevent the configuration from being chosen, leaving the hub & keyboard unconfigured. Since similar descriptor errors may turn out to be fairly common, it seemed wise not to include a rule that would break automatic configuration unnecessarily for such devices. The second rule may also trigger unnecessarily, although this should be less common. More likely it will annoy people by sometimes failing to accept configurations that should never have been chosen in the first place. The patch also changes usbcore's reaction when no configuration is suitable. Instead of raising an error and rejecting the device, now the core will simply leave the device unconfigured. People can always work around such problems by installing configurations manually through sysfs. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-23 12:03:12 -05:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb/core: update power budget for SuperSpeed Sarah pointed out that the USB3.0 spec also updates the amount of power that may be consumed by the device and quoted 9.2.5.1: |"The amount of current draw for SuperSpeed devices are increased to 150 |mA for low-power devices and 900 mA for high-power" This patch tries to update all users to use the larger values for SuperSpeed devices and use the "old" ones for everything else. While here, two other changes suggested by Alan: - the comment referering to 7.2.1.1 has been updated to 7.2.1 which is the correct source of the action. - the check for hubs with zero ports has been removed. - compute bus power by full_load * num_ports on root hubs Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-12-18 15:25:47 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb/core: update power budget for SuperSpeed Sarah pointed out that the USB3.0 spec also updates the amount of power that may be consumed by the device and quoted 9.2.5.1: |"The amount of current draw for SuperSpeed devices are increased to 150 |mA for low-power devices and 900 mA for high-power" This patch tries to update all users to use the larger values for SuperSpeed devices and use the "old" ones for everything else. While here, two other changes suggested by Alan: - the comment referering to 7.2.1.1 has been updated to 7.2.1 which is the correct source of the action. - the check for hubs with zero ports has been removed. - compute bus power by full_load * num_ports on root hubs Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-12-18 15:25:47 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb/core: consider link speed while looking at bMaxPower The USB 2.0 specification says that bMaxPower is the maximum power consumption expressed in 2 mA units and the USB 3.0 specification says that it is expressed in 8 mA units. This patch adds a helper function usb_get_max_power() which computes the value based on config & usb_device's speed value. The the device descriptor dump computes the value on its own. Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-12-18 15:25:46 +01:00
[PATCH] USB: Consider power budget when choosing configuration This patch (as609) changes the way we keep track of power budgeting for USB hubs and devices, and it updates the choose_configuration routine to take this information into account. (This is something we should have been doing all along.) A new field in struct usb_device holds the amount of bus current available from the upstream port, and the usb_hub structure keeps track of the current available for each downstream port. Two new rules for configuration selection are added: Don't select a self-powered configuration when only bus power is available. Don't select a configuration requiring more bus power than is available. However the first rule is #if-ed out, because I found that the internal hub in my HP USB keyboard claims that its only configuration is self-powered. The rule would prevent the configuration from being chosen, leaving the hub & keyboard unconfigured. Since similar descriptor errors may turn out to be fairly common, it seemed wise not to include a rule that would break automatic configuration unnecessarily for such devices. The second rule may also trigger unnecessarily, although this should be less common. More likely it will annoy people by sometimes failing to accept configurations that should never have been chosen in the first place. The patch also changes usbcore's reaction when no configuration is suitable. Instead of raising an error and rejecting the device, now the core will simply leave the device unconfigured. People can always work around such problems by installing configurations manually through sysfs. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-23 12:03:12 -05:00
usb/core: update power budget for SuperSpeed Sarah pointed out that the USB3.0 spec also updates the amount of power that may be consumed by the device and quoted 9.2.5.1: |"The amount of current draw for SuperSpeed devices are increased to 150 |mA for low-power devices and 900 mA for high-power" This patch tries to update all users to use the larger values for SuperSpeed devices and use the "old" ones for everything else. While here, two other changes suggested by Alan: - the comment referering to 7.2.1.1 has been updated to 7.2.1 which is the correct source of the action. - the check for hubs with zero ports has been removed. - compute bus power by full_load * num_ports on root hubs Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-12-18 15:25:47 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] USB: Consider power budget when choosing configuration This patch (as609) changes the way we keep track of power budgeting for USB hubs and devices, and it updates the choose_configuration routine to take this information into account. (This is something we should have been doing all along.) A new field in struct usb_device holds the amount of bus current available from the upstream port, and the usb_hub structure keeps track of the current available for each downstream port. Two new rules for configuration selection are added: Don't select a self-powered configuration when only bus power is available. Don't select a configuration requiring more bus power than is available. However the first rule is #if-ed out, because I found that the internal hub in my HP USB keyboard claims that its only configuration is self-powered. The rule would prevent the configuration from being chosen, leaving the hub & keyboard unconfigured. Since similar descriptor errors may turn out to be fairly common, it seemed wise not to include a rule that would break automatic configuration unnecessarily for such devices. The second rule may also trigger unnecessarily, although this should be less common. More likely it will annoy people by sometimes failing to accept configurations that should never have been chosen in the first place. The patch also changes usbcore's reaction when no configuration is suitable. Instead of raising an error and rejecting the device, now the core will simply leave the device unconfigured. People can always work around such problems by installing configurations manually through sysfs. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-23 12:03:12 -05:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] USB: Consider power budget when choosing configuration This patch (as609) changes the way we keep track of power budgeting for USB hubs and devices, and it updates the choose_configuration routine to take this information into account. (This is something we should have been doing all along.) A new field in struct usb_device holds the amount of bus current available from the upstream port, and the usb_hub structure keeps track of the current available for each downstream port. Two new rules for configuration selection are added: Don't select a self-powered configuration when only bus power is available. Don't select a configuration requiring more bus power than is available. However the first rule is #if-ed out, because I found that the internal hub in my HP USB keyboard claims that its only configuration is self-powered. The rule would prevent the configuration from being chosen, leaving the hub & keyboard unconfigured. Since similar descriptor errors may turn out to be fairly common, it seemed wise not to include a rule that would break automatic configuration unnecessarily for such devices. The second rule may also trigger unnecessarily, although this should be less common. More likely it will annoy people by sometimes failing to accept configurations that should never have been chosen in the first place. The patch also changes usbcore's reaction when no configuration is suitable. Instead of raising an error and rejecting the device, now the core will simply leave the device unconfigured. People can always work around such problems by installing configurations manually through sysfs. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-23 12:03:12 -05:00
drivers: usb: core: {file,hub,sysfs,usb}.c: Whitespace fixes including: - removing of trailing whitespace - removing spaces before array indexing (foo [] to foo[]) - reindention of a switch-case block - spaces to tabs Signed-off-by: Matthias Beyer <mail@beyermatthias.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-10 23:41:27 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: Check device descriptor before resusciation If a device connected to an xHCI host controller disconnects from the USB bus and then reconnects, e.g. triggered by a firmware update, then the host controller automatically activates the connection and the port is enabled. The implementation of hub_port_connect_change() assumes that if the port is enabled then nothing has changed. There is no check if the USB descriptors have changed. As a result, the kernel's internal copy of the descriptors ends up being incorrect and the device doesn't work properly anymore. The solution to the problem is for hub_port_connect_change() always to check whether the device's descriptors have changed before resuscitating an enabled port. Signed-off-by: David Heinzelmann <heinzelmann.david@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20191009044647.24536-1-heinzelmann.david@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-09 06:46:47 +02:00
USB: core: Change usb_get_device_descriptor() API The usb_get_device_descriptor() routine reads the device descriptor from the udev device and stores it directly in udev->descriptor. This interface is error prone, because the USB subsystem expects in-memory copies of a device's descriptors to be immutable once the device has been initialized. The interface is changed so that the device descriptor is left in a kmalloc-ed buffer, not copied into the usb_device structure. A pointer to the buffer is returned to the caller, who is then responsible for kfree-ing it. The corresponding changes needed in the various callers are fairly small. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/d0111bb6-56c1-4f90-adf2-6cfe152f6561@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:12:21 -04:00
usb: hub: Check device descriptor before resusciation If a device connected to an xHCI host controller disconnects from the USB bus and then reconnects, e.g. triggered by a firmware update, then the host controller automatically activates the connection and the port is enabled. The implementation of hub_port_connect_change() assumes that if the port is enabled then nothing has changed. There is no check if the USB descriptors have changed. As a result, the kernel's internal copy of the descriptors ends up being incorrect and the device doesn't work properly anymore. The solution to the problem is for hub_port_connect_change() always to check whether the device's descriptors have changed before resuscitating an enabled port. Signed-off-by: David Heinzelmann <heinzelmann.david@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20191009044647.24536-1-heinzelmann.david@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-09 06:46:47 +02:00
USB: core: Change usb_get_device_descriptor() API The usb_get_device_descriptor() routine reads the device descriptor from the udev device and stores it directly in udev->descriptor. This interface is error prone, because the USB subsystem expects in-memory copies of a device's descriptors to be immutable once the device has been initialized. The interface is changed so that the device descriptor is left in a kmalloc-ed buffer, not copied into the usb_device structure. A pointer to the buffer is returned to the caller, who is then responsible for kfree-ing it. The corresponding changes needed in the various callers are fairly small. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/d0111bb6-56c1-4f90-adf2-6cfe152f6561@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:12:21 -04:00
usb: hub: Check device descriptor before resusciation If a device connected to an xHCI host controller disconnects from the USB bus and then reconnects, e.g. triggered by a firmware update, then the host controller automatically activates the connection and the port is enabled. The implementation of hub_port_connect_change() assumes that if the port is enabled then nothing has changed. There is no check if the USB descriptors have changed. As a result, the kernel's internal copy of the descriptors ends up being incorrect and the device doesn't work properly anymore. The solution to the problem is for hub_port_connect_change() always to check whether the device's descriptors have changed before resuscitating an enabled port. Signed-off-by: David Heinzelmann <heinzelmann.david@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20191009044647.24536-1-heinzelmann.david@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-09 06:46:47 +02:00
usb: refactor port handling in hub_events() In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:15 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: Check for dropped connection before switching to full speed Some buggy USB disk adapters disconnect and reconnect multiple times during the enumeration procedure. This may lead to a device connecting at full speed instead of high speed, because when the USB stack sees that a device isn't able to enumerate at high speed, it tries to hand the connection over to a full-speed companion controller. The logic for doing this is careful to check that the device is still connected. But this check is inadequate if the device disconnects and reconnects before the check is done. The symptom is that a device works, but much more slowly than it is capable of operating. The situation was made worse recently by commit 22547c4cc4fe ("usb: hub: Wait for connection to be reestablished after port reset"), which increases the delay following a reset before a disconnect is recognized, thus giving the device more time to reconnect. This patch makes the check more robust. If the device was disconnected at any time during enumeration, we will now skip the full-speed handover. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Zdenek Kabelac <zkabelac@redhat.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-08-01 10:41:56 -04:00
usb/core: update power budget for SuperSpeed Sarah pointed out that the USB3.0 spec also updates the amount of power that may be consumed by the device and quoted 9.2.5.1: |"The amount of current draw for SuperSpeed devices are increased to 150 |mA for low-power devices and 900 mA for high-power" This patch tries to update all users to use the larger values for SuperSpeed devices and use the "old" ones for everything else. While here, two other changes suggested by Alan: - the comment referering to 7.2.1.1 has been updated to 7.2.1 which is the correct source of the action. - the check for hubs with zero ports has been removed. - compute bus power by full_load * num_ports on root hubs Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-12-18 15:25:47 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: force handover port to companion when hub_port_connect_change fails This patch hands over the port to the companion when the hub_port_connect_change fails. Signed-off-by: Balaji Rao <balajirrao@gmail.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-22 01:58:14 +05:30
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
usb: refactor port handling in hub_events() In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:15 -07:00
usbcore: don't log on consecutive debounce failures of the same port Some laptops have an internal port for a BT device which picks up noise when the kill switch is used, but not enough to trigger printk_rlimit(). So we shouldn't log consecutive faults of this kind. Signed-off-by: Oliver Neukum <oneukum@suse.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-14 15:39:49 +02:00
usb: hub: Fix locking issues with address0_mutex Fix the circular lock dependency and unbalanced unlock of addess0_mutex introduced when fixing an address0_mutex enumeration retry race in commit ae6dc22d2d1 ("usb: hub: Fix usb enumeration issue due to address0 race") Make sure locking order between port_dev->status_lock and address0_mutex is correct, and that address0_mutex is not unlocked in hub_port_connect "done:" codepath which may be reached without locking address0_mutex Fixes: 6ae6dc22d2d1 ("usb: hub: Fix usb enumeration issue due to address0 race") Cc: <stable@vger.kernel.org> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211123101656.1113518-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-23 12:16:56 +02:00
USB: try to salvage lost power sessions This patch (as1073) adds to khubd a way to recover from power-session interruption caused by transient connect-change or enable-change events. After the debouncing period, khubd attempts to do a USB-Persist-style reset or reset-resume. If it works, the connection will remain unscathed. The upshot is that we will be more immune to noise caused by EMI. The grace period is on the order of 100 ms, so this won't permit recovery from the "accidentally knocked the USB cable out of its socket" type of event, but it's a start. As an added bonus, if a device was suspended when the system goes to sleep then we no longer need to check for power-session interruptions when the system wakes up. Khubd will naturally see the status change while processing the device's parent hub and will do the right thing. The remote_wakeup() routine is changed; now it expects the caller to acquire the device lock rather than acquiring the lock itself. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:55 -04:00
USB: debounce before unregistering This patch (as1080) makes a significant change to the way khubd handles port connect-change and enable-change events. Both types of event are now debounced, and the debouncing is carried out _before_ an existing usb_device is unregistered, instead of afterward. This means that drivers will have to deal with longer runs of errors when a device is unplugged, but they are supposed to be prepared for that in any case. The advantage is that when an enable-change occurs (caused for example by electromagnetic interference), the debouncing period will provide time for the cause of the problem to die away. A simple port reset (added in a forthcoming patch) will then allow us to recover from the fault. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:28 -04:00
usb: refine phy notify operation during connection and disconnection At commit 925aa46ba963a4da6d8ee6ab1d04a02ffa8db62b, Richard Zhao <richard.zhao@freescale.com> adds the phy notification callback when port change occurs. In fact, this phy notification should be added according to below rules: 1. Only set HW_USBPHY_CTRL.ENHOSTDISCONDETECT during high speed host mode. 2. Do not set HW_USBPHY_CTRL.ENHOSTDISCONDETECT during the reset and speed negotiation period. 3. Do not set HW_USBPHY_CTRL.ENHOSTDISCONDETECT during host suspend/resume sequence. Please refer: i.mx23RM(page: 413) for below rules. http://www.freescale.com/files/dsp/doc/ref_manual/IMX23RM.pdf Freescale i.MX SoC, i.mx23, i.mx28 and i.mx6(i.mx6SL does not need to follow the 3rd rule) need to follow above rules. Current code set connect notification (HW_USBPHY_CTRL.ENHOSTDISCONDETECT) at hub_port_connect_change, it conflicts with above the 2th rule. The correct notification setting method should be: 1. Set connect notify after the second bus reset. 2. Set disconnect notify after disconnection. Signed-off-by: Peter Chen <peter.chen@freescale.com> Tested-by: Mike Thompson <mpthompson@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-09 09:44:43 +08:00
usb: core: notify disconnection when core detects disconnect It is safe to call notify disconnect when the usb core thinks the device is disconnected. This commit also fixes one bug found at below situation: we have not enabled usb wakeup, we do system suspend when there is an usb device at the port, after suspend, we plug out the usb device, then plug in device again. At that time, the nofity disconnect was not called at current code, as the controller doesn't know the usb device was disconnected during the suspend, but USB core knows the port has changed during that periods. So to fix this problem, and let the usb core call notify disconnect. Cc: 3.17+ <stable@vger.kernel.org> Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-04 11:14:31 +08:00
usb: rename phy to usb_phy in HCD The USB PHY member of the HCD structure is renamed to 'usb_phy' and modifications are done in all drivers accessing it. This is in preparation to adding the generic PHY support. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> [Sergei: added missing 'drivers/usb/misc/lvstest.c' file, resolved rejects, updated changelog.] Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-24 23:05:50 +04:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
usb: refine phy notify operation during connection and disconnection At commit 925aa46ba963a4da6d8ee6ab1d04a02ffa8db62b, Richard Zhao <richard.zhao@freescale.com> adds the phy notification callback when port change occurs. In fact, this phy notification should be added according to below rules: 1. Only set HW_USBPHY_CTRL.ENHOSTDISCONDETECT during high speed host mode. 2. Do not set HW_USBPHY_CTRL.ENHOSTDISCONDETECT during the reset and speed negotiation period. 3. Do not set HW_USBPHY_CTRL.ENHOSTDISCONDETECT during host suspend/resume sequence. Please refer: i.mx23RM(page: 413) for below rules. http://www.freescale.com/files/dsp/doc/ref_manual/IMX23RM.pdf Freescale i.MX SoC, i.mx23, i.mx28 and i.mx6(i.mx6SL does not need to follow the 3rd rule) need to follow above rules. Current code set connect notification (HW_USBPHY_CTRL.ENHOSTDISCONDETECT) at hub_port_connect_change, it conflicts with above the 2th rule. The correct notification setting method should be: 1. Set connect notify after the second bus reset. 2. Set disconnect notify after disconnection. Signed-off-by: Peter Chen <peter.chen@freescale.com> Tested-by: Mike Thompson <mpthompson@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-09 09:44:43 +08:00
USB: debounce before unregistering This patch (as1080) makes a significant change to the way khubd handles port connect-change and enable-change events. Both types of event are now debounced, and the debouncing is carried out _before_ an existing usb_device is unregistered, instead of afterward. This means that drivers will have to deal with longer runs of errors when a device is unplugged, but they are supposed to be prepared for that in any case. The advantage is that when an enable-change occurs (caused for example by electromagnetic interference), the debouncing period will provide time for the cause of the problem to die away. A simple port reset (added in a forthcoming patch) will then allow us to recover from the fault. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-28 11:06:28 -04:00
USB: add a "remove hardware" sysfs attribute This patch (as1297) adds a "remove" attribute to each USB device's directory in sysfs. Writing to this attribute causes the device to be deconfigured (the same as writing 0 to the "bConfigurationValue" attribute) and then tells the hub driver to disable the device's upstream port. The device remains locked during these activities so there is no possibility of it getting reconfigured in between. The port will remain disabled until after the device is unplugged. The purpose of this is to provide a means for user programs to imitate the "Safely remove hardware" applet in Windows. Some devices do expect their ports to be disabled before they are unplugged, and they provide visual feedback to users indicating when they can safely be unplugged. The security implications are minimal. Writing to the "remove" attribute is no more dangerous than writing to the "bConfigurationValue" attribute. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: David Zeuthen <davidz@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 15:20:13 -04:00
USB: revert recovery from transient errors This patch (as1135) essentially reverts the major parts of two earlier patches to usbcore, because they ended up causing a regression. Trying to recover from transient communication errors can lead to other problems, because operations that failed during the error period are not always retried. The simplest example is the initial Set-Config request sent after device enumeration; if it gets lost then it will not be retried and the device will remain unconfigured. This patch restores the old behavior in which any port disconnect or port disable causes the entire device structure to be removed, fixing a reported regression. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Frans Pop <elendil@planet.nl> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-22 14:43:08 -04:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
USB: revert recovery from transient errors This patch (as1135) essentially reverts the major parts of two earlier patches to usbcore, because they ended up causing a regression. Trying to recover from transient communication errors can lead to other problems, because operations that failed during the error period are not always retried. The simplest example is the initial Set-Config request sent after device enumeration; if it gets lost then it will not be retried and the device will remain unconfigured. This patch restores the old behavior in which any port disconnect or port disable causes the entire device structure to be removed, fixing a reported regression. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Frans Pop <elendil@planet.nl> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-22 14:43:08 -04:00
usbcore: don't log on consecutive debounce failures of the same port Some laptops have an internal port for a BT device which picks up noise when the kill switch is used, but not enough to trigger printk_rlimit(). So we shouldn't log consecutive faults of this kind. Signed-off-by: Oliver Neukum <oneukum@suse.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-14 15:39:49 +02:00
usbcore: Fix wrong device in an error message in hub_port_connect() The commit [5ee0f803cc3a: usbcore: don't log on consecutive debounce failures of the same port] added the check of the reliable port, but it also replaced the device argument to dev_err() wrongly, which leads to a NULL dereference. This patch restores the right device, port_dev->dev. Also, since dev_err() itself shows the port number, reduce the port number shown in the error message, essentially reverting to the state before the commit 5ee0f803cc3a. [The fix suggested by Hannes, and the error message cleanup suggested by Alan Stern] Fixes: 5ee0f803cc3a ('usbcore: don't log on consecutive debounce failures of the same port') Reported-by: Hannes Reinecke <hare@suse.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-08-19 17:37:55 +02:00
USB: revert recovery from transient errors This patch (as1135) essentially reverts the major parts of two earlier patches to usbcore, because they ended up causing a regression. Trying to recover from transient communication errors can lead to other problems, because operations that failed during the error period are not always retried. The simplest example is the initial Set-Config request sent after device enumeration; if it gets lost then it will not be retried and the device will remain unconfigured. This patch restores the old behavior in which any port disconnect or port disable causes the entire device structure to be removed, fixing a reported regression. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Frans Pop <elendil@planet.nl> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-22 14:43:08 -04:00
usbcore: don't log on consecutive debounce failures of the same port Some laptops have an internal port for a BT device which picks up noise when the kill switch is used, but not enough to trigger printk_rlimit(). So we shouldn't log consecutive faults of this kind. Signed-off-by: Oliver Neukum <oneukum@suse.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-14 15:39:49 +02:00
USB: revert recovery from transient errors This patch (as1135) essentially reverts the major parts of two earlier patches to usbcore, because they ended up causing a regression. Trying to recover from transient communication errors can lead to other problems, because operations that failed during the error period are not always retried. The simplest example is the initial Set-Config request sent after device enumeration; if it gets lost then it will not be retried and the device will remain unconfigured. This patch restores the old behavior in which any port disconnect or port disable causes the entire device structure to be removed, fixing a reported regression. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Frans Pop <elendil@planet.nl> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-22 14:43:08 -04:00
USB: add a "remove hardware" sysfs attribute This patch (as1297) adds a "remove" attribute to each USB device's directory in sysfs. Writing to this attribute causes the device to be deconfigured (the same as writing 0 to the "bConfigurationValue" attribute) and then tells the hub driver to disable the device's upstream port. The device remains locked during these activities so there is no possibility of it getting reconfigured in between. The port will remain disabled until after the device is unplugged. The purpose of this is to provide a means for user programs to imitate the "Safely remove hardware" applet in Windows. Some devices do expect their ports to be disabled before they are unplugged, and they provide visual feedback to users indicating when they can safely be unplugged. The security implications are minimal. Writing to the "remove" attribute is no more dangerous than writing to the "bConfigurationValue" attribute. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: David Zeuthen <davidz@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 15:20:13 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: hub: modify hub reset logic in hub driver Currently if port power is turned off by user on hub port using USBDEVFS then port power is turned back ON by hub driver. This commit modifies hub reset logic in hub_port_connect() to prevent hub driver from turning back the port power ON if port is not owned by kernel. Signed-off-by: Deepak Das <deepakdas.linux@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-01-21 23:39:58 +05:30
usb: disable port power control if not supported in wHubCharacteristics A hub indicates whether it supports per-port power control via the wHubCharacteristics field in its descriptor. If it is not supported a hub will still emulate ClearPortPower(PORT_POWER) requests by stopping the link state machine. However, since this does not save power do not bother suspending. This also consolidates support checks into a hub_is_port_power_switchable() helper. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:12 -07:00
usb: hub: port: add sysfs entry to switch port power In some cases the port of an hub needs to be disabled or switched off and on again. E.g. when the connected device needs to be re-enumerated. Or it needs to be explicitly disabled while the rest of the usb tree stays working. For this purpose this patch adds an sysfs switch to enable/disable the port on any hub. In the case the hub is supporting power switching, the power line will be disabled to the connected device. When the port gets disabled, the associated device gets disconnected and removed from the logical usb tree. No further device will be enumerated on that port until the port gets enabled again. Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220607114522.3359148-1-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-07 13:45:22 +02:00
usb: core: hub: modify hub reset logic in hub driver Currently if port power is turned off by user on hub port using USBDEVFS then port power is turned back ON by hub driver. This commit modifies hub reset logic in hub_port_connect() to prevent hub driver from turning back the port power ON if port is not owned by kernel. Signed-off-by: Deepak Das <deepakdas.linux@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-01-21 23:39:58 +05:30
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: revert recovery from transient errors This patch (as1135) essentially reverts the major parts of two earlier patches to usbcore, because they ended up causing a regression. Trying to recover from transient communication errors can lead to other problems, because operations that failed during the error period are not always retried. The simplest example is the initial Set-Config request sent after device enumeration; if it gets lost then it will not be retried and the device will remain unconfigured. This patch restores the old behavior in which any port disconnect or port disable causes the entire device structure to be removed, fixing a reported regression. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Frans Pop <elendil@planet.nl> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-22 14:43:08 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
drivers: usb: core: {file,hub,sysfs,usb}.c: Whitespace fixes including: - removing of trailing whitespace - removing spaces before array indexing (foo [] to foo[]) - reindention of a switch-case block - spaces to tabs Signed-off-by: Matthias Beyer <mail@beyermatthias.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-10 23:41:27 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb/core: update power budget for SuperSpeed Sarah pointed out that the USB3.0 spec also updates the amount of power that may be consumed by the device and quoted 9.2.5.1: |"The amount of current draw for SuperSpeed devices are increased to 150 |mA for low-power devices and 900 mA for high-power" This patch tries to update all users to use the larger values for SuperSpeed devices and use the "old" ones for everything else. While here, two other changes suggested by Alan: - the comment referering to 7.2.1.1 has been updated to 7.2.1 which is the correct source of the action. - the check for hubs with zero ports has been removed. - compute bus power by full_load * num_ports on root hubs Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-12-18 15:25:47 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: avoid error messages when a device is disconnected This patch (as1673) reduces the amount of log spew from the hub driver by removing a bunch of error messages in the case where the device in question is already known to have been disconnected. Since the disconnect event itself appears in the log, there's no need for other error messages. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Jenya Y <jy.gerstmaier@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-27 16:14:01 -04:00
usb: hub: Fix usb enumeration issue due to address0 race xHC hardware can only have one slot in default state with address 0 waiting for a unique address at a time, otherwise "undefined behavior may occur" according to xhci spec 5.4.3.4 The address0_mutex exists to prevent this across both xhci roothubs. If hub_port_init() fails, it may unlock the mutex and exit with a xhci slot in default state. If the other xhci roothub calls hub_port_init() at this point we end up with two slots in default state. Make sure the address0_mutex protects the slot default state across hub_port_init() retries, until slot is addressed or disabled. Note, one known minor case is not fixed by this patch. If device needs to be reset during resume, but fails all hub_port_init() retries in usb_reset_and_verify_device(), then it's possible the slot is still left in default state when address0_mutex is unlocked. Cc: <stable@vger.kernel.org> Fixes: 638139eb95d2 ("usb: hub: allow to process more usb hub events in parallel") Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211115221630.871204-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-16 00:16:30 +02:00
USB: hub: Clean up use of port initialization schemes and retries The SET_CONFIG_TRIES macro in hub.c is badly named; it controls the number of port-initialization retry attempts rather than the number of Set-Configuration attempts. Furthermore, the USE_NEW_SCHEME macro and use_new_scheme() function are written in a very confusing manner, making it almost impossible to figure out exactly what they do or check that they are correct. This patch renames SET_CONFIG_TRIES to PORT_INIT_TRIES, removes USE_NEW_SCHEME entirely, and rewrites use_new_scheme() to be much more transparent, with added comments explaining how it works. The patch also pulls the single call site of use_new_scheme() out from the Get-Descriptor retry loop (where it returns the same value each time) and renames the local variable used to store the result. The overall effect is a minor cleanup. However, there is one functional change: If the "use_both_schemes" module parameter isn't set (by default it is set), the existing code does only two retry iterations. After this patch it will always perform four, regardless of the parameter's value. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200928152050.GA134701@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-28 11:20:50 -04:00
usb: core: stop USB enumeration if too many retries When a broken USB accessory connects to a USB host, usbcore might keep doing enumeration retries. If the host has a watchdog mechanism, the kernel panic will happen on the host. This patch provides an attribute early_stop to limit the numbers of retries for each port of a hub. If a port was marked with early_stop attribute, unsuccessful connection attempts will fail quickly. In addition, if an early_stop port has failed to initialize, it will ignore all future connection events until early_stop attribute is clear. Signed-off-by: Ray Chi <raychi@google.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20221107072754.3336357-1-raychi@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-11-07 15:27:54 +08:00
usb: hub: Fix locking issues with address0_mutex Fix the circular lock dependency and unbalanced unlock of addess0_mutex introduced when fixing an address0_mutex enumeration retry race in commit ae6dc22d2d1 ("usb: hub: Fix usb enumeration issue due to address0 race") Make sure locking order between port_dev->status_lock and address0_mutex is correct, and that address0_mutex is not unlocked in hub_port_connect "done:" codepath which may be reached without locking address0_mutex Fixes: 6ae6dc22d2d1 ("usb: hub: Fix usb enumeration issue due to address0 race") Cc: <stable@vger.kernel.org> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211123101656.1113518-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-23 12:16:56 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
usb: hub: Fix locking issues with address0_mutex Fix the circular lock dependency and unbalanced unlock of addess0_mutex introduced when fixing an address0_mutex enumeration retry race in commit ae6dc22d2d1 ("usb: hub: Fix usb enumeration issue due to address0 race") Make sure locking order between port_dev->status_lock and address0_mutex is correct, and that address0_mutex is not unlocked in hub_port_connect "done:" codepath which may be reached without locking address0_mutex Fixes: 6ae6dc22d2d1 ("usb: hub: Fix usb enumeration issue due to address0 race") Cc: <stable@vger.kernel.org> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211123101656.1113518-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-23 12:16:56 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
drivers: usb: core: {file,hub,sysfs,usb}.c: Whitespace fixes including: - removing of trailing whitespace - removing spaces before array indexing (foo [] to foo[]) - reindention of a switch-case block - spaces to tabs Signed-off-by: Matthias Beyer <mail@beyermatthias.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-10 23:41:27 +02:00
usbcore: store each usb_device's level in the tree This patch (as778) adds a field to struct usb_device to store the device's level in the USB tree. In itself this number isn't really important. But the overhead is very low, and in a later patch it will be used for preventing bogus warnings from the lockdep checker. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-08-30 15:46:48 -04:00
[PATCH] USB: Consider power budget when choosing configuration This patch (as609) changes the way we keep track of power budgeting for USB hubs and devices, and it updates the choose_configuration routine to take this information into account. (This is something we should have been doing all along.) A new field in struct usb_device holds the amount of bus current available from the upstream port, and the usb_hub structure keeps track of the current available for each downstream port. Two new rules for configuration selection are added: Don't select a self-powered configuration when only bus power is available. Don't select a configuration requiring more bus power than is available. However the first rule is #if-ed out, because I found that the internal hub in my HP USB keyboard claims that its only configuration is self-powered. The rule would prevent the configuration from being chosen, leaving the hub & keyboard unconfigured. Since similar descriptor errors may turn out to be fairly common, it seemed wise not to include a rule that would break automatic configuration unnecessarily for such devices. The second rule may also trigger unnecessarily, although this should be less common. More likely it will annoy people by sometimes failing to accept configurations that should never have been chosen in the first place. The patch also changes usbcore's reaction when no configuration is suitable. Instead of raising an error and rejecting the device, now the core will simply leave the device unconfigured. People can always work around such problems by installing configurations manually through sysfs. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-23 12:03:12 -05:00
usb: define USB_SPEED_SUPER_PLUS speed for SuperSpeedPlus USB3.1 devices Add a new USB_SPEED_SUPER_PLUS device speed, and make sure usb core can handle the new speed. In most cases the behaviour is the same as with USB_SPEED_SUPER SuperSpeed devices. In a few places we add a "Plus" string to inform the user of the new speed. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-10 09:59:25 +02:00
USB: Remove bogus USB_PORT_STAT_SUPER_SPEED symbol. USB_PORT_STAT_SUPER_SPEED is a made up symbol that the USB core used to track whether USB ports had a SuperSpeed device attached. This is a linux-internal symbol that was used when SuperSpeed and non-SuperSpeed devices would show up under the same xHCI roothub. This particular port status is never returned by external USB 3.0 hubs. (Instead they have a USB_PORT_STAT_SPEED_5GBPS that uses a completely different speed mask.) Now that the xHCI driver registers two roothubs, USB 3.0 devices will only show up under USB 3.0 hubs. Rip out USB_PORT_STAT_SUPER_SPEED and replace it with calls to hub_is_superspeed(). Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-06 21:00:19 -08:00
USB: Don't reset USB 3.0 devices on port change detection. The USB 3.0 bus specification defines a new connection sequence for USB 3.0 hubs and roothubs. USB 3.0 devices are reset and link trained by the hub before the port status change notification is sent to the host OS. This means that an entire tree of devices can be trained in parallel on power up, and the OS no longer needs to reset USB 3.0 devices. Change the USB core's hub port init sequence so that it does not reset USB 3.0 devices. The port status change from the roothub and from the USB 3.0 hub will report the SuperSpeed connect correctly. This patch currently only handles the roothub case. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-27 19:54:26 -07:00
USB: use "device number" instead of "address" The USB stack historically has conflated device numbers (i.e., the value of udev->devnum) with device addresses. This is understandable, because until recently the two values were always the same. But with USB-3.0 they aren't the same, so we should start calling these things by their correct names. This patch (as1449b) changes many of the references to "address" in the hub driver to "device number" or "devnum". The patch also removes some unnecessary or misleading comments. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Luben Tuikov <ltuikov@yahoo.com> Reviewed-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-22 09:53:41 -05:00
USB: core: use kernel assigned address for devices under xHCI xHCI driver uses hardware assigned device address. This may cause device address conflict in certain cases. Use kernel assigned address for devices under xHCI. Store the xHC assigned address locally in xHCI driver. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-10-14 07:22:51 -07:00
USB: Support for addressing a USB device under xHCI Add host controller driver API and a slot_id variable to struct usb_device. This allows the xHCI host controller driver to ask the hardware to allocate a slot for the device when a struct usb_device is allocated. The slot needs to be allocated at that point because the hardware can run out of internal resources, and we want to know that very early in the device connection process. Don't call this new API for root hubs, since they aren't real devices. Add HCD API to let the host controller choose the device address. This is especially important for xHCI hardware running in a virtualized environment. The guests running under the VM don't need to know which addresses on the bus are taken, because the hardware picks the address for them. Announce SuperSpeed USB devices after the address has been assigned by the hardware. Don't use the new get descriptor/set address scheme with xHCI. Unless special handling is done in the host controller driver, the xHC can't issue control transfers before you set the device address. Support for the older addressing scheme will be added when the xHCI driver supports the Block Set Address Request (BSR) flag in the Address Device command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-27 19:57:26 -07:00
USB: Don't reset USB 3.0 devices on port change detection. The USB 3.0 bus specification defines a new connection sequence for USB 3.0 hubs and roothubs. USB 3.0 devices are reset and link trained by the hub before the port status change notification is sent to the host OS. This means that an entire tree of devices can be trained in parallel on power up, and the OS no longer needs to reset USB 3.0 devices. Change the USB core's hub port init sequence so that it does not reset USB 3.0 devices. The port status change from the roothub and from the USB 3.0 hub will report the SuperSpeed connect correctly. This patch currently only handles the roothub case. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-27 19:54:26 -07:00
USB: core: Fix race by not overwriting udev->descriptor in hub_port_init() Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors(): BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011 CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351 print_report mm/kasan/report.c:462 [inline] kasan_report+0x11c/0x130 mm/kasan/report.c:572 read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 ... Allocated by task 758: ... __do_kmalloc_node mm/slab_common.c:966 [inline] __kmalloc+0x5e/0x190 mm/slab_common.c:979 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:680 [inline] usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887 usb_enumerate_device drivers/usb/core/hub.c:2407 [inline] usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545 As analyzed by Khazhy Kumykov, the cause of this bug is a race between read_descriptors() and hub_port_init(): The first routine uses a field in udev->descriptor, not expecting it to change, while the second overwrites it. Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") this race couldn't occur, because the routines were mutually exclusive thanks to the device locking. Removing that locking from read_descriptors() exposed it to the race. The best way to fix the bug is to keep hub_port_init() from changing udev->descriptor once udev has been initialized and registered. Drivers expect the descriptors stored in the kernel to be immutable; we should not undermine this expectation. In fact, this change should have been made long ago. So now hub_port_init() will take an additional argument, specifying a buffer in which to store the device descriptor it reads. (If udev has not yet been initialized, the buffer pointer will be NULL and then hub_port_init() will store the device descriptor in udev as before.) This eliminates the data race responsible for the out-of-bounds read. The changes to hub_port_init() appear more extensive than they really are, because of indentation changes resulting from an attempt to avoid writing to other parts of the usb_device structure after it has been initialized. Similar changes should be made to the code that reads the BOS descriptor, but that can be handled in a separate patch later on. This patch is sufficient to fix the bug found by syzbot. Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Khazhy Kumykov <khazhy@google.com> Fixes: 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:14:14 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: Fix usb enumeration issue due to address0 race xHC hardware can only have one slot in default state with address 0 waiting for a unique address at a time, otherwise "undefined behavior may occur" according to xhci spec 5.4.3.4 The address0_mutex exists to prevent this across both xhci roothubs. If hub_port_init() fails, it may unlock the mutex and exit with a xhci slot in default state. If the other xhci roothub calls hub_port_init() at this point we end up with two slots in default state. Make sure the address0_mutex protects the slot default state across hub_port_init() retries, until slot is addressed or disabled. Note, one known minor case is not fixed by this patch. If device needs to be reset during resume, but fails all hub_port_init() retries in usb_reset_and_verify_device(), then it's possible the slot is still left in default state when address0_mutex is unlocked. Cc: <stable@vger.kernel.org> Fixes: 638139eb95d2 ("usb: hub: allow to process more usb hub events in parallel") Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211115221630.871204-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-16 00:16:30 +02:00
usb: hub: Fix locking issues with address0_mutex Fix the circular lock dependency and unbalanced unlock of addess0_mutex introduced when fixing an address0_mutex enumeration retry race in commit ae6dc22d2d1 ("usb: hub: Fix usb enumeration issue due to address0 race") Make sure locking order between port_dev->status_lock and address0_mutex is correct, and that address0_mutex is not unlocked in hub_port_connect "done:" codepath which may be reached without locking address0_mutex Fixes: 6ae6dc22d2d1 ("usb: hub: Fix usb enumeration issue due to address0 race") Cc: <stable@vger.kernel.org> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211123101656.1113518-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-23 12:16:56 +02:00
usb: hub: Fix usb enumeration issue due to address0 race xHC hardware can only have one slot in default state with address 0 waiting for a unique address at a time, otherwise "undefined behavior may occur" according to xhci spec 5.4.3.4 The address0_mutex exists to prevent this across both xhci roothubs. If hub_port_init() fails, it may unlock the mutex and exit with a xhci slot in default state. If the other xhci roothub calls hub_port_init() at this point we end up with two slots in default state. Make sure the address0_mutex protects the slot default state across hub_port_init() retries, until slot is addressed or disabled. Note, one known minor case is not fixed by this patch. If device needs to be reset during resume, but fails all hub_port_init() retries in usb_reset_and_verify_device(), then it's possible the slot is still left in default state when address0_mutex is unlocked. Cc: <stable@vger.kernel.org> Fixes: 638139eb95d2 ("usb: hub: allow to process more usb hub events in parallel") Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211115221630.871204-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-16 00:16:30 +02:00
USB delay init quirk for logitech Harmony 700-series devices The Logitech Harmony 700 series needs an extra delay during initialization. This patch adds a USB quirk which enables such a delay and adds the device to the quirks list. Signed-off-by: Phil Dibowitz <phil@ipom.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-07-22 00:05:01 +02:00
usb: Increase quirk delay for USB devices Commit e0429362ab15 ("usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e") introduced quirk to workaround an issue with some Logitech webcams. The workaround is introducing delay for some USB operations. According to our testing, delay introduced by original commit is not long enough and in rare cases we still see issues described by the aforementioned commit. This patch increases delays introduced by original commit. Having this patch applied we do not see those problems anymore. Signed-off-by: Dmitry Fleytman <dmitry@daynix.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-05 11:40:56 +03:00
USB delay init quirk for logitech Harmony 700-series devices The Logitech Harmony 700 series needs an extra delay during initialization. This patch adds a USB quirk which enables such a delay and adds the device to the quirks list. Signed-off-by: Phil Dibowitz <phil@ipom.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-07-22 00:05:01 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb/core: update power budget for SuperSpeed Sarah pointed out that the USB3.0 spec also updates the amount of power that may be consumed by the device and quoted 9.2.5.1: |"The amount of current draw for SuperSpeed devices are increased to 150 |mA for low-power devices and 900 mA for high-power" This patch tries to update all users to use the larger values for SuperSpeed devices and use the "old" ones for everything else. While here, two other changes suggested by Alan: - the comment referering to 7.2.1.1 has been updated to 7.2.1 which is the correct source of the action. - the check for hubs with zero ports has been removed. - compute bus power by full_load * num_ports on root hubs Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-12-18 15:25:47 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: introduce a new usb_get_std_status() helper This new helper is a simple wrapper around usb_get_status(). This patch is in preparation to adding support for fetching PTM_STATUS types. No functional changes. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-02 10:57:40 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: simplify the interface of usb_get_status() This patch simplifies the interface presented by usb_get_status(). Instead of forcing callers to check for the proper data length and convert the status value to host byte order, the function will now do these things itself. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-30 15:35:40 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: move hub init and LED blink work to power efficient workqueue Allow the scheduler to select the best CPU to handle hub initalization and LED blinking work. This extends idle residency times on idle CPUs and conserves power. This functionality is enabled when CONFIG_WQ_POWER_EFFICIENT is selected. [zoran.markovic@linaro.org: Rebased to latest kernel. Added commit message. Changed reference from system to power efficient workqueue for LEDs in check_highspeed() and hub_port_connect_change().] Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Xenia Ragiadakou <burzalodowa@gmail.com> Cc: Julius Werner <jwerner@chromium.org> Cc: Krzysztof Mazur <krzysiek@podlesie.net> Cc: Matthias Beyer <mail@beyermatthias.de> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Mathias Nyman <mathias.nyman@linux.intel.com> Cc: Thomas Pugliese <thomas.pugliese@gmail.com> Signed-off-by: Shaibal Dutta <shaibal.dutta@broadcom.com> Signed-off-by: Zoran Markovic <zoran.markovic@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-01 19:16:46 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
drivers: usb: core: {file,hub,sysfs,usb}.c: Whitespace fixes including: - removing of trailing whitespace - removing spaces before array indexing (foo [] to foo[]) - reindention of a switch-case block - spaces to tabs Signed-off-by: Matthias Beyer <mail@beyermatthias.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-10 23:41:27 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: hub: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-18 20:36:58 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
Revert "usb: move struct usb_device->children to struct usb_hub_port->child" 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-14 09:20:37 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: assign default peer ports for root hubs Assume that the peer of a superspeed port is the port with the same id on the shared_hcd root hub. This identification scheme is required of external hubs by the USB3 spec [1]. However, for root hubs, tier mismatch may be in effect [2]. Tier mismatch can only be enumerated via platform firmware. For now, simply perform the nominal association. A new lock 'usb_port_peer_mutex' is introduced to synchronize port device add/remove with peer lookups. It protects peering against changes to hcd->shared_hcd, hcd->self.root_hub, hdev->maxchild, and port_dev->child pointers. [1]: usb 3.1 section 10.3.3 [2]: xhci 1.1 appendix D Cc: Alan Stern <stern@rowland.harvard.edu> [alan: usb_port_peer_mutex locking scheme] Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:28 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: assign default peer ports for root hubs Assume that the peer of a superspeed port is the port with the same id on the shared_hcd root hub. This identification scheme is required of external hubs by the USB3 spec [1]. However, for root hubs, tier mismatch may be in effect [2]. Tier mismatch can only be enumerated via platform firmware. For now, simply perform the nominal association. A new lock 'usb_port_peer_mutex' is introduced to synchronize port device add/remove with peer lookups. It protects peering against changes to hcd->shared_hcd, hcd->self.root_hub, hdev->maxchild, and port_dev->child pointers. [1]: usb 3.1 section 10.3.3 [2]: xhci 1.1 appendix D Cc: Alan Stern <stern@rowland.harvard.edu> [alan: usb_port_peer_mutex locking scheme] Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:28 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: assign default peer ports for root hubs Assume that the peer of a superspeed port is the port with the same id on the shared_hcd root hub. This identification scheme is required of external hubs by the USB3 spec [1]. However, for root hubs, tier mismatch may be in effect [2]. Tier mismatch can only be enumerated via platform firmware. For now, simply perform the nominal association. A new lock 'usb_port_peer_mutex' is introduced to synchronize port device add/remove with peer lookups. It protects peering against changes to hcd->shared_hcd, hcd->self.root_hub, hdev->maxchild, and port_dev->child pointers. [1]: usb 3.1 section 10.3.3 [2]: xhci 1.1 appendix D Cc: Alan Stern <stern@rowland.harvard.edu> [alan: usb_port_peer_mutex locking scheme] Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:28 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: assign default peer ports for root hubs Assume that the peer of a superspeed port is the port with the same id on the shared_hcd root hub. This identification scheme is required of external hubs by the USB3 spec [1]. However, for root hubs, tier mismatch may be in effect [2]. Tier mismatch can only be enumerated via platform firmware. For now, simply perform the nominal association. A new lock 'usb_port_peer_mutex' is introduced to synchronize port device add/remove with peer lookups. It protects peering against changes to hcd->shared_hcd, hcd->self.root_hub, hdev->maxchild, and port_dev->child pointers. [1]: usb 3.1 section 10.3.3 [2]: xhci 1.1 appendix D Cc: Alan Stern <stern@rowland.harvard.edu> [alan: usb_port_peer_mutex locking scheme] Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:28 -07:00
usb: core: need to call usb_phy_notify_connect after device setup Since we notify disconnecting based on the usb device is existed (port_dev->child, the child device at roothub is not NULL), we need to notify connect after device has been registered. This fixes a bug that do fast plug in/out test, and the notify_disconnect is not called due to roothub child is NULL and the enumeration has failed. Cc: v3.17+ <stable@vger.kernel.org> Signed-off-by: Tony Zheng <Tony.Zheng@freescale.com> Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-17 19:43:02 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
wusb: make ep0_reinit available for modules We need to be able to call ep0_reinit() [renamed to usb_ep0_reinit()] from the WUSB security code. The reason is that when we authenticate the device, it's address changes (from having bit 7 set to having it cleared). Thus, we need to signal the USB stack to reinitialize EP0, so the status with the previous address kept at the HCD layer is cleared and properly reinitialized. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-08 13:24:46 -07:00
USB: use "device number" instead of "address" The USB stack historically has conflated device numbers (i.e., the value of udev->devnum) with device addresses. This is understandable, because until recently the two values were always the same. But with USB-3.0 they aren't the same, so we should start calling these things by their correct names. This patch (as1449b) changes many of the references to "address" in the hub driver to "device number" or "devnum". The patch also removes some unnecessary or misleading comments. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Luben Tuikov <ltuikov@yahoo.com> Reviewed-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-22 09:53:41 -05:00
USB: Move hcd free_dev call into usb_disconnect to fix oops USB: Move hcd free_dev call into usb_disconnect I found a way to oops the kernel: 1. Open a USB device through devio. 2. Remove the hcd module in the host kernel. 3. Close the devio file descriptor. The problem is that closing the file descriptor does usb_release_dev as it is the last reference. usb_release_dev then tries to invoke the hcd free_dev function (or rather dereferencing the hcd driver struct). This causes an oops as the hcd driver has already been unloaded so the struct is gone. This patch tries to fix this by bringing the free_dev call earlier and into usb_disconnect. I have verified that repeating the above steps no longer crashes with this patch applied. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-10 20:15:03 +11:00
usb: hub: Fix locking issues with address0_mutex Fix the circular lock dependency and unbalanced unlock of addess0_mutex introduced when fixing an address0_mutex enumeration retry race in commit ae6dc22d2d1 ("usb: hub: Fix usb enumeration issue due to address0 race") Make sure locking order between port_dev->status_lock and address0_mutex is correct, and that address0_mutex is not unlocked in hub_port_connect "done:" codepath which may be reached without locking address0_mutex Fixes: 6ae6dc22d2d1 ("usb: hub: Fix usb enumeration issue due to address0 race") Cc: <stable@vger.kernel.org> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211123101656.1113518-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-23 12:16:56 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB Core: hub.c: prevent re-enumeration on HNP Patch is to prevent the OTG host of doing 3 times enumeration of device when the Host suspends for HNP. The error code used in this case is ENOTSUPP. Signed-off-by: Vikram Pandita <vikram.pandita@ti.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-25 21:31:07 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: Cycle HUB power when initialization fails Sometimes the USB device gets confused about the state of the initialization and the connection fails. In particular, the device thinks that it's already set up and running while the host thinks the device still needs to be configured. To work around this issue, power-cycle the hub's output to issue a sort of "reset" to the device. This makes the device restart its state machine and then the initialization succeeds. This fixes problems where the kernel reports a list of errors like this: usb 1-1.3: device not accepting address 19, error -71 The end result is a non-functioning device. After this patch, the sequence becomes like this: usb 1-1.3: new high-speed USB device number 18 using ci_hdrc usb 1-1.3: device not accepting address 18, error -71 usb 1-1.3: new high-speed USB device number 19 using ci_hdrc usb 1-1.3: device not accepting address 19, error -71 usb 1-1-port3: attempt power cycle usb 1-1.3: new high-speed USB device number 21 using ci_hdrc usb-storage 1-1.3:1.2: USB Mass Storage device detected Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-09 13:16:46 +01:00
USB: hub: Clean up use of port initialization schemes and retries The SET_CONFIG_TRIES macro in hub.c is badly named; it controls the number of port-initialization retry attempts rather than the number of Set-Configuration attempts. Furthermore, the USE_NEW_SCHEME macro and use_new_scheme() function are written in a very confusing manner, making it almost impossible to figure out exactly what they do or check that they are correct. This patch renames SET_CONFIG_TRIES to PORT_INIT_TRIES, removes USE_NEW_SCHEME entirely, and rewrites use_new_scheme() to be much more transparent, with added comments explaining how it works. The patch also pulls the single call site of use_new_scheme() out from the Get-Descriptor retry loop (where it returns the same value each time) and renames the local variable used to store the result. The overall effect is a minor cleanup. However, there is one functional change: If the "use_both_schemes" module parameter isn't set (by default it is set), the existing code does only two retry iterations. After this patch it will always perform four, regardless of the parameter's value. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200928152050.GA134701@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-28 11:20:50 -04:00
usb: hub: Cycle HUB power when initialization fails Sometimes the USB device gets confused about the state of the initialization and the connection fails. In particular, the device thinks that it's already set up and running while the host thinks the device still needs to be configured. To work around this issue, power-cycle the hub's output to issue a sort of "reset" to the device. This makes the device restart its state machine and then the initialization succeeds. This fixes problems where the kernel reports a list of errors like this: usb 1-1.3: device not accepting address 19, error -71 The end result is a non-functioning device. After this patch, the sequence becomes like this: usb 1-1.3: new high-speed USB device number 18 using ci_hdrc usb 1-1.3: device not accepting address 18, error -71 usb 1-1.3: new high-speed USB device number 19 using ci_hdrc usb 1-1.3: device not accepting address 19, error -71 usb 1-1-port3: attempt power cycle usb 1-1.3: new high-speed USB device number 21 using ci_hdrc usb-storage 1-1.3:1.2: USB Mass Storage device detected Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-09 13:16:46 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: EHCI: suppress unwanted error messages This patch (as1096) fixes an annoying problem: When a full-speed or low-speed device is plugged into an EHCI controller, it fails to enumerate at high speed and then is handed over to the companion controller. But usbcore logs a misleading and unwanted error message when the high-speed enumeration fails. The patch adds a new HCD method, port_handed_over, which asks whether a port has been handed over to a companion controller. If it has, the error message is suppressed. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: David Brownell <david-b@pacbell.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-05-20 16:58:29 -04:00
USB: avoid error messages when a device is disconnected This patch (as1673) reduces the amount of log spew from the hub driver by removing a bunch of error messages in the case where the device in question is already known to have been disconnected. Since the disconnect event itself appears in the log, there's no need for other error messages. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Jenya Y <jy.gerstmaier@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-27 16:14:01 -04:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
USB: avoid error messages when a device is disconnected This patch (as1673) reduces the amount of log spew from the hub driver by removing a bunch of error messages in the case where the device in question is already known to have been disconnected. Since the disconnect event itself appears in the log, there's no need for other error messages. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Jenya Y <jy.gerstmaier@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-27 16:14:01 -04:00
drivers: usb: core: {file,hub,sysfs,usb}.c: Whitespace fixes including: - removing of trailing whitespace - removing spaces before array indexing (foo [] to foo[]) - reindention of a switch-case block - spaces to tabs Signed-off-by: Matthias Beyer <mail@beyermatthias.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-10 23:41:27 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: Check for dropped connection before switching to full speed Some buggy USB disk adapters disconnect and reconnect multiple times during the enumeration procedure. This may lead to a device connecting at full speed instead of high speed, because when the USB stack sees that a device isn't able to enumerate at high speed, it tries to hand the connection over to a full-speed companion controller. The logic for doing this is careful to check that the device is still connected. But this check is inadequate if the device disconnects and reconnects before the check is done. The symptom is that a device works, but much more slowly than it is capable of operating. The situation was made worse recently by commit 22547c4cc4fe ("usb: hub: Wait for connection to be reestablished after port reset"), which increases the delay following a reset before a disconnect is recognized, thus giving the device more time to reconnect. This patch makes the check more robust. If the device was disconnected at any time during enumeration, we will now skip the full-speed handover. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Zdenek Kabelac <zkabelac@redhat.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-08-01 10:41:56 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: refactor port handling in hub_events() In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:15 -07:00
usb: introduce port status lock In general we do not want khubd to act on port status changes that are the result of in progress resets or USB runtime PM operations. Specifically port power control testing has been able to trigger an unintended disconnect in hub_port_connect_change(), paraphrasing: if ((portstatus & USB_PORT_STAT_CONNECTION) && udev && udev->state != USB_STATE_NOTATTACHED) { if (portstatus & USB_PORT_STAT_ENABLE) { /* Nothing to do */ } else if (udev->state == USB_STATE_SUSPENDED && udev->persist_enabled) { ... } else { /* Don't resuscitate */; } } ...by falling to the "Don't resuscitate" path or missing USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of modifying the port status. So, we want a new lock to hold off khubd for a given port while the child device is being suspended, resumed, or reset. The lock ordering rules are now usb_lock_device() => usb_lock_port(). This is mandated by the device core which may hold the device_lock on the usb_device before invoking usb_port_{suspend|resume} which in turn take the status_lock on the usb_port. We attempt to hold the status_lock for the duration of a port_event() run, and drop/re-acquire it when needing to take the device_lock. The lock is also dropped/re-acquired during hub_port_reconnect(). This patch also deletes hub->busy_bits as all use cases are now covered by port PM runtime synchronization or the port->status_lock and it pushes down usb_device_lock() into usb_remote_wakeup(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:26 -07:00
USB: Refactor hub remote wake handling. Refactor the code to check for a remote wakeup on a port into its own function. Keep the behavior the same, and set connect_change in hub_events if the device disconnected on resume. Cleanup references to hdev->children[i-1] to use a common variable. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-01-24 13:53:18 -08:00
usb: refactor port handling in hub_events() In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:15 -07:00
USB: core: Change usb_get_device_descriptor() API The usb_get_device_descriptor() routine reads the device descriptor from the udev device and stores it directly in udev->descriptor. This interface is error prone, because the USB subsystem expects in-memory copies of a device's descriptors to be immutable once the device has been initialized. The interface is changed so that the device descriptor is left in a kmalloc-ed buffer, not copied into the usb_device structure. A pointer to the buffer is returned to the caller, who is then responsible for kfree-ing it. The corresponding changes needed in the various callers are fairly small. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/d0111bb6-56c1-4f90-adf2-6cfe152f6561@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:12:21 -04:00
usb: refactor port handling in hub_events() In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:15 -07:00
USB: Refactor hub remote wake handling. Refactor the code to check for a remote wakeup on a port into its own function. Keep the behavior the same, and set connect_change in hub_events if the device disconnected on resume. Cleanup references to hdev->children[i-1] to use a common variable. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-01-24 13:53:18 -08:00
usb: refactor port handling in hub_events() In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:15 -07:00
USB/xHCI: Support device-initiated USB 3.0 resume. USB 3.0 hubs don't have a port suspend change bit (that bit is now reserved). Instead, when a host-initiated resume finishes, the hub sets the port link state change bit. When a USB 3.0 device initiates remote wakeup, the parent hubs with their upstream links in U3 will pass the LFPS up the chain. The first hub that has an upstream link in U0 (which may be the roothub) will reflect that LFPS back down the path to the device. However, the parent hubs in the resumed path will not set their link state change bit. Instead, the device that initiated the resume has to send an asynchronous "Function Wake" Device Notification up to the host controller. Therefore, we need a way to notify the USB core of a device resume without going through the normal hub URB completion method. First, make the xHCI roothub act like an external USB 3.0 hub and not pass up the port link state change bit when a device-initiated resume finishes. Introduce a new xHCI bit field, port_remote_wakeup, so that we can tell the difference between a port coming out of the U3Exit state (host-initiated resume) and the RExit state (ending state of device-initiated resume). Since the USB core can't tell whether a port on a hub has resumed by looking at the Hub Status buffer, we need to introduce a bitfield, wakeup_bits, that indicates which ports have resumed. When the xHCI driver notices a port finishing a device-initiated resume, we call into a new USB core function, usb_wakeup_notification(), that will set the right bit in wakeup_bits, and kick khubd for that hub. We also call usb_wakeup_notification() when the Function Wake Device Notification is received by the xHCI driver. This covers the case where the link between the roothub and the first-tier hub is in U0, and the hub reflects the resume signaling back to the device without giving any indication it has done so until the device sends the Function Wake notification. Change the code in khubd that handles the remote wakeup to look at the state the USB core thinks the device is in, and handle the remote wakeup if the port's wakeup bit is set. This patch only takes care of the case where the device is attached directly to the roothub, or the USB 3.0 hub that is attached to the root hub is the device sending the Function Wake Device Notification (e.g. because a new USB device was attached). The other cases will be covered in a second patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-11-14 18:00:01 -08:00
usb: refactor port handling in hub_events() In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:15 -07:00
USB: Refactor hub remote wake handling. Refactor the code to check for a remote wakeup on a port into its own function. Keep the behavior the same, and set connect_change in hub_events if the device disconnected on resume. Cleanup references to hdev->children[i-1] to use a common variable. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-01-24 13:53:18 -08:00
usb: refactor port handling in hub_events() In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:15 -07:00
usb: hub: Check device descriptor before resusciation If a device connected to an xHCI host controller disconnects from the USB bus and then reconnects, e.g. triggered by a firmware update, then the host controller automatically activates the connection and the port is enabled. The implementation of hub_port_connect_change() assumes that if the port is enabled then nothing has changed. There is no check if the USB descriptors have changed. As a result, the kernel's internal copy of the descriptors ends up being incorrect and the device doesn't work properly anymore. The solution to the problem is for hub_port_connect_change() always to check whether the device's descriptors have changed before resuscitating an enabled port. Signed-off-by: David Heinzelmann <heinzelmann.david@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20191009044647.24536-1-heinzelmann.david@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-09 06:46:47 +02:00
USB: core: Change usb_get_device_descriptor() API The usb_get_device_descriptor() routine reads the device descriptor from the udev device and stores it directly in udev->descriptor. This interface is error prone, because the USB subsystem expects in-memory copies of a device's descriptors to be immutable once the device has been initialized. The interface is changed so that the device descriptor is left in a kmalloc-ed buffer, not copied into the usb_device structure. A pointer to the buffer is returned to the caller, who is then responsible for kfree-ing it. The corresponding changes needed in the various callers are fairly small. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/d0111bb6-56c1-4f90-adf2-6cfe152f6561@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:12:21 -04:00
usb: hub: Check device descriptor before resusciation If a device connected to an xHCI host controller disconnects from the USB bus and then reconnects, e.g. triggered by a firmware update, then the host controller automatically activates the connection and the port is enabled. The implementation of hub_port_connect_change() assumes that if the port is enabled then nothing has changed. There is no check if the USB descriptors have changed. As a result, the kernel's internal copy of the descriptors ends up being incorrect and the device doesn't work properly anymore. The solution to the problem is for hub_port_connect_change() always to check whether the device's descriptors have changed before resuscitating an enabled port. Signed-off-by: David Heinzelmann <heinzelmann.david@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20191009044647.24536-1-heinzelmann.david@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-09 06:46:47 +02:00
USB: core: Change usb_get_device_descriptor() API The usb_get_device_descriptor() routine reads the device descriptor from the udev device and stores it directly in udev->descriptor. This interface is error prone, because the USB subsystem expects in-memory copies of a device's descriptors to be immutable once the device has been initialized. The interface is changed so that the device descriptor is left in a kmalloc-ed buffer, not copied into the usb_device structure. A pointer to the buffer is returned to the caller, who is then responsible for kfree-ing it. The corresponding changes needed in the various callers are fairly small. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/d0111bb6-56c1-4f90-adf2-6cfe152f6561@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:12:21 -04:00
usb: hub: Check device descriptor before resusciation If a device connected to an xHCI host controller disconnects from the USB bus and then reconnects, e.g. triggered by a firmware update, then the host controller automatically activates the connection and the port is enabled. The implementation of hub_port_connect_change() assumes that if the port is enabled then nothing has changed. There is no check if the USB descriptors have changed. As a result, the kernel's internal copy of the descriptors ends up being incorrect and the device doesn't work properly anymore. The solution to the problem is for hub_port_connect_change() always to check whether the device's descriptors have changed before resuscitating an enabled port. Signed-off-by: David Heinzelmann <heinzelmann.david@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20191009044647.24536-1-heinzelmann.david@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-09 06:46:47 +02:00
USB: core: Change usb_get_device_descriptor() API The usb_get_device_descriptor() routine reads the device descriptor from the udev device and stores it directly in udev->descriptor. This interface is error prone, because the USB subsystem expects in-memory copies of a device's descriptors to be immutable once the device has been initialized. The interface is changed so that the device descriptor is left in a kmalloc-ed buffer, not copied into the usb_device structure. A pointer to the buffer is returned to the caller, who is then responsible for kfree-ing it. The corresponding changes needed in the various callers are fairly small. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/d0111bb6-56c1-4f90-adf2-6cfe152f6561@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:12:21 -04:00
usb: hub: Check device descriptor before resusciation If a device connected to an xHCI host controller disconnects from the USB bus and then reconnects, e.g. triggered by a firmware update, then the host controller automatically activates the connection and the port is enabled. The implementation of hub_port_connect_change() assumes that if the port is enabled then nothing has changed. There is no check if the USB descriptors have changed. As a result, the kernel's internal copy of the descriptors ends up being incorrect and the device doesn't work properly anymore. The solution to the problem is for hub_port_connect_change() always to check whether the device's descriptors have changed before resuscitating an enabled port. Signed-off-by: David Heinzelmann <heinzelmann.david@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20191009044647.24536-1-heinzelmann.david@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-09 06:46:47 +02:00
USB: core: Change usb_get_device_descriptor() API The usb_get_device_descriptor() routine reads the device descriptor from the udev device and stores it directly in udev->descriptor. This interface is error prone, because the USB subsystem expects in-memory copies of a device's descriptors to be immutable once the device has been initialized. The interface is changed so that the device descriptor is left in a kmalloc-ed buffer, not copied into the usb_device structure. A pointer to the buffer is returned to the caller, who is then responsible for kfree-ing it. The corresponding changes needed in the various callers are fairly small. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/d0111bb6-56c1-4f90-adf2-6cfe152f6561@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:12:21 -04:00
usb: hub: Check device descriptor before resusciation If a device connected to an xHCI host controller disconnects from the USB bus and then reconnects, e.g. triggered by a firmware update, then the host controller automatically activates the connection and the port is enabled. The implementation of hub_port_connect_change() assumes that if the port is enabled then nothing has changed. There is no check if the USB descriptors have changed. As a result, the kernel's internal copy of the descriptors ends up being incorrect and the device doesn't work properly anymore. The solution to the problem is for hub_port_connect_change() always to check whether the device's descriptors have changed before resuscitating an enabled port. Signed-off-by: David Heinzelmann <heinzelmann.david@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20191009044647.24536-1-heinzelmann.david@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-09 06:46:47 +02:00
USB / PM: Drop CONFIG_PM_RUNTIME from the USB core 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 <rafael.j.wysocki@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-29 23:47:05 +01:00
usb: refactor port handling in hub_events() In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:15 -07:00
usb: introduce port status lock In general we do not want khubd to act on port status changes that are the result of in progress resets or USB runtime PM operations. Specifically port power control testing has been able to trigger an unintended disconnect in hub_port_connect_change(), paraphrasing: if ((portstatus & USB_PORT_STAT_CONNECTION) && udev && udev->state != USB_STATE_NOTATTACHED) { if (portstatus & USB_PORT_STAT_ENABLE) { /* Nothing to do */ } else if (udev->state == USB_STATE_SUSPENDED && udev->persist_enabled) { ... } else { /* Don't resuscitate */; } } ...by falling to the "Don't resuscitate" path or missing USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of modifying the port status. So, we want a new lock to hold off khubd for a given port while the child device is being suspended, resumed, or reset. The lock ordering rules are now usb_lock_device() => usb_lock_port(). This is mandated by the device core which may hold the device_lock on the usb_device before invoking usb_port_{suspend|resume} which in turn take the status_lock on the usb_port. We attempt to hold the status_lock for the duration of a port_event() run, and drop/re-acquire it when needing to take the device_lock. The lock is also dropped/re-acquired during hub_port_reconnect(). This patch also deletes hub->busy_bits as all use cases are now covered by port PM runtime synchronization or the port->status_lock and it pushes down usb_device_lock() into usb_remote_wakeup(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:26 -07:00
usb: refactor port handling in hub_events() In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:15 -07:00
usb: introduce port status lock In general we do not want khubd to act on port status changes that are the result of in progress resets or USB runtime PM operations. Specifically port power control testing has been able to trigger an unintended disconnect in hub_port_connect_change(), paraphrasing: if ((portstatus & USB_PORT_STAT_CONNECTION) && udev && udev->state != USB_STATE_NOTATTACHED) { if (portstatus & USB_PORT_STAT_ENABLE) { /* Nothing to do */ } else if (udev->state == USB_STATE_SUSPENDED && udev->persist_enabled) { ... } else { /* Don't resuscitate */; } } ...by falling to the "Don't resuscitate" path or missing USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of modifying the port status. So, we want a new lock to hold off khubd for a given port while the child device is being suspended, resumed, or reset. The lock ordering rules are now usb_lock_device() => usb_lock_port(). This is mandated by the device core which may hold the device_lock on the usb_device before invoking usb_port_{suspend|resume} which in turn take the status_lock on the usb_port. We attempt to hold the status_lock for the duration of a port_event() run, and drop/re-acquire it when needing to take the device_lock. The lock is also dropped/re-acquired during hub_port_reconnect(). This patch also deletes hub->busy_bits as all use cases are now covered by port PM runtime synchronization or the port->status_lock and it pushes down usb_device_lock() into usb_remote_wakeup(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:26 -07:00
usb: refactor port handling in hub_events() In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:15 -07:00
USB: Refactor hub remote wake handling. Refactor the code to check for a remote wakeup on a port into its own function. Keep the behavior the same, and set connect_change in hub_events if the device disconnected on resume. Cleanup references to hdev->children[i-1] to use a common variable. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-01-24 13:53:18 -08:00
usb: refactor port handling in hub_events() In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:15 -07:00
usb: introduce port status lock In general we do not want khubd to act on port status changes that are the result of in progress resets or USB runtime PM operations. Specifically port power control testing has been able to trigger an unintended disconnect in hub_port_connect_change(), paraphrasing: if ((portstatus & USB_PORT_STAT_CONNECTION) && udev && udev->state != USB_STATE_NOTATTACHED) { if (portstatus & USB_PORT_STAT_ENABLE) { /* Nothing to do */ } else if (udev->state == USB_STATE_SUSPENDED && udev->persist_enabled) { ... } else { /* Don't resuscitate */; } } ...by falling to the "Don't resuscitate" path or missing USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of modifying the port status. So, we want a new lock to hold off khubd for a given port while the child device is being suspended, resumed, or reset. The lock ordering rules are now usb_lock_device() => usb_lock_port(). This is mandated by the device core which may hold the device_lock on the usb_device before invoking usb_port_{suspend|resume} which in turn take the status_lock on the usb_port. We attempt to hold the status_lock for the duration of a port_event() run, and drop/re-acquire it when needing to take the device_lock. The lock is also dropped/re-acquired during hub_port_reconnect(). This patch also deletes hub->busy_bits as all use cases are now covered by port PM runtime synchronization or the port->status_lock and it pushes down usb_device_lock() into usb_remote_wakeup(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:26 -07:00
usb: refactor port handling in hub_events() In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:15 -07:00
usb: introduce port status lock In general we do not want khubd to act on port status changes that are the result of in progress resets or USB runtime PM operations. Specifically port power control testing has been able to trigger an unintended disconnect in hub_port_connect_change(), paraphrasing: if ((portstatus & USB_PORT_STAT_CONNECTION) && udev && udev->state != USB_STATE_NOTATTACHED) { if (portstatus & USB_PORT_STAT_ENABLE) { /* Nothing to do */ } else if (udev->state == USB_STATE_SUSPENDED && udev->persist_enabled) { ... } else { /* Don't resuscitate */; } } ...by falling to the "Don't resuscitate" path or missing USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of modifying the port status. So, we want a new lock to hold off khubd for a given port while the child device is being suspended, resumed, or reset. The lock ordering rules are now usb_lock_device() => usb_lock_port(). This is mandated by the device core which may hold the device_lock on the usb_device before invoking usb_port_{suspend|resume} which in turn take the status_lock on the usb_port. We attempt to hold the status_lock for the duration of a port_event() run, and drop/re-acquire it when needing to take the device_lock. The lock is also dropped/re-acquired during hub_port_reconnect(). This patch also deletes hub->busy_bits as all use cases are now covered by port PM runtime synchronization or the port->status_lock and it pushes down usb_device_lock() into usb_remote_wakeup(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:26 -07:00
usb: refactor port handling in hub_events() In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:15 -07:00
usb: introduce port status lock In general we do not want khubd to act on port status changes that are the result of in progress resets or USB runtime PM operations. Specifically port power control testing has been able to trigger an unintended disconnect in hub_port_connect_change(), paraphrasing: if ((portstatus & USB_PORT_STAT_CONNECTION) && udev && udev->state != USB_STATE_NOTATTACHED) { if (portstatus & USB_PORT_STAT_ENABLE) { /* Nothing to do */ } else if (udev->state == USB_STATE_SUSPENDED && udev->persist_enabled) { ... } else { /* Don't resuscitate */; } } ...by falling to the "Don't resuscitate" path or missing USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of modifying the port status. So, we want a new lock to hold off khubd for a given port while the child device is being suspended, resumed, or reset. The lock ordering rules are now usb_lock_device() => usb_lock_port(). This is mandated by the device core which may hold the device_lock on the usb_device before invoking usb_port_{suspend|resume} which in turn take the status_lock on the usb_port. We attempt to hold the status_lock for the duration of a port_event() run, and drop/re-acquire it when needing to take the device_lock. The lock is also dropped/re-acquired during hub_port_reconnect(). This patch also deletes hub->busy_bits as all use cases are now covered by port PM runtime synchronization or the port->status_lock and it pushes down usb_device_lock() into usb_remote_wakeup(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:26 -07:00
USB: Refactor hub remote wake handling. Refactor the code to check for a remote wakeup on a port into its own function. Keep the behavior the same, and set connect_change in hub_events if the device disconnected on resume. Cleanup references to hdev->children[i-1] to use a common variable. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-01-24 13:53:18 -08:00
usb: core: added uevent for over-current After commit 1cbd53c8cd85 ("usb: core: introduce per-port over-current counters") usb ports expose a sysfs value 'over_current_count' to user space. This value on its own is not very useful as it requires manual polling. As a solution, fire a udev event from the usb hub device that specifies the values 'OVER_CURRENT_PORT' and 'OVER_CURRENT_COUNT' that indicate the path of the usb port where the over-current event occurred and the value of 'over_current_count' in sysfs. Additionally, call sysfs_notify() so the sysfs value supports poll(). Signed-off-by: Jon Flatley <jflat@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-20 10:17:54 -07:00
usb: hub: Simplify error and success path in port_over_current_notify kasprintf() returns NULL or valid pointer. Since kfree() can handle NULL pointer condition, simplify error and success paths in function port_over_current_notify() by removing multiple error path labels. Signed-off-by: Bhuvanesh Surachari <Bhuvanesh_Surachari@mentor.com> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Link: https://lore.kernel.org/r/1652369834-4480-1-git-send-email-erosca@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12 17:37:14 +02:00
usb: core: added uevent for over-current After commit 1cbd53c8cd85 ("usb: core: introduce per-port over-current counters") usb ports expose a sysfs value 'over_current_count' to user space. This value on its own is not very useful as it requires manual polling. As a solution, fire a udev event from the usb hub device that specifies the values 'OVER_CURRENT_PORT' and 'OVER_CURRENT_COUNT' that indicate the path of the usb port where the over-current event occurred and the value of 'over_current_count' in sysfs. Additionally, call sysfs_notify() so the sysfs value supports poll(). Signed-off-by: Jon Flatley <jflat@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-20 10:17:54 -07:00
usb: hub: Simplify error and success path in port_over_current_notify kasprintf() returns NULL or valid pointer. Since kfree() can handle NULL pointer condition, simplify error and success paths in function port_over_current_notify() by removing multiple error path labels. Signed-off-by: Bhuvanesh Surachari <Bhuvanesh_Surachari@mentor.com> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Link: https://lore.kernel.org/r/1652369834-4480-1-git-send-email-erosca@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12 17:37:14 +02:00
usb: core: added uevent for over-current After commit 1cbd53c8cd85 ("usb: core: introduce per-port over-current counters") usb ports expose a sysfs value 'over_current_count' to user space. This value on its own is not very useful as it requires manual polling. As a solution, fire a udev event from the usb hub device that specifies the values 'OVER_CURRENT_PORT' and 'OVER_CURRENT_COUNT' that indicate the path of the usb port where the over-current event occurred and the value of 'over_current_count' in sysfs. Additionally, call sysfs_notify() so the sysfs value supports poll(). Signed-off-by: Jon Flatley <jflat@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-20 10:17:54 -07:00
usb: hub: Simplify error and success path in port_over_current_notify kasprintf() returns NULL or valid pointer. Since kfree() can handle NULL pointer condition, simplify error and success paths in function port_over_current_notify() by removing multiple error path labels. Signed-off-by: Bhuvanesh Surachari <Bhuvanesh_Surachari@mentor.com> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Link: https://lore.kernel.org/r/1652369834-4480-1-git-send-email-erosca@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-12 17:37:14 +02:00
usb: core: added uevent for over-current After commit 1cbd53c8cd85 ("usb: core: introduce per-port over-current counters") usb ports expose a sysfs value 'over_current_count' to user space. This value on its own is not very useful as it requires manual polling. As a solution, fire a udev event from the usb hub device that specifies the values 'OVER_CURRENT_PORT' and 'OVER_CURRENT_COUNT' that indicate the path of the usb port where the over-current event occurred and the value of 'over_current_count' in sysfs. Additionally, call sysfs_notify() so the sysfs value supports poll(). Signed-off-by: Jon Flatley <jflat@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-20 10:17:54 -07:00
usb: core: fix memory leak on port_dev_path allocation Currently the allocation of port_dev_path from the call to kobject_get_path is not being kfree'd, causing a memory leak. Fix this by kfree'ing this at the end of the function. Add an extra error exit path to fix one of the early leaks when envp[0] fails to be allocated. Detected by CoverityScan, CID#1473771 ("Resource Leak") Fixes: 201af55da8a3 ("usb: core: added uevent for over-current") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-10-03 10:59:57 +01:00
usb: core: added uevent for over-current After commit 1cbd53c8cd85 ("usb: core: introduce per-port over-current counters") usb ports expose a sysfs value 'over_current_count' to user space. This value on its own is not very useful as it requires manual polling. As a solution, fire a udev event from the usb hub device that specifies the values 'OVER_CURRENT_PORT' and 'OVER_CURRENT_COUNT' that indicate the path of the usb port where the over-current event occurred and the value of 'over_current_count' in sysfs. Additionally, call sysfs_notify() so the sysfs value supports poll(). Signed-off-by: Jon Flatley <jflat@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-20 10:17:54 -07:00
usb: refactor port handling in hub_events() In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:15 -07:00
usb: introduce port status lock In general we do not want khubd to act on port status changes that are the result of in progress resets or USB runtime PM operations. Specifically port power control testing has been able to trigger an unintended disconnect in hub_port_connect_change(), paraphrasing: if ((portstatus & USB_PORT_STAT_CONNECTION) && udev && udev->state != USB_STATE_NOTATTACHED) { if (portstatus & USB_PORT_STAT_ENABLE) { /* Nothing to do */ } else if (udev->state == USB_STATE_SUSPENDED && udev->persist_enabled) { ... } else { /* Don't resuscitate */; } } ...by falling to the "Don't resuscitate" path or missing USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of modifying the port status. So, we want a new lock to hold off khubd for a given port while the child device is being suspended, resumed, or reset. The lock ordering rules are now usb_lock_device() => usb_lock_port(). This is mandated by the device core which may hold the device_lock on the usb_device before invoking usb_port_{suspend|resume} which in turn take the status_lock on the usb_port. We attempt to hold the status_lock for the duration of a port_event() run, and drop/re-acquire it when needing to take the device_lock. The lock is also dropped/re-acquired during hub_port_reconnect(). This patch also deletes hub->busy_bits as all use cases are now covered by port PM runtime synchronization or the port->status_lock and it pushes down usb_device_lock() into usb_remote_wakeup(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:26 -07:00
usb: refactor port handling in hub_events() In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:15 -07:00
Revert "usb: Reset USB-3 devices on USB-3 link bounce" This revert a82b76f7fa6154e8ab2d8071842a3e38b9c0d0ff. The commit causes an extra reset in remote wakeup as described in: http://www.spinics.net/lists/linux-usb/msg119080.html Signed-off-by: Zhuang Jin Can <jin.can.zhuang@intel.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-01-26 23:30:39 +08:00
usb: refactor port handling in hub_events() In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:15 -07:00
usb: hub: avoid warm port reset during USB3 disconnect During disconnect USB-3 ports often go via SS.Inactive link error state before the missing terminations are noticed, and link finally goes to RxDetect state Avoid immediately warm-resetting ports in SS.Inactive state. Let ports settle for a while and re-read the link status a few times 20ms apart to see if the ports transitions out of SS.Inactive. According to USB 3.x spec 7.5.2, a port in SS.Inactive should automatically check for missing far-end receiver termination every 12 ms (SSInactiveQuietTimeout) The futile multiple warm reset retries of a disconnected device takes a lot of time, also the resetting of a removed devices has caused cases where the reset bit got stuck for a long time on xHCI roothub. This lead to issues in detecting new devices connected to the same port shortly after. Tested-by: Mark Pearson <markpearson@lenovo.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211210111653.1378381-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-10 13:16:53 +02:00
usb: refactor port handling in hub_events() In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:15 -07:00
usb: hub: port: add sysfs entry to switch port power In some cases the port of an hub needs to be disabled or switched off and on again. E.g. when the connected device needs to be re-enumerated. Or it needs to be explicitly disabled while the rest of the usb tree stays working. For this purpose this patch adds an sysfs switch to enable/disable the port on any hub. In the case the hub is supporting power switching, the power line will be disabled to the connected device. When the port gets disabled, the associated device gets disconnected and removed from the logical usb tree. No further device will be enumerated on that port until the port gets enabled again. Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220607114522.3359148-1-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-07 13:45:22 +02:00
usb: refactor port handling in hub_events() In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:15 -07:00
usb: core: introduce per-port over-current counters For some userspace applications information on the number of over-current conditions at specific USB hub ports is relevant. In our case we have a series of USB hardware (using the cp210x driver) which communicates using a proprietary protocol. These devices sometimes trigger an over-current situation on some hubs. In case of such an over-current situation the USB devices offer an interface for reducing the max used power. As these conditions are quite rare and imply performance reductions of the device we don't want to reduce the max power always. Therefore give user-space applications the possibility to react adequately by introducing an over_current_counter in the usb port struct which is exported via sysfs. Signed-off-by: Richard Leitner <richard.leitner@skidata.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-03-20 11:17:13 +01:00
usb: core: added uevent for over-current After commit 1cbd53c8cd85 ("usb: core: introduce per-port over-current counters") usb ports expose a sysfs value 'over_current_count' to user space. This value on its own is not very useful as it requires manual polling. As a solution, fire a udev event from the usb hub device that specifies the values 'OVER_CURRENT_PORT' and 'OVER_CURRENT_COUNT' that indicate the path of the usb port where the over-current event occurred and the value of 'over_current_count' in sysfs. Additionally, call sysfs_notify() so the sysfs value supports poll(). Signed-off-by: Jon Flatley <jflat@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-20 10:17:54 -07:00
usb: refactor port handling in hub_events() In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:15 -07:00
usb: core: introduce per-port over-current counters For some userspace applications information on the number of over-current conditions at specific USB hub ports is relevant. In our case we have a series of USB hardware (using the cp210x driver) which communicates using a proprietary protocol. These devices sometimes trigger an over-current situation on some hubs. In case of such an over-current situation the USB devices offer an interface for reducing the max used power. As these conditions are quite rare and imply performance reductions of the device we don't want to reduce the max power always. Therefore give user-space applications the possibility to react adequately by introducing an over_current_counter in the usb port struct which is exported via sysfs. Signed-off-by: Richard Leitner <richard.leitner@skidata.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-03-20 11:17:13 +01:00
usb: refactor port handling in hub_events() In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:15 -07:00
usb: hub: port: add sysfs entry to switch port power In some cases the port of an hub needs to be disabled or switched off and on again. E.g. when the connected device needs to be re-enumerated. Or it needs to be explicitly disabled while the rest of the usb tree stays working. For this purpose this patch adds an sysfs switch to enable/disable the port on any hub. In the case the hub is supporting power switching, the power line will be disabled to the connected device. When the port gets disabled, the associated device gets disconnected and removed from the logical usb tree. No further device will be enumerated on that port until the port gets enabled again. Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220607114522.3359148-1-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-07 13:45:22 +02:00
usb: refactor port handling in hub_events() In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:15 -07:00
usb: synchronize port poweroff and khubd If a port is powered-off, or in the process of being powered-off, prevent khubd from operating on it. Otherwise, the following sequence of events leading to an unintended disconnect may occur: Events: (0) <set pm_qos_no_poweroff to '0' for port1> (1) hub 2-2:1.0: hub_resume (2) hub 2-2:1.0: port 1: status 0301 change 0000 (3) hub 2-2:1.0: state 7 ports 4 chg 0002 evt 0000 (4) hub 2-2:1.0: port 1, power off status 0000, change 0000, 12 Mb/s (5) usb 2-2.1: USB disconnect, device number 5 Description: (1) hub is resumed before sending a ClearPortFeature request (2) hub_activate() notices the port is connected and sets hub->change_bits for the port (3) hub_events() starts, but at the same time the port suspends (4) hub_connect_change() sees the disabled port and triggers disconnect Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:20 -07:00
usb: core: stop USB enumeration if too many retries When a broken USB accessory connects to a USB host, usbcore might keep doing enumeration retries. If the host has a watchdog mechanism, the kernel panic will happen on the host. This patch provides an attribute early_stop to limit the numbers of retries for each port of a hub. If a port was marked with early_stop attribute, unsuccessful connection attempts will fail quickly. In addition, if an early_stop port has failed to initialize, it will ignore all future connection events until early_stop attribute is clear. Signed-off-by: Ray Chi <raychi@google.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20221107072754.3336357-1-raychi@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-11-07 15:27:54 +08:00
usb: refactor port handling in hub_events() In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:15 -07:00
usb: hub: avoid warm port reset during USB3 disconnect During disconnect USB-3 ports often go via SS.Inactive link error state before the missing terminations are noticed, and link finally goes to RxDetect state Avoid immediately warm-resetting ports in SS.Inactive state. Let ports settle for a while and re-read the link status a few times 20ms apart to see if the ports transitions out of SS.Inactive. According to USB 3.x spec 7.5.2, a port in SS.Inactive should automatically check for missing far-end receiver termination every 12 ms (SSInactiveQuietTimeout) The futile multiple warm reset retries of a disconnected device takes a lot of time, also the resetting of a removed devices has caused cases where the reset bit got stuck for a long time on xHCI roothub. This lead to issues in detecting new devices connected to the same port shortly after. Tested-by: Mark Pearson <markpearson@lenovo.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211210111653.1378381-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-10 13:16:53 +02:00
usb: refactor port handling in hub_events() In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:15 -07:00
usb: hub: avoid warm port reset during USB3 disconnect During disconnect USB-3 ports often go via SS.Inactive link error state before the missing terminations are noticed, and link finally goes to RxDetect state Avoid immediately warm-resetting ports in SS.Inactive state. Let ports settle for a while and re-read the link status a few times 20ms apart to see if the ports transitions out of SS.Inactive. According to USB 3.x spec 7.5.2, a port in SS.Inactive should automatically check for missing far-end receiver termination every 12 ms (SSInactiveQuietTimeout) The futile multiple warm reset retries of a disconnected device takes a lot of time, also the resetting of a removed devices has caused cases where the reset bit got stuck for a long time on xHCI roothub. This lead to issues in detecting new devices connected to the same port shortly after. Tested-by: Mark Pearson <markpearson@lenovo.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211210111653.1378381-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-10 13:16:53 +02:00
usb: hub: port: add sysfs entry to switch port power In some cases the port of an hub needs to be disabled or switched off and on again. E.g. when the connected device needs to be re-enumerated. Or it needs to be explicitly disabled while the rest of the usb tree stays working. For this purpose this patch adds an sysfs switch to enable/disable the port on any hub. In the case the hub is supporting power switching, the power line will be disabled to the connected device. When the port gets disabled, the associated device gets disconnected and removed from the logical usb tree. No further device will be enumerated on that port until the port gets enabled again. Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20220607114522.3359148-1-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-07 13:45:22 +02:00
usb: hub: avoid warm port reset during USB3 disconnect During disconnect USB-3 ports often go via SS.Inactive link error state before the missing terminations are noticed, and link finally goes to RxDetect state Avoid immediately warm-resetting ports in SS.Inactive state. Let ports settle for a while and re-read the link status a few times 20ms apart to see if the ports transitions out of SS.Inactive. According to USB 3.x spec 7.5.2, a port in SS.Inactive should automatically check for missing far-end receiver termination every 12 ms (SSInactiveQuietTimeout) The futile multiple warm reset retries of a disconnected device takes a lot of time, also the resetting of a removed devices has caused cases where the reset bit got stuck for a long time on xHCI roothub. This lead to issues in detecting new devices connected to the same port shortly after. Tested-by: Mark Pearson <markpearson@lenovo.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211210111653.1378381-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-10 13:16:53 +02:00
usb: refactor port handling in hub_events() In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:15 -07:00
usb: hub: avoid warm port reset during USB3 disconnect During disconnect USB-3 ports often go via SS.Inactive link error state before the missing terminations are noticed, and link finally goes to RxDetect state Avoid immediately warm-resetting ports in SS.Inactive state. Let ports settle for a while and re-read the link status a few times 20ms apart to see if the ports transitions out of SS.Inactive. According to USB 3.x spec 7.5.2, a port in SS.Inactive should automatically check for missing far-end receiver termination every 12 ms (SSInactiveQuietTimeout) The futile multiple warm reset retries of a disconnected device takes a lot of time, also the resetting of a removed devices has caused cases where the reset bit got stuck for a long time on xHCI roothub. This lead to issues in detecting new devices connected to the same port shortly after. Tested-by: Mark Pearson <markpearson@lenovo.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211210111653.1378381-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-10 13:16:53 +02:00
usb: refactor port handling in hub_events() In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:15 -07:00
Revert "usb: Reset USB-3 devices on USB-3 link bounce" This revert a82b76f7fa6154e8ab2d8071842a3e38b9c0d0ff. The commit causes an extra reset in remote wakeup as described in: http://www.spinics.net/lists/linux-usb/msg119080.html Signed-off-by: Zhuang Jin Can <jin.can.zhuang@intel.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-01-26 23:30:39 +08:00
usb: hub: avoid warm port reset during USB3 disconnect During disconnect USB-3 ports often go via SS.Inactive link error state before the missing terminations are noticed, and link finally goes to RxDetect state Avoid immediately warm-resetting ports in SS.Inactive state. Let ports settle for a while and re-read the link status a few times 20ms apart to see if the ports transitions out of SS.Inactive. According to USB 3.x spec 7.5.2, a port in SS.Inactive should automatically check for missing far-end receiver termination every 12 ms (SSInactiveQuietTimeout) The futile multiple warm reset retries of a disconnected device takes a lot of time, also the resetting of a removed devices has caused cases where the reset bit got stuck for a long time on xHCI roothub. This lead to issues in detecting new devices connected to the same port shortly after. Tested-by: Mark Pearson <markpearson@lenovo.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211210111653.1378381-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-10 13:16:53 +02:00
Revert "usb: Reset USB-3 devices on USB-3 link bounce" This revert a82b76f7fa6154e8ab2d8071842a3e38b9c0d0ff. The commit causes an extra reset in remote wakeup as described in: http://www.spinics.net/lists/linux-usb/msg119080.html Signed-off-by: Zhuang Jin Can <jin.can.zhuang@intel.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-01-26 23:30:39 +08:00
usb: hub: avoid warm port reset during USB3 disconnect During disconnect USB-3 ports often go via SS.Inactive link error state before the missing terminations are noticed, and link finally goes to RxDetect state Avoid immediately warm-resetting ports in SS.Inactive state. Let ports settle for a while and re-read the link status a few times 20ms apart to see if the ports transitions out of SS.Inactive. According to USB 3.x spec 7.5.2, a port in SS.Inactive should automatically check for missing far-end receiver termination every 12 ms (SSInactiveQuietTimeout) The futile multiple warm reset retries of a disconnected device takes a lot of time, also the resetting of a removed devices has caused cases where the reset bit got stuck for a long time on xHCI roothub. This lead to issues in detecting new devices connected to the same port shortly after. Tested-by: Mark Pearson <markpearson@lenovo.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211210111653.1378381-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-10 13:16:53 +02:00
usb: refactor port handling in hub_events() In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:15 -07:00
usb: hub: convert khubd into workqueue There is no need to have separate kthread for handling USB hub events. It is more elegant to use the workqueue framework. The workqueue is allocated as freezable because the original thread was freezable as well. Also it is allocated as ordered because the code is not ready for parallel processing of hub events, see choose_devnum(). struct usb_hub is passed via the work item. Therefore we do not need hub_event_list. Also hub_thread() is not longer needed. It would call only hub_event(). The rest of the code did manipulate the kthread and it is handled by the workqueue framework now. kick_khubd is renamed to kick_hub_wq() to make the function clear. And the protection against races is done another way, see below. hub_event_lock has been removed. It cannot longer be used to protect struct usb_hub between hub_event() and hub_disconnect(). Instead we need to get hub->kref already in kick_hub_wq(). The lock is not really needed for the other scenarios as well. queue_work() returns whether it succeeded. We could revert the needed operations accordingly. This is enough to avoid duplicity and inconsistencies. Yes, the removed lock causes that there is not longer such a strong synchronization between scheduling the work and manipulating hub->disconnected. But kick_hub_wq() must never be called together with hub_disconnect() otherwise even the original code would have failed. Any callers are responsible for this. Therefore the only problem is that hub_disconnect() could be called in parallel with hub_event(). But this was possible even in the past. struct usb_hub is still guarded by hub->kref and released in hub_events() when needed. Note that the source file is still full of the obsolete "khubd" strings. Let's remove them in a follow up patch. This patch already is complex enough. Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to allocate the workqueue. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:21 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: convert khubd into workqueue There is no need to have separate kthread for handling USB hub events. It is more elegant to use the workqueue framework. The workqueue is allocated as freezable because the original thread was freezable as well. Also it is allocated as ordered because the code is not ready for parallel processing of hub events, see choose_devnum(). struct usb_hub is passed via the work item. Therefore we do not need hub_event_list. Also hub_thread() is not longer needed. It would call only hub_event(). The rest of the code did manipulate the kthread and it is handled by the workqueue framework now. kick_khubd is renamed to kick_hub_wq() to make the function clear. And the protection against races is done another way, see below. hub_event_lock has been removed. It cannot longer be used to protect struct usb_hub between hub_event() and hub_disconnect(). Instead we need to get hub->kref already in kick_hub_wq(). The lock is not really needed for the other scenarios as well. queue_work() returns whether it succeeded. We could revert the needed operations accordingly. This is enough to avoid duplicity and inconsistencies. Yes, the removed lock causes that there is not longer such a strong synchronization between scheduling the work and manipulating hub->disconnected. But kick_hub_wq() must never be called together with hub_disconnect() otherwise even the original code would have failed. Any callers are responsible for this. Therefore the only problem is that hub_disconnect() could be called in parallel with hub_event(). But this was possible even in the past. struct usb_hub is still guarded by hub->kref and released in hub_events() when needed. Note that the source file is still full of the obsolete "khubd" strings. Let's remove them in a follow up patch. This patch already is complex enough. Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to allocate the workqueue. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:21 +02:00
usb: hub: rename hub_events() to hub_event() and handle only one event there We would like to convert khubd kthread to a workqueue. As a result hub_events() will handle only one event per call. In fact, we could do this already now because there is another cycle in hub_thread(). It calls hub_events() until hub_event_list is empty. This patch renames the function to hub_event(), removes the while cycle, and renames the goto targets from loop* to out*. When touching the code, it fixes also formatting of dev_err() and dev_dbg() calls to make checkpatch.pl happy :-) Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:20 +02:00
usb: hub: convert khubd into workqueue There is no need to have separate kthread for handling USB hub events. It is more elegant to use the workqueue framework. The workqueue is allocated as freezable because the original thread was freezable as well. Also it is allocated as ordered because the code is not ready for parallel processing of hub events, see choose_devnum(). struct usb_hub is passed via the work item. Therefore we do not need hub_event_list. Also hub_thread() is not longer needed. It would call only hub_event(). The rest of the code did manipulate the kthread and it is handled by the workqueue framework now. kick_khubd is renamed to kick_hub_wq() to make the function clear. And the protection against races is done another way, see below. hub_event_lock has been removed. It cannot longer be used to protect struct usb_hub between hub_event() and hub_disconnect(). Instead we need to get hub->kref already in kick_hub_wq(). The lock is not really needed for the other scenarios as well. queue_work() returns whether it succeeded. We could revert the needed operations accordingly. This is enough to avoid duplicity and inconsistencies. Yes, the removed lock causes that there is not longer such a strong synchronization between scheduling the work and manipulating hub->disconnected. But kick_hub_wq() must never be called together with hub_disconnect() otherwise even the original code would have failed. Any callers are responsible for this. Therefore the only problem is that hub_disconnect() could be called in parallel with hub_event(). But this was possible even in the past. struct usb_hub is still guarded by hub->kref and released in hub_events() when needed. Note that the source file is still full of the obsolete "khubd" strings. Let's remove them in a follow up patch. This patch already is complex enough. Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to allocate the workqueue. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:21 +02:00
usb, kcov: collect coverage from hub_event Add kcov_remote_start()/kcov_remote_stop() annotations to the hub_event() function, which is responsible for processing events on USB buses, in particular events that happen during USB device enumeration. Since hub_event() is run in a global background kernel thread (see Documentation/dev-tools/kcov.rst for details), each USB bus gets a unique global handle from the USB subsystem kcov handle range. As the result kcov can now be used to collect coverage from events that happen on a particular USB bus. [akpm@linux-foundation.org: avoid patch conflicts to make life easier for Andrew] Link: http://lkml.kernel.org/r/de4fe1c219db2d002d905dc1736e2a3bfa1db997.1572366574.git.andreyknvl@google.com Signed-off-by: Andrey Konovalov <andreyknvl@google.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Alexander Potapenko <glider@google.com> Cc: Anders Roxell <anders.roxell@linaro.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: David Windsor <dwindsor@gmail.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Elena Reshetova <elena.reshetova@intel.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Marco Elver <elver@google.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-12-04 16:52:47 -08:00
usb: hub: rename hub_events() to hub_event() and handle only one event there We would like to convert khubd kthread to a workqueue. As a result hub_events() will handle only one event per call. In fact, we could do this already now because there is another cycle in hub_thread(). It calls hub_events() until hub_event_list is empty. This patch renames the function to hub_event(), removes the while cycle, and renames the goto targets from loop* to out*. When touching the code, it fixes also formatting of dev_err() and dev_dbg() calls to make checkpatch.pl happy :-) Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:20 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: rename hub_events() to hub_event() and handle only one event there We would like to convert khubd kthread to a workqueue. As a result hub_events() will handle only one event per call. In fact, we could do this already now because there is another cycle in hub_thread(). It calls hub_events() until hub_event_list is empty. This patch renames the function to hub_event(), removes the while cycle, and renames the goto targets from loop* to out*. When touching the code, it fixes also formatting of dev_err() and dev_dbg() calls to make checkpatch.pl happy :-) Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:20 +02:00
usb: hub: convert khubd into workqueue There is no need to have separate kthread for handling USB hub events. It is more elegant to use the workqueue framework. The workqueue is allocated as freezable because the original thread was freezable as well. Also it is allocated as ordered because the code is not ready for parallel processing of hub events, see choose_devnum(). struct usb_hub is passed via the work item. Therefore we do not need hub_event_list. Also hub_thread() is not longer needed. It would call only hub_event(). The rest of the code did manipulate the kthread and it is handled by the workqueue framework now. kick_khubd is renamed to kick_hub_wq() to make the function clear. And the protection against races is done another way, see below. hub_event_lock has been removed. It cannot longer be used to protect struct usb_hub between hub_event() and hub_disconnect(). Instead we need to get hub->kref already in kick_hub_wq(). The lock is not really needed for the other scenarios as well. queue_work() returns whether it succeeded. We could revert the needed operations accordingly. This is enough to avoid duplicity and inconsistencies. Yes, the removed lock causes that there is not longer such a strong synchronization between scheduling the work and manipulating hub->disconnected. But kick_hub_wq() must never be called together with hub_disconnect() otherwise even the original code would have failed. Any callers are responsible for this. Therefore the only problem is that hub_disconnect() could be called in parallel with hub_event(). But this was possible even in the past. struct usb_hub is still guarded by hub->kref and released in hub_events() when needed. Note that the source file is still full of the obsolete "khubd" strings. Let's remove them in a follow up patch. This patch already is complex enough. Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to allocate the workqueue. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:21 +02:00
usb: hub: rename hub_events() to hub_event() and handle only one event there We would like to convert khubd kthread to a workqueue. As a result hub_events() will handle only one event per call. In fact, we could do this already now because there is another cycle in hub_thread(). It calls hub_events() until hub_event_list is empty. This patch renames the function to hub_event(), removes the while cycle, and renames the goto targets from loop* to out*. When touching the code, it fixes also formatting of dev_err() and dev_dbg() calls to make checkpatch.pl happy :-) Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:20 +02:00
usb: hub: convert khubd into workqueue There is no need to have separate kthread for handling USB hub events. It is more elegant to use the workqueue framework. The workqueue is allocated as freezable because the original thread was freezable as well. Also it is allocated as ordered because the code is not ready for parallel processing of hub events, see choose_devnum(). struct usb_hub is passed via the work item. Therefore we do not need hub_event_list. Also hub_thread() is not longer needed. It would call only hub_event(). The rest of the code did manipulate the kthread and it is handled by the workqueue framework now. kick_khubd is renamed to kick_hub_wq() to make the function clear. And the protection against races is done another way, see below. hub_event_lock has been removed. It cannot longer be used to protect struct usb_hub between hub_event() and hub_disconnect(). Instead we need to get hub->kref already in kick_hub_wq(). The lock is not really needed for the other scenarios as well. queue_work() returns whether it succeeded. We could revert the needed operations accordingly. This is enough to avoid duplicity and inconsistencies. Yes, the removed lock causes that there is not longer such a strong synchronization between scheduling the work and manipulating hub->disconnected. But kick_hub_wq() must never be called together with hub_disconnect() otherwise even the original code would have failed. Any callers are responsible for this. Therefore the only problem is that hub_disconnect() could be called in parallel with hub_event(). But this was possible even in the past. struct usb_hub is still guarded by hub->kref and released in hub_events() when needed. Note that the source file is still full of the obsolete "khubd" strings. Let's remove them in a follow up patch. This patch already is complex enough. Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to allocate the workqueue. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:21 +02:00
usb: hub: rename hub_events() to hub_event() and handle only one event there We would like to convert khubd kthread to a workqueue. As a result hub_events() will handle only one event per call. In fact, we could do this already now because there is another cycle in hub_thread(). It calls hub_events() until hub_event_list is empty. This patch renames the function to hub_event(), removes the while cycle, and renames the goto targets from loop* to out*. When touching the code, it fixes also formatting of dev_err() and dev_dbg() calls to make checkpatch.pl happy :-) Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:20 +02:00
usb: hub: convert khubd into workqueue There is no need to have separate kthread for handling USB hub events. It is more elegant to use the workqueue framework. The workqueue is allocated as freezable because the original thread was freezable as well. Also it is allocated as ordered because the code is not ready for parallel processing of hub events, see choose_devnum(). struct usb_hub is passed via the work item. Therefore we do not need hub_event_list. Also hub_thread() is not longer needed. It would call only hub_event(). The rest of the code did manipulate the kthread and it is handled by the workqueue framework now. kick_khubd is renamed to kick_hub_wq() to make the function clear. And the protection against races is done another way, see below. hub_event_lock has been removed. It cannot longer be used to protect struct usb_hub between hub_event() and hub_disconnect(). Instead we need to get hub->kref already in kick_hub_wq(). The lock is not really needed for the other scenarios as well. queue_work() returns whether it succeeded. We could revert the needed operations accordingly. This is enough to avoid duplicity and inconsistencies. Yes, the removed lock causes that there is not longer such a strong synchronization between scheduling the work and manipulating hub->disconnected. But kick_hub_wq() must never be called together with hub_disconnect() otherwise even the original code would have failed. Any callers are responsible for this. Therefore the only problem is that hub_disconnect() could be called in parallel with hub_event(). But this was possible even in the past. struct usb_hub is still guarded by hub->kref and released in hub_events() when needed. Note that the source file is still full of the obsolete "khubd" strings. Let's remove them in a follow up patch. This patch already is complex enough. Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to allocate the workqueue. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:21 +02:00
usb: hub: rename hub_events() to hub_event() and handle only one event there We would like to convert khubd kthread to a workqueue. As a result hub_events() will handle only one event per call. In fact, we could do this already now because there is another cycle in hub_thread(). It calls hub_events() until hub_event_list is empty. This patch renames the function to hub_event(), removes the while cycle, and renames the goto targets from loop* to out*. When touching the code, it fixes also formatting of dev_err() and dev_dbg() calls to make checkpatch.pl happy :-) Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:20 +02:00
USB: Add autosuspend support to the hub driver This patch (as742b) adds autosuspend/autoresume support to the USB hub driver. The largest aspect of the change is that we no longer need a special flag for root hubs that want to be resumed. Now every hub is autoresumed whenever khubd needs to access it. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-11-09 14:44:33 -05:00
usb: hub: rename hub_events() to hub_event() and handle only one event there We would like to convert khubd kthread to a workqueue. As a result hub_events() will handle only one event per call. In fact, we could do this already now because there is another cycle in hub_thread(). It calls hub_events() until hub_event_list is empty. This patch renames the function to hub_event(), removes the while cycle, and renames the goto targets from loop* to out*. When touching the code, it fixes also formatting of dev_err() and dev_dbg() calls to make checkpatch.pl happy :-) Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:20 +02:00
USB: Add autosuspend support to the hub driver This patch (as742b) adds autosuspend/autoresume support to the USB hub driver. The largest aspect of the change is that we no longer need a special flag for root hubs that want to be resumed. Now every hub is autoresumed whenever khubd needs to access it. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-11-09 14:44:33 -05:00
usb: hub: rename hub_events() to hub_event() and handle only one event there We would like to convert khubd kthread to a workqueue. As a result hub_events() will handle only one event per call. In fact, we could do this already now because there is another cycle in hub_thread(). It calls hub_events() until hub_event_list is empty. This patch renames the function to hub_event(), removes the while cycle, and renames the goto targets from loop* to out*. When touching the code, it fixes also formatting of dev_err() and dev_dbg() calls to make checkpatch.pl happy :-) Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:20 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: rename hub_events() to hub_event() and handle only one event there We would like to convert khubd kthread to a workqueue. As a result hub_events() will handle only one event per call. In fact, we could do this already now because there is another cycle in hub_thread(). It calls hub_events() until hub_event_list is empty. This patch renames the function to hub_event(), removes the while cycle, and renames the goto targets from loop* to out*. When touching the code, it fixes also formatting of dev_err() and dev_dbg() calls to make checkpatch.pl happy :-) Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:20 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: rename hub_events() to hub_event() and handle only one event there We would like to convert khubd kthread to a workqueue. As a result hub_events() will handle only one event per call. In fact, we could do this already now because there is another cycle in hub_thread(). It calls hub_events() until hub_event_list is empty. This patch renames the function to hub_event(), removes the while cycle, and renames the goto targets from loop* to out*. When touching the code, it fixes also formatting of dev_err() and dev_dbg() calls to make checkpatch.pl happy :-) Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:20 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: rename hub_events() to hub_event() and handle only one event there We would like to convert khubd kthread to a workqueue. As a result hub_events() will handle only one event per call. In fact, we could do this already now because there is another cycle in hub_thread(). It calls hub_events() until hub_event_list is empty. This patch renames the function to hub_event(), removes the while cycle, and renames the goto targets from loop* to out*. When touching the code, it fixes also formatting of dev_err() and dev_dbg() calls to make checkpatch.pl happy :-) Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:20 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: rename hub_events() to hub_event() and handle only one event there We would like to convert khubd kthread to a workqueue. As a result hub_events() will handle only one event per call. In fact, we could do this already now because there is another cycle in hub_thread(). It calls hub_events() until hub_event_list is empty. This patch renames the function to hub_event(), removes the while cycle, and renames the goto targets from loop* to out*. When touching the code, it fixes also formatting of dev_err() and dev_dbg() calls to make checkpatch.pl happy :-) Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:20 +02:00
usb: refactor port handling in hub_events() In preparation for synchronizing port handling with pm_runtime transitions refactor port handling into its own subroutine. We expect that clearing some status flags will be required regardless of the port state, so handle those first and group all non-trivial actions at the bottom of the routine. This also splits off the bottom half of hub_port_connect_change() into hub_port_reconnect() in prepartion for introducing a port->status_lock. hub_port_reconnect() will expect the port lock to not be held while hub_port_connect_change() expects to enter with it held. Other cleanups include: 1/ reflowing to 80 columns 2/ replacing redundant usages of 'hub->hdev' with 'hdev' 3/ consolidate clearing of ->change_bits() in hub_port_connect_change 4/ consolidate calls to usb_reset_device Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:15 -07:00
usb: hub: rename hub_events() to hub_event() and handle only one event there We would like to convert khubd kthread to a workqueue. As a result hub_events() will handle only one event per call. In fact, we could do this already now because there is another cycle in hub_thread(). It calls hub_events() until hub_event_list is empty. This patch renames the function to hub_event(), removes the while cycle, and renames the goto targets from loop* to out*. When touching the code, it fixes also formatting of dev_err() and dev_dbg() calls to make checkpatch.pl happy :-) Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:20 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: rename hub_events() to hub_event() and handle only one event there We would like to convert khubd kthread to a workqueue. As a result hub_events() will handle only one event per call. In fact, we could do this already now because there is another cycle in hub_thread(). It calls hub_events() until hub_event_list is empty. This patch renames the function to hub_event(), removes the while cycle, and renames the goto targets from loop* to out*. When touching the code, it fixes also formatting of dev_err() and dev_dbg() calls to make checkpatch.pl happy :-) Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:20 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: rename hub_events() to hub_event() and handle only one event there We would like to convert khubd kthread to a workqueue. As a result hub_events() will handle only one event per call. In fact, we could do this already now because there is another cycle in hub_thread(). It calls hub_events() until hub_event_list is empty. This patch renames the function to hub_event(), removes the while cycle, and renames the goto targets from loop* to out*. When touching the code, it fixes also formatting of dev_err() and dev_dbg() calls to make checkpatch.pl happy :-) Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:20 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: rename hub_events() to hub_event() and handle only one event there We would like to convert khubd kthread to a workqueue. As a result hub_events() will handle only one event per call. In fact, we could do this already now because there is another cycle in hub_thread(). It calls hub_events() until hub_event_list is empty. This patch renames the function to hub_event(), removes the while cycle, and renames the goto targets from loop* to out*. When touching the code, it fixes also formatting of dev_err() and dev_dbg() calls to make checkpatch.pl happy :-) Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:20 +02:00
usb: hub: convert khubd into workqueue There is no need to have separate kthread for handling USB hub events. It is more elegant to use the workqueue framework. The workqueue is allocated as freezable because the original thread was freezable as well. Also it is allocated as ordered because the code is not ready for parallel processing of hub events, see choose_devnum(). struct usb_hub is passed via the work item. Therefore we do not need hub_event_list. Also hub_thread() is not longer needed. It would call only hub_event(). The rest of the code did manipulate the kthread and it is handled by the workqueue framework now. kick_khubd is renamed to kick_hub_wq() to make the function clear. And the protection against races is done another way, see below. hub_event_lock has been removed. It cannot longer be used to protect struct usb_hub between hub_event() and hub_disconnect(). Instead we need to get hub->kref already in kick_hub_wq(). The lock is not really needed for the other scenarios as well. queue_work() returns whether it succeeded. We could revert the needed operations accordingly. This is enough to avoid duplicity and inconsistencies. Yes, the removed lock causes that there is not longer such a strong synchronization between scheduling the work and manipulating hub->disconnected. But kick_hub_wq() must never be called together with hub_disconnect() otherwise even the original code would have failed. Any callers are responsible for this. Therefore the only problem is that hub_disconnect() could be called in parallel with hub_event(). But this was possible even in the past. struct usb_hub is still guarded by hub->kref and released in hub_events() when needed. Note that the source file is still full of the obsolete "khubd" strings. Let's remove them in a follow up patch. This patch already is complex enough. Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to allocate the workqueue. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:21 +02:00
usb: hub: rename hub_events() to hub_event() and handle only one event there We would like to convert khubd kthread to a workqueue. As a result hub_events() will handle only one event per call. In fact, we could do this already now because there is another cycle in hub_thread(). It calls hub_events() until hub_event_list is empty. This patch renames the function to hub_event(), removes the while cycle, and renames the goto targets from loop* to out*. When touching the code, it fixes also formatting of dev_err() and dev_dbg() calls to make checkpatch.pl happy :-) Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:20 +02:00
usb: hub: convert khubd into workqueue There is no need to have separate kthread for handling USB hub events. It is more elegant to use the workqueue framework. The workqueue is allocated as freezable because the original thread was freezable as well. Also it is allocated as ordered because the code is not ready for parallel processing of hub events, see choose_devnum(). struct usb_hub is passed via the work item. Therefore we do not need hub_event_list. Also hub_thread() is not longer needed. It would call only hub_event(). The rest of the code did manipulate the kthread and it is handled by the workqueue framework now. kick_khubd is renamed to kick_hub_wq() to make the function clear. And the protection against races is done another way, see below. hub_event_lock has been removed. It cannot longer be used to protect struct usb_hub between hub_event() and hub_disconnect(). Instead we need to get hub->kref already in kick_hub_wq(). The lock is not really needed for the other scenarios as well. queue_work() returns whether it succeeded. We could revert the needed operations accordingly. This is enough to avoid duplicity and inconsistencies. Yes, the removed lock causes that there is not longer such a strong synchronization between scheduling the work and manipulating hub->disconnected. But kick_hub_wq() must never be called together with hub_disconnect() otherwise even the original code would have failed. Any callers are responsible for this. Therefore the only problem is that hub_disconnect() could be called in parallel with hub_event(). But this was possible even in the past. struct usb_hub is still guarded by hub->kref and released in hub_events() when needed. Note that the source file is still full of the obsolete "khubd" strings. Let's remove them in a follow up patch. This patch already is complex enough. Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to allocate the workqueue. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:21 +02:00
USB: core: Add hub_get() and hub_put() routines Create hub_get() and hub_put() routines to encapsulate the kref_get() and kref_put() calls in hub.c. The new routines will be used by the next patch in this series. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/604da420-ae8a-4a9e-91a4-2d511ff404fb@rowland.harvard.edu Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-15 13:04:50 -04:00
usb, kcov: collect coverage from hub_event Add kcov_remote_start()/kcov_remote_stop() annotations to the hub_event() function, which is responsible for processing events on USB buses, in particular events that happen during USB device enumeration. Since hub_event() is run in a global background kernel thread (see Documentation/dev-tools/kcov.rst for details), each USB bus gets a unique global handle from the USB subsystem kcov handle range. As the result kcov can now be used to collect coverage from events that happen on a particular USB bus. [akpm@linux-foundation.org: avoid patch conflicts to make life easier for Andrew] Link: http://lkml.kernel.org/r/de4fe1c219db2d002d905dc1736e2a3bfa1db997.1572366574.git.andreyknvl@google.com Signed-off-by: Andrey Konovalov <andreyknvl@google.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Alexander Potapenko <glider@google.com> Cc: Anders Roxell <anders.roxell@linaro.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: David Windsor <dwindsor@gmail.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Elena Reshetova <elena.reshetova@intel.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Marco Elver <elver@google.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-12-04 16:52:47 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB hub: make USB device id constant The id_table field of the struct usb_device_id is constant in <linux/usb.h> so it is worth to make the initialization data also constant. The semantic match that finds this kind of pattern is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ disable decl_init,const_decl_init; identifier I1, I2, x; @@ struct I1 { ... const struct I2 *x; ... }; @s@ identifier r.I1, y; identifier r.x, E; @@ struct I1 y = { .x = E, }; @c@ identifier r.I2; identifier s.E; @@ const struct I2 E[] = ... ; @depends on !c@ identifier r.I2; identifier s.E; @@ + const struct I2 E[] = ...; // </smpl> Signed-off-by: Németh Márton <nm127@freemail.hu> Cc: Julia Lawall <julia@diku.dk> Cc: cocci@diku.dk Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-10 15:34:53 +01:00
usb: core: hub: limit HUB_QUIRK_DISABLE_AUTOSUSPEND to USB5534B On Tue, May 12, 2020 at 09:36:07PM +0800, Kai-Heng Feng wrote [1]: > This patch prevents my Raven Ridge xHCI from getting runtime suspend. The problem described in v5.6 commit 1208f9e1d758c9 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub") applies solely to the USB5534B hub [2] present on the Kingfisher Infotainment Carrier Board, manufactured by Shimafuji Electric Inc [3]. Despite that, the aforementioned commit applied the quirk to _all_ hubs carrying vendor ID 0x424 (i.e. SMSC), of which there are more [4] than initially expected. Consequently, the quirk is now enabled on platforms carrying SMSC/Microchip hub models which potentially don't exhibit the original issue. To avoid reports like [1], further limit the quirk's scope to USB5534B [2], by employing both Vendor and Product ID checks. Tested on H3ULCB + Kingfisher rev. M05. [1] https://lore.kernel.org/linux-renesas-soc/73933975-6F0E-40F5-9584-D2B8F615C0F3@canonical.com/ [2] https://www.microchip.com/wwwproducts/en/USB5534B [3] http://www.shimafuji.co.jp/wp/wp-content/uploads/2018/08/SBEV-RCAR-KF-M06Board_HWSpecificationEN_Rev130.pdf [4] https://devicehunt.com/search/type/usb/vendor/0424/device/any Fixes: 1208f9e1d758c9 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub") Cc: stable@vger.kernel.org # v4.14+ Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Hardik Gajjar <hgajjar@de.adit-jv.com> Cc: linux-renesas-soc@vger.kernel.org Cc: linux-usb@vger.kernel.org Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Link: https://lore.kernel.org/r/20200514220246.13290-1-erosca@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-15 00:02:46 +02:00
USB: hub: Fix the broken detection of USB3 device in SMSC hub Renesas R-Car H3ULCB + Kingfisher Infotainment Board is either not able to detect the USB3.0 mass storage devices or is detecting those as USB2.0 high speed devices. The explanation given by Renesas is that, due to a HW issue, the XHCI driver does not wake up after going to sleep on connecting a USB3.0 device. In order to mitigate that, disable the auto-suspend feature specifically for SMSC hubs from hub_probe() function, as a quirk. Renesas Kingfisher Infotainment Board has two USB3.0 ports (CN2) which are connected via USB5534B 4-port SuperSpeed/Hi-Speed, low-power, configurable hub controller. [1] SanDisk USB 3.0 device detected as USB-2.0 before the patch [ 74.036390] usb 5-1.1: new high-speed USB device number 4 using xhci-hcd [ 74.061598] usb 5-1.1: New USB device found, idVendor=0781, idProduct=5581, bcdDevice= 1.00 [ 74.069976] usb 5-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 74.077303] usb 5-1.1: Product: Ultra [ 74.080980] usb 5-1.1: Manufacturer: SanDisk [ 74.085263] usb 5-1.1: SerialNumber: 4C530001110208116550 [2] SanDisk USB 3.0 device detected as USB-3.0 after the patch [ 34.565078] usb 6-1.1: new SuperSpeed Gen 1 USB device number 3 using xhci-hcd [ 34.588719] usb 6-1.1: New USB device found, idVendor=0781, idProduct=5581, bcdDevice= 1.00 [ 34.597098] usb 6-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 34.604430] usb 6-1.1: Product: Ultra [ 34.608110] usb 6-1.1: Manufacturer: SanDisk [ 34.612397] usb 6-1.1: SerialNumber: 4C530001110208116550 Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Eugeniu Rosca <erosca@de.adit-jv.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/1580989763-32291-1-git-send-email-hgajjar@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-06 12:49:23 +01:00
usb: core: hub: limit HUB_QUIRK_DISABLE_AUTOSUSPEND to USB5534B On Tue, May 12, 2020 at 09:36:07PM +0800, Kai-Heng Feng wrote [1]: > This patch prevents my Raven Ridge xHCI from getting runtime suspend. The problem described in v5.6 commit 1208f9e1d758c9 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub") applies solely to the USB5534B hub [2] present on the Kingfisher Infotainment Carrier Board, manufactured by Shimafuji Electric Inc [3]. Despite that, the aforementioned commit applied the quirk to _all_ hubs carrying vendor ID 0x424 (i.e. SMSC), of which there are more [4] than initially expected. Consequently, the quirk is now enabled on platforms carrying SMSC/Microchip hub models which potentially don't exhibit the original issue. To avoid reports like [1], further limit the quirk's scope to USB5534B [2], by employing both Vendor and Product ID checks. Tested on H3ULCB + Kingfisher rev. M05. [1] https://lore.kernel.org/linux-renesas-soc/73933975-6F0E-40F5-9584-D2B8F615C0F3@canonical.com/ [2] https://www.microchip.com/wwwproducts/en/USB5534B [3] http://www.shimafuji.co.jp/wp/wp-content/uploads/2018/08/SBEV-RCAR-KF-M06Board_HWSpecificationEN_Rev130.pdf [4] https://devicehunt.com/search/type/usb/vendor/0424/device/any Fixes: 1208f9e1d758c9 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub") Cc: stable@vger.kernel.org # v4.14+ Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Hardik Gajjar <hgajjar@de.adit-jv.com> Cc: linux-renesas-soc@vger.kernel.org Cc: linux-usb@vger.kernel.org Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Link: https://lore.kernel.org/r/20200514220246.13290-1-erosca@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-15 00:02:46 +02:00
USB: hub: Fix the broken detection of USB3 device in SMSC hub Renesas R-Car H3ULCB + Kingfisher Infotainment Board is either not able to detect the USB3.0 mass storage devices or is detecting those as USB2.0 high speed devices. The explanation given by Renesas is that, due to a HW issue, the XHCI driver does not wake up after going to sleep on connecting a USB3.0 device. In order to mitigate that, disable the auto-suspend feature specifically for SMSC hubs from hub_probe() function, as a quirk. Renesas Kingfisher Infotainment Board has two USB3.0 ports (CN2) which are connected via USB5534B 4-port SuperSpeed/Hi-Speed, low-power, configurable hub controller. [1] SanDisk USB 3.0 device detected as USB-2.0 before the patch [ 74.036390] usb 5-1.1: new high-speed USB device number 4 using xhci-hcd [ 74.061598] usb 5-1.1: New USB device found, idVendor=0781, idProduct=5581, bcdDevice= 1.00 [ 74.069976] usb 5-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 74.077303] usb 5-1.1: Product: Ultra [ 74.080980] usb 5-1.1: Manufacturer: SanDisk [ 74.085263] usb 5-1.1: SerialNumber: 4C530001110208116550 [2] SanDisk USB 3.0 device detected as USB-3.0 after the patch [ 34.565078] usb 6-1.1: new SuperSpeed Gen 1 USB device number 3 using xhci-hcd [ 34.588719] usb 6-1.1: New USB device found, idVendor=0781, idProduct=5581, bcdDevice= 1.00 [ 34.597098] usb 6-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 34.604430] usb 6-1.1: Product: Ultra [ 34.608110] usb 6-1.1: Manufacturer: SanDisk [ 34.612397] usb 6-1.1: SerialNumber: 4C530001110208116550 Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Eugeniu Rosca <erosca@de.adit-jv.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/1580989763-32291-1-git-send-email-hgajjar@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-06 12:49:23 +01:00
usb: core: hub: Disable autosuspend for Cypress CY7C65632 The Cypress CY7C65632 appears to have an issue with auto suspend and detecting devices, not too dissimilar to the SMSC 5534B hub. It is easiest to reproduce by connecting multiple mass storage devices to the hub at the same time. On a Lenovo Yoga, around 1 in 3 attempts result in the devices not being detected. It is however possible to make them appear using lsusb -v. Disabling autosuspend for this hub resolves the issue. Fixes: 1208f9e1d758 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub") Cc: stable@vger.kernel.org Signed-off-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20210614155524.2228800-1-andrew@lunn.ch Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-14 17:55:23 +02:00
USB: check port changes before hub runtime suspend for some bug device The hub status endpoint has a long 'bInterval', which is 255ms for FS/LS device and 256ms for HS device according to USB 2.0 spec, so the device connection change may be reported later more than 255ms via status pipe. The connection change in hub may have been happened already on the downstream ports, but no status URB completes when it is killed in hub_suspend(auto), so the connection change may be missed by some buggy hub devices, which won't generate remote wakeup signal after their remote wakeup is enabled and they are put into suspend state. The problem can be observed at least on the below Genesys Logic, Inc. hub devices: 0x05e3,0x0606 0x05e3,0x0608 In theory, there is no way to fix the problem completely, but we can make it less likely to occur by this patch. This patch introduces one quirk of HUB_QUIRK_CHECK_PORTS_AUTOSUSPEND to check ports' change during hub_suspend(auto) for the buggy devices. If ports' change is found, terminate the auto suspend and return to working state. So for the buggy hubs, if the connection change happend before the ports' check, it can be handled correctly. If it happens between the ports' check and enabling remote wakeup/entering suspend, it will be missed. Considered the interval is quite short, it is very less likely to happen during the window. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-24 11:59:24 +08:00
drivers: usb: core: {file,hub,sysfs,usb}.c: Whitespace fixes including: - removing of trailing whitespace - removing spaces before array indexing (foo [] to foo[]) - reindention of a switch-case block - spaces to tabs Signed-off-by: Matthias Beyer <mail@beyermatthias.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-10 23:41:27 +02:00
USB: check port changes before hub runtime suspend for some bug device The hub status endpoint has a long 'bInterval', which is 255ms for FS/LS device and 256ms for HS device according to USB 2.0 spec, so the device connection change may be reported later more than 255ms via status pipe. The connection change in hub may have been happened already on the downstream ports, but no status URB completes when it is killed in hub_suspend(auto), so the connection change may be missed by some buggy hub devices, which won't generate remote wakeup signal after their remote wakeup is enabled and they are put into suspend state. The problem can be observed at least on the below Genesys Logic, Inc. hub devices: 0x05e3,0x0606 0x05e3,0x0608 In theory, there is no way to fix the problem completely, but we can make it less likely to occur by this patch. This patch introduces one quirk of HUB_QUIRK_CHECK_PORTS_AUTOSUSPEND to check ports' change during hub_suspend(auto) for the buggy devices. If ports' change is found, terminate the auto suspend and return to working state. So for the buggy hubs, if the connection change happend before the ports' check, it can be handled correctly. If it happens between the ports' check and enabling remote wakeup/entering suspend, it will be missed. Considered the interval is quite short, it is very less likely to happen during the window. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-24 11:59:24 +08:00
usb: core: hub: disable autosuspend for TI TUSB8041 The Texas Instruments TUSB8041 has an autosuspend problem at high temperature. If there is not USB traffic, after a couple of ms, the device enters in autosuspend mode. In this condition the external clock stops working, to save energy. When the USB activity turns on, ther hub exits the autosuspend state, the clock starts running again and all works fine. At ambient temperature all works correctly, but at high temperature, when the USB activity turns on, the external clock doesn't restart and the hub disappears from the USB bus. Disabling the autosuspend mode for this hub solves the issue. Signed-off-by: Flavio Suligoi <f.suligoi@asem.it> Cc: stable <stable@kernel.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20221219124759.3207032-1-f.suligoi@asem.it Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-19 13:47:59 +01:00
usb: hub: Add quirk to decrease IN-ep poll interval for Microchip USB491x hub There is a potential delay in notifying Linux USB drivers of downstream USB bus activity when connecting a high-speed or superSpeed device via the Microchip USB491x hub. This delay is due to the fixed bInterval value of 12 in the silicon of the Microchip USB491x hub. Microchip requested to ignore the device descriptor and decrease that value to 9 as it was too late to modify that in silicon. This patch speeds up the USB enummeration process that helps to pass Apple Carplay certifications and improve the User experience when utilizing the USB device via Microchip Multihost USB491x Hub. A new hub quirk HUB_QUIRK_REDUCE_FRAME_INTR_BINTERVAL speeds up the notification process for Microchip USB491x hub by limiting the maximum bInterval value to 9. Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20231205181829.127353-2-hgajjar@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-05 19:18:29 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: core: hub: Removed some warnings generated by checkpatch.pl Removed some checkpatch.pl warnings saying there was an unwanted space between function names and their arguments. Signed-off-by: Chase Metzger <chasemetzger15@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-18 20:36:58 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: add reset_resume method This patch (as918) introduces a new USB driver method: reset_resume. It is called when a device needs to be reset as part of a resume procedure (whether because of a device quirk or because of the USB-Persist facility), thereby taking over a role formerly assigned to the post_reset method. As a consequence, post_reset no longer needs an argument indicating whether it is being called as part of a reset-resume. This separation of functions makes the code clearer. In addition, the pre_reset and post_reset method return types are changed; they now must return an error code. The return value is unused at present, but at some later time we may unbind drivers and re-probe if they encounter an error during reset handling. The existing pre_reset and post_reset methods in the usbhid, usb-storage, and hub drivers are updated to match the new requirements. For usbhid the post_reset routine is also used for reset_resume (duplicate method pointers); for the other drivers a new reset_resume routine is added. The change to hub.c looks bigger than it really is, because mark_children_for_reset_resume() gets moved down next to the new hub_reset_resume() routine. A minor change to usb-storage makes the usb_stor_report_bus_reset() routine acquire the host lock instead of requiring the caller to hold it already. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Jiri Kosina <jkosina@suse.cz> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-30 15:38:16 -04:00
[PATCH] USB hub: use usb_reset_composite_device This patch (as700) modifies the hub driver to take advantage of the new usb_reset_composite_device API. The existing code had special-case calls stuck into usb_reset_device, just before and after the reset. With the new version there's no need for special-case stuff; it all happens naturally in the form of pre_reset and post_reset notifications. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-01 13:37:24 -04:00
USB-BKL: Convert usb_driver ioctl to unlocked_ioctl And audit all the users. None needed the BKL. That was easy because there was only very few around. Tested with allmodconfig build on x86-64 Signed-off-by: Andi Kleen <ak@linux.intel.com> Cc: Arnd Bergmann <arnd@arndb.de> From: Andi Kleen <ak@linux.intel.com>
2010-06-01 23:04:41 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: Add autosuspend support to the hub driver This patch (as742b) adds autosuspend/autoresume support to the USB hub driver. The largest aspect of the change is that we no longer need a special flag for root hubs that want to be resumed. Now every hub is autoresumed whenever khubd needs to access it. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-11-09 14:44:33 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: convert khubd into workqueue There is no need to have separate kthread for handling USB hub events. It is more elegant to use the workqueue framework. The workqueue is allocated as freezable because the original thread was freezable as well. Also it is allocated as ordered because the code is not ready for parallel processing of hub events, see choose_devnum(). struct usb_hub is passed via the work item. Therefore we do not need hub_event_list. Also hub_thread() is not longer needed. It would call only hub_event(). The rest of the code did manipulate the kthread and it is handled by the workqueue framework now. kick_khubd is renamed to kick_hub_wq() to make the function clear. And the protection against races is done another way, see below. hub_event_lock has been removed. It cannot longer be used to protect struct usb_hub between hub_event() and hub_disconnect(). Instead we need to get hub->kref already in kick_hub_wq(). The lock is not really needed for the other scenarios as well. queue_work() returns whether it succeeded. We could revert the needed operations accordingly. This is enough to avoid duplicity and inconsistencies. Yes, the removed lock causes that there is not longer such a strong synchronization between scheduling the work and manipulating hub->disconnected. But kick_hub_wq() must never be called together with hub_disconnect() otherwise even the original code would have failed. Any callers are responsible for this. Therefore the only problem is that hub_disconnect() could be called in parallel with hub_event(). But this was possible even in the past. struct usb_hub is still guarded by hub->kref and released in hub_events() when needed. Note that the source file is still full of the obsolete "khubd" strings. Let's remove them in a follow up patch. This patch already is complex enough. Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to allocate the workqueue. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:21 +02:00
usb: hub: allow to process more usb hub events in parallel It seems that only choose_devnum() was not ready to process more hub events at the same time. All should be fine if we take bus->usb_address0_mutex there. It will make sure that more devnums will not be chosen for the given bus and the related devices at the same time. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:24 +02:00
usb: hub: convert khubd into workqueue There is no need to have separate kthread for handling USB hub events. It is more elegant to use the workqueue framework. The workqueue is allocated as freezable because the original thread was freezable as well. Also it is allocated as ordered because the code is not ready for parallel processing of hub events, see choose_devnum(). struct usb_hub is passed via the work item. Therefore we do not need hub_event_list. Also hub_thread() is not longer needed. It would call only hub_event(). The rest of the code did manipulate the kthread and it is handled by the workqueue framework now. kick_khubd is renamed to kick_hub_wq() to make the function clear. And the protection against races is done another way, see below. hub_event_lock has been removed. It cannot longer be used to protect struct usb_hub between hub_event() and hub_disconnect(). Instead we need to get hub->kref already in kick_hub_wq(). The lock is not really needed for the other scenarios as well. queue_work() returns whether it succeeded. We could revert the needed operations accordingly. This is enough to avoid duplicity and inconsistencies. Yes, the removed lock causes that there is not longer such a strong synchronization between scheduling the work and manipulating hub->disconnected. But kick_hub_wq() must never be called together with hub_disconnect() otherwise even the original code would have failed. Any callers are responsible for this. Therefore the only problem is that hub_disconnect() could be called in parallel with hub_event(). But this was possible even in the past. struct usb_hub is still guarded by hub->kref and released in hub_events() when needed. Note that the source file is still full of the obsolete "khubd" strings. Let's remove them in a follow up patch. This patch already is complex enough. Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to allocate the workqueue. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:21 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: convert khubd into workqueue There is no need to have separate kthread for handling USB hub events. It is more elegant to use the workqueue framework. The workqueue is allocated as freezable because the original thread was freezable as well. Also it is allocated as ordered because the code is not ready for parallel processing of hub events, see choose_devnum(). struct usb_hub is passed via the work item. Therefore we do not need hub_event_list. Also hub_thread() is not longer needed. It would call only hub_event(). The rest of the code did manipulate the kthread and it is handled by the workqueue framework now. kick_khubd is renamed to kick_hub_wq() to make the function clear. And the protection against races is done another way, see below. hub_event_lock has been removed. It cannot longer be used to protect struct usb_hub between hub_event() and hub_disconnect(). Instead we need to get hub->kref already in kick_hub_wq(). The lock is not really needed for the other scenarios as well. queue_work() returns whether it succeeded. We could revert the needed operations accordingly. This is enough to avoid duplicity and inconsistencies. Yes, the removed lock causes that there is not longer such a strong synchronization between scheduling the work and manipulating hub->disconnected. But kick_hub_wq() must never be called together with hub_disconnect() otherwise even the original code would have failed. Any callers are responsible for this. Therefore the only problem is that hub_disconnect() could be called in parallel with hub_event(). But this was possible even in the past. struct usb_hub is still guarded by hub->kref and released in hub_events() when needed. Note that the source file is still full of the obsolete "khubd" strings. Let's remove them in a follow up patch. This patch already is complex enough. Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to allocate the workqueue. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:21 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: convert khubd into workqueue There is no need to have separate kthread for handling USB hub events. It is more elegant to use the workqueue framework. The workqueue is allocated as freezable because the original thread was freezable as well. Also it is allocated as ordered because the code is not ready for parallel processing of hub events, see choose_devnum(). struct usb_hub is passed via the work item. Therefore we do not need hub_event_list. Also hub_thread() is not longer needed. It would call only hub_event(). The rest of the code did manipulate the kthread and it is handled by the workqueue framework now. kick_khubd is renamed to kick_hub_wq() to make the function clear. And the protection against races is done another way, see below. hub_event_lock has been removed. It cannot longer be used to protect struct usb_hub between hub_event() and hub_disconnect(). Instead we need to get hub->kref already in kick_hub_wq(). The lock is not really needed for the other scenarios as well. queue_work() returns whether it succeeded. We could revert the needed operations accordingly. This is enough to avoid duplicity and inconsistencies. Yes, the removed lock causes that there is not longer such a strong synchronization between scheduling the work and manipulating hub->disconnected. But kick_hub_wq() must never be called together with hub_disconnect() otherwise even the original code would have failed. Any callers are responsible for this. Therefore the only problem is that hub_disconnect() could be called in parallel with hub_event(). But this was possible even in the past. struct usb_hub is still guarded by hub->kref and released in hub_events() when needed. Note that the source file is still full of the obsolete "khubd" strings. Let's remove them in a follow up patch. This patch already is complex enough. Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to allocate the workqueue. Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:21 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: fix usb_reset_device and usb_reset_composite_device(take 3) This patch renames the existing usb_reset_device in hub.c to usb_reset_and_verify_device and renames the existing usb_reset_composite_device to usb_reset_device. Also the new usb_reset_and_verify_device does't need to be EXPORTED . The idea of the patch is that external interface driver should warn the other interfaces' driver of the same device before and after reseting the usb device. One interface driver shoud call _old_ usb_reset_composite_device instead of _old_ usb_reset_device since it can't assume the device contains only one interface. The _old_ usb_reset_composite_device is safe for single interface device also. we rename the two functions to make the change easily. This patch is under guideline from Alan Stern. Signed-off-by: Ming Lei <tom.leiming@gmail.com>
2008-06-18 22:00:29 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] usbcore: port reset for composite devices This patch (as699) adds usb_reset_composite_device(), a routine for sending a USB port reset to a device with multiple interfaces owned by different drivers. Drivers are notified about impending and completed resets through two new methods in the usb_driver structure. The patch modifieds the usbfs ioctl code to make it use the new routine instead of usb_reset_device(). Follow-up patches will modify the hub, usb-storage, and usbhid drivers so they can utilize this new API. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-01 13:33:42 -04:00
USB: fix usb_reset_device and usb_reset_composite_device(take 3) This patch renames the existing usb_reset_device in hub.c to usb_reset_and_verify_device and renames the existing usb_reset_composite_device to usb_reset_device. Also the new usb_reset_and_verify_device does't need to be EXPORTED . The idea of the patch is that external interface driver should warn the other interfaces' driver of the same device before and after reseting the usb device. One interface driver shoud call _old_ usb_reset_composite_device instead of _old_ usb_reset_device since it can't assume the device contains only one interface. The _old_ usb_reset_composite_device is safe for single interface device also. we rename the two functions to make the change easily. This patch is under guideline from Alan Stern. Signed-off-by: Ming Lei <tom.leiming@gmail.com>
2008-06-18 22:00:29 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: rename khubd to hub_wq in documentation and comments USB hub has started to use a workqueue instead of kthread. Let's update the documentation and comments here and there. This patch mostly just replaces "khubd" with "hub_wq". There are only few exceptions where the whole sentence was updated. These more complicated changes can be found in the following files: Documentation/usb/hotplug.txt drivers/net/usb/usbnet.c drivers/usb/core/hcd.c drivers/usb/host/ohci-hcd.c drivers/usb/host/xhci.c Signed-off-by: Petr Mladek <pmladek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-19 17:32:23 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: fix some scripts/kernel-doc warnings When building the htmldocs (in verbose mode), scripts/kernel-doc reports the following type of warnings: Warning(drivers/usb/core/usb.c:76): No description found for return value of 'usb_find_alt_setting' Fix them by: - adding some missing descriptions of return values - using "Return" sections for those descriptions Signed-off-by: Yacine Belkadi <yacine.belkadi.1@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-02 20:10:04 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: fix some scripts/kernel-doc warnings When building the htmldocs (in verbose mode), scripts/kernel-doc reports the following type of warnings: Warning(drivers/usb/core/usb.c:76): No description found for return value of 'usb_find_alt_setting' Fix them by: - adding some missing descriptions of return values - using "Return" sections for those descriptions Signed-off-by: Yacine Belkadi <yacine.belkadi.1@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-02 20:10:04 +02:00
usb: introduce port status lock In general we do not want khubd to act on port status changes that are the result of in progress resets or USB runtime PM operations. Specifically port power control testing has been able to trigger an unintended disconnect in hub_port_connect_change(), paraphrasing: if ((portstatus & USB_PORT_STAT_CONNECTION) && udev && udev->state != USB_STATE_NOTATTACHED) { if (portstatus & USB_PORT_STAT_ENABLE) { /* Nothing to do */ } else if (udev->state == USB_STATE_SUSPENDED && udev->persist_enabled) { ... } else { /* Don't resuscitate */; } } ...by falling to the "Don't resuscitate" path or missing USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of modifying the port status. So, we want a new lock to hold off khubd for a given port while the child device is being suspended, resumed, or reset. The lock ordering rules are now usb_lock_device() => usb_lock_port(). This is mandated by the device core which may hold the device_lock on the usb_device before invoking usb_port_{suspend|resume} which in turn take the status_lock on the usb_port. We attempt to hold the status_lock for the duration of a port_event() run, and drop/re-acquire it when needing to take the device_lock. The lock is also dropped/re-acquired during hub_port_reconnect(). This patch also deletes hub->busy_bits as all use cases are now covered by port PM runtime synchronization or the port->status_lock and it pushes down usb_device_lock() into usb_remote_wakeup(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:26 -07:00
USB: add RESET_RESUME device quirk This patch (as888) adds a new USB device quirk for devices which are unable to resume correctly. By using the new code added for the USB-persist facility, it is a simple matter to reset these devices instead of resuming them. To get things kicked off, a quirk entry is added for the Philips PSC805. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-04 11:53:03 -04:00
usb: introduce port status lock In general we do not want khubd to act on port status changes that are the result of in progress resets or USB runtime PM operations. Specifically port power control testing has been able to trigger an unintended disconnect in hub_port_connect_change(), paraphrasing: if ((portstatus & USB_PORT_STAT_CONNECTION) && udev && udev->state != USB_STATE_NOTATTACHED) { if (portstatus & USB_PORT_STAT_ENABLE) { /* Nothing to do */ } else if (udev->state == USB_STATE_SUSPENDED && udev->persist_enabled) { ... } else { /* Don't resuscitate */; } } ...by falling to the "Don't resuscitate" path or missing USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of modifying the port status. So, we want a new lock to hold off khubd for a given port while the child device is being suspended, resumed, or reset. The lock ordering rules are now usb_lock_device() => usb_lock_port(). This is mandated by the device core which may hold the device_lock on the usb_device before invoking usb_port_{suspend|resume} which in turn take the status_lock on the usb_port. We attempt to hold the status_lock for the duration of a port_event() run, and drop/re-acquire it when needing to take the device_lock. The lock is also dropped/re-acquired during hub_port_reconnect(). This patch also deletes hub->busy_bits as all use cases are now covered by port PM runtime synchronization or the port->status_lock and it pushes down usb_device_lock() into usb_remote_wakeup(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:26 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: fix usb_reset_device and usb_reset_composite_device(take 3) This patch renames the existing usb_reset_device in hub.c to usb_reset_and_verify_device and renames the existing usb_reset_composite_device to usb_reset_device. Also the new usb_reset_and_verify_device does't need to be EXPORTED . The idea of the patch is that external interface driver should warn the other interfaces' driver of the same device before and after reseting the usb device. One interface driver shoud call _old_ usb_reset_composite_device instead of _old_ usb_reset_device since it can't assume the device contains only one interface. The _old_ usb_reset_composite_device is safe for single interface device also. we rename the two functions to make the change easily. This patch is under guideline from Alan Stern. Signed-off-by: Ming Lei <tom.leiming@gmail.com>
2008-06-18 22:00:29 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: Check bandwidth when switching alt settings. Make the USB core check the bandwidth when switching from one interface alternate setting to another. Also check the bandwidth when resetting a configuration (so that alt setting 0 is used). If this check fails, the device's state is unchanged. If the device refuses the new alt setting, re-instate the old alt setting in the host controller hardware. If a USB device doesn't have an alternate interface setting 0, install the first alt setting in its descriptors when a new configuration is requested, or the device is reset. Add a mutex per root hub to protect bandwidth operations: adding/reseting/changing configurations, and changing alternate interface settings. We want to ensure that the xHCI host controller and the USB device are set up for the same configurations and alternate settings. There are two (possibly three) steps to do this: 1. The host controller needs to check that bandwidth is available for a different setting, by issuing and waiting for a configure endpoint command. 2. Once that returns successfully, a control message is sent to the device. 3. If that fails, the host controller must be notified through another configure endpoint command. The mutex is used to make these three operations seem atomic, to prevent another driver from using more bandwidth for a different device while we're in the middle of these operations. While we're touching the bandwidth code, rename usb_hcd_check_bandwidth() to usb_hcd_alloc_bandwidth(). This function does more than just check that the bandwidth change won't exceed the bus bandwidth; it actually changes the bandwidth configuration in the xHCI host controller. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-03 09:44:36 -08:00
USB: core: Fix race by not overwriting udev->descriptor in hub_port_init() Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors(): BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011 CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351 print_report mm/kasan/report.c:462 [inline] kasan_report+0x11c/0x130 mm/kasan/report.c:572 read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 ... Allocated by task 758: ... __do_kmalloc_node mm/slab_common.c:966 [inline] __kmalloc+0x5e/0x190 mm/slab_common.c:979 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:680 [inline] usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887 usb_enumerate_device drivers/usb/core/hub.c:2407 [inline] usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545 As analyzed by Khazhy Kumykov, the cause of this bug is a race between read_descriptors() and hub_port_init(): The first routine uses a field in udev->descriptor, not expecting it to change, while the second overwrites it. Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") this race couldn't occur, because the routines were mutually exclusive thanks to the device locking. Removing that locking from read_descriptors() exposed it to the race. The best way to fix the bug is to keep hub_port_init() from changing udev->descriptor once udev has been initialized and registered. Drivers expect the descriptors stored in the kernel to be immutable; we should not undermine this expectation. In fact, this change should have been made long ago. So now hub_port_init() will take an additional argument, specifying a buffer in which to store the device descriptor it reads. (If udev has not yet been initialized, the buffer pointer will be NULL and then hub_port_init() will store the device descriptor in udev as before.) This eliminates the data race responsible for the out-of-bounds read. The changes to hub_port_init() appear more extensive than they really are, because of indentation changes resulting from an attempt to avoid writing to other parts of the usb_device structure after it has been initialized. Similar changes should be made to the code that reads the BOS descriptor, but that can be handled in a separate patch later on. This patch is sufficient to fix the bug found by syzbot. Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Khazhy Kumykov <khazhy@google.com> Fixes: 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:14:14 -04:00
usbcore: compare and release one bos descriptor in usb_reset_and_verify_device() In usb_reset_and_verify_device(), hub_port_init() allocates a new bos descriptor to hold the value read by the device. The new bos descriptor has to be compared with the old one in order to figure out if device 's firmware has changed in which case the device has to be reenumerated. In the original code, none of the two descriptors was deallocated leading to memory leaks. This patch compares the old bos descriptor with the new one to detect change in firmware and releases the newly allocated bos descriptor to prevent memory leak. Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com> Reported-by: Martin MOKREJS <mmokrejs@gmail.com> Tested-by: Martin MOKREJS <mmokrejs@gmail.com> Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-29 21:45:48 +03:00
usb: Clear host_endpoint->streams when implicitly freeing streams If streams are still allocated on device-reset or set-interface then the hcd code implictly frees the streams. Clear host_endpoint->streams in this case so that if a driver later tries to re-allocate them it won't run afoul of the device already having streams check in usb_alloc_streams(). Note normally streams still being allocated at reset / set-intf would be a driver bug, but this can happen without it being a driver bug on reset-resume. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-11-08 16:37:26 +01:00
[PATCH] USB: Store port number in usb_device This patch (as610) adds a field to struct usb_device to store the device's port number. This allows us to remove several loops in the hub driver (searching for a particular device among all the entries in the parent's array of children). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-23 12:09:52 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: introduce port status lock In general we do not want khubd to act on port status changes that are the result of in progress resets or USB runtime PM operations. Specifically port power control testing has been able to trigger an unintended disconnect in hub_port_connect_change(), paraphrasing: if ((portstatus & USB_PORT_STAT_CONNECTION) && udev && udev->state != USB_STATE_NOTATTACHED) { if (portstatus & USB_PORT_STAT_ENABLE) { /* Nothing to do */ } else if (udev->state == USB_STATE_SUSPENDED && udev->persist_enabled) { ... } else { /* Don't resuscitate */; } } ...by falling to the "Don't resuscitate" path or missing USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of modifying the port status. So, we want a new lock to hold off khubd for a given port while the child device is being suspended, resumed, or reset. The lock ordering rules are now usb_lock_device() => usb_lock_port(). This is mandated by the device core which may hold the device_lock on the usb_device before invoking usb_port_{suspend|resume} which in turn take the status_lock on the usb_port. We attempt to hold the status_lock for the duration of a port_event() run, and drop/re-acquire it when needing to take the device_lock. The lock is also dropped/re-acquired during hub_port_reconnect(). This patch also deletes hub->busy_bits as all use cases are now covered by port PM runtime synchronization or the port->status_lock and it pushes down usb_device_lock() into usb_remote_wakeup(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:26 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: introduce port status lock In general we do not want khubd to act on port status changes that are the result of in progress resets or USB runtime PM operations. Specifically port power control testing has been able to trigger an unintended disconnect in hub_port_connect_change(), paraphrasing: if ((portstatus & USB_PORT_STAT_CONNECTION) && udev && udev->state != USB_STATE_NOTATTACHED) { if (portstatus & USB_PORT_STAT_ENABLE) { /* Nothing to do */ } else if (udev->state == USB_STATE_SUSPENDED && udev->persist_enabled) { ... } else { /* Don't resuscitate */; } } ...by falling to the "Don't resuscitate" path or missing USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of modifying the port status. So, we want a new lock to hold off khubd for a given port while the child device is being suspended, resumed, or reset. The lock ordering rules are now usb_lock_device() => usb_lock_port(). This is mandated by the device core which may hold the device_lock on the usb_device before invoking usb_port_{suspend|resume} which in turn take the status_lock on the usb_port. We attempt to hold the status_lock for the duration of a port_event() run, and drop/re-acquire it when needing to take the device_lock. The lock is also dropped/re-acquired during hub_port_reconnect(). This patch also deletes hub->busy_bits as all use cases are now covered by port PM runtime synchronization or the port->status_lock and it pushes down usb_device_lock() into usb_remote_wakeup(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:26 -07:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: Disable USB 2.0 Link PM before device reset. Before the USB core resets a device, we need to disable the L1 timeout for the roothub, if USB 2.0 Link PM is enabled. Otherwise the port may transition into L1 in between descriptor fetches, before we know if the USB device descriptors changed. LPM will be re-enabled after the full device descriptors are fetched, and we can confirm the device still supports USB 2.0 LPM after the reset. We don't need to wait for the USB device to exit L1 before resetting the device, since the xHCI roothub port diagrams show a transition to the Reset state from any of the Ux states (see Figure 34 in the 2012-08-14 xHCI specification update). This patch should be backported to kernels as old as 3.2, that contain the commit 65580b4321eb36f16ae8b5987bfa1bb948fc5112 "xHCI: set USB2 hardware LPM". That was the first commit to enable USB 2.0 hardware-driven Link Power Management. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2013-09-30 17:26:29 +03:00
USB: Consolidate LPM checks to avoid enabling LPM twice USB Bluetooth controller QCA ROME (0cf3:e007) sometimes stops working after S3: [ 165.110742] Bluetooth: hci0: using NVM file: qca/nvm_usb_00000302.bin [ 168.432065] Bluetooth: hci0: Failed to send body at 4 of 1953 (-110) After some experiments, I found that disabling LPM can workaround the issue. On some platforms, the USB power is cut during S3, so the driver uses reset-resume to resume the device. During port resume, LPM gets enabled twice, by usb_reset_and_verify_device() and usb_port_resume(). Consolidate all checks into new LPM helpers to make sure LPM only gets enabled once. Fixes: de68bab4fa96 ("usb: Don't enable USB 2.0 Link PM by default.”) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: stable <stable@vger.kernel.org> # after much soaking Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-12 03:54:25 +08:00
usb: Disable USB 2.0 Link PM before device reset. Before the USB core resets a device, we need to disable the L1 timeout for the roothub, if USB 2.0 Link PM is enabled. Otherwise the port may transition into L1 in between descriptor fetches, before we know if the USB device descriptors changed. LPM will be re-enabled after the full device descriptors are fetched, and we can confirm the device still supports USB 2.0 LPM after the reset. We don't need to wait for the USB device to exit L1 before resetting the device, since the xHCI roothub port diagrams show a transition to the Reset state from any of the Ux states (see Figure 34 in the 2012-08-14 xHCI specification update). This patch should be backported to kernels as old as 3.2, that contain the commit 65580b4321eb36f16ae8b5987bfa1bb948fc5112 "xHCI: set USB2 hardware LPM". That was the first commit to enable USB 2.0 hardware-driven Link Power Management. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2013-09-30 17:26:29 +03:00
usb: core : hub: Fix BOS 'NULL pointer' kernel panic When a USB 3.0 mass storage device is disconnected in transporting state, storage device driver may handle it as a transport error and reset the device by invoking usb_reset_and_verify_device() and following could happen: in usb_reset_and_verify_device(): udev->bos = NULL; For U1/U2 enabled devices, driver will disable LPM, and in some conditions: from usb_unlocked_disable_lpm() --> usb_disable_lpm() --> usb_enable_lpm() udev->bos->ss_cap->bU1devExitLat; And it causes 'NULL pointer' and 'kernel panic': [ 157.976257] Unable to handle kernel NULL pointer dereference at virtual address 00000010 ... [ 158.026400] PC is at usb_enable_link_state+0x34/0x2e0 [ 158.031442] LR is at usb_enable_lpm+0x98/0xac ... [ 158.137368] [<ffffffc0006a1cac>] usb_enable_link_state+0x34/0x2e0 [ 158.143451] [<ffffffc0006a1fec>] usb_enable_lpm+0x94/0xac [ 158.148840] [<ffffffc0006a20e8>] usb_disable_lpm+0xa8/0xb4 ... [ 158.214954] Kernel panic - not syncing: Fatal exception This commit moves 'udev->bos = NULL' behind usb_unlocked_disable_lpm() to prevent from NULL pointer access. Issue can be reproduced by following setup: 1) A SS pen drive behind a SS hub connected to the host. 2) Transporting data between the pen drive and the host. 3) Abruptly disconnect hub and pen drive from host. 4) With a chance it crashes. Signed-off-by: Hans Yang <hansy@nvidia.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-01 16:54:59 +08:00
Revert "usb: hub: do not clear BOS field during reset device" This reverts commit d8f00cd685f5c8e0def8593e520a7fef12c22407. Tony writes: This upstream commit is causing an oops: d8f00cd685f5 ("usb: hub: do not clear BOS field during reset device") This patch has already been included in several -stable kernels. Here are the affected kernels: 4.5.0-rc4 (current git) 4.4.2 4.3.6 (currently in review) 4.1.18 3.18.27 3.14.61 How to reproduce the problem: Boot kernel with slub debugging enabled (otherwise memory corruption will cause random oopses later instead of immediately) Plug in USB 3.0 disk to xhci USB 3.0 port dd if=/dev/sdc of=/dev/null bs=65536 (where /dev/sdc is the USB 3.0 disk) Unplug USB cable while dd is still going Oops is immediate: Reported-by: Tony Battersby <tonyb@cybernetics.com> Cc: Du, Changbin <changbin.du@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-20 14:19:34 -08:00
usb: core : hub: Fix BOS 'NULL pointer' kernel panic When a USB 3.0 mass storage device is disconnected in transporting state, storage device driver may handle it as a transport error and reset the device by invoking usb_reset_and_verify_device() and following could happen: in usb_reset_and_verify_device(): udev->bos = NULL; For U1/U2 enabled devices, driver will disable LPM, and in some conditions: from usb_unlocked_disable_lpm() --> usb_disable_lpm() --> usb_enable_lpm() udev->bos->ss_cap->bU1devExitLat; And it causes 'NULL pointer' and 'kernel panic': [ 157.976257] Unable to handle kernel NULL pointer dereference at virtual address 00000010 ... [ 158.026400] PC is at usb_enable_link_state+0x34/0x2e0 [ 158.031442] LR is at usb_enable_lpm+0x98/0xac ... [ 158.137368] [<ffffffc0006a1cac>] usb_enable_link_state+0x34/0x2e0 [ 158.143451] [<ffffffc0006a1fec>] usb_enable_lpm+0x94/0xac [ 158.148840] [<ffffffc0006a20e8>] usb_disable_lpm+0xa8/0xb4 ... [ 158.214954] Kernel panic - not syncing: Fatal exception This commit moves 'udev->bos = NULL' behind usb_unlocked_disable_lpm() to prevent from NULL pointer access. Issue can be reproduced by following setup: 1) A SS pen drive behind a SS hub connected to the host. 2) Transporting data between the pen drive and the host. 3) Abruptly disconnect hub and pen drive from host. 4) With a chance it crashes. Signed-off-by: Hans Yang <hansy@nvidia.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-01 16:54:59 +08:00
usb: hub: Fix usb enumeration issue due to address0 race xHC hardware can only have one slot in default state with address 0 waiting for a unique address at a time, otherwise "undefined behavior may occur" according to xhci spec 5.4.3.4 The address0_mutex exists to prevent this across both xhci roothubs. If hub_port_init() fails, it may unlock the mutex and exit with a xhci slot in default state. If the other xhci roothub calls hub_port_init() at this point we end up with two slots in default state. Make sure the address0_mutex protects the slot default state across hub_port_init() retries, until slot is addressed or disabled. Note, one known minor case is not fixed by this patch. If device needs to be reset during resume, but fails all hub_port_init() retries in usb_reset_and_verify_device(), then it's possible the slot is still left in default state when address0_mutex is unlocked. Cc: <stable@vger.kernel.org> Fixes: 638139eb95d2 ("usb: hub: allow to process more usb hub events in parallel") Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211115221630.871204-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-16 00:16:30 +02:00
USB: hub: Clean up use of port initialization schemes and retries The SET_CONFIG_TRIES macro in hub.c is badly named; it controls the number of port-initialization retry attempts rather than the number of Set-Configuration attempts. Furthermore, the USE_NEW_SCHEME macro and use_new_scheme() function are written in a very confusing manner, making it almost impossible to figure out exactly what they do or check that they are correct. This patch renames SET_CONFIG_TRIES to PORT_INIT_TRIES, removes USE_NEW_SCHEME entirely, and rewrites use_new_scheme() to be much more transparent, with added comments explaining how it works. The patch also pulls the single call site of use_new_scheme() out from the Get-Descriptor retry loop (where it returns the same value each time) and renames the local variable used to store the result. The overall effect is a minor cleanup. However, there is one functional change: If the "use_both_schemes" module parameter isn't set (by default it is set), the existing code does only two retry iterations. After this patch it will always perform four, regardless of the parameter's value. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200928152050.GA134701@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-28 11:20:50 -04:00
usb: core: stop USB enumeration if too many retries When a broken USB accessory connects to a USB host, usbcore might keep doing enumeration retries. If the host has a watchdog mechanism, the kernel panic will happen on the host. This patch provides an attribute early_stop to limit the numbers of retries for each port of a hub. If a port was marked with early_stop attribute, unsuccessful connection attempts will fail quickly. In addition, if an early_stop port has failed to initialize, it will ignore all future connection events until early_stop attribute is clear. Signed-off-by: Ray Chi <raychi@google.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20221107072754.3336357-1-raychi@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-11-07 15:27:54 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
wusb: make ep0_reinit available for modules We need to be able to call ep0_reinit() [renamed to usb_ep0_reinit()] from the WUSB security code. The reason is that when we authenticate the device, it's address changes (from having bit 7 set to having it cleared). Thus, we need to signal the USB stack to reinitialize EP0, so the status with the previous address kept at the HCD layer is cleared and properly reinitialized. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-08 13:24:46 -07:00
USB: core: Fix race by not overwriting udev->descriptor in hub_port_init() Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors(): BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011 CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351 print_report mm/kasan/report.c:462 [inline] kasan_report+0x11c/0x130 mm/kasan/report.c:572 read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 ... Allocated by task 758: ... __do_kmalloc_node mm/slab_common.c:966 [inline] __kmalloc+0x5e/0x190 mm/slab_common.c:979 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:680 [inline] usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887 usb_enumerate_device drivers/usb/core/hub.c:2407 [inline] usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545 As analyzed by Khazhy Kumykov, the cause of this bug is a race between read_descriptors() and hub_port_init(): The first routine uses a field in udev->descriptor, not expecting it to change, while the second overwrites it. Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") this race couldn't occur, because the routines were mutually exclusive thanks to the device locking. Removing that locking from read_descriptors() exposed it to the race. The best way to fix the bug is to keep hub_port_init() from changing udev->descriptor once udev has been initialized and registered. Drivers expect the descriptors stored in the kernel to be immutable; we should not undermine this expectation. In fact, this change should have been made long ago. So now hub_port_init() will take an additional argument, specifying a buffer in which to store the device descriptor it reads. (If udev has not yet been initialized, the buffer pointer will be NULL and then hub_port_init() will store the device descriptor in udev as before.) This eliminates the data race responsible for the out-of-bounds read. The changes to hub_port_init() appear more extensive than they really are, because of indentation changes resulting from an attempt to avoid writing to other parts of the usb_device structure after it has been initialized. Similar changes should be made to the code that reads the BOS descriptor, but that can be handled in a separate patch later on. This patch is sufficient to fix the bug found by syzbot. Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Khazhy Kumykov <khazhy@google.com> Fixes: 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04 15:14:14 -04:00
USB: Make device reset stop retrying after disconnect This patch (as898) changes the port reset code in the hub driver. If a connect change occurs, it is reported the same way as a disconnect (which of course is what it really is). It also changes usb_reset_device(), to prevent the routine from futilely retrying the reset after a disconnect has occurred. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-05-04 11:55:54 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: hub: Fix usb enumeration issue due to address0 race xHC hardware can only have one slot in default state with address 0 waiting for a unique address at a time, otherwise "undefined behavior may occur" according to xhci spec 5.4.3.4 The address0_mutex exists to prevent this across both xhci roothubs. If hub_port_init() fails, it may unlock the mutex and exit with a xhci slot in default state. If the other xhci roothub calls hub_port_init() at this point we end up with two slots in default state. Make sure the address0_mutex protects the slot default state across hub_port_init() retries, until slot is addressed or disabled. Note, one known minor case is not fixed by this patch. If device needs to be reset during resume, but fails all hub_port_init() retries in usb_reset_and_verify_device(), then it's possible the slot is still left in default state when address0_mutex is unlocked. Cc: <stable@vger.kernel.org> Fixes: 638139eb95d2 ("usb: hub: allow to process more usb hub events in parallel") Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211115221630.871204-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-16 00:16:30 +02:00
usbcore: khubd and busy-port handling We don't want khubd to start interfering in the device-resume process merely because the PORT_STATUS_C_SUSPEND feature happens to be set. Ports need to be marked as busy while a resume is taking place. In addition, so long as ports are marked as busy, khubd won't be able to clear their various status-change features. On an interrupt-driven root hub this could lead to an interrupt storm. Root hub IRQs should not be re-enabled until the busy_bits value is equal to 0. This patch (as765) fixes these two potential problems. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-08-11 16:52:39 -04:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
drivers: usb: core: {file,hub,sysfs,usb}.c: Whitespace fixes including: - removing of trailing whitespace - removing spaces before array indexing (foo [] to foo[]) - reindention of a switch-case block - spaces to tabs Signed-off-by: Matthias Beyer <mail@beyermatthias.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-10 23:41:27 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usbcore: compare and release one bos descriptor in usb_reset_and_verify_device() In usb_reset_and_verify_device(), hub_port_init() allocates a new bos descriptor to hold the value read by the device. The new bos descriptor has to be compared with the old one in order to figure out if device 's firmware has changed in which case the device has to be reenumerated. In the original code, none of the two descriptors was deallocated leading to memory leaks. This patch compares the old bos descriptor with the new one to detect change in firmware and releases the newly allocated bos descriptor to prevent memory leak. Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com> Reported-by: Martin MOKREJS <mmokrejs@gmail.com> Tested-by: Martin MOKREJS <mmokrejs@gmail.com> Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-29 21:45:48 +03:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
drivers: usb: core: {file,hub,sysfs,usb}.c: Whitespace fixes including: - removing of trailing whitespace - removing spaces before array indexing (foo [] to foo[]) - reindention of a switch-case block - spaces to tabs Signed-off-by: Matthias Beyer <mail@beyermatthias.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-10 23:41:27 +02:00
USB: don't send Set-Interface after reset This patch (as1221) changes the way usbcore reinitializes a device following a reset or a reset-resume. Currently we call usb_set_interface() for every interface in the active configuration; this is to put the interface into the same altsetting as before the reset and to make sure that the host's endpoint state matches the device's endpoint state. However, sending a Set-Interface request is a waste of time if an interface was already in altsetting 0 before the reset, since it is certainly in altsetting 0 afterward. In addition, many devices can't handle Set-Interface requests -- they crash when they receive them. So instead, the patch adds code to check each interface. If the interface wasn't in altsetting 0 before the reset, we go head with the Set-Interface request as before. But if it was then we skip sending the Set-Interface request, and we clear out the host-side endpoint state by calling usb_disable_interface() followed by usb_enable_interface(). The patch also adds a couple of new comments to explain what's going on. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-02-26 10:21:02 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: Check bandwidth when switching alt settings. Make the USB core check the bandwidth when switching from one interface alternate setting to another. Also check the bandwidth when resetting a configuration (so that alt setting 0 is used). If this check fails, the device's state is unchanged. If the device refuses the new alt setting, re-instate the old alt setting in the host controller hardware. If a USB device doesn't have an alternate interface setting 0, install the first alt setting in its descriptors when a new configuration is requested, or the device is reset. Add a mutex per root hub to protect bandwidth operations: adding/reseting/changing configurations, and changing alternate interface settings. We want to ensure that the xHCI host controller and the USB device are set up for the same configurations and alternate settings. There are two (possibly three) steps to do this: 1. The host controller needs to check that bandwidth is available for a different setting, by issuing and waiting for a configure endpoint command. 2. Once that returns successfully, a control message is sent to the device. 3. If that fails, the host controller must be notified through another configure endpoint command. The mutex is used to make these three operations seem atomic, to prevent another driver from using more bandwidth for a different device while we're in the middle of these operations. While we're touching the bandwidth code, rename usb_hcd_check_bandwidth() to usb_hcd_alloc_bandwidth(). This function does more than just check that the bandwidth change won't exceed the bus bandwidth; it actually changes the bandwidth configuration in the xHCI host controller. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-03 09:44:36 -08:00
usb: Change usb_hcd->bandwidth_mutex to a pointer. 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 <sarah.a.sharp@linux.intel.com>
2010-10-15 08:55:24 -07:00
USB: Check bandwidth when switching alt settings. Make the USB core check the bandwidth when switching from one interface alternate setting to another. Also check the bandwidth when resetting a configuration (so that alt setting 0 is used). If this check fails, the device's state is unchanged. If the device refuses the new alt setting, re-instate the old alt setting in the host controller hardware. If a USB device doesn't have an alternate interface setting 0, install the first alt setting in its descriptors when a new configuration is requested, or the device is reset. Add a mutex per root hub to protect bandwidth operations: adding/reseting/changing configurations, and changing alternate interface settings. We want to ensure that the xHCI host controller and the USB device are set up for the same configurations and alternate settings. There are two (possibly three) steps to do this: 1. The host controller needs to check that bandwidth is available for a different setting, by issuing and waiting for a configure endpoint command. 2. Once that returns successfully, a control message is sent to the device. 3. If that fails, the host controller must be notified through another configure endpoint command. The mutex is used to make these three operations seem atomic, to prevent another driver from using more bandwidth for a different device while we're in the middle of these operations. While we're touching the bandwidth code, rename usb_hcd_check_bandwidth() to usb_hcd_alloc_bandwidth(). This function does more than just check that the bandwidth change won't exceed the bus bandwidth; it actually changes the bandwidth configuration in the xHCI host controller. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-03 09:44:36 -08:00
usb: Change usb_hcd->bandwidth_mutex to a pointer. 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 <sarah.a.sharp@linux.intel.com>
2010-10-15 08:55:24 -07:00
USB: Check bandwidth when switching alt settings. Make the USB core check the bandwidth when switching from one interface alternate setting to another. Also check the bandwidth when resetting a configuration (so that alt setting 0 is used). If this check fails, the device's state is unchanged. If the device refuses the new alt setting, re-instate the old alt setting in the host controller hardware. If a USB device doesn't have an alternate interface setting 0, install the first alt setting in its descriptors when a new configuration is requested, or the device is reset. Add a mutex per root hub to protect bandwidth operations: adding/reseting/changing configurations, and changing alternate interface settings. We want to ensure that the xHCI host controller and the USB device are set up for the same configurations and alternate settings. There are two (possibly three) steps to do this: 1. The host controller needs to check that bandwidth is available for a different setting, by issuing and waiting for a configure endpoint command. 2. Once that returns successfully, a control message is sent to the device. 3. If that fails, the host controller must be notified through another configure endpoint command. The mutex is used to make these three operations seem atomic, to prevent another driver from using more bandwidth for a different device while we're in the middle of these operations. While we're touching the bandwidth code, rename usb_hcd_check_bandwidth() to usb_hcd_alloc_bandwidth(). This function does more than just check that the bandwidth change won't exceed the bus bandwidth; it actually changes the bandwidth configuration in the xHCI host controller. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-03 09:44:36 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: Change usb_hcd->bandwidth_mutex to a pointer. 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 <sarah.a.sharp@linux.intel.com>
2010-10-15 08:55:24 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
drivers: usb: core: {file,hub,sysfs,usb}.c: Whitespace fixes including: - removing of trailing whitespace - removing spaces before array indexing (foo [] to foo[]) - reindention of a switch-case block - spaces to tabs Signed-off-by: Matthias Beyer <mail@beyermatthias.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-10 23:41:27 +02:00
usb: Change usb_hcd->bandwidth_mutex to a pointer. 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 <sarah.a.sharp@linux.intel.com>
2010-10-15 08:55:24 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: don't send Set-Interface after reset This patch (as1221) changes the way usbcore reinitializes a device following a reset or a reset-resume. Currently we call usb_set_interface() for every interface in the active configuration; this is to put the interface into the same altsetting as before the reset and to make sure that the host's endpoint state matches the device's endpoint state. However, sending a Set-Interface request is a waste of time if an interface was already in altsetting 0 before the reset, since it is certainly in altsetting 0 afterward. In addition, many devices can't handle Set-Interface requests -- they crash when they receive them. So instead, the patch adds code to check each interface. If the interface wasn't in altsetting 0 before the reset, we go head with the Set-Interface request as before. But if it was then we skip sending the Set-Interface request, and we clear out the host-side endpoint state by calling usb_disable_interface() followed by usb_enable_interface(). The patch also adds a couple of new comments to explain what's going on. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-02-26 10:21:02 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: Check bandwidth when switching alt settings. Make the USB core check the bandwidth when switching from one interface alternate setting to another. Also check the bandwidth when resetting a configuration (so that alt setting 0 is used). If this check fails, the device's state is unchanged. If the device refuses the new alt setting, re-instate the old alt setting in the host controller hardware. If a USB device doesn't have an alternate interface setting 0, install the first alt setting in its descriptors when a new configuration is requested, or the device is reset. Add a mutex per root hub to protect bandwidth operations: adding/reseting/changing configurations, and changing alternate interface settings. We want to ensure that the xHCI host controller and the USB device are set up for the same configurations and alternate settings. There are two (possibly three) steps to do this: 1. The host controller needs to check that bandwidth is available for a different setting, by issuing and waiting for a configure endpoint command. 2. Once that returns successfully, a control message is sent to the device. 3. If that fails, the host controller must be notified through another configure endpoint command. The mutex is used to make these three operations seem atomic, to prevent another driver from using more bandwidth for a different device while we're in the middle of these operations. While we're touching the bandwidth code, rename usb_hcd_check_bandwidth() to usb_hcd_alloc_bandwidth(). This function does more than just check that the bandwidth change won't exceed the bus bandwidth; it actually changes the bandwidth configuration in the xHCI host controller. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-03 09:44:36 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: don't send Set-Interface after reset This patch (as1221) changes the way usbcore reinitializes a device following a reset or a reset-resume. Currently we call usb_set_interface() for every interface in the active configuration; this is to put the interface into the same altsetting as before the reset and to make sure that the host's endpoint state matches the device's endpoint state. However, sending a Set-Interface request is a waste of time if an interface was already in altsetting 0 before the reset, since it is certainly in altsetting 0 afterward. In addition, many devices can't handle Set-Interface requests -- they crash when they receive them. So instead, the patch adds code to check each interface. If the interface wasn't in altsetting 0 before the reset, we go head with the Set-Interface request as before. But if it was then we skip sending the Set-Interface request, and we clear out the host-side endpoint state by calling usb_disable_interface() followed by usb_enable_interface(). The patch also adds a couple of new comments to explain what's going on. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-02-26 10:21:02 -05:00
USB: Fix duplicate sysfs problem after device reset. Borislav Petkov reports issues with duplicate sysfs endpoint files after a resume from a hibernate. It turns out that the code to support alternate settings under xHCI has issues when a device with a non-default alternate setting is reset during the hibernate: [ 427.681810] Restarting tasks ... [ 427.681995] hub 1-0:1.0: state 7 ports 6 chg 0004 evt 0000 [ 427.682019] usb usb3: usb resume [ 427.682030] ohci_hcd 0000:00:12.0: wakeup root hub [ 427.682191] hub 1-0:1.0: port 2, status 0501, change 0000, 480 Mb/s [ 427.682205] usb 1-2: usb wakeup-resume [ 427.682226] usb 1-2: finish reset-resume [ 427.682886] done. [ 427.734658] ehci_hcd 0000:00:12.2: port 2 high speed [ 427.734663] ehci_hcd 0000:00:12.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT [ 427.746682] hub 3-0:1.0: hub_reset_resume [ 427.746693] hub 3-0:1.0: trying to enable port power on non-switchable hub [ 427.786715] usb 1-2: reset high speed USB device using ehci_hcd and address 2 [ 427.839653] ehci_hcd 0000:00:12.2: port 2 high speed [ 427.839666] ehci_hcd 0000:00:12.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT [ 427.847717] ohci_hcd 0000:00:12.0: GetStatus roothub.portstatus [1] = 0x00010100 CSC PPS [ 427.915497] hub 1-2:1.0: remove_intf_ep_devs: if: ffff88022f9e8800 ->ep_devs_created: 1 [ 427.915774] hub 1-2:1.0: remove_intf_ep_devs: bNumEndpoints: 1 [ 427.915934] hub 1-2:1.0: if: ffff88022f9e8800: endpoint devs removed. [ 427.916158] hub 1-2:1.0: create_intf_ep_devs: if: ffff88022f9e8800 ->ep_devs_created: 0, ->unregistering: 0 [ 427.916434] hub 1-2:1.0: create_intf_ep_devs: bNumEndpoints: 1 [ 427.916609] ep_81: create, parent hub [ 427.916632] ------------[ cut here ]------------ [ 427.916644] WARNING: at fs/sysfs/dir.c:477 sysfs_add_one+0x82/0x96() [ 427.916649] Hardware name: System Product Name [ 427.916653] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:12.2/usb1/1-2/1-2:1.0/ep_81' [ 427.916658] Modules linked in: binfmt_misc kvm_amd kvm powernow_k8 cpufreq_ondemand cpufreq_powersave cpufreq_userspace freq_table cpufreq_conservative ipv6 vfat fat +8250_pnp 8250 pcspkr ohci_hcd serial_core k10temp edac_core [ 427.916694] Pid: 278, comm: khubd Not tainted 2.6.33-rc2-00187-g08d869a-dirty #13 [ 427.916699] Call Trace: The problem is caused by a mismatch between the USB core's view of the device state and the USB device and xHCI host's view of the device state. After the device reset and re-configuration, the device and the xHCI host think they are using alternate setting 0 of all interfaces. However, the USB core keeps track of the old state, which may include non-zero alternate settings. It uses intf->cur_altsetting to keep the endpoint sysfs files for the old state across the reset. The bandwidth allocation functions need to know what the xHCI host thinks the current alternate settings are, so original patch set intf->cur_altsetting to the alternate setting 0. This caused duplicate endpoint files to be created. The solution is to not set intf->cur_altsetting before calling usb_set_interface() in usb_reset_and_verify_device(). Instead, we add a new flag to struct usb_interface to tell usb_hcd_alloc_bandwidth() to use alternate setting 0 as the currently installed alternate setting. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Borislav Petkov <petkovbb@googlemail.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-06 10:16:51 -08:00
USB: Check bandwidth when switching alt settings. Make the USB core check the bandwidth when switching from one interface alternate setting to another. Also check the bandwidth when resetting a configuration (so that alt setting 0 is used). If this check fails, the device's state is unchanged. If the device refuses the new alt setting, re-instate the old alt setting in the host controller hardware. If a USB device doesn't have an alternate interface setting 0, install the first alt setting in its descriptors when a new configuration is requested, or the device is reset. Add a mutex per root hub to protect bandwidth operations: adding/reseting/changing configurations, and changing alternate interface settings. We want to ensure that the xHCI host controller and the USB device are set up for the same configurations and alternate settings. There are two (possibly three) steps to do this: 1. The host controller needs to check that bandwidth is available for a different setting, by issuing and waiting for a configure endpoint command. 2. Once that returns successfully, a control message is sent to the device. 3. If that fails, the host controller must be notified through another configure endpoint command. The mutex is used to make these three operations seem atomic, to prevent another driver from using more bandwidth for a different device while we're in the middle of these operations. While we're touching the bandwidth code, rename usb_hcd_check_bandwidth() to usb_hcd_alloc_bandwidth(). This function does more than just check that the bandwidth change won't exceed the bus bandwidth; it actually changes the bandwidth configuration in the xHCI host controller. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-03 09:44:36 -08:00
USB: Fix duplicate sysfs problem after device reset. Borislav Petkov reports issues with duplicate sysfs endpoint files after a resume from a hibernate. It turns out that the code to support alternate settings under xHCI has issues when a device with a non-default alternate setting is reset during the hibernate: [ 427.681810] Restarting tasks ... [ 427.681995] hub 1-0:1.0: state 7 ports 6 chg 0004 evt 0000 [ 427.682019] usb usb3: usb resume [ 427.682030] ohci_hcd 0000:00:12.0: wakeup root hub [ 427.682191] hub 1-0:1.0: port 2, status 0501, change 0000, 480 Mb/s [ 427.682205] usb 1-2: usb wakeup-resume [ 427.682226] usb 1-2: finish reset-resume [ 427.682886] done. [ 427.734658] ehci_hcd 0000:00:12.2: port 2 high speed [ 427.734663] ehci_hcd 0000:00:12.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT [ 427.746682] hub 3-0:1.0: hub_reset_resume [ 427.746693] hub 3-0:1.0: trying to enable port power on non-switchable hub [ 427.786715] usb 1-2: reset high speed USB device using ehci_hcd and address 2 [ 427.839653] ehci_hcd 0000:00:12.2: port 2 high speed [ 427.839666] ehci_hcd 0000:00:12.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT [ 427.847717] ohci_hcd 0000:00:12.0: GetStatus roothub.portstatus [1] = 0x00010100 CSC PPS [ 427.915497] hub 1-2:1.0: remove_intf_ep_devs: if: ffff88022f9e8800 ->ep_devs_created: 1 [ 427.915774] hub 1-2:1.0: remove_intf_ep_devs: bNumEndpoints: 1 [ 427.915934] hub 1-2:1.0: if: ffff88022f9e8800: endpoint devs removed. [ 427.916158] hub 1-2:1.0: create_intf_ep_devs: if: ffff88022f9e8800 ->ep_devs_created: 0, ->unregistering: 0 [ 427.916434] hub 1-2:1.0: create_intf_ep_devs: bNumEndpoints: 1 [ 427.916609] ep_81: create, parent hub [ 427.916632] ------------[ cut here ]------------ [ 427.916644] WARNING: at fs/sysfs/dir.c:477 sysfs_add_one+0x82/0x96() [ 427.916649] Hardware name: System Product Name [ 427.916653] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:12.2/usb1/1-2/1-2:1.0/ep_81' [ 427.916658] Modules linked in: binfmt_misc kvm_amd kvm powernow_k8 cpufreq_ondemand cpufreq_powersave cpufreq_userspace freq_table cpufreq_conservative ipv6 vfat fat +8250_pnp 8250 pcspkr ohci_hcd serial_core k10temp edac_core [ 427.916694] Pid: 278, comm: khubd Not tainted 2.6.33-rc2-00187-g08d869a-dirty #13 [ 427.916699] Call Trace: The problem is caused by a mismatch between the USB core's view of the device state and the USB device and xHCI host's view of the device state. After the device reset and re-configuration, the device and the xHCI host think they are using alternate setting 0 of all interfaces. However, the USB core keeps track of the old state, which may include non-zero alternate settings. It uses intf->cur_altsetting to keep the endpoint sysfs files for the old state across the reset. The bandwidth allocation functions need to know what the xHCI host thinks the current alternate settings are, so original patch set intf->cur_altsetting to the alternate setting 0. This caused duplicate endpoint files to be created. The solution is to not set intf->cur_altsetting before calling usb_set_interface() in usb_reset_and_verify_device(). Instead, we add a new flag to struct usb_interface to tell usb_hcd_alloc_bandwidth() to use alternate setting 0 as the currently installed alternate setting. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Borislav Petkov <petkovbb@googlemail.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-06 10:16:51 -08:00
USB: don't send Set-Interface after reset This patch (as1221) changes the way usbcore reinitializes a device following a reset or a reset-resume. Currently we call usb_set_interface() for every interface in the active configuration; this is to put the interface into the same altsetting as before the reset and to make sure that the host's endpoint state matches the device's endpoint state. However, sending a Set-Interface request is a waste of time if an interface was already in altsetting 0 before the reset, since it is certainly in altsetting 0 afterward. In addition, many devices can't handle Set-Interface requests -- they crash when they receive them. So instead, the patch adds code to check each interface. If the interface wasn't in altsetting 0 before the reset, we go head with the Set-Interface request as before. But if it was then we skip sending the Set-Interface request, and we clear out the host-side endpoint state by calling usb_disable_interface() followed by usb_enable_interface(). The patch also adds a couple of new comments to explain what's going on. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-02-26 10:21:02 -05:00
USB: Fix duplicate sysfs problem after device reset. Borislav Petkov reports issues with duplicate sysfs endpoint files after a resume from a hibernate. It turns out that the code to support alternate settings under xHCI has issues when a device with a non-default alternate setting is reset during the hibernate: [ 427.681810] Restarting tasks ... [ 427.681995] hub 1-0:1.0: state 7 ports 6 chg 0004 evt 0000 [ 427.682019] usb usb3: usb resume [ 427.682030] ohci_hcd 0000:00:12.0: wakeup root hub [ 427.682191] hub 1-0:1.0: port 2, status 0501, change 0000, 480 Mb/s [ 427.682205] usb 1-2: usb wakeup-resume [ 427.682226] usb 1-2: finish reset-resume [ 427.682886] done. [ 427.734658] ehci_hcd 0000:00:12.2: port 2 high speed [ 427.734663] ehci_hcd 0000:00:12.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT [ 427.746682] hub 3-0:1.0: hub_reset_resume [ 427.746693] hub 3-0:1.0: trying to enable port power on non-switchable hub [ 427.786715] usb 1-2: reset high speed USB device using ehci_hcd and address 2 [ 427.839653] ehci_hcd 0000:00:12.2: port 2 high speed [ 427.839666] ehci_hcd 0000:00:12.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT [ 427.847717] ohci_hcd 0000:00:12.0: GetStatus roothub.portstatus [1] = 0x00010100 CSC PPS [ 427.915497] hub 1-2:1.0: remove_intf_ep_devs: if: ffff88022f9e8800 ->ep_devs_created: 1 [ 427.915774] hub 1-2:1.0: remove_intf_ep_devs: bNumEndpoints: 1 [ 427.915934] hub 1-2:1.0: if: ffff88022f9e8800: endpoint devs removed. [ 427.916158] hub 1-2:1.0: create_intf_ep_devs: if: ffff88022f9e8800 ->ep_devs_created: 0, ->unregistering: 0 [ 427.916434] hub 1-2:1.0: create_intf_ep_devs: bNumEndpoints: 1 [ 427.916609] ep_81: create, parent hub [ 427.916632] ------------[ cut here ]------------ [ 427.916644] WARNING: at fs/sysfs/dir.c:477 sysfs_add_one+0x82/0x96() [ 427.916649] Hardware name: System Product Name [ 427.916653] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:12.2/usb1/1-2/1-2:1.0/ep_81' [ 427.916658] Modules linked in: binfmt_misc kvm_amd kvm powernow_k8 cpufreq_ondemand cpufreq_powersave cpufreq_userspace freq_table cpufreq_conservative ipv6 vfat fat +8250_pnp 8250 pcspkr ohci_hcd serial_core k10temp edac_core [ 427.916694] Pid: 278, comm: khubd Not tainted 2.6.33-rc2-00187-g08d869a-dirty #13 [ 427.916699] Call Trace: The problem is caused by a mismatch between the USB core's view of the device state and the USB device and xHCI host's view of the device state. After the device reset and re-configuration, the device and the xHCI host think they are using alternate setting 0 of all interfaces. However, the USB core keeps track of the old state, which may include non-zero alternate settings. It uses intf->cur_altsetting to keep the endpoint sysfs files for the old state across the reset. The bandwidth allocation functions need to know what the xHCI host thinks the current alternate settings are, so original patch set intf->cur_altsetting to the alternate setting 0. This caused duplicate endpoint files to be created. The solution is to not set intf->cur_altsetting before calling usb_set_interface() in usb_reset_and_verify_device(). Instead, we add a new flag to struct usb_interface to tell usb_hcd_alloc_bandwidth() to use alternate setting 0 as the currently installed alternate setting. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Borislav Petkov <petkovbb@googlemail.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-06 10:16:51 -08:00
USB: don't send Set-Interface after reset This patch (as1221) changes the way usbcore reinitializes a device following a reset or a reset-resume. Currently we call usb_set_interface() for every interface in the active configuration; this is to put the interface into the same altsetting as before the reset and to make sure that the host's endpoint state matches the device's endpoint state. However, sending a Set-Interface request is a waste of time if an interface was already in altsetting 0 before the reset, since it is certainly in altsetting 0 afterward. In addition, many devices can't handle Set-Interface requests -- they crash when they receive them. So instead, the patch adds code to check each interface. If the interface wasn't in altsetting 0 before the reset, we go head with the Set-Interface request as before. But if it was then we skip sending the Set-Interface request, and we clear out the host-side endpoint state by calling usb_disable_interface() followed by usb_enable_interface(). The patch also adds a couple of new comments to explain what's going on. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-02-26 10:21:02 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usb: Clear host_endpoint->streams when implicitly freeing streams If streams are still allocated on device-reset or set-interface then the hcd code implictly frees the streams. Clear host_endpoint->streams in this case so that if a driver later tries to re-allocate them it won't run afoul of the device already having streams check in usb_alloc_streams(). Note normally streams still being allocated at reset / set-intf would be a driver bug, but this can happen without it being a driver bug on reset-resume. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-11-08 16:37:26 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
USB: Enable Latency Tolerance Messaging (LTM). 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-06-25 12:08:08 -07:00
USB: Add new USB LPM helpers Use new helpers to make LPM enabling/disabling more clear. This is a preparation to subsequent patch. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: stable <stable@vger.kernel.org> # after much soaking Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-12 03:54:24 +08:00
USB: Disable USB 3.0 LPM in critical sections. 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-02 14:25:52 -07:00
USB: Enable Latency Tolerance Messaging (LTM). 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-06-25 12:08:08 -07:00
Revert "usb: hub: do not clear BOS field during reset device" This reverts commit d8f00cd685f5c8e0def8593e520a7fef12c22407. Tony writes: This upstream commit is causing an oops: d8f00cd685f5 ("usb: hub: do not clear BOS field during reset device") This patch has already been included in several -stable kernels. Here are the affected kernels: 4.5.0-rc4 (current git) 4.4.2 4.3.6 (currently in review) 4.1.18 3.18.27 3.14.61 How to reproduce the problem: Boot kernel with slub debugging enabled (otherwise memory corruption will cause random oopses later instead of immediately) Plug in USB 3.0 disk to xhci USB 3.0 port dd if=/dev/sdc of=/dev/null bs=65536 (where /dev/sdc is the USB 3.0 disk) Unplug USB cable while dd is still going Oops is immediate: Reported-by: Tony Battersby <tonyb@cybernetics.com> Cc: Du, Changbin <changbin.du@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-20 14:19:34 -08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
drivers: usb: core: {file,hub,sysfs,usb}.c: Whitespace fixes including: - removing of trailing whitespace - removing spaces before array indexing (foo [] to foo[]) - reindention of a switch-case block - spaces to tabs Signed-off-by: Matthias Beyer <mail@beyermatthias.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-10 23:41:27 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
usbcore: compare and release one bos descriptor in usb_reset_and_verify_device() In usb_reset_and_verify_device(), hub_port_init() allocates a new bos descriptor to hold the value read by the device. The new bos descriptor has to be compared with the old one in order to figure out if device 's firmware has changed in which case the device has to be reenumerated. In the original code, none of the two descriptors was deallocated leading to memory leaks. This patch compares the old bos descriptor with the new one to detect change in firmware and releases the newly allocated bos descriptor to prevent memory leak. Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com> Reported-by: Martin MOKREJS <mmokrejs@gmail.com> Tested-by: Martin MOKREJS <mmokrejs@gmail.com> Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-29 21:45:48 +03:00
usb: core : hub: Fix BOS 'NULL pointer' kernel panic When a USB 3.0 mass storage device is disconnected in transporting state, storage device driver may handle it as a transport error and reset the device by invoking usb_reset_and_verify_device() and following could happen: in usb_reset_and_verify_device(): udev->bos = NULL; For U1/U2 enabled devices, driver will disable LPM, and in some conditions: from usb_unlocked_disable_lpm() --> usb_disable_lpm() --> usb_enable_lpm() udev->bos->ss_cap->bU1devExitLat; And it causes 'NULL pointer' and 'kernel panic': [ 157.976257] Unable to handle kernel NULL pointer dereference at virtual address 00000010 ... [ 158.026400] PC is at usb_enable_link_state+0x34/0x2e0 [ 158.031442] LR is at usb_enable_lpm+0x98/0xac ... [ 158.137368] [<ffffffc0006a1cac>] usb_enable_link_state+0x34/0x2e0 [ 158.143451] [<ffffffc0006a1fec>] usb_enable_lpm+0x94/0xac [ 158.148840] [<ffffffc0006a20e8>] usb_disable_lpm+0xa8/0xb4 ... [ 158.214954] Kernel panic - not syncing: Fatal exception This commit moves 'udev->bos = NULL' behind usb_unlocked_disable_lpm() to prevent from NULL pointer access. Issue can be reproduced by following setup: 1) A SS pen drive behind a SS hub connected to the host. 2) Transporting data between the pen drive and the host. 3) Abruptly disconnect hub and pen drive from host. 4) With a chance it crashes. Signed-off-by: Hans Yang <hansy@nvidia.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-01 16:54:59 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] usbcore: port reset for composite devices This patch (as699) adds usb_reset_composite_device(), a routine for sending a USB port reset to a device with multiple interfaces owned by different drivers. Drivers are notified about impending and completed resets through two new methods in the usb_driver structure. The patch modifieds the usbfs ioctl code to make it use the new routine instead of usb_reset_device(). Follow-up patches will modify the hub, usb-storage, and usbhid drivers so they can utilize this new API. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-01 13:33:42 -04:00
USB: fix usb_reset_device and usb_reset_composite_device(take 3) This patch renames the existing usb_reset_device in hub.c to usb_reset_and_verify_device and renames the existing usb_reset_composite_device to usb_reset_device. Also the new usb_reset_and_verify_device does't need to be EXPORTED . The idea of the patch is that external interface driver should warn the other interfaces' driver of the same device before and after reseting the usb device. One interface driver shoud call _old_ usb_reset_composite_device instead of _old_ usb_reset_device since it can't assume the device contains only one interface. The _old_ usb_reset_composite_device is safe for single interface device also. we rename the two functions to make the change easily. This patch is under guideline from Alan Stern. Signed-off-by: Ming Lei <tom.leiming@gmail.com>
2008-06-18 22:00:29 +08:00
usb: Allow USB device to be warm reset in suspended state On Dell WD15 dock, sometimes USB ethernet cannot be detected after plugging cable to the ethernet port, the hub and roothub get runtime resumed and runtime suspended immediately: ... [ 433.315169] xhci_hcd 0000:3a:00.0: hcd_pci_runtime_resume: 0 [ 433.315204] usb usb4: usb auto-resume [ 433.315226] hub 4-0:1.0: hub_resume [ 433.315239] xhci_hcd 0000:3a:00.0: Get port status 4-1 read: 0x10202e2, return 0x10343 [ 433.315264] usb usb4-port1: status 0343 change 0001 [ 433.315279] xhci_hcd 0000:3a:00.0: clear port1 connect change, portsc: 0x10002e2 [ 433.315293] xhci_hcd 0000:3a:00.0: Get port status 4-2 read: 0x2a0, return 0x2a0 [ 433.317012] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling. [ 433.422282] xhci_hcd 0000:3a:00.0: Get port status 4-1 read: 0x10002e2, return 0x343 [ 433.422307] usb usb4-port1: do warm reset [ 433.422311] usb 4-1: device reset not allowed in state 8 [ 433.422339] hub 4-0:1.0: state 7 ports 2 chg 0002 evt 0000 [ 433.422346] xhci_hcd 0000:3a:00.0: Get port status 4-1 read: 0x10002e2, return 0x343 [ 433.422356] usb usb4-port1: do warm reset [ 433.422358] usb 4-1: device reset not allowed in state 8 [ 433.422428] xhci_hcd 0000:3a:00.0: set port remote wake mask, actual port 0 status = 0xf0002e2 [ 433.422455] xhci_hcd 0000:3a:00.0: set port remote wake mask, actual port 1 status = 0xe0002a0 [ 433.422465] hub 4-0:1.0: hub_suspend [ 433.422475] usb usb4: bus auto-suspend, wakeup 1 [ 433.426161] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling. [ 433.466209] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.510204] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.554051] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.598235] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.642154] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.686204] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.730205] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.774203] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.818207] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.862040] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.862053] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling. [ 433.862077] xhci_hcd 0000:3a:00.0: xhci_suspend: stopping port polling. [ 433.862096] xhci_hcd 0000:3a:00.0: // Setting command ring address to 0x8578fc001 [ 433.862312] xhci_hcd 0000:3a:00.0: hcd_pci_runtime_suspend: 0 [ 433.862445] xhci_hcd 0000:3a:00.0: PME# enabled [ 433.902376] xhci_hcd 0000:3a:00.0: restoring config space at offset 0xc (was 0x0, writing 0x20) [ 433.902395] xhci_hcd 0000:3a:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100403) [ 433.902490] xhci_hcd 0000:3a:00.0: PME# disabled [ 433.902504] xhci_hcd 0000:3a:00.0: enabling bus mastering [ 433.902547] xhci_hcd 0000:3a:00.0: // Setting command ring address to 0x8578fc001 [ 433.902649] pcieport 0000:00:1b.0: PME: Spurious native interrupt! [ 433.902839] xhci_hcd 0000:3a:00.0: Port change event, 4-1, id 3, portsc: 0xb0202e2 [ 433.902842] xhci_hcd 0000:3a:00.0: resume root hub [ 433.902845] xhci_hcd 0000:3a:00.0: handle_port_status: starting port polling. [ 433.902877] xhci_hcd 0000:3a:00.0: xhci_resume: starting port polling. [ 433.902889] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling. [ 433.902891] xhci_hcd 0000:3a:00.0: hcd_pci_runtime_resume: 0 [ 433.902919] usb usb4: usb wakeup-resume [ 433.902942] usb usb4: usb auto-resume [ 433.902966] hub 4-0:1.0: hub_resume ... As Mathias pointed out, the hub enters Cold Attach Status state and requires a warm reset. However usb_reset_device() bails out early when the device is in suspended state, as its callers port_event() and hub_event() don't always resume the device. Since there's nothing wrong to reset a suspended device, allow usb_reset_device() to do so to solve the issue. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191106062710.29880-1-kai.heng.feng@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-06 14:27:10 +08:00
[PATCH] usbcore: port reset for composite devices This patch (as699) adds usb_reset_composite_device(), a routine for sending a USB port reset to a device with multiple interfaces owned by different drivers. Drivers are notified about impending and completed resets through two new methods in the usb_driver structure. The patch modifieds the usbfs ioctl code to make it use the new routine instead of usb_reset_device(). Follow-up patches will modify the hub, usb-storage, and usbhid drivers so they can utilize this new API. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-01 13:33:42 -04:00
usb: fix some scripts/kernel-doc warnings When building the htmldocs (in verbose mode), scripts/kernel-doc reports the following type of warnings: Warning(drivers/usb/core/usb.c:76): No description found for return value of 'usb_find_alt_setting' Fix them by: - adding some missing descriptions of return values - using "Return" sections for those descriptions Signed-off-by: Yacine Belkadi <yacine.belkadi.1@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-02 20:10:04 +02:00
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>
2022-08-26 15:31:32 -04:00
USB: core: Fix RST error in hub.c A recent commit added an invalid RST expression to a kerneldoc comment in hub.c. The fix is trivial. Fixes: 9c6d778800b9 ("USB: core: Prevent nested device-reset calls") Cc: <stable@vger.kernel.org> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/YxDDcsLtRZ7c20pq@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-01 10:36:34 -04:00
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>
2022-08-26 15:31:32 -04:00
[PATCH] usbcore: port reset for composite devices This patch (as699) adds usb_reset_composite_device(), a routine for sending a USB port reset to a device with multiple interfaces owned by different drivers. Drivers are notified about impending and completed resets through two new methods in the usb_driver structure. The patch modifieds the usbfs ioctl code to make it use the new routine instead of usb_reset_device(). Follow-up patches will modify the hub, usb-storage, and usbhid drivers so they can utilize this new API. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-01 13:33:42 -04:00
usb: fix some scripts/kernel-doc warnings When building the htmldocs (in verbose mode), scripts/kernel-doc reports the following type of warnings: Warning(drivers/usb/core/usb.c:76): No description found for return value of 'usb_find_alt_setting' Fix them by: - adding some missing descriptions of return values - using "Return" sections for those descriptions Signed-off-by: Yacine Belkadi <yacine.belkadi.1@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-02 20:10:04 +02:00
[PATCH] usbcore: port reset for composite devices This patch (as699) adds usb_reset_composite_device(), a routine for sending a USB port reset to a device with multiple interfaces owned by different drivers. Drivers are notified about impending and completed resets through two new methods in the usb_driver structure. The patch modifieds the usbfs ioctl code to make it use the new routine instead of usb_reset_device(). Follow-up patches will modify the hub, usb-storage, and usbhid drivers so they can utilize this new API. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-01 13:33:42 -04:00
USB: Force unbinding of drivers lacking reset_resume or other methods This patch (as1024) takes care of a FIXME issue: Drivers that don't have the necessary suspend, resume, reset_resume, pre_reset, or post_reset methods will be unbound and their interface reprobed when one of the unsupported events occurs. This is made slightly more difficult by the fact that bind operations won't work during a system sleep transition. So instead the code has to defer the operation until the transition ends. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-23 16:00:40 -04:00
[PATCH] usbcore: port reset for composite devices This patch (as699) adds usb_reset_composite_device(), a routine for sending a USB port reset to a device with multiple interfaces owned by different drivers. Drivers are notified about impending and completed resets through two new methods in the usb_driver structure. The patch modifieds the usbfs ioctl code to make it use the new routine instead of usb_reset_device(). Follow-up patches will modify the hub, usb-storage, and usbhid drivers so they can utilize this new API. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-01 13:33:42 -04:00
USB: fix usb_reset_device and usb_reset_composite_device(take 3) This patch renames the existing usb_reset_device in hub.c to usb_reset_and_verify_device and renames the existing usb_reset_composite_device to usb_reset_device. Also the new usb_reset_and_verify_device does't need to be EXPORTED . The idea of the patch is that external interface driver should warn the other interfaces' driver of the same device before and after reseting the usb device. One interface driver shoud call _old_ usb_reset_composite_device instead of _old_ usb_reset_device since it can't assume the device contains only one interface. The _old_ usb_reset_composite_device is safe for single interface device also. we rename the two functions to make the change easily. This patch is under guideline from Alan Stern. Signed-off-by: Ming Lei <tom.leiming@gmail.com>
2008-06-18 22:00:29 +08:00
[PATCH] usbcore: port reset for composite devices This patch (as699) adds usb_reset_composite_device(), a routine for sending a USB port reset to a device with multiple interfaces owned by different drivers. Drivers are notified about impending and completed resets through two new methods in the usb_driver structure. The patch modifieds the usbfs ioctl code to make it use the new routine instead of usb_reset_device(). Follow-up patches will modify the hub, usb-storage, and usbhid drivers so they can utilize this new API. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-01 13:33:42 -04:00
USB: updates to usb_reset_composite_device() This patch (as1023) updates the code in usb_reset_composite_device(): Some local variable declarations are moved to inner loops. The interface locks are not acquired. This isn't necessary any more; its only reason was to prevent an interface from being suspended or resumed during the reset. But now interface power management is controlled by the USB device lock, not by the interface lock. The check for whether the interface is registered is removed. There doesn't seem to be any reason for checking; a driver for a non-registered interface deserves to be informed of device resets just as much as any other. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-03 15:44:29 -05:00
usb: forbid memory allocation with I/O during bus reset If one storage interface or usb network interface(iSCSI case) exists in current configuration, memory allocation with GFP_KERNEL during usb_device_reset() might trigger I/O transfer on the storage interface itself and cause deadlock because the 'us->dev_mutex' is held in .pre_reset() and the storage interface can't do I/O transfer when the reset is triggered by other interface, or the error handling can't be completed if the reset is triggered by the storage itself (error handling path). Signed-off-by: Ming Lei <ming.lei@canonical.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: David Decotigny <david.decotigny@google.com> Cc: Tom Herbert <therbert@google.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Jens Axboe <axboe@kernel.dk> Cc: Minchan Kim <minchan@kernel.org> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Oliver Neukum <oneukum@suse.de> Reviewed-by: Jiri Kosina <jkosina@suse.cz> Cc: Mel Gorman <mel@csn.ul.ie> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Michal Hocko <mhocko@suse.cz> Cc: Ingo Molnar <mingo@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-22 16:34:22 -08:00
usb: introduce port status lock In general we do not want khubd to act on port status changes that are the result of in progress resets or USB runtime PM operations. Specifically port power control testing has been able to trigger an unintended disconnect in hub_port_connect_change(), paraphrasing: if ((portstatus & USB_PORT_STAT_CONNECTION) && udev && udev->state != USB_STATE_NOTATTACHED) { if (portstatus & USB_PORT_STAT_ENABLE) { /* Nothing to do */ } else if (udev->state == USB_STATE_SUSPENDED && udev->persist_enabled) { ... } else { /* Don't resuscitate */; } } ...by falling to the "Don't resuscitate" path or missing USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of modifying the port status. So, we want a new lock to hold off khubd for a given port while the child device is being suspended, resumed, or reset. The lock ordering rules are now usb_lock_device() => usb_lock_port(). This is mandated by the device core which may hold the device_lock on the usb_device before invoking usb_port_{suspend|resume} which in turn take the status_lock on the usb_port. We attempt to hold the status_lock for the duration of a port_event() run, and drop/re-acquire it when needing to take the device_lock. The lock is also dropped/re-acquired during hub_port_reconnect(). This patch also deletes hub->busy_bits as all use cases are now covered by port PM runtime synchronization or the port->status_lock and it pushes down usb_device_lock() into usb_remote_wakeup(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:26 -07:00
[PATCH] usbcore: port reset for composite devices This patch (as699) adds usb_reset_composite_device(), a routine for sending a USB port reset to a device with multiple interfaces owned by different drivers. Drivers are notified about impending and completed resets through two new methods in the usb_driver structure. The patch modifieds the usbfs ioctl code to make it use the new routine instead of usb_reset_device(). Follow-up patches will modify the hub, usb-storage, and usbhid drivers so they can utilize this new API. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-01 13:33:42 -04:00
usb: introduce port status lock In general we do not want khubd to act on port status changes that are the result of in progress resets or USB runtime PM operations. Specifically port power control testing has been able to trigger an unintended disconnect in hub_port_connect_change(), paraphrasing: if ((portstatus & USB_PORT_STAT_CONNECTION) && udev && udev->state != USB_STATE_NOTATTACHED) { if (portstatus & USB_PORT_STAT_ENABLE) { /* Nothing to do */ } else if (udev->state == USB_STATE_SUSPENDED && udev->persist_enabled) { ... } else { /* Don't resuscitate */; } } ...by falling to the "Don't resuscitate" path or missing USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of modifying the port status. So, we want a new lock to hold off khubd for a given port while the child device is being suspended, resumed, or reset. The lock ordering rules are now usb_lock_device() => usb_lock_port(). This is mandated by the device core which may hold the device_lock on the usb_device before invoking usb_port_{suspend|resume} which in turn take the status_lock on the usb_port. We attempt to hold the status_lock for the duration of a port_event() run, and drop/re-acquire it when needing to take the device_lock. The lock is also dropped/re-acquired during hub_port_reconnect(). This patch also deletes hub->busy_bits as all use cases are now covered by port PM runtime synchronization or the port->status_lock and it pushes down usb_device_lock() into usb_remote_wakeup(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:26 -07:00
[PATCH] usbcore: port reset for composite devices This patch (as699) adds usb_reset_composite_device(), a routine for sending a USB port reset to a device with multiple interfaces owned by different drivers. Drivers are notified about impending and completed resets through two new methods in the usb_driver structure. The patch modifieds the usbfs ioctl code to make it use the new routine instead of usb_reset_device(). Follow-up patches will modify the hub, usb-storage, and usbhid drivers so they can utilize this new API. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-01 13:33:42 -04:00
usb: Allow USB device to be warm reset in suspended state On Dell WD15 dock, sometimes USB ethernet cannot be detected after plugging cable to the ethernet port, the hub and roothub get runtime resumed and runtime suspended immediately: ... [ 433.315169] xhci_hcd 0000:3a:00.0: hcd_pci_runtime_resume: 0 [ 433.315204] usb usb4: usb auto-resume [ 433.315226] hub 4-0:1.0: hub_resume [ 433.315239] xhci_hcd 0000:3a:00.0: Get port status 4-1 read: 0x10202e2, return 0x10343 [ 433.315264] usb usb4-port1: status 0343 change 0001 [ 433.315279] xhci_hcd 0000:3a:00.0: clear port1 connect change, portsc: 0x10002e2 [ 433.315293] xhci_hcd 0000:3a:00.0: Get port status 4-2 read: 0x2a0, return 0x2a0 [ 433.317012] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling. [ 433.422282] xhci_hcd 0000:3a:00.0: Get port status 4-1 read: 0x10002e2, return 0x343 [ 433.422307] usb usb4-port1: do warm reset [ 433.422311] usb 4-1: device reset not allowed in state 8 [ 433.422339] hub 4-0:1.0: state 7 ports 2 chg 0002 evt 0000 [ 433.422346] xhci_hcd 0000:3a:00.0: Get port status 4-1 read: 0x10002e2, return 0x343 [ 433.422356] usb usb4-port1: do warm reset [ 433.422358] usb 4-1: device reset not allowed in state 8 [ 433.422428] xhci_hcd 0000:3a:00.0: set port remote wake mask, actual port 0 status = 0xf0002e2 [ 433.422455] xhci_hcd 0000:3a:00.0: set port remote wake mask, actual port 1 status = 0xe0002a0 [ 433.422465] hub 4-0:1.0: hub_suspend [ 433.422475] usb usb4: bus auto-suspend, wakeup 1 [ 433.426161] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling. [ 433.466209] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.510204] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.554051] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.598235] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.642154] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.686204] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.730205] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.774203] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.818207] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.862040] xhci_hcd 0000:3a:00.0: port 0 polling in bus suspend, waiting [ 433.862053] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling. [ 433.862077] xhci_hcd 0000:3a:00.0: xhci_suspend: stopping port polling. [ 433.862096] xhci_hcd 0000:3a:00.0: // Setting command ring address to 0x8578fc001 [ 433.862312] xhci_hcd 0000:3a:00.0: hcd_pci_runtime_suspend: 0 [ 433.862445] xhci_hcd 0000:3a:00.0: PME# enabled [ 433.902376] xhci_hcd 0000:3a:00.0: restoring config space at offset 0xc (was 0x0, writing 0x20) [ 433.902395] xhci_hcd 0000:3a:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100403) [ 433.902490] xhci_hcd 0000:3a:00.0: PME# disabled [ 433.902504] xhci_hcd 0000:3a:00.0: enabling bus mastering [ 433.902547] xhci_hcd 0000:3a:00.0: // Setting command ring address to 0x8578fc001 [ 433.902649] pcieport 0000:00:1b.0: PME: Spurious native interrupt! [ 433.902839] xhci_hcd 0000:3a:00.0: Port change event, 4-1, id 3, portsc: 0xb0202e2 [ 433.902842] xhci_hcd 0000:3a:00.0: resume root hub [ 433.902845] xhci_hcd 0000:3a:00.0: handle_port_status: starting port polling. [ 433.902877] xhci_hcd 0000:3a:00.0: xhci_resume: starting port polling. [ 433.902889] xhci_hcd 0000:3a:00.0: xhci_hub_status_data: stopping port polling. [ 433.902891] xhci_hcd 0000:3a:00.0: hcd_pci_runtime_resume: 0 [ 433.902919] usb usb4: usb wakeup-resume [ 433.902942] usb usb4: usb auto-resume [ 433.902966] hub 4-0:1.0: hub_resume ... As Mathias pointed out, the hub enters Cold Attach Status state and requires a warm reset. However usb_reset_device() bails out early when the device is in suspended state, as its callers port_event() and hub_event() don't always resume the device. Since there's nothing wrong to reset a suspended device, allow usb_reset_device() to do so to solve the issue. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191106062710.29880-1-kai.heng.feng@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-06 14:27:10 +08:00
[PATCH] usbcore: port reset for composite devices This patch (as699) adds usb_reset_composite_device(), a routine for sending a USB port reset to a device with multiple interfaces owned by different drivers. Drivers are notified about impending and completed resets through two new methods in the usb_driver structure. The patch modifieds the usbfs ioctl code to make it use the new routine instead of usb_reset_device(). Follow-up patches will modify the hub, usb-storage, and usbhid drivers so they can utilize this new API. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-01 13:33:42 -04:00
usb: introduce port status lock In general we do not want khubd to act on port status changes that are the result of in progress resets or USB runtime PM operations. Specifically port power control testing has been able to trigger an unintended disconnect in hub_port_connect_change(), paraphrasing: if ((portstatus & USB_PORT_STAT_CONNECTION) && udev && udev->state != USB_STATE_NOTATTACHED) { if (portstatus & USB_PORT_STAT_ENABLE) { /* Nothing to do */ } else if (udev->state == USB_STATE_SUSPENDED && udev->persist_enabled) { ... } else { /* Don't resuscitate */; } } ...by falling to the "Don't resuscitate" path or missing USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of modifying the port status. So, we want a new lock to hold off khubd for a given port while the child device is being suspended, resumed, or reset. The lock ordering rules are now usb_lock_device() => usb_lock_port(). This is mandated by the device core which may hold the device_lock on the usb_device before invoking usb_port_{suspend|resume} which in turn take the status_lock on the usb_port. We attempt to hold the status_lock for the duration of a port_event() run, and drop/re-acquire it when needing to take the device_lock. The lock is also dropped/re-acquired during hub_port_reconnect(). This patch also deletes hub->busy_bits as all use cases are now covered by port PM runtime synchronization or the port->status_lock and it pushes down usb_device_lock() into usb_remote_wakeup(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:26 -07:00
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>
2022-08-26 15:31:32 -04:00
usb: introduce port status lock In general we do not want khubd to act on port status changes that are the result of in progress resets or USB runtime PM operations. Specifically port power control testing has been able to trigger an unintended disconnect in hub_port_connect_change(), paraphrasing: if ((portstatus & USB_PORT_STAT_CONNECTION) && udev && udev->state != USB_STATE_NOTATTACHED) { if (portstatus & USB_PORT_STAT_ENABLE) { /* Nothing to do */ } else if (udev->state == USB_STATE_SUSPENDED && udev->persist_enabled) { ... } else { /* Don't resuscitate */; } } ...by falling to the "Don't resuscitate" path or missing USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of modifying the port status. So, we want a new lock to hold off khubd for a given port while the child device is being suspended, resumed, or reset. The lock ordering rules are now usb_lock_device() => usb_lock_port(). This is mandated by the device core which may hold the device_lock on the usb_device before invoking usb_port_{suspend|resume} which in turn take the status_lock on the usb_port. We attempt to hold the status_lock for the duration of a port_event() run, and drop/re-acquire it when needing to take the device_lock. The lock is also dropped/re-acquired during hub_port_reconnect(). This patch also deletes hub->busy_bits as all use cases are now covered by port PM runtime synchronization or the port->status_lock and it pushes down usb_device_lock() into usb_remote_wakeup(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:26 -07:00
usb: forbid memory allocation with I/O during bus reset If one storage interface or usb network interface(iSCSI case) exists in current configuration, memory allocation with GFP_KERNEL during usb_device_reset() might trigger I/O transfer on the storage interface itself and cause deadlock because the 'us->dev_mutex' is held in .pre_reset() and the storage interface can't do I/O transfer when the reset is triggered by other interface, or the error handling can't be completed if the reset is triggered by the storage itself (error handling path). Signed-off-by: Ming Lei <ming.lei@canonical.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: David Decotigny <david.decotigny@google.com> Cc: Tom Herbert <therbert@google.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Jens Axboe <axboe@kernel.dk> Cc: Minchan Kim <minchan@kernel.org> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Oliver Neukum <oneukum@suse.de> Reviewed-by: Jiri Kosina <jkosina@suse.cz> Cc: Mel Gorman <mel@csn.ul.ie> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Michal Hocko <mhocko@suse.cz> Cc: Ingo Molnar <mingo@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-22 16:34:22 -08:00
usbcore: add autosuspend/autoresume infrastructure This patch (as739) adds the basic infrastructure for USB autosuspend and autoresume. The main features are: PM usage counters added to struct usb_device and struct usb_interface, indicating whether it's okay to autosuspend them or they are currently in use. Flag added to usb_device indicating whether the current suspend/resume operation originated from outside or as an autosuspend/autoresume. Flag added to usb_driver indicating whether the driver supports autosuspend. If not, no device bound to the driver will be autosuspended. Mutex added to usb_device for protecting PM operations. Unlike the device semaphore, the locking rule for the pm_mutex is that you must acquire the locks going _up_ the device tree. New routines handling autosuspend/autoresume requests for interfaces and devices. Suspend and resume requests are propagated up the device tree (but not outside the USB subsystem). work_struct added to usb_device, for carrying out delayed autosuspend requests. Autoresume added (and autosuspend prevented) during probe and disconnect. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-08-30 15:47:02 -04:00
usbcore: remove unused argument in autosuspend Thanks to several earlier patches, usb_autosuspend_device() and usb_autoresume_device() are never called with a second argument other than 1. This patch (as819) removes the now-redundant argument. It also consolidates some common code between those two routines, putting it into a new subroutine called usb_autopm_do_device(). And it includes a sizable kerneldoc update for the affected functions. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-11-20 11:38:46 -05:00
usbcore: add autosuspend/autoresume infrastructure This patch (as739) adds the basic infrastructure for USB autosuspend and autoresume. The main features are: PM usage counters added to struct usb_device and struct usb_interface, indicating whether it's okay to autosuspend them or they are currently in use. Flag added to usb_device indicating whether the current suspend/resume operation originated from outside or as an autosuspend/autoresume. Flag added to usb_driver indicating whether the driver supports autosuspend. If not, no device bound to the driver will be autosuspended. Mutex added to usb_device for protecting PM operations. Unlike the device semaphore, the locking rule for the pm_mutex is that you must acquire the locks going _up_ the device tree. New routines handling autosuspend/autoresume requests for interfaces and devices. Suspend and resume requests are propagated up the device tree (but not outside the USB subsystem). work_struct added to usb_device, for carrying out delayed autosuspend requests. Autoresume added (and autosuspend prevented) during probe and disconnect. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-08-30 15:47:02 -04:00
[PATCH] usbcore: port reset for composite devices This patch (as699) adds usb_reset_composite_device(), a routine for sending a USB port reset to a device with multiple interfaces owned by different drivers. Drivers are notified about impending and completed resets through two new methods in the usb_driver structure. The patch modifieds the usbfs ioctl code to make it use the new routine instead of usb_reset_device(). Follow-up patches will modify the hub, usb-storage, and usbhid drivers so they can utilize this new API. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-01 13:33:42 -04:00
USB: updates to usb_reset_composite_device() This patch (as1023) updates the code in usb_reset_composite_device(): Some local variable declarations are moved to inner loops. The interface locks are not acquired. This isn't necessary any more; its only reason was to prevent an interface from being suspended or resumed during the reset. But now interface power management is controlled by the USB device lock, not by the interface lock. The check for whether the interface is registered is removed. There doesn't seem to be any reason for checking; a driver for a non-registered interface deserves to be informed of device resets just as much as any other. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-03 15:44:29 -05:00
USB: Force unbinding of drivers lacking reset_resume or other methods This patch (as1024) takes care of a FIXME issue: Drivers that don't have the necessary suspend, resume, reset_resume, pre_reset, or post_reset methods will be unbound and their interface reprobed when one of the unsupported events occurs. This is made slightly more difficult by the fact that bind operations won't work during a system sleep transition. So instead the code has to defer the operation until the transition ends. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-23 16:00:40 -04:00
USB: updates to usb_reset_composite_device() This patch (as1023) updates the code in usb_reset_composite_device(): Some local variable declarations are moved to inner loops. The interface locks are not acquired. This isn't necessary any more; its only reason was to prevent an interface from being suspended or resumed during the reset. But now interface power management is controlled by the USB device lock, not by the interface lock. The check for whether the interface is registered is removed. There doesn't seem to be any reason for checking; a driver for a non-registered interface deserves to be informed of device resets just as much as any other. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-03 15:44:29 -05:00
[PATCH] usbcore: port reset for composite devices This patch (as699) adds usb_reset_composite_device(), a routine for sending a USB port reset to a device with multiple interfaces owned by different drivers. Drivers are notified about impending and completed resets through two new methods in the usb_driver structure. The patch modifieds the usbfs ioctl code to make it use the new routine instead of usb_reset_device(). Follow-up patches will modify the hub, usb-storage, and usbhid drivers so they can utilize this new API. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-01 13:33:42 -04:00
USB: Force unbinding of drivers lacking reset_resume or other methods This patch (as1024) takes care of a FIXME issue: Drivers that don't have the necessary suspend, resume, reset_resume, pre_reset, or post_reset methods will be unbound and their interface reprobed when one of the unsupported events occurs. This is made slightly more difficult by the fact that bind operations won't work during a system sleep transition. So instead the code has to defer the operation until the transition ends. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-23 16:00:40 -04:00
[PATCH] usbcore: port reset for composite devices This patch (as699) adds usb_reset_composite_device(), a routine for sending a USB port reset to a device with multiple interfaces owned by different drivers. Drivers are notified about impending and completed resets through two new methods in the usb_driver structure. The patch modifieds the usbfs ioctl code to make it use the new routine instead of usb_reset_device(). Follow-up patches will modify the hub, usb-storage, and usbhid drivers so they can utilize this new API. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-01 13:33:42 -04:00
usb: introduce port status lock In general we do not want khubd to act on port status changes that are the result of in progress resets or USB runtime PM operations. Specifically port power control testing has been able to trigger an unintended disconnect in hub_port_connect_change(), paraphrasing: if ((portstatus & USB_PORT_STAT_CONNECTION) && udev && udev->state != USB_STATE_NOTATTACHED) { if (portstatus & USB_PORT_STAT_ENABLE) { /* Nothing to do */ } else if (udev->state == USB_STATE_SUSPENDED && udev->persist_enabled) { ... } else { /* Don't resuscitate */; } } ...by falling to the "Don't resuscitate" path or missing USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of modifying the port status. So, we want a new lock to hold off khubd for a given port while the child device is being suspended, resumed, or reset. The lock ordering rules are now usb_lock_device() => usb_lock_port(). This is mandated by the device core which may hold the device_lock on the usb_device before invoking usb_port_{suspend|resume} which in turn take the status_lock on the usb_port. We attempt to hold the status_lock for the duration of a port_event() run, and drop/re-acquire it when needing to take the device_lock. The lock is also dropped/re-acquired during hub_port_reconnect(). This patch also deletes hub->busy_bits as all use cases are now covered by port PM runtime synchronization or the port->status_lock and it pushes down usb_device_lock() into usb_remote_wakeup(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:26 -07:00
USB: fix usb_reset_device and usb_reset_composite_device(take 3) This patch renames the existing usb_reset_device in hub.c to usb_reset_and_verify_device and renames the existing usb_reset_composite_device to usb_reset_device. Also the new usb_reset_and_verify_device does't need to be EXPORTED . The idea of the patch is that external interface driver should warn the other interfaces' driver of the same device before and after reseting the usb device. One interface driver shoud call _old_ usb_reset_composite_device instead of _old_ usb_reset_device since it can't assume the device contains only one interface. The _old_ usb_reset_composite_device is safe for single interface device also. we rename the two functions to make the change easily. This patch is under guideline from Alan Stern. Signed-off-by: Ming Lei <tom.leiming@gmail.com>
2008-06-18 22:00:29 +08:00
usb: introduce port status lock In general we do not want khubd to act on port status changes that are the result of in progress resets or USB runtime PM operations. Specifically port power control testing has been able to trigger an unintended disconnect in hub_port_connect_change(), paraphrasing: if ((portstatus & USB_PORT_STAT_CONNECTION) && udev && udev->state != USB_STATE_NOTATTACHED) { if (portstatus & USB_PORT_STAT_ENABLE) { /* Nothing to do */ } else if (udev->state == USB_STATE_SUSPENDED && udev->persist_enabled) { ... } else { /* Don't resuscitate */; } } ...by falling to the "Don't resuscitate" path or missing USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of modifying the port status. So, we want a new lock to hold off khubd for a given port while the child device is being suspended, resumed, or reset. The lock ordering rules are now usb_lock_device() => usb_lock_port(). This is mandated by the device core which may hold the device_lock on the usb_device before invoking usb_port_{suspend|resume} which in turn take the status_lock on the usb_port. We attempt to hold the status_lock for the duration of a port_event() run, and drop/re-acquire it when needing to take the device_lock. The lock is also dropped/re-acquired during hub_port_reconnect(). This patch also deletes hub->busy_bits as all use cases are now covered by port PM runtime synchronization or the port->status_lock and it pushes down usb_device_lock() into usb_remote_wakeup(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:09:26 -07:00
[PATCH] usbcore: port reset for composite devices This patch (as699) adds usb_reset_composite_device(), a routine for sending a USB port reset to a device with multiple interfaces owned by different drivers. Drivers are notified about impending and completed resets through two new methods in the usb_driver structure. The patch modifieds the usbfs ioctl code to make it use the new routine instead of usb_reset_device(). Follow-up patches will modify the hub, usb-storage, and usbhid drivers so they can utilize this new API. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-01 13:33:42 -04:00
USB: updates to usb_reset_composite_device() This patch (as1023) updates the code in usb_reset_composite_device(): Some local variable declarations are moved to inner loops. The interface locks are not acquired. This isn't necessary any more; its only reason was to prevent an interface from being suspended or resumed during the reset. But now interface power management is controlled by the USB device lock, not by the interface lock. The check for whether the interface is registered is removed. There doesn't seem to be any reason for checking; a driver for a non-registered interface deserves to be informed of device resets just as much as any other. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-03 15:44:29 -05:00
USB: Force unbinding of drivers lacking reset_resume or other methods This patch (as1024) takes care of a FIXME issue: Drivers that don't have the necessary suspend, resume, reset_resume, pre_reset, or post_reset methods will be unbound and their interface reprobed when one of the unsupported events occurs. This is made slightly more difficult by the fact that bind operations won't work during a system sleep transition. So instead the code has to defer the operation until the transition ends. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-23 16:00:40 -04:00
USB: updates to usb_reset_composite_device() This patch (as1023) updates the code in usb_reset_composite_device(): Some local variable declarations are moved to inner loops. The interface locks are not acquired. This isn't necessary any more; its only reason was to prevent an interface from being suspended or resumed during the reset. But now interface power management is controlled by the USB device lock, not by the interface lock. The check for whether the interface is registered is removed. There doesn't seem to be any reason for checking; a driver for a non-registered interface deserves to be informed of device resets just as much as any other. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-12-03 15:44:29 -05:00
USB: Force unbinding of drivers lacking reset_resume or other methods This patch (as1024) takes care of a FIXME issue: Drivers that don't have the necessary suspend, resume, reset_resume, pre_reset, or post_reset methods will be unbound and their interface reprobed when one of the unsupported events occurs. This is made slightly more difficult by the fact that bind operations won't work during a system sleep transition. So instead the code has to defer the operation until the transition ends. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-23 16:00:40 -04:00
[PATCH] usbcore: port reset for composite devices This patch (as699) adds usb_reset_composite_device(), a routine for sending a USB port reset to a device with multiple interfaces owned by different drivers. Drivers are notified about impending and completed resets through two new methods in the usb_driver structure. The patch modifieds the usbfs ioctl code to make it use the new routine instead of usb_reset_device(). Follow-up patches will modify the hub, usb-storage, and usbhid drivers so they can utilize this new API. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-01 13:33:42 -04:00
USB: Force unbinding of drivers lacking reset_resume or other methods This patch (as1024) takes care of a FIXME issue: Drivers that don't have the necessary suspend, resume, reset_resume, pre_reset, or post_reset methods will be unbound and their interface reprobed when one of the unsupported events occurs. This is made slightly more difficult by the fact that bind operations won't work during a system sleep transition. So instead the code has to defer the operation until the transition ends. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-23 16:00:40 -04:00
USB: unbind all interfaces before rebinding any When a driver doesn't have pre_reset, post_reset, or reset_resume methods, the USB core unbinds that driver when its device undergoes a reset or a reset-resume, and then rebinds it afterward. The existing straightforward implementation can lead to problems, because each interface gets unbound and rebound before the next interface is handled. If a driver claims additional interfaces, the claim may fail because the old binding instance may still own the additional interface when the new instance tries to claim it. This patch fixes the problem by first unbinding all the interfaces that are marked (i.e., their needs_binding flag is set) and then rebinding all of them. The patch also makes the helper functions in driver.c a little more uniform and adjusts some out-of-date comments. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: "Poulain, Loic" <loic.poulain@intel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-12 11:30:38 -04:00
[PATCH] usbcore: port reset for composite devices This patch (as699) adds usb_reset_composite_device(), a routine for sending a USB port reset to a device with multiple interfaces owned by different drivers. Drivers are notified about impending and completed resets through two new methods in the usb_driver structure. The patch modifieds the usbfs ioctl code to make it use the new routine instead of usb_reset_device(). Follow-up patches will modify the hub, usb-storage, and usbhid drivers so they can utilize this new API. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-01 13:33:42 -04:00
USB: core: Don't unbind interfaces following device reset failure The SCSI core does not like to have devices or hosts unregistered while error recovery is in progress. Trying to do so can lead to self-deadlock: Part of the removal code tries to obtain a lock already held by the error handler. This can cause problems for the usb-storage and uas drivers, because their error handler routines perform a USB reset, and if the reset fails then the USB core automatically goes on to unbind all drivers from the device's interfaces -- all while still in the context of the SCSI error handler. As it turns out, practically all the scenarios leading to a USB reset failure end up causing a device disconnect (the main error pathway in usb_reset_and_verify_device(), at the end of the routine, calls hub_port_logical_disconnect() before returning). As a result, the hub_wq thread will soon become aware of the problem and will unbind all the device's drivers in its own context, not in the error-handler's context. This means that usb_reset_device() does not need to call usb_unbind_and_rebind_marked_interfaces() in cases where usb_reset_and_verify_device() has returned an error, because hub_wq will take care of everything anyway. This particular problem was observed in somewhat artificial circumstances, by using usbfs to tell a hub to power-down a port connected to a USB-3 mass storage device using the UAS protocol. With the port turned off, the currently executing command timed out and the error handler started running. The USB reset naturally failed, because the hub port was off, and the error handler deadlocked as described above. Not carrying out the call to usb_unbind_and_rebind_marked_interfaces() fixes this issue. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Kento Kobayashi <Kento.A.Kobayashi@sony.com> Tested-by: Kento Kobayashi <Kento.A.Kobayashi@sony.com> CC: Bart Van Assche <bvanassche@acm.org> CC: Martin K. Petersen <martin.petersen@oracle.com> CC: Jacky Cao <Jacky.Cao@sony.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-16 10:50:01 -04:00
[PATCH] usbcore: port reset for composite devices This patch (as699) adds usb_reset_composite_device(), a routine for sending a USB port reset to a device with multiple interfaces owned by different drivers. Drivers are notified about impending and completed resets through two new methods in the usb_driver structure. The patch modifieds the usbfs ioctl code to make it use the new routine instead of usb_reset_device(). Follow-up patches will modify the hub, usb-storage, and usbhid drivers so they can utilize this new API. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-01 13:33:42 -04:00
usbcore: remove unused argument in autosuspend Thanks to several earlier patches, usb_autosuspend_device() and usb_autoresume_device() are never called with a second argument other than 1. This patch (as819) removes the now-redundant argument. It also consolidates some common code between those two routines, putting it into a new subroutine called usb_autopm_do_device(). And it includes a sizable kerneldoc update for the affected functions. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-11-20 11:38:46 -05:00
usb: forbid memory allocation with I/O during bus reset If one storage interface or usb network interface(iSCSI case) exists in current configuration, memory allocation with GFP_KERNEL during usb_device_reset() might trigger I/O transfer on the storage interface itself and cause deadlock because the 'us->dev_mutex' is held in .pre_reset() and the storage interface can't do I/O transfer when the reset is triggered by other interface, or the error handling can't be completed if the reset is triggered by the storage itself (error handling path). Signed-off-by: Ming Lei <ming.lei@canonical.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: David Decotigny <david.decotigny@google.com> Cc: Tom Herbert <therbert@google.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Jens Axboe <axboe@kernel.dk> Cc: Minchan Kim <minchan@kernel.org> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Oliver Neukum <oneukum@suse.de> Reviewed-by: Jiri Kosina <jkosina@suse.cz> Cc: Mel Gorman <mel@csn.ul.ie> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Michal Hocko <mhocko@suse.cz> Cc: Ingo Molnar <mingo@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-22 16:34:22 -08:00
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>
2022-08-26 15:31:32 -04:00
[PATCH] usbcore: port reset for composite devices This patch (as699) adds usb_reset_composite_device(), a routine for sending a USB port reset to a device with multiple interfaces owned by different drivers. Drivers are notified about impending and completed resets through two new methods in the usb_driver structure. The patch modifieds the usbfs ioctl code to make it use the new routine instead of usb_reset_device(). Follow-up patches will modify the hub, usb-storage, and usbhid drivers so they can utilize this new API. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-01 13:33:42 -04:00
USB: fix usb_reset_device and usb_reset_composite_device(take 3) This patch renames the existing usb_reset_device in hub.c to usb_reset_and_verify_device and renames the existing usb_reset_composite_device to usb_reset_device. Also the new usb_reset_and_verify_device does't need to be EXPORTED . The idea of the patch is that external interface driver should warn the other interfaces' driver of the same device before and after reseting the usb device. One interface driver shoud call _old_ usb_reset_composite_device instead of _old_ usb_reset_device since it can't assume the device contains only one interface. The _old_ usb_reset_composite_device is safe for single interface device also. we rename the two functions to make the change easily. This patch is under guideline from Alan Stern. Signed-off-by: Ming Lei <tom.leiming@gmail.com>
2008-06-18 22:00:29 +08:00
USB: Introduce usb_queue_reset() to do resets from atomic contexts This patch introduces a new call to be able to do a USB reset from an atomic contect. This is quite helpful in USB callbacks to handle errors (when the only thing that can be done is to do a device reset). It is done queuing a work struct that will do the actual reset. The struct is "attached" to an interface so pending requests from an interface are removed when said interface is unbound from the driver. The call flow then becomes: usb_queue_reset_device() __usb_queue_reset_device() [workqueue] usb_reset_device() usb_probe_interface() usb_cancel_queue_reset() [error path] usb_unbind_interface() usb_cancel_queue_reset() usb_driver_release_interface() usb_cancel_queue_reset() Note usb_cancel_queue_reset() needs smarts to try not to unqueue when it is actually being executed. This happens when we run the reset from the workqueue: usb_reset_device() is called and on interface unbind time, usb_cancel_queue_reset() would be called. That would deadlock on cancel_work_sync(). To avoid that, we set (before running usb_reset_device()) usb_intf->reset_running and clear it inmediately after returning. Patch is against 2.6.28-rc2 and depends on http://marc.info/?l=linux-usb&m=122581634925308&w=2 (as submitted by Alan Stern). Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-13 10:31:35 -08:00
USB: don't cancel queued resets when unbinding drivers 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 <stern@rowland.harvard.edu> Reported-by: Russell King - ARM Linux <linux@arm.linux.org.uk> Reported-by: Olivier Sobrie <olivier@sobrie.be> Tested-by: Olivier Sobrie <olivier@sobrie.be> Cc: stable <stable@vger.kernel.org> # 3.19 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-01-21 14:02:43 -05:00
USB: Introduce usb_queue_reset() to do resets from atomic contexts This patch introduces a new call to be able to do a USB reset from an atomic contect. This is quite helpful in USB callbacks to handle errors (when the only thing that can be done is to do a device reset). It is done queuing a work struct that will do the actual reset. The struct is "attached" to an interface so pending requests from an interface are removed when said interface is unbound from the driver. The call flow then becomes: usb_queue_reset_device() __usb_queue_reset_device() [workqueue] usb_reset_device() usb_probe_interface() usb_cancel_queue_reset() [error path] usb_unbind_interface() usb_cancel_queue_reset() usb_driver_release_interface() usb_cancel_queue_reset() Note usb_cancel_queue_reset() needs smarts to try not to unqueue when it is actually being executed. This happens when we run the reset from the workqueue: usb_reset_device() is called and on interface unbind time, usb_cancel_queue_reset() would be called. That would deadlock on cancel_work_sync(). To avoid that, we set (before running usb_reset_device()) usb_intf->reset_running and clear it inmediately after returning. Patch is against 2.6.28-rc2 and depends on http://marc.info/?l=linux-usb&m=122581634925308&w=2 (as submitted by Alan Stern). Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-13 10:31:35 -08:00
USB: don't cancel queued resets when unbinding drivers 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 <stern@rowland.harvard.edu> Reported-by: Russell King - ARM Linux <linux@arm.linux.org.uk> Reported-by: Olivier Sobrie <olivier@sobrie.be> Tested-by: Olivier Sobrie <olivier@sobrie.be> Cc: stable <stable@vger.kernel.org> # 3.19 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-01-21 14:02:43 -05:00
USB: Introduce usb_queue_reset() to do resets from atomic contexts This patch introduces a new call to be able to do a USB reset from an atomic contect. This is quite helpful in USB callbacks to handle errors (when the only thing that can be done is to do a device reset). It is done queuing a work struct that will do the actual reset. The struct is "attached" to an interface so pending requests from an interface are removed when said interface is unbound from the driver. The call flow then becomes: usb_queue_reset_device() __usb_queue_reset_device() [workqueue] usb_reset_device() usb_probe_interface() usb_cancel_queue_reset() [error path] usb_unbind_interface() usb_cancel_queue_reset() usb_driver_release_interface() usb_cancel_queue_reset() Note usb_cancel_queue_reset() needs smarts to try not to unqueue when it is actually being executed. This happens when we run the reset from the workqueue: usb_reset_device() is called and on interface unbind time, usb_cancel_queue_reset() would be called. That would deadlock on cancel_work_sync(). To avoid that, we set (before running usb_reset_device()) usb_intf->reset_running and clear it inmediately after returning. Patch is against 2.6.28-rc2 and depends on http://marc.info/?l=linux-usb&m=122581634925308&w=2 (as submitted by Alan Stern). Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-13 10:31:35 -08:00
USB: don't cancel queued resets when unbinding drivers 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 <stern@rowland.harvard.edu> Reported-by: Russell King - ARM Linux <linux@arm.linux.org.uk> Reported-by: Olivier Sobrie <olivier@sobrie.be> Tested-by: Olivier Sobrie <olivier@sobrie.be> Cc: stable <stable@vger.kernel.org> # 3.19 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-01-21 14:02:43 -05:00
USB: Introduce usb_queue_reset() to do resets from atomic contexts This patch introduces a new call to be able to do a USB reset from an atomic contect. This is quite helpful in USB callbacks to handle errors (when the only thing that can be done is to do a device reset). It is done queuing a work struct that will do the actual reset. The struct is "attached" to an interface so pending requests from an interface are removed when said interface is unbound from the driver. The call flow then becomes: usb_queue_reset_device() __usb_queue_reset_device() [workqueue] usb_reset_device() usb_probe_interface() usb_cancel_queue_reset() [error path] usb_unbind_interface() usb_cancel_queue_reset() usb_driver_release_interface() usb_cancel_queue_reset() Note usb_cancel_queue_reset() needs smarts to try not to unqueue when it is actually being executed. This happens when we run the reset from the workqueue: usb_reset_device() is called and on interface unbind time, usb_cancel_queue_reset() would be called. That would deadlock on cancel_work_sync(). To avoid that, we set (before running usb_reset_device()) usb_intf->reset_running and clear it inmediately after returning. Patch is against 2.6.28-rc2 and depends on http://marc.info/?l=linux-usb&m=122581634925308&w=2 (as submitted by Alan Stern). Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-13 10:31:35 -08:00
usb: move children to struct usb_port The usb_device structure contains an array of usb_device "children". This array is only valid if the usb_device is a hub, so it makes no sense to store it there. Instead, store the usb_device child in its parent usb_port structure. Since usb_port is an internal USB core structure, add a new function to get the USB device child, usb_hub_find_child(). Add a new macro, usb_hub_get_each_child(), to iterate over all the children attached to a particular USB hub. Remove the printing the USB children array pointer from the usb-ip driver, since it's really not necessary. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-05 13:44:32 +08:00
usb: fix some scripts/kernel-doc warnings When building the htmldocs (in verbose mode), scripts/kernel-doc reports the following type of warnings: Warning(drivers/usb/core/usb.c:76): No description found for return value of 'usb_find_alt_setting' Fix them by: - adding some missing descriptions of return values - using "Return" sections for those descriptions Signed-off-by: Yacine Belkadi <yacine.belkadi.1@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-02 20:10:04 +02:00
usb: move children to struct usb_port The usb_device structure contains an array of usb_device "children". This array is only valid if the usb_device is a hub, so it makes no sense to store it there. Instead, store the usb_device child in its parent usb_port structure. Since usb_port is an internal USB core structure, add a new function to get the USB device child, usb_hub_find_child(). Add a new macro, usb_hub_get_each_child(), to iterate over all the children attached to a particular USB hub. Remove the printing the USB children array pointer from the usb-ip driver, since it's really not necessary. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-05 13:44:32 +08:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
usb: move children to struct usb_port The usb_device structure contains an array of usb_device "children". This array is only valid if the usb_device is a hub, so it makes no sense to store it there. Instead, store the usb_device child in its parent usb_port structure. Since usb_port is an internal USB core structure, add a new function to get the USB device child, usb_hub_find_child(). Add a new macro, usb_hub_get_each_child(), to iterate over all the children attached to a particular USB hub. Remove the printing the USB children array pointer from the usb-ip driver, since it's really not necessary. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-05 13:44:32 +08:00
usb/acpi: Bind ACPI node to USB port, not usb_device. In the ACPI DSDT table, only usb root hub and usb ports are ACPI device nodes. Originally, we bound the usb port's ACPI node to the usb device attached to the port. However, we want to access those ACPI port methods when the port is empty, and there's no usb_device associated with that port. Now that the usb port is a real device, we can bind the port's ACPI node to struct usb_port instead. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-05 13:44:33 +08:00
USB: Set usb port's DeviceRemovable according acpi information ACPI provide "_PLD" and "_UPC" aml methods to describe usb port visibility and connectability. This patch is to add usb_hub_adjust_DeviceRemovable() to adjust usb hub port's DeviceRemovable according ACPI information and invoke it in the rh_call_control(). When hub descriptor request is issued at first time, usb port device isn't created and usb port is not bound with acpi. So first hub descriptor request is not changed based on ACPI information. After usb port devices being created, call usb_hub_adjust_DeviceRemovable in the hub_configure() and then set hub port's DeviceRemovable according ACPI information and this also works for non-root hub. 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>
2013-01-21 22:18:00 +08:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
USB: Set usb port's DeviceRemovable according acpi information ACPI provide "_PLD" and "_UPC" aml methods to describe usb port visibility and connectability. This patch is to add usb_hub_adjust_DeviceRemovable() to adjust usb hub port's DeviceRemovable according ACPI information and invoke it in the rh_call_control(). When hub descriptor request is issued at first time, usb port device isn't created and usb port is not bound with acpi. So first hub descriptor request is not changed based on ACPI information. After usb port devices being created, call usb_hub_adjust_DeviceRemovable in the hub_configure() and then set hub port's DeviceRemovable according ACPI information and this also works for non-root hub. 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>
2013-01-21 22:18:00 +08:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
USB: Set usb port's DeviceRemovable according acpi information ACPI provide "_PLD" and "_UPC" aml methods to describe usb port visibility and connectability. This patch is to add usb_hub_adjust_DeviceRemovable() to adjust usb hub port's DeviceRemovable according ACPI information and invoke it in the rh_call_control(). When hub descriptor request is issued at first time, usb port device isn't created and usb port is not bound with acpi. So first hub descriptor request is not changed based on ACPI information. After usb port devices being created, call usb_hub_adjust_DeviceRemovable in the hub_configure() and then set hub port's DeviceRemovable according ACPI information and this also works for non-root hub. 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>
2013-01-21 22:18:00 +08:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
USB: Set usb port's DeviceRemovable according acpi information ACPI provide "_PLD" and "_UPC" aml methods to describe usb port visibility and connectability. This patch is to add usb_hub_adjust_DeviceRemovable() to adjust usb hub port's DeviceRemovable according ACPI information and invoke it in the rh_call_control(). When hub descriptor request is issued at first time, usb port device isn't created and usb port is not bound with acpi. So first hub descriptor request is not changed based on ACPI information. After usb port devices being created, call usb_hub_adjust_DeviceRemovable in the hub_configure() and then set hub port's DeviceRemovable according ACPI information and this also works for non-root hub. 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>
2013-01-21 22:18:00 +08:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
USB: Set usb port's DeviceRemovable according acpi information ACPI provide "_PLD" and "_UPC" aml methods to describe usb port visibility and connectability. This patch is to add usb_hub_adjust_DeviceRemovable() to adjust usb hub port's DeviceRemovable according ACPI information and invoke it in the rh_call_control(). When hub descriptor request is issued at first time, usb port device isn't created and usb port is not bound with acpi. So first hub descriptor request is not changed based on ACPI information. After usb port devices being created, call usb_hub_adjust_DeviceRemovable in the hub_configure() and then set hub port's DeviceRemovable according ACPI information and this also works for non-root hub. 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>
2013-01-21 22:18:00 +08:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
USB: Set usb port's DeviceRemovable according acpi information ACPI provide "_PLD" and "_UPC" aml methods to describe usb port visibility and connectability. This patch is to add usb_hub_adjust_DeviceRemovable() to adjust usb hub port's DeviceRemovable according ACPI information and invoke it in the rh_call_control(). When hub descriptor request is issued at first time, usb port device isn't created and usb port is not bound with acpi. So first hub descriptor request is not changed based on ACPI information. After usb port devices being created, call usb_hub_adjust_DeviceRemovable in the hub_configure() and then set hub port's DeviceRemovable according ACPI information and this also works for non-root hub. 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>
2013-01-21 22:18:00 +08:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
USB: Set usb port's DeviceRemovable according acpi information ACPI provide "_PLD" and "_UPC" aml methods to describe usb port visibility and connectability. This patch is to add usb_hub_adjust_DeviceRemovable() to adjust usb hub port's DeviceRemovable according ACPI information and invoke it in the rh_call_control(). When hub descriptor request is issued at first time, usb port device isn't created and usb port is not bound with acpi. So first hub descriptor request is not changed based on ACPI information. After usb port devices being created, call usb_hub_adjust_DeviceRemovable in the hub_configure() and then set hub port's DeviceRemovable according ACPI information and this also works for non-root hub. 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>
2013-01-21 22:18:00 +08:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
USB: Set usb port's DeviceRemovable according acpi information ACPI provide "_PLD" and "_UPC" aml methods to describe usb port visibility and connectability. This patch is to add usb_hub_adjust_DeviceRemovable() to adjust usb hub port's DeviceRemovable according ACPI information and invoke it in the rh_call_control(). When hub descriptor request is issued at first time, usb port device isn't created and usb port is not bound with acpi. So first hub descriptor request is not changed based on ACPI information. After usb port devices being created, call usb_hub_adjust_DeviceRemovable in the hub_configure() and then set hub port's DeviceRemovable according ACPI information and this also works for non-root hub. 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>
2013-01-21 22:18:00 +08:00
usb: rename usb_port device objects The current port name "portX" is ambiguous. Before adding more port messages rename ports to "<hub-device-name>-portX" This is an ABI change, but the suspicion is that it will go unnoticed as the port power control implementation has been broken since its introduction. If however, someone was relying on the old name we can add sysfs links from the old name to the new name. Additionally, it unifies/simplifies port dev_printk messages and modifies instances of: dev_XXX(hub->intfdev, ..."port %d"... dev_XXX(&hdev->dev, ..."port%d"... into: dev_XXX(&port_dev->dev, ... Now that the names are unique usb_port devices it would be nice if they could be included in /sys/bus/usb. However, it turns out that this breaks 'lsusb -t'. For now, create a dummy port driver so that print messages are prefixed "usb 1-1-port3" rather than the subsystem-ambiguous " 1-1-port3". Finally, it corrects an odd usage of sscanf("port%d") in usb-acpi.c. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-20 18:08:17 -07:00
USB: Set usb port's DeviceRemovable according acpi information ACPI provide "_PLD" and "_UPC" aml methods to describe usb port visibility and connectability. This patch is to add usb_hub_adjust_DeviceRemovable() to adjust usb hub port's DeviceRemovable according ACPI information and invoke it in the rh_call_control(). When hub descriptor request is issued at first time, usb port device isn't created and usb port is not bound with acpi. So first hub descriptor request is not changed based on ACPI information. After usb port devices being created, call usb_hub_adjust_DeviceRemovable in the hub_configure() and then set hub port's DeviceRemovable according ACPI information and this also works for non-root hub. 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>
2013-01-21 22:18:00 +08:00
usb/acpi: Bind ACPI node to USB port, not usb_device. In the ACPI DSDT table, only usb root hub and usb ports are ACPI device nodes. Originally, we bound the usb port's ACPI node to the usb device attached to the port. However, we want to access those ACPI port methods when the port is empty, and there's no usb_device associated with that port. Now that the usb port is a real device, we can bind the port's ACPI node to struct usb_port instead. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-05 13:44:33 +08:00
usb: fix some scripts/kernel-doc warnings When building the htmldocs (in verbose mode), scripts/kernel-doc reports the following type of warnings: Warning(drivers/usb/core/usb.c:76): No description found for return value of 'usb_find_alt_setting' Fix them by: - adding some missing descriptions of return values - using "Return" sections for those descriptions Signed-off-by: Yacine Belkadi <yacine.belkadi.1@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-02 20:10:04 +02:00
usb/acpi: Bind ACPI node to USB port, not usb_device. In the ACPI DSDT table, only usb root hub and usb ports are ACPI device nodes. Originally, we bound the usb port's ACPI node to the usb device attached to the port. However, we want to access those ACPI port methods when the port is empty, and there's no usb_device associated with that port. Now that the usb port is a real device, we can bind the port's ACPI node to struct usb_port instead. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-05 13:44:33 +08:00
usb: add usb port auto power off mechanism This patch is to add usb port auto power off mechanism. When usb device is suspending, usb core will suspend usb port and usb port runtime pm callback will clear PORT_POWER feature to power off port if all conditions were met. These conditions are remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist enable. When it resumes, power on port again. Add did_runtime_put in the struct usb_port to ensure pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put to true when call pm_runtime_put(portdev) during suspending. The pm_runtime_get(portdev) only will be called when did_runtime_put is set to true during resuming. Set did_runtime_put to false after calling pm_runtime_get(portdev). Make clear_port_feature() and hdev_to_hub() as global symbol. Rename clear_port_feature() to usb_clear_port_feature() and hdev_to_hub() to usb_hub_to_struct_hub(). Extend hub_port_debounce() with the fuction of debouncing to be connected. Add two wraps: hub_port_debounce_be_connected() and hub_port_debouce_be_stable(). Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds needs around 1.5 or more to make the hub port status to be connected steadily after being powered off and powered on. Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-23 04:26:30 +08:00
usb/acpi: Bind ACPI node to USB port, not usb_device. In the ACPI DSDT table, only usb root hub and usb ports are ACPI device nodes. Originally, we bound the usb port's ACPI node to the usb device attached to the port. However, we want to access those ACPI port methods when the port is empty, and there's no usb_device associated with that port. Now that the usb port is a real device, we can bind the port's ACPI node to struct usb_port instead. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-05 13:44:33 +08:00
usb: check usb_hub_to_struct_hub() return value usb_hub_to_struct_hub() can return NULL in some unlikely cases. Add checks where appropriate, or pass the hub pointer as an additional argument if it's known to be valid. The places it makes sense to check usb_hub_to_struct_hub() are picked based on feedback from Alan Stern. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-18 17:28:48 +03:00
ACPI: Eliminate the DEVICE_ACPI_HANDLE() macro Since DEVICE_ACPI_HANDLE() is now literally identical to ACPI_HANDLE(), replace it with the latter everywhere and drop its definition from include/acpi.h. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-14 23:17:21 +01:00
usb/acpi: Bind ACPI node to USB port, not usb_device. In the ACPI DSDT table, only usb root hub and usb ports are ACPI device nodes. Originally, we bound the usb port's ACPI node to the usb device attached to the port. However, we want to access those ACPI port methods when the port is empty, and there's no usb_device associated with that port. Now that the usb port is a real device, we can bind the port's ACPI node to struct usb_port instead. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-05 13:44:33 +08:00