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>
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 (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 (as1178) uses the new round_jiffies_up_relative() routine
for setting the autosuspend delayed_work timer. It's appropriate
since we don't care too much about the exact length of the delay, but
we don't want it to be too short (rounded down).
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>
When a driver unbinds from an interface, usbcore always sends a
Set-Interface request to reinstall altsetting 0. Unforunately, quite
a few devices have buggy firmware that crashes when it receives this
request.
To avoid such problems, this patch (as1180) arranges to send the
Set-Interface request only when the interface is not already in
altsetting 0.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
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>
Reset upon resumption will wipe the input buffer and is therefore
a reason to not suspend if remote wakeup is requested because
the driver needs that data.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1130) fixes an incompatibility between the new PM
infrastructure and USB power management. We are not allowed to call
drivers' probe routines during a system sleep transition between the
"prepare" and "complete" callbacks, but that's exactly what we do when
a driver doesn't have full suspend/resume support. Such drivers are
unbound during the "suspend" call and reprobed during the "resume" call.
The patch causes the reprobe step to be skipped if the "complete"
callback hasn't been issued yet, i.e., if the interface's
dev.power.status field is not equal to DPM_ON. Thus during the
"resume" callback nothing bad will happen, and during the final
"complete" callback the reprobing will occur as desired.
This fixes the problem reported in Bugzilla #11263.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1129) adds support for the new PM callbacks to usbcore.
The new callbacks merely invoke the same old USB power management
routines as the old ones did.
A minor improvement is that the callbacks are present only in the
"USB-device" device_type structure, rather than in the bus_type
structure. This way they will be invoked only for USB devices, not
for USB interfaces. The core USB PM routines automatically handle
suspending and resuming interfaces along with their devices.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1128) fixes one of the problems related to the new PM
infrastructure. We are not allowed to register new child devices
during the middle of a system sleep transition, but unbinding a USB
driver causes the core to automatically install altsetting 0 and
thereby create new endpoint pseudo-devices.
The patch fixes this problem (and the related problem that installing
altsetting 0 will fail if the device is suspended) by deferring the
Set-Interface call until some later time when it is legal and can
succeed. Possible later times are: when a new driver is being probed
for the interface, and when the interface is being resumed.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1127) makes a minor change to the prototypes of the
usb_suspend_interface() and usb_resume_interface() routines. Now the
usb_device structure is passed as an argument, instead of being
computed on-the-fly from the usb_interface argument.
It makes the code look simpler, even if it really isn't much different
from before.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1123b) fixes a compiler warning: do_unbind_rebind() is
defined but not used if CONFIG_PM=n.
Problem originally found and initial patch submitted by Alexander
Beregalov <a.beregalov@gmail.com>.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
usb/core/driver: fix warning:
drivers/usb/core/driver.c:834: warning: 'do_unbind_rebind' defined but not used
Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com>
Acked-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 (as1091) changes the way usbcore handles interface
unbinding. If the interface's driver supports "soft" unbinding (a new
flag in the driver structure) then in-flight URBs are not cancelled
and endpoints are not disabled. Instead the driver is allowed to
continue communicating with the device (although of course it should
stop before its disconnect routine returns).
The purpose of this change is to allow drivers to do a clean shutdown
when they get unbound from a device that is still plugged in. Killing
all the URBs and disabling the endpoints before calling the driver's
disconnect method doesn't give the driver any control over what
happens, and it can leave devices in indeterminate states. For
example, when usb-storage unbinds it doesn't want to stop while in the
middle of transmitting a SCSI command.
The soft_unbind flag is added because in the past, a number of drivers
have experienced problems related to ongoing I/O after their disconnect
routine returned. Hence "soft" unbinding is made available only to
drivers that claim to support it.
The patch also replaces "interface_to_usbdev(intf)" with "udev" in a
couple of places, a minor simplification.
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>
The bus_id field is going away, use the dev_name() function instead.
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
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>
When a USB device is suspended, whether or not it is enabled for
remote wakeup depends on the device_may_wakeup() setting. The setting
is then saved in the do_remote_wakeup flag.
Later on, however, the device_may_wakeup() value can change because of
user activity. So when testing whether a suspended device is or
should be enabled for remote wakeup, we should always test
do_remote_wakeup instead of device_may_wakeup(). This patch (as1076)
makes that change for root hubs in several places.
The patch also adjusts uhci-hcd so that when an autostopped controller
is suspended, the remote wakeup setting agrees with the value recorded
in the root hub's do_remote_wakeup flag.
And the patch adjusts ehci-hcd so that wakeup events on selectively
suspended ports (i.e., the bus itself isn't suspended) don't turn on
the PME# wakeup signal.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
power.power_state is scheduled for removal. This patch (as1053)
removes all uses of that field from drivers/usb. Almost all of them
were write-only, the most significant exceptions being sl811-hcd.c and
u132-hcd.c.
Part of this patch was written by Pavel Machek.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: David Brownell <david-b@pacbell.net>
Acked-by: Pavel Machek <pavel@ucw.cz>
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>
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>
Some crazy devices in the wild have a vendor id of 0x0000. If we try to
add a module alias with this id, we just can't do it due to a check in
the file2alias.c file. Change the test to verify that both the vendor
and product ids are 0x0000 to show a real "blank" module alias.
Note, the module-init-tools package also needs to be changed to properly
generate the depmod tables.
Cc: Janusz <janumix@poczta.fm>
Cc: stable <stable@kernel.org>
Cc: Jon Masters <jcm@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Don't try to call the "raw" sysfs_create_file when we already have a
helper function to do this kind of work for us.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1010) was written by both Kay Sievers and me. It solves
the problem of duplicated keys in USB uevent structures by refactoring
the uevent subroutines, taking advantage of the way the hotplug core
calls uevent handlers for the device's bus and for the device's type.
Keys needed for both USB-device and USB-interface events are added in
usb_uevent(), which is the bus handler. Keys appropriate only for
USB-device or USB-interface events are added in usb_dev_uevent() or
usb_if_uevent() respectively, the type handlers.
In addition, unnecessary tests for NULL pointers are removed as are
duplicated debugging log statements.
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>
This patch (as1002) fixes a small race which can occur when a driver
expects usbcore to reschedule an autosuspend request. If the request
arrives too late, it won't be rescheduled. The patch adds an extra
argument to autosuspend_check(), indicating that a reschedule is
needed no matter how much time has elapsed.
It also tries to avoid letting asynchronous changes to the value of
jiffies cause a delay to become negative, by caching a local copy of
the current time.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
System suspends and hibernation are supposed to be as transparent as
possible. By this reasoning, if a USB device is already autosuspended
before the system sleep begins then it should remain autosuspended
after the system wakes up.
This patch (as1001) adds a skip_sys_resume flag to the usb_device
structure and uses it to avoid waking up devices which were suspended
when a system sleep began.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as992) fixes a recently-added bug. During a FREEZE or
PRETHAW suspend notification, non-root devices don't actually get
suspended. So we shouldn't tell their parent hubs that they did.
(This code path used to be skipped over, until the FREEZE/PRETHAW test
got moved out of usb_suspend_both() into generic_suspend().)
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as989) makes usbcore flush all outstanding URBs for each
device as the device is suspended. This will be true even when
CONFIG_USB_SUSPEND is not enabled.
In addition, an extra can_submit flag is added to the usb_device
structure. That flag will be turned off whenever a suspend request
has been received for the device, even if the device isn't actually
suspended because CONFIG_USB_SUSPEND isn't set.
It's no longer necessary to check for the device state being equal to
USB_STATE_SUSPENDED during URB submission; that check can be replaced
by a check of the can_submit flag. This also permits us to remove
some questionable references to the deprecated power.power_state field.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as987) changes the way FREEZE and PRETHAW suspend events
are handled in usbcore. The decision about whether or not to ignore
them for non-root devices is pushed down into the USB-device driver,
instead of being made in the core code.
This is appropriate, since devices exported to a virtualized guest or
over a network may indeed need to handle these types of suspend, even
though normal devices don't.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
If called and the device is not authorized to be used, it won't
configure the interface and print a message saying so.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This changes the uevent buffer functions to use a struct instead of a
long list of parameters. It does no longer require the caller to do the
proper buffer termination and size accounting, which is currently wrong
in some places. It fixes a known bug where parts of the uevent
environment are overwritten because of wrong index calculations.
Many thanks to Mathieu Desnoyers for finding bugs and improving the
error handling.
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes the order of list_add_tail() arguments in
usb_store_new_id() so the list can have more than one single element.
Signed-off-by: Nathael Pajani <nathael.pajani@cpe.fr>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as966) fixes a bug in the autosuspend code. The last_busy
field should be updated whenever any event occurs, not just events
that cause an autosuspend or an autoresume.
This partially fixes Bugzilla #8892.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This defines a dev_vdbg() call, which is enabled with -DVERBOSE_DEBUG.
When enabled, dev_vdbg() acts just like dev_dbg(). When disabled, it is a
NOP ... just like dev_dbg() without -DDEBUG. The specific code was moved
out of a USB patch, but lots of drivers have similar support.
That is, code can now be written to use an additional level of debug
output, selected at compile time. Many driver authors have found this
idiom to be very useful. A typical usage model is for "normal" debug
messages to focus on fault paths and not be very "chatty", so that those
messages can be left on during normal operation without much of a
performance or syslog load. On the other hand "verbose" messages would be
noisy enough that they wouldn't normally be enabled; they might even affect
timings enough to change system or driver behavior.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Make usb autosuspend timers 1sec jiffy aligned.
This helps to reduce the frequency at which the CPU must be taken out of a
lower-power state.
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as922) removes all but one of the remaining vestiges of
dev->power.power_state from usbcore. The only usage left must remain
until the deprecated "power/state" sysfs attribute is gone.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as918) introduces a new USB driver method: reset_resume.
It is called when a device needs to be reset as part of a resume
procedure (whether because of a device quirk or because of the
USB-Persist facility), thereby taking over a role formerly assigned to
the post_reset method. As a consequence, post_reset no longer needs
an argument indicating whether it is being called as part of a
reset-resume. This separation of functions makes the code clearer.
In addition, the pre_reset and post_reset method return types are
changed; they now must return an error code. The return value is
unused at present, but at some later time we may unbind drivers and
re-probe if they encounter an error during reset handling.
The existing pre_reset and post_reset methods in the usbhid,
usb-storage, and hub drivers are updated to match the new
requirements. For usbhid the post_reset routine is also used for
reset_resume (duplicate method pointers); for the other drivers a new
reset_resume routine is added. The change to hub.c looks bigger than
it really is, because mark_children_for_reset_resume() gets moved down
next to the new hub_reset_resume() routine.
A minor change to usb-storage makes the usb_stor_report_bus_reset()
routine acquire the host lock instead of requiring the caller to hold
it already.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as911) replaces some C++-style commented-out debugging
lines in driver.c with a new "verbose debugging" macro. It makes the
code look cleaner, and it's easier to turn the debugging on or off.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as888) adds a new USB device quirk for devices which are
unable to resume correctly. By using the new code added for the
USB-persist facility, it is a simple matter to reset these devices
instead of resuming them. To get things kicked off, a quirk entry is
added for the Philips PSC805.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as886) adds the controversial USB-persist facility,
allowing USB devices to persist across a power loss during system
suspend.
The facility is controlled by a new Kconfig option (with appropriate
warnings about the potential dangers); when the option is off the
behavior will remain the same as it is now. But when the option is
on, people will be able to use suspend-to-disk and keep their USB
filesystems intact -- something particularly valuable for small
machines where the root filesystem is on a USB device!
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as885) moves the root-hub bus_suspend() and bus_resume()
method calls from the hub driver's suspend and resume methods into the
usb_generic driver methods, where they make just as much sense.
Their old locations were not fully correct. For example, in a kernel
compiled without CONFIG_USB_SUSPEND, if one were to do:
echo -n 1-0:1.0 >/sys/bus/usb/drivers/hub/unbind
to unbind the hub driver from a root hub, there would then be no way
to suspend that root hub. Attempts to put the system to sleep would
fail; the USB controller driver would refuse to suspend because the
root hub was still active.
The patch also makes a very slight change in the way devices with no
driver are handled during suspend. Rather than doing a standard USB
port-suspend directly, now the suspend routine in usb_generic is
called. In practice this should never affect anyone.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as884) finally implements the time-saving semantics
possible with the Power Management FREEZE and PRETHAW events. Their
proper handling requires only that devices be quiesced, with
interrupts and DMA turned off; non-root USB devices don't actually
need to be put in a suspended state. The patch checks and avoids
doing the suspend call when possible.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as880) strives to keep the PM core's idea of a USB
interface's power state in synch with usbcore's own idea. In the end
this doesn't really matter, but it's better to be consistent.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as879) ties up some loose ends from an earlier patch.
These are things I didn't think to include at the time but which
clearly belonged there.
If an autosuspend fails because driver activity races with
the autosuspend call, restart the autosuspend timer.
When a device is resumed by an external request, it counts
as device activity and should update the last_busy time so
that the next autoresume won't occur immediately.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as897) changes the autosuspend timer code to use the
standard types and macros in dealing with jiffies values.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alan Stern