On Thu, 20 Mar 2008, Benjamin Herrenschmidt wrote: > > An important point I tried to make in the earlier email is that drivers > > will want a simple way to know when it is illegal for them to register > > new children. For example, suppose the registration is done by a > > workqueue routine. The most reliable way for the driver to insure that > > the routine won't try to register new children improperly is to have > > the routine check a flag which gets set _before_ prepare() is called. > > I don't totally agree here. Drivers could have their own flag set > internally with appropriate locking. The problem with your approach is > locking. Just setting a flag is mostly useless, -unless- there > appropriate locking between setter and testers. Here's an example of what I mean. One of the things we don't want to do is bind a new driver to a device after it has gone through the prepare() stage. Doing so would involve calling the driver's probe() routine, which is likely to want to register new children and who knows what else. The probe routine might even end up running after the device was suspended! Clearly this should be avoided. But the user can force a binding to occur by writing the device's path to the driver's "bind" attribute in sysfs. This means that driver_bind() in drivers/base/bus.c will need to know whether or not the device has gone through the prepare() stage, which means the device structure will need to have a flag set before prepare() is called (more precisely, the flag must be set before dev->sem is released following the call to prepare). Either that or else driver_bind() must always block whenever a system sleep is in progress. That would be easier -- but it's a lot like what the freezer would do. Which would you prefer? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html