Testing suspend and resume support in device drivers	(C) 2007 Rafael J. Wysocki <rjw@sisk.pl>, GPL1. Preparing the test systemUnfortunately, to effectively test the support for the system-wide suspend andresume transitions in a driver, it is necessary to suspend and resume a fullyfunctional system with this driver loaded.  Moreover, that should be doneseveral times, preferably several times in a row, and separately for the suspendto disk (STD) and the suspend to RAM (STR) transitions, because each of thesecases involves different ordering of operations and different interactions withthe machine's BIOS.Of course, for this purpose the test system has to be known to suspend andresume without the driver being tested.  Thus, if possible, you should firstresolve all suspend/resume-related problems in the test system before you starttesting the new driver.  Please see Documentation/power/basic-pm-debugging.txtfor more information about the debugging of suspend/resume functionality.2. Testing the driverOnce you have resolved the suspend/resume-related problems with your test systemwithout the new driver, you are ready to test it:a) Build the driver as a module, load it and try the STD in the test mode (see:Documents/power/basic-pm-debugging.txt, 1a)).b) Load the driver and attempt to suspend to disk in the "reboot", "shutdown"and "platform" modes (see: Documents/power/basic-pm-debugging.txt, 1).c) Compile the driver directly into the kernel and try the STD in the test mode.d) Attempt to suspend to disk with the driver compiled directly into the kernelin the "reboot", "shutdown" and "platform" modes.e) Attempt to suspend to RAM using the s2ram tool with the driver loaded (see:Documents/power/basic-pm-debugging.txt, 2).  As far as the STR tests areconcerned, it should not matter whether or not the driver is built as a module.Each of the above tests should be repeated several times and the STD testsshould be mixed with the STR tests.  If any of them fails, the driver cannot beregarded as suspend/resume-safe.