tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pmf(9) clarifications

On Wed, Apr 04, 2012 at 07:25:55AM +0100, Iain Hibbert wrote:
> Hi
> Regarding pmf(9) API, is it safe to call pmf_device_deregister() if the
> device was not successfully registered as a power handler? The
> documentation does not mention this (though the code looks as if that
> would work fine), nor the device_pmf_is_registered() function which may
> not be actually required? Some driver detach functions use it and some do
> not..

I think that drivers should never call device_pmf_is_registered(), but
sometimes they do anyway.

I don't know if it's safe to pmf_device_deregister() if you haven't
successfully pmf_device_register()'d, but it seems that config_detach()
could help drivers out with the de-registration.

> Also, is it allowed to sleep during suspend/resume?

Yes. fdc(4), for example, sleeps until the disk has stopped I/O or
seeking, and turned off the motor.

> documentation does not mention this, but it seems that shutting down
> cleanly might involve a flush of some kind. (I see that
> pmf_system_suspend() does flush disk caches specifically before the
> suspend, which sidesteps the issue a little)

I think the idea is that by the time pmf_system_suspend() calls
do_sys_sync(), no more buffers can be queued on the filesystems, and
after do_sys_sync(); bus_syncwait(), no more buffers can be queued on
the drivers except by pseudo-disks such as cgd, dk, and raid.  Disk
drivers will ordinarily stop servicing their buffer queue and will order
the hardware to flush its cache.


David Young    Urbana, IL    (217) 721-9981

Home | Main Index | Thread Index | Old Index