Re: Patches still in the queue

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/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel