Thread (1 message) 1 message, 1 author, 2008-03-06

Re: [RFC][PATCH] PM: Make PM core handle device registrations concurrent with suspend/hibernation

From: Alan Stern <stern@rowland.harvard.edu>
Date: 2008-03-06 20:28:26

On Thu, 6 Mar 2008, Rafael J. Wysocki wrote:
On Thursday, 6 of March 2008, Alan Stern wrote:
quoted
On Thu, 6 Mar 2008, Rafael J. Wysocki wrote:
quoted
quoted
I thought of one more thing you might want to add: device_pm_add() 
doesn't handle the case where dev->parent is NULL.
I'm not sure what you mean.

If dev->parent is NULL, we get into the "successful" branch where the device is
added to dpm_active.  Do you think we should add any extra handling of this
case?
If a device is registered after dpm_suspend() has returned, the
device won't be suspended properly before the system goes to sleep.  

If the device has a parent then you're okay, because the parent must
already be suspended and so device_pm_add() will fail.  But if the
device doesn't have a parent then device_pm_add() will succeed, which
you don't want.
Well, can it happen in practice?  If it can, then what way can it happen?
Yes, it can happen in practice when a new module is loaded.  In some 
ways, modules' init routines are like probe methods.

Maybe it can happen some other ways too, but I don't know of any.
It seems to me that we're discussing purely academic stuff here.  If it turns
out to be of any practical relevance, it will be trivial to add the handling of
it in the future.
To be safe, I think we should make system sleep mutually exclusive with 
module loading.

Alan Stern
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help