[lkml]   [2003]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [linux-usb-devel] Re: [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1
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)


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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:59    [W:0.092 / U:13.660 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site