[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:
> 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
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.
dyoung%pobox.com@localhost Urbana, IL (217) 721-9981
Main Index |
Thread Index |