On Wed, 2006-06-21 at 08:15 -0700, Linus Torvalds wrote: > > On Wed, 21 Jun 2006, Benjamin Herrenschmidt wrote: > > > > Not stopping queues but not servicing them instead ... hrm ... not that > > much difference if you ask me :) > > A _huge_ difference. > > You still don't seem to see it: > > > In fact, there is very little difference in practice as far as the > > driver implementation is concerned. I don't care either way as long as > > the driver is hardened against incoming things (requests, ioctl, > > whatever) happening after it's been suspended... > > The difference is _exactly_ on the driver level. > > If you stop the queues, most drivers don't have to care any more. They are > quiescent _without_ any driver impact what-so-ever. How do you handle things like partial tree suspend, runtime suspend of a given device and it's subtree etc.... ? the needs for power management go beyond just sytem suspend and drivers need to be capable of handling it. There won't always be an allmighty god to stop "subsystems" above the driver to send requests to it if the driver itself doesn't ask for that to happen.... (Oh and again, I'm strictly speaking about STR here). What annoys me the most is that you seem to be doing some kind of special casing of system suspend saying that drivers don't have to care about proper blocking of their "request queues" (again, this is a very generic term that ecompass not servicing a block device queue, telling the network stack to not call xmit, blocking or refusing on ioctl calls, etc etc....) because "something" above them will have prevented it from happening. That's what I don't agree with basically. Drivers need to do this little bit of work to make sure they can be safely suspending in a fully alive environment. It's not very hard to do (and those "subsystems" above drivers, when they exist at all, can well provide a help the driver can call to say "heh, I'm sleeping, don't bother me"... heh, they can even provide a callback to the driver to wake it up in the context of runtime suspend when activity happens) and it makes me sleep better :) Now, the case of system wide suspend has one special aspect to it, which is the notion that we are bringing down the swap device(s) etc..., and thus we need to have this prepare/finish phase we talked about to give a chance to drivers to secure in memory everything they'll need to succesfully suspend and resume. Additionally, as I explained earlier, it will make everybody's life MUCH easier (especially USB) if we define that between prepare() and finish(), no hotplug activity takes place (the bus drivers just basically ignore devices being plugged in during that phase, or if they can't completely ignore them, at least just leave a bit somewhere "need to come back on resume look what's going on here"). Ben. Ben.
