> > - For STR, don't do the freezer thing. > > In the long run, I agree. > > Still, can you please read this post from Alan Stern: > > https://lists.linux-foundation.org/pipermail/linux-pm/2007-June/012847.html > > ? I don't think I'm able to repeat the arguments given in there in a > convincing way. That's the same crackpot I've been hearing for the past 3 years or so ... Both Paulus and I think the freezer is just a way to try to put your head in the sand and ignore the problem. It causes as many problems as it solves on its own, and is just not a solution that will be of any use once you start implementing dynamic PM schemes etc... In many cases, having proper support for "live" suspend of devices is just a matter of having a couple of helpers in whatever subsystem those drivers hookup with. In the case of network, for example, it's mostly trivial (stop the queue). For block, it's not terribly hard neither, though you want to have some orderign/atomicity between the blocking of the incoming request queue and the sending of things like spindown & flush commands to the disk. For old-style IDE, that was fairly easily solved by piping suspend/resume command down the request queue itself and have the queue block/unblbock itself after processing them. Some of that logic could maybe be moved to the block layer for all block drivers to benefit. But yes, overall, there is work to do on drivers and I'm doing the ones I hit on the platforms I use. I don't think the freezer is any kind of remotely good solution, just a way to continue avoiding the problem. Ben. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
