Re: pmf(9) clarifications

[David Young <dyoung%pobox.com@localhost>]

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.

Dave

-- 
David Young
dyoung%pobox.com@localhost    Urbana, IL    (217) 721-9981