The considerations for usb_reset_device() should be pretty much the same as for usb_set_configuration(). If the reset succeeds and the descriptors don't change and everything else works, then nobody needs to be unbound or probed. But if that doesn't happen, the situation is much the same as if the configuration was deliberately changed.
It's much simpler if you think of the considerations as different ... :)
If the reset succeeds without the device changing, then the current code is pretty much correct -- except that the code doesn't use the device semaphore. (I seem to recall leaving all such issues for your rework of the reset code.)
If the reset fails somehow, or succeeds with descriptors changing, that should be handled by forcing khubd to perform disconnect processing 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?
In neither case is usb_set_configuration() directly involved. It's only used from khubd.
The real issue is ownership of usb_dev->serialize. set_config() -- and
reset_device() when something goes wrong -- must possess the mutex. But
if they're called during probe() then the thread they belong to already
owns it; they don't need to acquire it again. So there has to be some way
for the caller to say "Don't try to grab the serialize mutex because you
already own it somewhere earlier in the call stack". Yes it's awkward, but I don't see how else to do it.
Well, usb_set_configuration() shouldn't be called from driver probe(); leaving usb_reset_device(). And given what I described above, I don't see why that would have a problem. But some of those paths don't need to keep the device lock, since they're protected by the bus rwsem; so they might drop it before outcalls (and grab it on return), if needed.
One way around this problem is simply to outlaw calling either routine from within a probe. But I think that may be going too far. For example, usb-storage uses usb_reset_device() as a last-ditch error recovery method, and it doesn't distinguish whether the error occurred during probe or during normal operation.
See above. I think usb_reset_device() should be nearly OK, except for locking and the "now kick khubd" path (which has never worked). There's no interaction with the usb_set_configuration() code except indirectly, in that new "kick khubd" path.
- Dave
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
