On Thu, 2008-03-20 at 14:26 -0400, Alan Stern wrote: > > 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? I don't fully understand what you are saying here. You say "bind a new driver to a device after it has gone through the prepare() stage" So either there was already a driver bound to that device, which got a prepare() callback, and in which case bind() doesn't mean much. Or there was not, in which case there was no prepare() call involved. I suppose if you prepare(), then unbind(), then something tries to bind()... But wouldn't the core flag set after prepare() be plenty enough to shield against that ? I fail to see the race you are talking about here. Ben. -- 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
