Re: Patches still in the queue

Am Dienstag, 15. Mai 2007 16:33 schrieb Alan Stern:
> On Tue, 15 May 2007, Oliver Neukum wrote:

> > Yes, and it seems to me that persist should have its own method.
> > Those drivers that don't define it, don't support it.
> 
> It could have its own method.  The method would be nearly identical to
> post_reset(), since they have to do exactly the same thing as far as
> the device is concerned.  In fact, it probably would call post_reset().

With the additional option of running tests to make sure that the device
is indeed still the device it is supposed to be, eg reading out MAC.

> I'm not sure what you want to do with drivers that don't define a
> reset_resume method.  To say they don't support it is like saying they
> don't support regular resume; it may be true but it doesn't help.  We
> don't unbind drivers with no resume method and we don't unbind drivers
> with no post_reset method, so why should we unbind drivers with no
> reset_resume method?

Firstly, perhaps we should unbind if there's no post_reset().

Secondly, we are asking drivers to do something outside the spec. It's
not against the spec, but by no means inside. There is a way to handle
power failure in the spec, that is to reenumerate.

Thirdly, in some error cases, you _will_ need to reenumerate anyway,
eg. firmware gone, configuration cannot be restord, etc...

Fourthly, some drivers cannot do it in principal, because they cannot
restore a device's state, eg. printer, scanner, ...

> Another reason for not doing it is because there's a certain amount of
> fragility involved in unbinding drivers during a reset-resume (or
> during any kind of suspend or resume, for that matter).  These events
> can occur without the device lock being held; this happens with

You surely want to do this in single threaded manner before user space
is unfrozen, don't you?

> autosuspend and autoresume.  Hence the unbind would have to be deferred
> to a different thread -- as in that usb_rebind_interface() patch I
> wrote.  I don't like that approach; it adds too much additional 
> complexity.
> 
> On the other hand, if a driver doesn't support autosuspend then its 
> device will never be autosuspended or autoresumed.  Hence suspend, 
> resume, and reset calls will always occur with the device lock held.  
> In this case it would be safe to allow for rebinding in lieu of 
> resume, post_reset, or reset_resume.  What do you think?

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?

	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