Am Dienstag, 15. Mai 2007 20:40 schrieb Alan Stern:
> On Tue, 15 May 2007, Oliver Neukum wrote:
> > Fourthly, some drivers cannot do it in principal, because they cannot
> > restore a device's state, eg. printer, scanner, ...
>
> Yes. Conversely, some drivers don't care about it at all because they
> don't maintain any state in the device.
That I doubt. There's always the relationship with open files. Usually
eg. with mice you don't care because you use /dev/input/mice, but
if for any reason you use a specific mouse, you care.
> > You surely want to do this in single threaded manner before user space
> > is unfrozen, don't you?
>
> If we're talking about resuming from a system sleep, yes. But the same
> code paths get used in other circumstances. For example, you may
> remember the Philips audio device which needs to be reset because it
> can't resume -- it would get a reset_resume call during normal
> autoresume processing.
I think you are mixing things that shouldn't be. Recovery from a loss
of power is different from getting reset for resume. In the latter case
identity is not in doubt.
> Resets can occur whenever userspace requests them via usbfs, just as
> userspace can force a device to be suspended and resumed. So in any
> context we may face the possibility of a driver without a resume(),
> reset_resume(), or post_reset() method.
Yes. But reset_resume() is another category.
> > I think that locking matters only for autosuspend/resume. For pre/post_reset
> > the caller initiating the reset should be responsible for locking the
> > device.
> > I don't see your line of reasoning here. Could you elaborate?
>
> You are correct that autosuspend and autoresume are the only paths in
> which the device might not be locked. Hence rebinding a driver would
> be troublesome only in cases where the driver sets
> .supports_autosuspend and yet doesn't define both a resume() and a
A driver that does not resume() but autosuspend is buggy. Plain and simple.
> reset_resume() method. In such cases we could skip the rebinding.
Indeed. But if we do that we must unbind. We can't have undead devices.
Regards
Oliver
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
