Re: use of pm_runtime_disable() from driver probe?

[Alan Stern <stern@rowland.harvard.edu>]

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