aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/usb/core/hub.c
Commit message (Collapse)AuthorAgeFilesLines
* ehci: Support for Intel Moorestown MPH and OTG hostAlek Du2010-12-091-0/+10
| | | | | | | | | | | | The Intel Moorestown platform has EHCI MPH and EHCI OTG host. This patch adds PCI probe part for them. The HNP part and SRAM part will be added in another patch. This patch depends on the OTG transceive and OTG client patch from Hang Yuan that should be accepted already. Signed-off-by: Jacob Pan <jacob.jun.pan@intel.com> Signed-off-by: Alek Du <alek.du@intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Hao Wu <hao.wu@intel.com>
* 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>
* USB: usbcore: Do not disable USB3 protocol ports in hub_activate()Andiry Xu2010-05-201-2/+14
| | | | | | | | | | | | | 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>
* USB: don't enable remote wakeup by defaultAlan Stern2010-05-201-1/+0
| | | | | | | | | | | | | | | | | This patch (as1364) avoids enabling remote wakeup by default on all non-root-hub USB devices. Individual drivers or userspace will have to enable it wherever it is needed, such as for keyboards or network interfaces. Note: This affects only system sleep, not autosuspend. External hubs will continue to relay wakeup requests received from downstream through their upstream port, even when remote wakeup is not enabled for the hub itself. Disabling remote wakeup on a hub merely prevents it from generating wakeup requests in response to connect, disconnect, and overcurrent events. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: straighten out port feature vs. port status usageAlan Stern2010-05-201-1/+1
| | | | | | | | | | | | | | | This patch (as1349b) clears up the confusion in many USB host controller drivers between port features and port statuses. In mosty cases it's true that the status bit is in the position given by the corresponding feature value, but that's not always true and it's not guaranteed in the USB spec. There's no functional change, just replacing expressions of the form (1 << USB_PORT_FEAT_x) with USB_PORT_STAT_x, which has the same value. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: remove bogus USB_PORT_FEAT_*_SPEED symbolsAlan Stern2010-05-201-4/+4
| | | | | | | | | | | | | | | | | 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>
* USB: make hcd.h public (drivers dependency)Eric Lescouet2010-05-201-2/+1
| | | | | | | | | | | | | 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>
* USB hub: make USB device id constantNémeth Márton2010-03-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* USB: Move hcd free_dev call into usb_disconnect to fix oopsHerbert Xu2010-03-021-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* USB: convert to the runtime PM frameworkAlan Stern2010-03-021-50/+15
| | | | | | | | | | | | | | | | | | | | | | | 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>
* USB: implement usb_enable_autosuspendAlan Stern2010-03-021-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* USB: consolidate remote wakeup routinesAlan Stern2010-03-021-9/+4
| | | | | | | | | | | | | | | | 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>
* USB: rename USB_SPEED_VARIABLE to USB_SPEED_WIRELESSGreg Kroah-Hartman2010-03-021-3/+3
| | | | | | | | | It's really the wireless speed, so rename the thing to make more sense. Based on a recommendation from David Vrabel Cc: David Vrabel <david.vrabel@csr.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: retain USB device power/wakeup setting across reconfigurationDan Streetman2010-03-021-4/+12
| | | | | | | | | | | | | | | | | | | | | | 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>
* USB: Add call to notify xHC of a device reset.Sarah Sharp2010-03-021-8/+11
| | | | | | | | | | | | Add a new host controller driver method, reset_device(), that the USB core will use to notify the host of a successful device reset. The call may fail due to out-of-memory errors; attempt the port reset sequence again if that happens. Update hub_port_init() to allow resetting a configured device. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* PM: Allow USB devices to suspend/resume asynchronouslyRafael J. Wysocki2010-02-261-0/+1
| | | | | | | | | | | | | | | 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>
* USB: Fix duplicate sysfs problem after device reset.Sarah Sharp2010-01-201-10/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* USB: add missing delay during remote wakeupAlan Stern2010-01-201-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch (as1330) fixes a bug in khbud's handling of remote wakeups. When a device sends a remote-wakeup request, the parent hub (or the host controller driver, for directly attached devices) begins the resume sequence and notifies khubd when the sequence finishes. At this point the port's SUSPEND feature is automatically turned off. However the device needs an additional 10-ms resume-recovery time (TRSMRCY in the USB spec). Khubd does not wait for this delay if the SUSPEND feature is off, and as a result some devices fail to behave properly following a remote wakeup. This patch adds the missing delay to the remote-wakeup path. It also extends the resume-signalling delay used by ehci-hcd and uhci-hcd from 20 ms (the value in the spec) to 25 ms (the value we use for non-remote-wakeup resumes). The extra time appears to help some devices. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Cc: Rickard Bellini <rickard.bellini@ericsson.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: fix bugs in usb_(de)authorize_deviceAlan Stern2009-12-231-12/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* USB: rename usb_configure_deviceAlan Stern2009-12-231-13/+13
| | | | | | | | | | | | | 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>
* USB: core: hub: fix sparse warningFelipe Balbi2009-12-111-1/+1
| | | | | | | | | | 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>
* USB: Check bandwidth when switching alt settings.Sarah Sharp2009-12-111-1/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* USB: prepare for changover to Runtime PM frameworkAlan Stern2009-12-111-13/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* USB: add a "remove hardware" sysfs attributeAlan Stern2009-12-111-2/+48
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* USB: don't use a fixed DMA mapping for hub status URBsAlan Stern2009-12-111-7/+2
| | | | | | | | | | | | 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>
* USB: improved error handling in usb_port_suspend()Oliver Neukum2009-12-111-2/+7
| | | | | | | | | | | | 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>
* USB: EHCI: don't send Clear-TT-Buffer following a STALLAlan Stern2009-11-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | This patch (as1304) fixes a regression in ehci-hcd. Evidently some hubs don't handle Clear-TT-Buffer requests correctly, so we should avoid sending them when they don't appear to be absolutely necessary. The reported symptom is that output on a downstream audio device cuts out because the hub stops relaying isochronous packets. The patch prevents Clear-TT-Buffer requests from being sent following a STALL handshake. In theory a STALL indicates either that the downstream device sent a STALL or that no matching TT buffer could be found. In either case, the transfer is completed and the TT buffer does not remain busy, so it doesn't need to be cleared. Also, the patch fixes a minor flaw in the code that actually sends the Clear-TT-Buffer requests. Although the pipe direction isn't really used for control transfers, it should be a Send rather than a Receive. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Javier Kohen <jkohen@users.sourceforge.net> CC: David Brownell <david-b@pacbell.net> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: Add hub descriptor update hook for xHCISarah Sharp2009-09-231-0/+14
| | | | | | | | | | 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>
* USB: don't lose mode switch events on suspended devicesAlan Stern2009-09-231-8/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch (as1268) changes the way usbcore handles child devices that undergo a disconnection and reconnection while the parent hub is suspended. Currently, if the child isn't enabled for remote wakeup we leave it alone, figuring that it will go through a reset-resume when somebody tries to use it. However this isn't a good approach if the reason for the disconnection is that the child decided to switch modes or in some other way alter its descriptors. In that case we want to re-enumerate it as soon as possible, not wait until somebody forces a reset-resume. To resolve the issue, this patch treats reconnected suspended child devices as though they had requested a remote wakeup, even if they weren't enabled for it. The mode switch or descriptor change will be detected during the reset part of the reset-resume, and the device will be re-enumerated immediately. The disadvantage of this change is that it will cause autosuspended devices to be resumed when the computer wakes up from a system sleep during which the root hub was reset or lost power. This shouldn't matter much; some people would even argue that autosuspended devices should _always_ be resumed when the system wakes up! Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: "Yang Fei-AFY095" <fei.yang@motorola.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: check for hub driver not bound to root hub deviceAlan Stern2009-09-231-3/+7
| | | | | | | | | | | | | | | | | | | | 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>
* USB: make intf.pm_usage an atomic_tAlan Stern2009-09-231-2/+3
| | | | | | | | | | | | | This patch (as1260) changes the pm_usage_cnt field in struct usb_interface from an int to an atomic_t. This is so that drivers can invoke the usb_autopm_get_interface_async() and usb_autopm_put_interface_async() routines without locking and without fear of corrupting the pm_usage_cnt value. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: add API for userspace drivers to "claim" portsAlan Stern2009-09-231-5/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* USB: fix the clear_tt_buffer interfaceAlan Stern2009-07-121-14/+26
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* USB: Support for addressing a USB device under xHCISarah Sharp2009-06-151-19/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* USB: Don't reset USB 3.0 devices on port change detection.Sarah Sharp2009-06-151-6/+36
| | | | | | | | | | | | | | | | | 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>
* USB: Add USB 3.0 roothub support to USB core.Sarah Sharp2009-06-151-0/+5
| | | | | | | | | | | | | | | | Add USB 3.0 root hub descriptors. This is a kludge because I reused the old USB 2.0 descriptors, instead of using the new USB 3.0 hub descriptors with endpoint companion descriptors and other descriptors. I did this because I wasn't ready to add USB 3.0 hub changes to khubd. For now, a USB 3.0 roothub looks like a USB 2.0 roothub, with a higher speed. USB 3.0 hubs have no transaction translator (TT). Make USB core debugging handle super speed ports. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: Add SuperSpeed to the list of USB device speeds.Sarah Sharp2009-06-151-2/+9
| | | | | | | | | | | | | | | | | | | | | | | Modify the USB core to handle the new USB 3.0 speed, "SuperSpeed". This is 5.0 Gbps (wire speed). There are probably more places that check for speed that I've missed. SuperSpeed devices have a 512 byte endpoint 0 max packet size. This shows up as a bMaxPacketSize0 set to 0x09 (see table 9-8 of the USB 3.0 bus spec). xHCI spec says that the xHC can handle intervals up to 2^15 microframes. That might change when real silicon becomes available. Add FIXME note for SuperSpeed isochronous endpoints. They can transmit up to 16 packets in one "burst" before they wait for an acknowledgment of the packets. They can do up to 3 bursts per microframe (determined by the mult value in the endpoint companion descriptor). The xHCI driver doesn't have support for isoc yet, so fix this later. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: hub.c: fix sparse warningsH Hartley Sweeten2009-06-151-3/+3
| | | | | | | | | | | | | 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>
* USB: more u32 conversion after transfer_buffer_length and actual_lengthRoel Kluin2009-03-241-1/+1
| | | | | | | | | | | | | | | | | | 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>
* USB: don't send Set-Interface after resetAlan Stern2009-03-241-7/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* USB: allow libusb to talk to unauthenticated WUSB devicesDavid Vrabel2009-03-241-0/+1
| | | | | | | | | | | | | | 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>
* USB: replace uses of __constant_{endian}Harvey Harrison2009-03-241-4/+4
| | | | | | | | The base versions handle constant folding now. Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: fix toggle mismatch in disable_endpoint pathsAlan Stern2009-01-271-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>