The USB 3.0 bus specification introduces a new type of power management
called function suspend. The idea is to be able to suspend different
functions (i.e. a scanner or an SD card reader on a USB printer)
independently. A device can be in U0, but have one or more functions
suspended. Thus, signaling a function resume with the standard device
remote wake signaling was not possible.
Instead, a device will (without prompt from the host) send a "device
notification" for the function remote wake. A new Set Feature Function
Remote Wake was developed to turn remote wake up on and off for each
function.
USB 3.0 devices can still go into device suspend (U3), and signal a
remote wakeup to bring the link back into U1. However, they now use the
function remote wake device notification to allow the host to know which
function woke the device from U3.
The spec is a bit ambiguous about whether a function is allowed to
signal a remote wakeup if the function has been enabled for remote
wakeup, but not placed in function suspend before the device is placed
into U3.
Section 9.2.5.1 says "Suspending a device with more than one function
effectively suspends all the functions within the device." I interpret
that to mean that putting a device in U3 suspends all functions, and
thus if the host has previously enabled remote wake for those functions,
it should be able to signal a remote wake up on port status changes.
However, hub vendors may have a different interpretation, and it can't
hurt to put the function into suspend before putting the device into U3.
I cannot get an answer out of the USB 3.0 spec architects about this
ambiguity, so I'm erring on the safe side and always suspending the
first function before placing the device in U3. Note, this code should
be fixed if we ever find any USB 3.0 devices that have more than one
function.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
When the USB 3.0 hub support went in, I disabled selective suspend for
all external USB 3.0 hubs because they used a different mechanism to
enable remote wakeup. In fact, other USB 3.0 devices that could signal
remote wakeup would have been prevented from going into suspend because
they would have stalled the SetFeature Device Remote Wakeup request.
This patch adds support for the USB 3.0 way of enabling remote wake up
(with a SetFeature Function Suspend request), and enables selective
suspend for all hubs during hub_probe. It assumes that all USB 3.0 have
only one "function" as defined by the interface association descriptor,
which is true of all the USB 3.0 devices I've seen so far. FIXME if
that turns out to change later.
After a device signals a remote wakeup, it is supposed to send a Device
Notification packet to the host controller, signaling which function
sent the remote wakeup. The host can then put any other functions back
into function suspend. Since we don't have support for function suspend
(and no devices currently support it), we'll just assume the hub
function will resume the device properly when it received the port
status change notification, and simply ignore any device notification
events from the xHCI host controller.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
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>
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>
This patch is in succession of previous patch
commit c842114792
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>
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
* '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
...
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
* '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.
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>
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 0791971ba8
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
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>
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>
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>
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>
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>
* '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.
...
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 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_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>
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>
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>
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>
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>
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>
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>
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
This reverts commit 637d11bfb8. 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>
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>
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>
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
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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: 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Carry out the PM-routine interface change in the USB OTG pathway. This
was omitted from the earlier interface-change patch by mistake.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg KH <greg@kroah.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Felipe Balbi <felipe.balbi@nokia.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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>
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>
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>
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>
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>
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>
This patch (as1160b) adds support routines for asynchronous autosuspend
and autoresume, with accompanying documentation updates. There
already are several potential users of this interface, and others are
likely to arise as autosuspend support becomes more widespread.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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>
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>
This patch (as1152) may help prevent some problems associated with the
new policy of unbinding drivers that don't support suspend/resume or
pre_reset/post_reset. If for any reason the resume or reset fails, and
the device is logically disconnected, there's no point in trying to
rebind the driver. So the patch checks for success before carrying
out the unbind/rebind.
There was a report from one user that this fixed a problem he was
experiencing, but the details never became fully clear. In any case,
adding these tests can't hurt.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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>
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>
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>
This patch (as1069c) changes the way OHCI root-hub status-change
interrupts are enabled. Currently a special HCD method,
hub_irq_enable(), is called when the hub driver is finished using a
root hub. This approach turns out to be subject to races, resulting
in unnecessary polling.
The patch does away with the method entirely. Instead, the driver
automatically enables the RHSC interrupt when no more status changes
are present. This scheme is safe with controllers using
level-triggered semantics for their interrupt flags.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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>
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>
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>
From the current implementation of usb_reset_composite_device
function, the iface parameter is no longer useful. This function
doesn't do something special for the iface usb_interface,compared
with other interfaces in the usb_device. So remove the parameter
and fix the related caller.
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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>
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>
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>
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>
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>
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>
This reverts Linus's previous patch that is in mainline to make it
easier for the USB hub.c patches that follow this to apply cleanly. The
functionality will be added back in a followon patch in this series.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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>
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>
This reverts Alan's previous patch so that the recent Hub changes will
apply cleanly. The above mentioned patch was needed for 2.6.26 to work
properly.
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Lukas Hejtmanek <xhejtman@ics.muni.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This reverts commit e872154921.
Andrey Borzenkov reports that it resulted in a totally hung machine for
him when loading the OHCI driver. Extensive netconsole capture with
SysRq output shows that modprobe gets stuck in ohci_hub_status_data()
when probing and enabling the OHCI controller, see for example
http://lkml.org/lkml/2008/7/5/236
for an analysis.
The problem appears to be an interrupt flood triggered by the commit
that gets reverted, and Andrey confirmed that the revert makes things
work for him again.
Reported-and-tested-by: Andrey Borzenkov <arvidjaar@mail.ru>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: David Brownell <david-b@pacbell.net>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch (as1111) fixes a bug in the hub driver. When a hub
resumes, disconnections that occurred while the hub was suspended are
lost.
A completely different fix for this problem has already been accepted
for 2.6.27; however the problem still needs to be handled in 2.6.26.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Lukas Hejtmanek <xhejtman@ics.muni.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch tries to identify which devices are able to accept
reset-resume handling, by checking that there is at least one
interface driver bound and that all of the drivers have a reset_resume
method defined. If these conditions don't hold then during resume
processing, the device is logicall disconnected.
This is only a temporary fix. Later on we will explicitly unbind
drivers that can't handle reset-resumes.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oliver@neukum.org>
Cc: Pavel Machek <pavel@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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>
There is a potential deadlock when the usb_generic driver is unbound
from a device. The problem is that generic_disconnect() is called
with the device lock held, and it removes a bunch of device attributes
from sysfs. If a user task happens to be running an attribute method
at the time, the removal will block until the method returns. But at
least one of the attribute methods (the store routine for power/level)
needs to acquire the device lock!
This patch (as1093) eliminates the deadlock by moving the calls to
create and remove the sysfs attributes from the usb_generic driver
into usb_new_device() and usb_disconnect(), where they can be invoked
without holding the device lock.
Besides, the other sysfs attributes are created when the device is
registered and removed when the device is unregistered. So it seems
only fitting for the extra attributes to be created and removed at the
same time.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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>
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>
A WUSB device gets his address during the connection phase; later on,
during the authenthication phase (driven from user space) we assign
the final address. So we need to skip in hub_port_init() the actual
setting of the address for WUSB devices.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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>
__FUNCTION__ is gcc-specific, use __func__
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1069b) changes the way OHCI root-hub status-change
interrupts are enabled. Currently a special HCD method,
hub_irq_enable(), is called when the hub driver is finished using a
root hub. This approach turns out to be subject to races, resulting
in unnecessary polling.
The patch does away with the method entirely. Instead, the driver
automatically enables the RHSC interrupt when no more status changes
are present. This scheme is safe with controllers using
level-triggered semantics for their interrupt flags.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1077) logs an error message whenever the kernel is
unable to enumerate a new USB device.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1048) extends the descriptor checking after a device is
reset. Now the SerialNumber string descriptor is compared to its old
value, in addition to the device and configuration descriptors.
As a consequence, the kmalloc() call in usb_string() is now on the
error-handling pathway for usb-storage. Hence its allocation type is
changed to GFO_NOIO.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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>
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>
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>
This patch (as1044) causes EHCI port handover for non-high-speed
devices to occur during every root-hub resume, not just in cases where
the controller lost power or was reset. This is necessary because:
When some machines go into suspend, they remove power from
on-board USB devices while retaining suspend current for USB
controllers.
The user might well unplug a USB device while the system is
suspended and then plug it back in before resuming.
A corresponding change is made to the core resume routine; now
high-speed root hubs will always be resumed when the system wakes up,
even if they were suspended before the system went to sleep. If this
weren't done then EHCI port handover wouldn't work, since it is called
when the EHCI root hub is resumed.
Finally, a comment is added to the hub driver explaining the khubd has
to be freezable; if it weren't frozen then it could interfere with
port handover.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
None of these files use any of the functionality promised by
asm/semaphore.h. It's possible that they rely on it dragging in some
unrelated header file, but I can't build all these files, so we'll have
fix any build failures as they come up.
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Over two years ago, the Linux USB developers stated that they believed
there was no way to create a USB kernel driver that was not under the
GPL. This patch moves the USB apis to enforce that decision.
There are no known closed source USB drivers in the wild, so this patch
should cause no problems.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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>
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>
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>
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>
this function will run in the context of the scsi error handler thread.
It must use GFP_NOIO instead of GFP_KERNEL to avoid a possible
deadlock.
Cc: stable <stable@kernel.org>
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1027) replaces a call to flush_scheduled_work() -- a
dangerous routine to invoke, especially while holding any sort of lock
-- with calls to cancel_work_sync() and cancel_delayed_work_sync().
This fixes Bugzilla #9532.
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>
Introduce freezer-friendly wrappers around wait_event_interruptible() and
wait_event_interruptible_timeout(), originally defined in <linux/wait.h>, to
be used in freezable kernel threads. Make some of the freezable kernel
threads use them.
This is necessary for the freezer to stop sending signals to kernel threads,
which is implemented in the next patch.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Cc: Nigel Cunningham <nigel@nigel.suspend2.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
