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. I didn't mention locking because it seemed obvious that locking is needed. Of course a flag alone is mostly useless. But we already _do_ have a lock (dev->sem) and we _don't_ have a flag. I was pointing out that some drivers will want to have a flag added. Maybe so many drivers will want it that the flag should be added to the PM structure, where it will be available for every device. If only a few drivers want this new flag, then yes, they can put it in their private data structures. > However, I think this is mostly a non-issue, because the core _does_ > provide something here that is useful for drivers who don't want to > bother with the above: The failure return from device_add. If drivers > don't want to do something akin to what I described, they can just be > made to deal gracefully with the failure from device_add that would > happen due to the core internal flag being set after the return from > prepare(). Relying on a registration failure to handle this sort of thing is _not_ a good idea. For example, how would the driver distinguish failure caused by impending suspend from other sorts of failure? 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
