> drivers_sysfs_write() > while(!suspend_trylock()) > try_to_icebox() --> or even try_to_freeze(), what's the difference? > > hit hardware > unlock_suspend() > > where the PM core must wait for the suspend lock to get released (say with a > timeout)? Somewhat. What I'd like is to have that a construct of that sort on a per-driver basis though :-) Now the question is, in what way would the above be different from a simple suspend mutex ? I've been using mutexes in the past for a couple of drivers (iirc, that's how I did it for dmasound_pmac, though that driver is long past obsolescence now). But yes, that's the idea, something under control of drivers, instead of a 3rd party freezer that tries to hit at processes. > Hmm, perhaps we can use a special workqueue that's created before the suspend > (say by the PM core) and starts processing jobs after the resume? Yeah, whatever the implementation is, though, the interface should be transparent. But then, I see little use of that. Mostly things like this sysfs write to unbind Alan was talking about. Driver workqueues probably need to be functioning all the way until the driver itself is suspended, in which case, the driver may just flush_worqueues in it's suspend path at the right time to make sure it doesn't exit with something still pending. Ben. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
