On Thu, 11 Dec 2003, Duncan Sands wrote:
> On Wednesday 10 December 2003 19:19, Alan Stern wrote:
> >
> > I don't understand the problem. What's wrong with dropping dev->serialize
> > before calling usb_reset_device() or usb_set_configuration() and then
> > reacquiring it afterward?
>
> The problem is that between dropping the lock and usb_set_configuration (or
> whatever) picking it up again, the device may be disconnected, so
> usb_set_configuration
> needs to handle the case of being called after disconnect (it doesn't seem to
> check for that right now, but I only had a quick look).
It should handle that okay (provided you retain a reference to the
usb_device so that it doesn't get deallocated). Although it wouldn't hurt
to change one of the tests from
if (dev->state != USB_STATE_ADDRESS)
to
if (dev->state > USB_STATE_ADDRESS)
> Also, after usbfs picks up
> the lock again it needs to check for disconnect. None of this is a big deal, but
> it could all be avoided by a simpler change: provide a usb_physical_set_configuration
> (or whatever), which is usb_set_configuration without taking dev->serialize.
I agree that it would ease things to provide entry points for set_config
and reset_device that require the caller to hold dev->serialize already.
The issue you and Oliver noted about holding the bus semaphore will go
away when I finally get around to rewriting usb_reset_device().
Alan Stern
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
