Re: [linux-pm] subtle pm_runtime_put_sync race and sdio functions

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Wednesday, December 22, 2010, Alan Stern wrote:
> On Tue, 21 Dec 2010, Rafael J. Wysocki wrote:
> 
> > It basically goes like this.  There's device A that is only resumed when it's
> > needed to carry out an operation and is suspended immediately after that.
> > There's another device B that needs A to do something during its suspend.
> > So, when the suspend of B is started, A is woken up, does its work and is
> > suspended again (using pm_runtime_suspend()).  Then B is suspended.
> > 
> > We currently require that ->suspend() and ->resume() callbacks be defined
> > for A (presumably pointing to the same code as its runtime callbacks) so that
> > things work correctly, but perhaps we can just relax this requirement a bit?
> > I'm not 100% sure that's a good idea, just considering it.
> 
> I still don't know.  It would require a lot of special conditions: no
> child devices, not runtime-PM-disabled, not runtime-PM-forbidden...  
> Also, A's parent would have to be coded carefully; otherwise A's
> runtime resume would prevent the parent from suspending.
> 
> This just doesn't fit very well with the runtime PM model, or at least, 
> not in the form you described.
> 
> Consider this instead:  Since A is required to be functional before B
> can be used, A must be registered before B and hence B gets suspended
> before A.  Therefore during the prepare phase we can runtime-resume A
> and leave it powered up; when B needs to suspend, it won't matter that
> the runtime-PM calls are ineffective.

We don't really need to do that, because the runtime resume _is_ functional
during system suspend.  The only thing missing is a ->suspend() callback for A
(and a corresponding ->resume() callback to make sure A will be available to
B during system resume).

> Then when A's dpm_suspend occurs, it can safely go to a low-power state and
> stay there.

Agreed.

Thanks,
Rafael