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>

7 files changed, 53 insertions, 81 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 @@
 
                    Alan Stern <stern@rowland.harvard.edu>
 
-                 September 2, 2006 (Updated May 29, 2007)
+                September 2, 2006 (Updated February 25, 2008)
 
 
         What is the problem?
@@ -65,9 +65,10 @@ much better.)
 
         What is the solution?
 
-Setting CONFIG_USB_PERSIST will cause the kernel to work around these
-issues.  It enables a mode in which the core USB device data
-structures are allowed to persist across a power-session disruption.
+The kernel includes a feature called USB-persist.  It tries to work
+around these issues by allowing the core USB device data structures to
+persist across a power-session disruption.
+
 It works like this.  If the kernel sees that a USB host controller is
 not in the expected state during resume (i.e., if the controller was
 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
 same descriptors as before, including the Vendor and Product IDs, then
 the kernel continues to use the same device structure.  In effect, the
 kernel treats the device as though it had merely been reset instead of
-unplugged.
+unplugged.  The same thing happens if the host controller is in the
+expected state but a USB device was unplugged and then replugged.
 
 If no device is now attached to the port, or if the descriptors are
 different from what the kernel remembers, then the treatment is what
 you would expect.  The kernel destroys the old device structure and
 behaves as though the old device had been unplugged and a new device
-plugged in, just as it would without the CONFIG_USB_PERSIST option.
+plugged in.
 
 The end result is that the USB device remains available and usable.
 Filesystem mounts and memory mappings are unaffected, and the world is
 now a good and happy place.
 
-Note that even when CONFIG_USB_PERSIST is set, the "persist" feature
-will be applied only to those devices for which it is enabled.  You
-can enable the feature by doing (as root):
+Note that the "USB-persist" feature will be applied only to those
+devices for which it is enabled.  You can enable the feature by doing
+(as root):
 
         echo 1 >/sys/bus/usb/devices/.../power/persist
 
 where the "..." should be filled in the with the device's ID.  Disable
 the feature by writing 0 instead of 1.  For hubs the feature is
-automatically and permanently enabled, so you only have to worry about
-setting it for devices where it really matters.
+automatically and permanently enabled and the power/persist file
+doesn't even exist, so you only have to worry about setting it for
+devices where it really matters.
 
 
         Is this the best solution?
@@ -112,19 +115,19 @@ centralized Logical Volume Manager.  Such a solution would allow you
 to plug in a USB flash device, create a persistent volume associated
 with it, unplug the flash device, plug it back in later, and still
 have the same persistent volume associated with the device.  As such
-it would be more far-reaching than CONFIG_USB_PERSIST.
+it would be more far-reaching than USB-persist.
 
 On the other hand, writing a persistent volume manager would be a big
 job and using it would require significant input from the user.  This
 solution is much quicker and easier -- and it exists now, a giant
 point in its favor!
 
-Furthermore, the USB_PERSIST option applies to _all_ USB devices, not
+Furthermore, the USB-persist feature applies to _all_ USB devices, not
 just mass-storage devices.  It might turn out to be equally useful for
 other device types, such as network interfaces.
 
 
-        WARNING: Using CONFIG_USB_PERSIST can be dangerous!!
+        WARNING: USB-persist can be dangerous!!
 
 When recovering an interrupted power session the kernel does its best
 to make sure the USB device hasn't been changed; that is, the same
@@ -152,5 +155,5 @@ but yourself.
 YOU HAVE BEEN WARNED!  USE AT YOUR OWN RISK!
 
 That having been said, most of the time there shouldn't be any trouble
-at all.  The "persist" feature can be extremely useful.  Make the most
-of it.
+at all.  The USB-persist feature can be extremely useful.  Make the
+most of it.
diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
index a2b0aa48b8ea..c15621d64579 100644
--- a/drivers/usb/core/Kconfig
+++ b/drivers/usb/core/Kconfig
@@ -102,31 +102,6 @@ config USB_SUSPEND
 
           If you are unsure about this, say N here.
 
-config USB_PERSIST
-        bool "USB device persistence during system suspend (DANGEROUS)"
-        depends on USB && PM && EXPERIMENTAL
-        default n
-        help
-
-          If you say Y here and enable the "power/persist" attribute
-          for a USB device, the device's data structures will remain
-          persistent across system suspend, even if the USB bus loses
-          power.  (This includes hibernation, also known as swsusp or
-          suspend-to-disk.)  The devices will reappear as if by magic
-          when the system wakes up, with no need to unmount USB
-          filesystems, rmmod host-controller drivers, or do anything
-          else.
-
-                WARNING: This option can be dangerous!
-
-          If a USB device is replaced by another of the same type while
-          the system is asleep, there's a good chance the kernel won't
-          detect the change.  Likewise if the media in a USB storage
-          device is replaced.  When this happens it's almost certain to
-          cause data corruption and maybe even crash your system.
-
-          If you are unsure, say N here.
-
 config USB_OTG
         bool
         depends on USB && EXPERIMENTAL
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index df68e2562582..6dc589955d75 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -30,12 +30,6 @@
 #include "hcd.h"
 #include "hub.h"
 
-#ifdef  CONFIG_USB_PERSIST
-#define USB_PERSIST     1
-#else
-#define USB_PERSIST     0
-#endif
-
 /* if we are in debug mode, always announce new devices */
 #ifdef DEBUG
 #ifndef CONFIG_USB_ANNOUNCE_NEW_DEVICES
@@ -695,7 +689,7 @@ static void hub_restart(struct usb_hub *hub, int type)
                  * turn off the various status changes to prevent
                  * khubd from disconnecting it later.
                  */
-                if (USB_PERSIST && udev->persist_enabled && status == 0 &&
+                if (udev->persist_enabled && status == 0 &&
                                 !(portstatus & USB_PORT_STAT_ENABLE)) {
                         if (portchange & USB_PORT_STAT_C_ENABLE)