Re: [RFC][PATCH] Documentation: Ask driver writers to provide suspend/resume support

[Pavel Machek]

Hi!

> > > +PM support:	Since Linux is used on many portable and desktop systems, your
> > > +		driver is likely to be used on such a system and therefore it
> > > +		should support basic power management by implementing, if
> > > +		necessary, the .suspend and .resume methods used during the
> > > +		system-wide suspend and resume transitions.  You should verify
> > > +		that your driver correctly handles the suspend and resume, but
> > > +		if you are unable to ensure that, please at least define the
> > > +		.suspend method returning the -ENOSYS ("Function not
> > > +		implemented") error.
> > 
> > Perhaps pointer to Documentation/power/drivers-testing.txt would be
> > useful here?
> 
> Okay, maybe something like this:
> 
> "Please see Documentation/power/drivers-testing.txt for the driver testing
> instructions."
> 
> as the last sentence?

Looks ok. (BTW you have my ACK).

> > > +Unfortunately, to effectively test the support for the system-wide suspend and
> > > +resume transitions in a driver, it is necessary to suspend and resume a fully
> > > +functional system with this driver loaded.  Moreover, that should be done many
> > > +times, preferably many times in a row, and separately for the suspend to disk
> > > +(STD) and the suspend to RAM (STR) transitions, because each of these cases
> > > +involves different ordering of operations and different interactions with the
> > > +machine's BIOS.
> > 
> > Hmm, actually it is nice to mix STR + STD, too... and not sure if
> > "many" is right word... It sounds scary :-).
> 
> "a couple of"?

Sounds good.
> > > +II. Testing the driver
> > > +
> > > +Once you have resolved the suspend/resume-related problems with your test system
> > > +without the new driver, you are ready to test it:
> > > +
> > > +1. Build the driver as a module, load it and try the STD in the test mode
> > > +(cf. 1a)).
> > > +
> > > +2. Compile the driver directly into the kernel and try the STD in the test mode
> > > +(cf. 1a)).
> > > +
> > > +3. Build the driver as a module, load it and attempt to suspend to disk in the
> > > +"reboot", "shutdown" and "platform" modes (cf. 1).
> > > +
> > > +4. Compile the driver directly into the kernel and attempt to suspend to disk in
> > > +the "reboot", "shutdown" and "platform" modes (cf. 1).
> > > +
> > > +5. Build the driver as a module, load it and attempt to run s2ram (cf. 2).
> > > +
> > > +6. Compile the driver directly into the kernel and attempt to run s2ram (cf. 2).
> > > +
> > > +Each of the above tests should be repeated several times and if any of them
> > > +fails, the driver cannot be regarded as suspend/resume-safe.
> > 
> > Maybe reorder the tests so that poor submitter will not have to do 3
> > kernel compiles?
> 
> I thought he would figure out that there's more efficient way. ;-) 

He probably will... but it reads strangely. 

5. Build the driver as a module, load it and attempt to run s2ram. Then
repeat with driver build-in?

Hmm, and maybe driver loaded/build in is not a difference for s2ram?

								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/