Re: Drivers without suspend/resume/reset-resume support

On Thu, 11 Oct 2007, Oliver Neukum wrote:

> Am Mittwoch 10 Oktober 2007 schrieb Alan Stern:
> > Oliver:
> > 
> > We discussed earlier that if a driver doesn't have suspend/resume 
> > support, it ought to be unbound when its device is suspended.  
> > Likewise, if a driver doesn't have reset-resume support then it ought 
> > to be unbound when a reset-resume occurs.
> > 
> > It turns out this isn't as easy as it sounds.  Upcoming changes to the
> > driver and PM cores will make it very dangerous to unbind drivers
> > during a system suspend: If the driver's disconnect method tries to
> > unregister a child device, it will deadlock.  (Likewise, although it
> > doesn't matter for our purposes at the moment, if the driver tries to
> > register a child device, the registration will fail.)
> 
> When exactly? Can we defer the unbinding to resume() ? From the
> viewpoint of the hardware we are OK if we disable the endpoints and
> nuke all URBs.

The bad period of time begins when the PM core starts its procedure of
calling the suspend methods in all the devices, and it ends when PM
core has finished calling all the resume methods.  (If you want the
exact timing, look in drivers/base/power/main.c in Greg's most recent
patchset.  lock_all_devices() acquires all the device semaphores,
thereby blocking unregistration, and registration will fail whenever
pm_sleep_rwsem is write-locked.)

It's possible to defer the unbinding until the post-SUSPEND or
post-HIBERNATE notifier call, since that occurs after all the resume
methods have run and before userspace is unfrozen.  We're okay as far
as URBs and endpoints are concerned; the code in usb_suspend_both()
flushes all the endpoints and prevents further submissions.

> > One way around the problem would be to unbind these bad drivers before
> > the suspend begins, say in a notifier routine.  That would leave a
> 
> Problematic. You'd have to get the order of doing stuff exactly right.

What order are you concerned about?  It will be impossible to have
complete transparency anyway.  For instance, if userspace has opened a
device file for a non-compliant driver then the file descriptor will
become unusable when the driver is unbound, regardless of exactly when
the unbind occurs.

Of course there's always the other approach -- solve the problem by 
adding suspend and resume methods to every driver!

> > question about how to handle non-system suspends, such as when the user 
> > does "echo suspend >/sys/.../power/level".  But it's a nuisance any way 
> > you look at it.
> 
> IMHO these should fail if the drivers don't support it.

Maybe.

> > The reset-resume problem is even worse, since we don't know beforehand
> > when a reset-resume will be needed.
> 
> As we don't know whether the reset_resume() call will return an error, this
> doesn't increase the difficulty. I'd prefer the defer the unbinding as much
> as possible, right before user space is woken. This way we can sanely handle
> errors in resumption.

Remember also that an eventual goal is to eliminate the freezer.  
What's the right approach when userspace never does get frozen?

Simply adding suspend/resume support is looking more and more 
attractive...

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel