aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/usb/persist.txt
diff options
context:
space:
mode:
authorAlan Stern <stern@rowland.harvard.edu>2007-05-30 15:39:33 -0400
committerGreg Kroah-Hartman <gregkh@suse.de>2007-07-12 19:34:30 -0400
commitb41a60eca833d76593d4dac8a59f5c38714194ee (patch)
treea7c5cf721d9978503c3c8c88183747cf954b8733 /Documentation/usb/persist.txt
parent54515fe528d8c6f9bfaf7d0b9fffb908deecad78 (diff)
USB: add power/persist device attribute
This patch (as920) adds an extra level of protection to the USB-Persist facility. Now it will apply by default only to hubs; for all other devices the user must enable it explicitly by setting the power/persist device attribute. The disconnect_all_children() routine in hub.c has been removed and its code placed inline. This is the way it was originally as part of hub_pre_reset(); the revised usage in hub_reset_resume() is sufficiently different that the code can no longer be shared. Likewise, mark_children_for_reset() is now inline as part of hub_reset_resume(). The end result looks much cleaner than before. The sysfs interface is updated to add the new attribute file, and there are corresponding documentation updates. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'Documentation/usb/persist.txt')
-rw-r--r--Documentation/usb/persist.txt38
1 files changed, 25 insertions, 13 deletions
diff --git a/Documentation/usb/persist.txt b/Documentation/usb/persist.txt
index 6dcd5f884795..df54d645cbb5 100644
--- a/Documentation/usb/persist.txt
+++ b/Documentation/usb/persist.txt
@@ -2,7 +2,7 @@
2 2
3 Alan Stern <stern@rowland.harvard.edu> 3 Alan Stern <stern@rowland.harvard.edu>
4 4
5 September 2, 2006 (Updated March 27, 2007) 5 September 2, 2006 (Updated May 29, 2007)
6 6
7 7
8 What is the problem? 8 What is the problem?
@@ -52,9 +52,9 @@ you can convince the BIOS supplier to fix the problem (lots of luck!).
52 52
53On many systems the USB host controllers will get reset after a 53On many systems the USB host controllers will get reset after a
54suspend-to-RAM. On almost all systems, no suspend current is 54suspend-to-RAM. On almost all systems, no suspend current is
55available during suspend-to-disk (also known as swsusp). You can 55available during hibernation (also known as swsusp or suspend-to-disk).
56check the kernel log after resuming to see if either of these has 56You can check the kernel log after resuming to see if either of these
57happened; look for lines saying "root hub lost power or was reset". 57has happened; look for lines saying "root hub lost power or was reset".
58 58
59In practice, people are forced to unmount any filesystems on a USB 59In practice, people are forced to unmount any filesystems on a USB
60device before suspending. If the root filesystem is on a USB device, 60device before suspending. If the root filesystem is on a USB device,
@@ -71,15 +71,16 @@ structures are allowed to persist across a power-session disruption.
71It works like this. If the kernel sees that a USB host controller is 71It works like this. If the kernel sees that a USB host controller is
72not in the expected state during resume (i.e., if the controller was 72not in the expected state during resume (i.e., if the controller was
73reset or otherwise had lost power) then it applies a persistence check 73reset or otherwise had lost power) then it applies a persistence check
74to each of the USB devices below that controller. It doesn't try to 74to each of the USB devices below that controller for which the
75resume the device; that can't work once the power session is gone. 75"persist" attribute is set. It doesn't try to resume the device; that
76Instead it issues a USB port reset and then re-enumerates the device. 76can't work once the power session is gone. Instead it issues a USB
77(This is exactly the same thing that happens whenever a USB device is 77port reset and then re-enumerates the device. (This is exactly the
78reset.) If the re-enumeration shows that the device now attached to 78same thing that happens whenever a USB device is reset.) If the
79that port has the same descriptors as before, including the Vendor and 79re-enumeration shows that the device now attached to that port has the
80Product IDs, then the kernel continues to use the same device 80same descriptors as before, including the Vendor and Product IDs, then
81structure. In effect, the kernel treats the device as though it had 81the kernel continues to use the same device structure. In effect, the
82merely been reset instead of unplugged. 82kernel treats the device as though it had merely been reset instead of
83unplugged.
83 84
84If no device is now attached to the port, or if the descriptors are 85If no device is now attached to the port, or if the descriptors are
85different from what the kernel remembers, then the treatment is what 86different from what the kernel remembers, then the treatment is what
@@ -91,6 +92,17 @@ The end result is that the USB device remains available and usable.
91Filesystem mounts and memory mappings are unaffected, and the world is 92Filesystem mounts and memory mappings are unaffected, and the world is
92now a good and happy place. 93now a good and happy place.
93 94
95Note that even when CONFIG_USB_PERSIST is set, the "persist" feature
96will be applied only to those devices for which it is enabled. You
97can enable the feature by doing (as root):
98
99 echo 1 >/sys/bus/usb/devices/.../power/persist
100
101where the "..." should be filled in the with the device's ID. Disable
102the feature by writing 0 instead of 1. For hubs the feature is
103automatically and permanently enabled, so you only have to worry about
104setting it for devices where it really matters.
105
94 106
95 Is this the best solution? 107 Is this the best solution?
96 108