summaryrefslogtreecommitdiffstats
path: root/drivers/usb/core/hub.c
Commit message (Collapse)AuthorAgeFilesLines
* module_param: make bool parameters really bool (drivers & misc)Rusty Russell2012-01-131-4/+4
| | | | | | | | | | | | module_param(bool) used to counter-intuitively take an int. In fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy trick. It's time to remove the int/unsigned int option. For this version it'll simply give a warning, but it'll break next kernel version. Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* USB: Adding #define in hub_configure() and hcd.c fileAman Deep2011-12-091-44/+44
| | | | | | | | | | | | | | | | | 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>
* USB: remove BKL commentsDavidlohr Bueso2011-11-261-1/+0
| | | | | | | The BKL is a gonner. Signed-off-by: Davidlohr Bueso <dave@gnu.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* usb, xhci: Clear warm reset change event during initDon Zickus2011-11-041-0/+6
| | | | | | | | | | | | | | | | 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
* Merge branch 'pm-for-linus' of ↵Linus Torvalds2011-10-251-8/+7
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm * 'pm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (63 commits) PM / Clocks: Remove redundant NULL checks before kfree() PM / Documentation: Update docs about suspend and CPU hotplug ACPI / PM: Add Sony VGN-FW21E to nonvs blacklist. ARM: mach-shmobile: sh7372 A4R support (v4) ARM: mach-shmobile: sh7372 A3SP support (v4) PM / Sleep: Mark devices involved in wakeup signaling during suspend PM / Hibernate: Improve performance of LZO/plain hibernation, checksum image PM / Hibernate: Do not initialize static and extern variables to 0 PM / Freezer: Make fake_signal_wake_up() wake TASK_KILLABLE tasks too PM / Hibernate: Add resumedelay kernel param in addition to resumewait MAINTAINERS: Update linux-pm list address PM / ACPI: Blacklist Vaio VGN-FW520F machine known to require acpi_sleep=nonvs PM / ACPI: Blacklist Sony Vaio known to require acpi_sleep=nonvs PM / Hibernate: Add resumewait param to support MMC-like devices as resume file PM / Hibernate: Fix typo in a kerneldoc comment PM / Hibernate: Freeze kernel threads after preallocating memory PM: Update the policy on default wakeup settings PM / VT: Cleanup #if defined uglyness and fix compile error PM / Suspend: Off by one in pm_suspend() PM / Hibernate: Include storage keys in hibernation image on s390 ...
| * USB: Add wakeup info to debugging messagesAlan Stern2011-09-271-4/+3
| | | | | | | | | | | | | | | | | | | | 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>
| * PM / Runtime: Add macro to test for runtime PM eventsAlan Stern2011-08-191-5/+5
| | | | | | | | | | | | | | | | | | | | | | 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>
* | xHCI: set USB2 hardware LPMAndiry Xu2011-09-261-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | usbcore: check device's LPM capabilityAndiry Xu2011-09-261-2/+8
| | | | | | | | | | | | | | | | | | 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>
* | usbcore: get BOS descriptor setAndiry Xu2011-09-261-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | USB: When hot reset for USB3 fails, try warm reset.Sarah Sharp2011-09-201-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | usbcore: refine warm reset logicAndiry Xu2011-09-201-104/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | usb: Provide usb_speed_string() functionMichal Nazarewicz2011-09-181-18/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | USB: use usb_endpoint_maxp() instead of le16_to_cpu()Kuninori Morimoto2011-08-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now ${LINUX}/drivers/usb/* can use usb_endpoint_maxp(desc) to get maximum packet size instead of le16_to_cpu(desc->wMaxPacketSize). This patch fix it up Cc: Armin Fuerst <fuerst@in.tum.de> Cc: Pavel Machek <pavel@ucw.cz> Cc: Johannes Erdfelt <johannes@erdfelt.com> Cc: Vojtech Pavlik <vojtech@suse.cz> Cc: Oliver Neukum <oliver@neukum.name> Cc: David Kubicek <dave@awk.cz> Cc: Johan Hovold <jhovold@gmail.com> Cc: Brad Hards <bhards@bigpond.net.au> Acked-by: Felipe Balbi <balbi@ti.com> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Thomas Dahlmann <dahlmann.thomas@arcor.de> Cc: David Brownell <david-b@pacbell.net> Cc: David Lopo <dlopo@chipidea.mips.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Michal Nazarewicz <m.nazarewicz@samsung.com> Cc: Xie Xiaobo <X.Xie@freescale.com> Cc: Li Yang <leoli@freescale.com> Cc: Jiang Bo <tanya.jiang@freescale.com> Cc: Yuan-hsin Chen <yhchen@faraday-tech.com> Cc: Darius Augulis <augulis.darius@gmail.com> Cc: Xiaochen Shen <xiaochen.shen@intel.com> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Cc: OKI SEMICONDUCTOR, <toshiharu-linux@dsn.okisemi.com> Cc: Robert Jarzmik <robert.jarzmik@free.fr> Cc: Ben Dooks <ben@simtec.co.uk> Cc: Thomas Abraham <thomas.ab@samsung.com> Cc: Herbert Pötzl <herbert@13thfloor.at> Cc: Arnaud Patard <arnaud.patard@rtp-net.org> Cc: Roman Weissgaerber <weissg@vienna.at> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Tony Olech <tony.olech@elandigitalsystems.com> Cc: Florian Floe Echtler <echtler@fs.tum.de> Cc: Christian Lucht <lucht@codemercs.com> Cc: Juergen Stuber <starblue@sourceforge.net> Cc: Georges Toth <g.toth@e-biz.lu> Cc: Bill Ryder <bryder@sgi.com> Cc: Kuba Ober <kuba@mareimbrium.org> Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* | USB: Remove test for NULL that'll never happen in usb_disconnect()Jesper Juhl2011-08-221-5/+0
|/ | | | | | | | | In drivers/usb/core/hub.c::usb_disconnect(), 'udev' will never be NULL, so remove the test and printing of debug message. Signed-off-by: Jesper Juhl <jj@chaosbits.net> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Merge branch 'for-usb-linus' of ↵Greg Kroah-Hartman2011-06-271-0/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | git+ssh://master.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus * 'for-usb-linus' of git+ssh://master.kernel.org/pub/scm/linux/kernel/git/sarah/xhci: USB: Fix up URB error codes to reflect implementation. xhci: Always set urb->status to zero for isoc endpoints. xhci: Add reset on resume quirk for asrock p67 host xHCI 1.0: Incompatible Device Error xHCI 1.0: Force Stopped Event(FSE) xhci: Don't warn about zeroed bMaxBurst descriptor field. USB: Free bandwidth when usb_disable_device is called. xhci: Reject double add of active endpoints.
| * USB: Free bandwidth when usb_disable_device is called.Sarah Sharp2011-06-151-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tanya ran into an issue when trying to switch a UAS device from the BOT configuration to the UAS configuration via the bConfigurationValue sysfs file. Before installing the UAS configuration, set_bConfigurationValue() calls usb_disable_device(). That function is supposed to remove all host controller resources associated with that device, but it leaves some state in the xHCI host controller. Commit 0791971ba8fbc44e4f476079f856335ed45e6324 usb: allow drivers to use allocated bandwidth until unbound added a call to usb_disable_device() in usb_set_configuration(), before the xHCI bandwidth functions were invoked. That commit fixed a bug, but also introduced a bug that is triggered when a configured device is switched to a new configuration. usb_disable_device() goes through all the motions of unbinding the drivers attached to active interfaces and removing the USB core structures associated with those interfaces, but it doesn't actually remove the endpoints from the internal xHCI host controller bandwidth structures. When usb_disable_device() calls usb_disable_endpoint() with reset_hardware set to true, the entries in udev->ep_out and udev->ep_in will be set to NULL. Usually, when the USB core installs a new configuration, usb_hcd_alloc_bandwidth() will drop all non-NULL endpoints in udev->ep_out and udev->ep_in before adding any new endpoints. However, when the new UAS configuration was added, all those entries were null, so none of the old endpoints in the BOT configuration were dropped. The xHCI driver blindly added the UAS configuration endpoints, and some of the endpoint addresses overlapped with the old BOT configuration endpoints. This caused the xHCI host to reject the Configure Endpoint command. Now that the xHCI driver code is cleaned up to reject a double-add of active endpoints, we need to fix the USB core to properly drop old endpoints in usb_disable_device(). If the host controller driver needs bandwidth checking support, make usb_disable_device() call usb_disable_endpoint() with reset_hardware set to false, drop the endpoints from the xHCI host controller, and then call usb_disable_endpoint() again with reset_hardware set to true. The first call to usb_disable_endpoint() will cancel any pending URBs and wait on them to be freed in usb_hcd_disable_endpoint(), but will keep the pointers in udev->ep_out and udev->ep in intact. Then usb_hcd_alloc_bandwidth() will use those pointers to know which endpoints to drop. The final call to usb_disable_endpoint() will do two things: 1. It will call usb_hcd_disable_endpoint() again, which should be harmless since the ep->urb_list should be empty after the first call to usb_disable_endpoint() returns. 2. It will set the entries in udev->ep_out and udev->ep in to NULL, and call usb_hcd_disable_endpoint(). That call will have no effect, since the xHCI driver doesn't set the endpoint_disable function pointer. Note that usb_disable_device() will now need to be called with hcd->bandwidth_mutex held. This should be backported to kernels as old as 2.6.32. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Tanya Brokhman <tlinder@codeaurora.org> Cc: ablay@codeaurora.org Cc: Alan Stern <stern@rowland.harvard.edu> Cc: stable@kernel.org
* | USB: don't let the hub driver prevent system sleepAlan Stern2011-06-151-5/+8
|/ | | | | | | | | | | | | | | | | | | | | 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>
* USB: core: Tolerate protocol stall during hub and port status readLibor Pechacek2011-06-061-2/+4
| | | | | | | | | | | | 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>
* usbcore: warm reset USB3 port in SS.Inactive stateAndiry Xu2011-05-021-0/+46
| | | | | | | | | | | Some USB3.0 devices go to SS.Inactive state when hot plug to USB3 ports. Warm reset the port to transition it to U0 state. This patch fixes the issue that Kingston USB3.0 flash drive can not be recognized when hot plug to USB3 port. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* usbcore: Refine USB3.0 device suspend and resumeAndiry Xu2011-05-021-13/+20
| | | | | | | | | | | | | 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>
* xHCI: report USB3.0 portstatus comply with USB3.0 specificationAndiry Xu2011-05-021-15/+37
| | | | | | | | | | | 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>
* usbcore: Bug fix: system can't suspend with USB3.0 device connected to ↵Andiry Xu2011-04-131-1/+11
| | | | | | | | | | | | | USB3.0 hub This patch clear PORT_POWER when suspend a USB3.0 device behind a USB3.0 external hub, so the system can suspend and resume. Note USB3.0 device may not work after system resume and this is a temporary workaround. The correct fix will be in future patches. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* Fix common misspellingsLucas De Marchi2011-03-311-1/+1
| | | | | | Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
* Merge branch 'usb-next' of ↵Linus Torvalds2011-03-161-69/+130
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6 * 'usb-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6: (172 commits) USB: Add support for SuperSpeed isoc endpoints xhci: Clean up cycle bit math used during stalls. xhci: Fix cycle bit calculation during stall handling. xhci: Update internal dequeue pointers after stalls. USB: Disable auto-suspend for USB 3.0 hubs. USB: Remove bogus USB_PORT_STAT_SUPER_SPEED symbol. xhci: Return canceled URBs immediately when host is halted. xhci: Fixes for suspend/resume of shared HCDs. xhci: Fix re-init on power loss after resume. xhci: Make roothub functions deal with device removal. xhci: Limit roothub ports to 15 USB3 & 31 USB2 ports. xhci: Return a USB 3.0 hub descriptor for USB3 roothub. xhci: Register second xHCI roothub. xhci: Change xhci_find_slot_id_by_port() API. xhci: Refactor bus suspend state into a struct. xhci: Index with a port array instead of PORTSC addresses. USB: Set usb_hcd->state and flags for shared roothubs. usb: Make core allocate resources per PCI-device. usb: Store bus type in usb_hcd, not in driver flags. usb: Change usb_hcd->bandwidth_mutex to a pointer. ...
| * USB: Disable auto-suspend for USB 3.0 hubs.Sarah Sharp2011-03-131-2/+8
| | | | | | | | | | | | | | | | | | | | USB 3.0 devices have a slightly different suspend sequence than USB 2.0/1.1 devices. There isn't support for USB 3.0 device suspend yet, so make khubd leave autosuspend disabled for USB 3.0 hubs. Make sure that USB 3.0 roothubs still have autosuspend enabled, since that path in the xHCI driver works fine. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
| * USB: Remove bogus USB_PORT_STAT_SUPER_SPEED symbol.Sarah Sharp2011-03-131-28/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * usb: Change usb_hcd->bandwidth_mutex to a pointer.Sarah Sharp2011-03-131-4/+4
| | | | | | | | | | | | | | | | 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>
| * USB: Clear "warm" port reset change.Sarah Sharp2011-03-131-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In USB 3.0, there are two types of resets: a "hot" port reset and a "warm" port reset. The hot port reset is always tried first, and involves sending the reset signaling for a shorter amount of time. But sometimes devices don't respond to the hot reset, and a "Bigger Hammer" is needed. External hubs and roothubs will automatically try a warm reset when the hot reset fails, and they will set a status change bit to indicate when there is a "BH reset" change. Make sure the USB core clears that port status change bit, or we'll get lots of status change notifications on the interrupt endpoint of the USB 3.0 hub. (Side note: you may be confused why the USB 3.0 spec calls the same type of reset "warm reset" in some places and "BH reset" in other places. "BH" reset is supposed to stand for "Big Hammer" reset, but it also stands for "Brad Hosler". Brad died shortly after the USB 3.0 bus specification was started, and they decided to name the reset after him. The suggestion was made shortly before the spec was finalized, so the wording is a bit inconsistent.) Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
| * USB 3.0 Hub ChangesJohn Youn2011-03-131-8/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * USB: Only treat lasting over-current conditions as errorsPaul Bolle2011-03-111-5/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On a laptop I see these errors on (most) resumes: hub 3-0:1.0: over-current change on port 1 hub 3-0:1.0: over-current change on port 2 Since over-current conditions can disappear quite quickly it's better to downgrade that message to debug level, recheck for an over-current condition a little later and only print and over-current condition error if that condition (still) exists when it's rechecked. Add similar logic to hub over-current changes. (That code is untested, as those changes do not occur on this laptop.) Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * usb: core: hub.c Remove one to many n's in a word.Justin P. Mattock2011-02-281-1/+1
| | | | | | | | | | | | | | | | | | 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>
| * USB: use "device number" instead of "address"Alan Stern2011-02-251-26/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | USB / Hub: Do not call device_set_wakeup_capable() under spinlockRafael J. Wysocki2011-03-151-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | USB: Reset USB 3.0 devices on (re)discoveryLuben Tuikov2011-02-201-11/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Revert "USB: Reset USB 3.0 devices on (re)discovery"Greg Kroah-Hartman2011-02-171-7/+11
| | | | | | | | | | | | | | | | | | | | This reverts commit 637d11bfb814637ec7b81e878db3ffea6408a89a. Sarah wants to tweak it some more before it's applied to the tree. Cc: Luben Tuikov <ltuikov@yahoo.com> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* | USB: Reset USB 3.0 devices on (re)discoveryLuben Tuikov2011-02-171-11/+7
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Signed-off-by: Luben Tuikov <ltuikov@yahoo.com> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: prevent buggy hubs from crashing the USB stackAlan Stern2011-02-031-0/+5
| | | | | | | | | | | | | 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>
* usb: Realloc xHCI structures after a hub is verified.Sarah Sharp2011-01-141-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* USB: improve uses of usb_mark_last_busyAlan Stern2010-11-161-0/+9
| | | | | | | | | | | | | | | | | | | 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>
* USB: use the runtime-PM autosuspend implementationAlan Stern2010-11-161-0/+1
| | | | | | | | | | | | | 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>
* USB: make usb_mark_last_busy use pm_runtime_mark_last_busyMing Lei2010-11-161-1/+0
| | | | | | | | | | | Since the runtime-PM core already defines a .last_busy field in device.power, this patch uses it to replace the .last_busy field defined in usb_device and uses pm_runtime_mark_last_busy to implement usb_mark_last_busy. Signed-off-by: Ming Lei <tom.leiming@gmail.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: accept some invalid ep0-maxpacket valuesAlan Stern2010-10-221-3/+6
| | | | | | | | | | | | | | | | | | 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>
* usb: Fix issue with USB 3.0 devices after system resumeSarah Sharp2010-10-221-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the system suspends and a host controller's power is lost, the USB core attempts to revive any USB devices that had the persist_enabled flag set. For non-SuperSpeed devices, it will disable the port, and then set the udev->reset_resume flag. This will cause the USB core to reset the device, verify the device descriptors to make sure it's the same device, and re-install any non-default configurations or alternate interface settings. However, we can't disable SuperSpeed root hub ports because that turns off SuperSpeed terminations, which will inhibit any devices connecting at USB 3.0 speeds. (Plus external hubs don't allow SuperSpeed ports to be disabled.) Because of this logic in hub_activate(): /* We can forget about a "removed" device when there's a * physical disconnect or the connect status changes. */ if (!(portstatus & USB_PORT_STAT_CONNECTION) || (portchange & USB_PORT_STAT_C_CONNECTION)) clear_bit(port1, hub->removed_bits); if (!udev || udev->state == USB_STATE_NOTATTACHED) { /* Tell khubd to disconnect the device or * check for a new connection */ if (udev || (portstatus & USB_PORT_STAT_CONNECTION)) set_bit(port1, hub->change_bits); } else if (portstatus & USB_PORT_STAT_ENABLE) { /* The power session apparently survived the resume. * If there was an overcurrent or suspend change * (i.e., remote wakeup request), have khubd * take care of it. */ if (portchange) set_bit(port1, hub->change_bits); } else if (udev->persist_enabled) { udev->reset_resume = 1; set_bit(port1, hub->change_bits); } else { /* The power session is gone; tell khubd */ usb_set_device_state(udev, USB_STATE_NOTATTACHED); set_bit(port1, hub->change_bits); } a SuperSpeed device after a resume with a loss of power will never get the reset_resume flag set. Instead the core will assume the power session survived and that the device still has the same address, configuration, and alternate interface settings. The xHCI host controller will have no knowledge of the device (since all xhci_virt_devices were destroyed when power loss was discovered, and xhci_discover_or_reset_device() has not been called), and all URBs to the device will fail. If the device driver responds by resetting the device, everything will continue smoothly. However, if lsusb is used before the device driver resets the device (or there is no driver), then all lsusb descriptor fetches will fail. The quick fix is to pretend the port is disabled in hub_activate(), by clearing the local variable. But I'm not sure what other parts of the hub driver need to be changed because they have assumptions about when ports will be disabled. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: core: use kernel assigned address for devices under xHCIAndiry Xu2010-10-221-14/+13
| | | | | | | | | | | 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>
* USB: core: update comment to match current function nameWolfram Sang2010-10-221-1/+1
| | | | | | | | Found while debugging a USB problem and trying to find the mentioned function. Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB delay init quirk for logitech Harmony 700-series devicesPhil Dibowitz2010-08-101-1/+5
| | | | | | | | | | | | 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>
* USB-BKL: Convert usb_driver ioctl to unlocked_ioctlAndi Kleen2010-08-101-1/+2
| | | | | | | | | | | | 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>
* USB: EHCI: EHCI 1.1 addendum: Basic LPM feature supportAlek Du2010-08-101-1/+3
| | | | | | | | | | | 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>
* USB: Fix USB3.0 Port Speed Downgrade after port resetSarah Sharp2010-07-261-0/+2
| | | | | | | | | | | | | | | | | | | | | | Without this fix, a USB 3.0 port is downgraded to full speed after a port reset of a configured device. The USB 3.0 terminations will be disabled permanently, and USB 3.0 devices will always enumerate as full speed devices, until the host controller is unplugged (if it is an ExpressCard) or the computer is rebooted. Fajun Chen traced this traced the speed downgrade issue to the port reset and the interpretation of port status in USB hub driver code. The hub code was not testing for the port being a SuperSpeed port, and it fell through to the else case of Full Speed. The following patch adds SuperSpeed mapping from the port status, and fixes the speed downgrade issue. Reported-by: Fajun Chen <fajun.chen@seagate.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
OpenPOWER on IntegriCloud