Re: [linux-pm] [patch update 2 fix] PM: Introduce core framework for run-time PM of I/O devices

Rafael J. Wysocki
2009-06-21T11:32:29Z

On Sunday 21 June 2009, Alan Stern wrote:
> On Sun, 21 Jun 2009, Rafael J. Wysocki wrote:
>
> > On Saturday 20 June 2009, Alan Stern wrote:
> > > Some more thoughts...
> > >
> > > Magnus, you might have some insights here. It occurred to me that some
> > > devices can switch power levels very quickly, and the drivers might
> > > therefore want the runtime suspend and resume methods to be called as
> > > soon as possible, even in interrupt context.
> >
> > Then, we'll need special suspend and resume calls for them.
>
> Good idea. pm_runtime_resume_atomic() and pm_runtime_suspend_atomic().
> No need for _request variants since the status should never be
> RPM_SUSPENDING or RPM_RESUMING while the lock is released.

Yes, exactly. I also thought of the same names. :-)

> > > Similarly, we should insure that runtime PM calls made before the
> > > device is registered don't do anything. So when the device structure
> > > is first created and the contents are all 0, this should also be
> > > interpreted as an exceptional state. We could call it RPM_UNREGISTERED
> > > and use it for both purposes.
> >
> > Hmm. How do you think is possible that the pm_runtime_* functions will be
> > called in such a situation?
>
> By mistake. :-)
>
> Seriously, there _are_ places where drivers get bound to device before
> those devices are registered. This happens for example in USB when a
> bunch of related interfaces are present in the same physical device.
> When the first interface is registered, its driver binds itself to all
> the others even though they haven't been registered yet.

Well, the suspend functions could be protected against that under the
assumption that no suspend is possible for resume_counter = 0 (then, the "good
to go" value would be -1).

Still, the resume functions start from acquring a spinlock, which is not going
to work if that spinlock is uninitialized.

Best,
Rafael