1. Preparing the test system¶

Unfortunately, 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 hibernation(aka suspend to disk or STD) and suspend to RAM (STR), because each of thesecases involves slightly different 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.rstfor more information about the debugging of suspend/resume functionality.

2. Testing the driver¶

Once you have resolved the suspend/resume-related problems with your test systemwithout the new driver, you are ready to test it:

1. Build the driver as a module, load it and try the test modes of hibernation(see: Documentation/power/basic-pm-debugging.rst, 1).
2. Load the driver and attempt to hibernate in the “reboot”, “shutdown” and“platform” modes (see: Documentation/power/basic-pm-debugging.rst, 1).
3. Compile the driver directly into the kernel and try the test modes ofhibernation.
4. Attempt to hibernate with the driver compiled directly into the kernelin the “reboot”, “shutdown” and “platform” modes.
5. Try the test modes of suspend (see:Documentation/power/basic-pm-debugging.rst, 2). [As far as the STR tests areconcerned, it should not matter whether or not the driver is built as amodule.]
6. Attempt to suspend to RAM using the s2ram tool with the driver loaded(see: Documentation/power/basic-pm-debugging.rst, 2).

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.