Cc: Kyle Moffett <mrmacman_g4@...>, Nigel Cunningham <nigel@...>, Pavel Machek <pavel@...>, Rafael J. Wysocki <rjw@...>, Matthew Garrett <mjg59@...>, <linux-kernel@...>, <linux-pm@...>
I'll make this reply short by agreeing up front with most of what you
say.
On Sun, 8 Jul 2007, Benjamin Herrenschmidt wrote:
Yes, these are the problem cases.
That's what USB does as well (for the drivers which have runtime PM
support -- at the moment only a few of them).
We can try falling back on this approach for now. If the drivers are
smart enough to fail cleanly when the device is already suspended, it
should work.
But I'm not sure it's a good idea in the long run. Think of a printer
daemon, for example. It shouldn't have to experience unexpected I/O
problems merely because someone has decided to put the system to sleep.
This will be up to the people responsible for the subsystems. I can
take care of USB.
Yes. Rafael, how close is your new notifier chain to mainline? Can it
at least be added to Greg KH's development tree so that I can start
using it?
Exactly.
That's what I had in mind. Rafael, can we add an "icebox" routine?
Like Ben says, it doesn't need to be much more than a waitqueue
that the current task puts itself on if a suspend is in progress.
Callers arriving at a time when the icebox isn't activated should
simply return without blocking. Basically the icebox should be active
at the same times as the existing freezer.
Here's a wacky idea which just might work:
In order to prevent binding and unbinding, while suspending devices all
the PM core has to do is avoid dropping the device semaphores! It can
release the semaphores as it resumes the devices.
Of course, for this to work it's necessary to avoid changes to the
device list during the suspend. However I believe the iteration can be
made safe against unregistration, so we only have to prevent device
registration. (And anyway, it won't be possible to unregister a device
while the PM core is holding its semaphore.)
If we are willing to be somewhat non-transparent, this is easy to
accomplish. After the notifier chain has been alerted about the
upcoming suspend, we tell the driver core to disallow adding new
devices. Maybe use SRCU to synchronize with registration calls that
are in progress. Thus, until the suspend is over device_add() will
immediately return an error. We could even add a new ESUSPENDING code
to errno.h; it would come in handy in a few places.
Drivers are already prepared for device registration to fail (or they
ought to be), so this change shouldn't knock the bottom out of things.
device_add() isn't on a hot path, so adding an extra check and
srcu_read_lock() won't hurt.
I have had the same thought, that unbinding and unregistration would be
easier to handle than binding and registration. As it happens, holding
the device semaphore will block both all three -- which makes life
simpler.
Putting a WARN_ON() in device_add() would be a good idea.
There are other possibilities too. For example, instead of using
keventd these attributes could use a separate workqueue which would put
itself in the icebox during a suspend. Or maybe sysfs can be reworked
so that they don't need to use a workqueue at all.
I hope that everyone will agree that now is a good time to get started
on them. There shouldn't be any problem about having them present
along with the freezer, and then it will be all that much easier to
remove the freezer later on if that's what we decide to do.
Alan Stern
-
