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