diff options
author | Alan Stern <stern@rowland.harvard.edu> | 2008-03-03 15:15:59 -0500 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@suse.de> | 2008-04-25 00:16:32 -0400 |
commit | feccc30d90155bcbc937f87643182a43d25873eb (patch) | |
tree | 96394e24075a885f1a8bb3e53203f8397e78ea46 /Documentation/usb/persist.txt | |
parent | 5e6effaed6da94e727cd45f945ad2489af8570b3 (diff) |
USB: remove CONFIG_USB_PERSIST setting
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>
Diffstat (limited to 'Documentation/usb/persist.txt')
-rw-r--r-- | Documentation/usb/persist.txt | 35 |
1 files changed, 19 insertions, 16 deletions
diff --git a/Documentation/usb/persist.txt b/Documentation/usb/persist.txt index df54d645cbb5..bea58dbd30fe 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 May 29, 2007) | 5 | September 2, 2006 (Updated February 25, 2008) |
6 | 6 | ||
7 | 7 | ||
8 | What is the problem? | 8 | What is the problem? |
@@ -65,9 +65,10 @@ much better.) | |||
65 | 65 | ||
66 | What is the solution? | 66 | What is the solution? |
67 | 67 | ||
68 | Setting CONFIG_USB_PERSIST will cause the kernel to work around these | 68 | The kernel includes a feature called USB-persist. It tries to work |
69 | issues. It enables a mode in which the core USB device data | 69 | around these issues by allowing the core USB device data structures to |
70 | structures are allowed to persist across a power-session disruption. | 70 | persist across a power-session disruption. |
71 | |||
71 | It works like this. If the kernel sees that a USB host controller is | 72 | It works like this. If the kernel sees that a USB host controller is |
72 | not in the expected state during resume (i.e., if the controller was | 73 | not in the expected state during resume (i.e., if the controller was |
73 | reset or otherwise had lost power) then it applies a persistence check | 74 | reset or otherwise had lost power) then it applies a persistence check |
@@ -80,28 +81,30 @@ re-enumeration shows that the device now attached to that port has the | |||
80 | same descriptors as before, including the Vendor and Product IDs, then | 81 | same descriptors as before, including the Vendor and Product IDs, then |
81 | the kernel continues to use the same device structure. In effect, the | 82 | the kernel continues to use the same device structure. In effect, the |
82 | kernel treats the device as though it had merely been reset instead of | 83 | kernel treats the device as though it had merely been reset instead of |
83 | unplugged. | 84 | unplugged. The same thing happens if the host controller is in the |
85 | expected state but a USB device was unplugged and then replugged. | ||
84 | 86 | ||
85 | If no device is now attached to the port, or if the descriptors are | 87 | If no device is now attached to the port, or if the descriptors are |
86 | different from what the kernel remembers, then the treatment is what | 88 | different from what the kernel remembers, then the treatment is what |
87 | you would expect. The kernel destroys the old device structure and | 89 | you would expect. The kernel destroys the old device structure and |
88 | behaves as though the old device had been unplugged and a new device | 90 | behaves as though the old device had been unplugged and a new device |
89 | plugged in, just as it would without the CONFIG_USB_PERSIST option. | 91 | plugged in. |
90 | 92 | ||
91 | The end result is that the USB device remains available and usable. | 93 | The end result is that the USB device remains available and usable. |
92 | Filesystem mounts and memory mappings are unaffected, and the world is | 94 | Filesystem mounts and memory mappings are unaffected, and the world is |
93 | now a good and happy place. | 95 | now a good and happy place. |
94 | 96 | ||
95 | Note that even when CONFIG_USB_PERSIST is set, the "persist" feature | 97 | Note that the "USB-persist" feature will be applied only to those |
96 | will be applied only to those devices for which it is enabled. You | 98 | devices for which it is enabled. You can enable the feature by doing |
97 | can enable the feature by doing (as root): | 99 | (as root): |
98 | 100 | ||
99 | echo 1 >/sys/bus/usb/devices/.../power/persist | 101 | echo 1 >/sys/bus/usb/devices/.../power/persist |
100 | 102 | ||
101 | where the "..." should be filled in the with the device's ID. Disable | 103 | where the "..." should be filled in the with the device's ID. Disable |
102 | the feature by writing 0 instead of 1. For hubs the feature is | 104 | the feature by writing 0 instead of 1. For hubs the feature is |
103 | automatically and permanently enabled, so you only have to worry about | 105 | automatically and permanently enabled and the power/persist file |
104 | setting it for devices where it really matters. | 106 | doesn't even exist, so you only have to worry about setting it for |
107 | devices where it really matters. | ||
105 | 108 | ||
106 | 109 | ||
107 | Is this the best solution? | 110 | Is this the best solution? |
@@ -112,19 +115,19 @@ centralized Logical Volume Manager. Such a solution would allow you | |||
112 | to plug in a USB flash device, create a persistent volume associated | 115 | to plug in a USB flash device, create a persistent volume associated |
113 | with it, unplug the flash device, plug it back in later, and still | 116 | with it, unplug the flash device, plug it back in later, and still |
114 | have the same persistent volume associated with the device. As such | 117 | have the same persistent volume associated with the device. As such |
115 | it would be more far-reaching than CONFIG_USB_PERSIST. | 118 | it would be more far-reaching than USB-persist. |
116 | 119 | ||
117 | On the other hand, writing a persistent volume manager would be a big | 120 | On the other hand, writing a persistent volume manager would be a big |
118 | job and using it would require significant input from the user. This | 121 | job and using it would require significant input from the user. This |
119 | solution is much quicker and easier -- and it exists now, a giant | 122 | solution is much quicker and easier -- and it exists now, a giant |
120 | point in its favor! | 123 | point in its favor! |
121 | 124 | ||
122 | Furthermore, the USB_PERSIST option applies to _all_ USB devices, not | 125 | Furthermore, the USB-persist feature applies to _all_ USB devices, not |
123 | just mass-storage devices. It might turn out to be equally useful for | 126 | just mass-storage devices. It might turn out to be equally useful for |
124 | other device types, such as network interfaces. | 127 | other device types, such as network interfaces. |
125 | 128 | ||
126 | 129 | ||
127 | WARNING: Using CONFIG_USB_PERSIST can be dangerous!! | 130 | WARNING: USB-persist can be dangerous!! |
128 | 131 | ||
129 | When recovering an interrupted power session the kernel does its best | 132 | When recovering an interrupted power session the kernel does its best |
130 | to make sure the USB device hasn't been changed; that is, the same | 133 | to make sure the USB device hasn't been changed; that is, the same |
@@ -152,5 +155,5 @@ but yourself. | |||
152 | YOU HAVE BEEN WARNED! USE AT YOUR OWN RISK! | 155 | YOU HAVE BEEN WARNED! USE AT YOUR OWN RISK! |
153 | 156 | ||
154 | That having been said, most of the time there shouldn't be any trouble | 157 | That having been said, most of the time there shouldn't be any trouble |
155 | at all. The "persist" feature can be extremely useful. Make the most | 158 | at all. The USB-persist feature can be extremely useful. Make the |
156 | of it. | 159 | most of it. |