On Wed, 11 Jul 2012, Rafael J. Wysocki wrote: > > This opens up the possibility of calling probe while a runtime resume > > or suspend is in progress. (On the other hand, the existing code > > doesn't prevent a concurrent runtime resume.) Maybe it would be best > > to leave the pm_runtime_barrier(). > > That wouldn't close the race, though, because the suspend/resume may still > be started right after _barrier has returned. True, but see below. > The race is only possible if runtime PM is enabled by a subsystem or PM domain > code before the first eligible driver is registered and if that code is not > careful enough to get ready for driver registration. I'm not sure how likely > it is to happen in practice. It's not just the first eligible driver. Drivers can be bound and unbound dynamically, and suspends/resume operations can sit on the wait queue or wait until a timer expires. We don't want an old request suddenly to take effect in the middle of a probe. The barrier will get rid of any old requests. New ones would have to be added after the probe starts, which as you say, is unlikely. Alan Stern
