On Fri, 19 Sep 2003, David Brownell wrote: > Alan Stern wrote: > > > But for the other "device-morphed" case we don't need to do all that > > stuff. There's no need to get rid of the current struct usb_device and > > allocate a new one; just re-use the existing one. Re-enumeration can pick > > up with the device already in the ADDRESS state. > > That could work too. I thought the other way looked like less code; > maybe not, it depends how the parts get assembled. I also liked the > idea of just _knowing_ there's can't be old state lying around.
No doubt it would work either way. It just seems like a shame to have to go through the whole "reset the port, allocate the struct usb_device, and set the address" routine when it's not needed. > >>for the device. That means khubd disconnecting this driver (assuming it > >>successfully probed) and putting the port into a state where it'll > >>start enumerating again. Isn't there sume hub port feature we can > >>set/clear that'll automatically do that? > > > > > > There isn't, unfortunately. There is a hub port feature that would do it, > > but it can't be set, only cleared. We will have to invent some way of > > queueing such a request. > > That's a part that needs investigation. If we can't notice the > end of a reset sequence using current khubd code, surely it can be > taught to have non-hub devices in its queue! All we have to do is change the type of notifications that khubd gets. > > Not having thought this through very carefully, I don't want to say too > > much. But I don't think we can rely on the bus rw-semaphore, because that > > might or might not be held during usb_reset_device(). > > True. Which is why I want reset_device() to be orthogonal to config > change processing, so locks won't collide as readily. It's not clear what that means. The _best_ way to make sure that locks in two routines don't collide is to arrange things so that the second routine only runs when it's called by the first -- the very opposite of orthogonality. > > Consider the "device morphed" case. When that happens we have to wind > > everything back to the ADDRESS state, which means unbinding all the > > drivers and destroying all the interfaces. The question is, should the > > unbinding be done right away (within the usb_reset_device() routine) or > > should it be delayed until khubd or keventd or whoever gets around to > > seeing the queued request? Oliver has said, and I agree, that the drivers > > should be unbound immediately. > > I must have missed that discussion. See <http://marc.theaimsgroup.com/?l=linux-usb-devel&m=106046334808580&w=2> > Why? We already know drivers > "shall" handle device unplug at any such awkward instants; and it's > not as if any driver bound at that instant is ever going to succeed > in another i/o call to that device until it "re-enumerates". If they > can clean up after that, they can clean up post-morphing too. > > Why have two almost-identical faults expect different cleanup? > Plus, remember how complex the disconnect processing is already. > An "even more immediate" cleanup mode wouldn't simplify... It's true that so long as the device remains in the DEFAULT or the ADDRESS state, a driver is unlikely to be able to make it do much of anything. So perhaps deferring the unbinding wouldn't hurt. Alan Stern ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
