I'm only going to respond to a few points here, because this discussion is getting a little out of hand...
On Wed, 5 May 2004, David Brownell wrote: > > The big question is how to make device resets work. It's pretty clear > > that usb_reset_device(udev) needs to lock both the parent hub and udev. > > I don't quite see that. During the brief period during enumeration when > (a) both devices exist, and (b) set_configuration hasn't yet succeeded, > it'd be in a retry loop which can re-create the device -- sure. > > But during usb_reset_device(), there are basically two outcomes, neither > of which require the hub to be locked: (i) device resets fine, and is > restored to same configuration and altsettings. No topology changed. > (ii) reset fault, including "device morphed" and "error" cases, which > should trigger disconnect/cleanup. (And then later re-enumeration.) You're saying that usb_reset_device() doesn't really need to lock the hub? Doesn't this contradict what you wrote earlier: >> I interpreted "children" to mean just usbdev->children[], not ports. If >> you allow it to include the ports as well, you rule out the possibility of >> manipulating different ports simultaneously. I admit that doesn't come up >> very often, but do you really want to prevent it entirely? > > If finer grained locking turns out to be necessary, it could > be added later. Are you sure all hubs can support that sort > of concurrent manipulation? I'm not. I took that to mean you thought there should _never_ be concurrent operations on a hub, even if they are manipulating different ports. It seems like a good idea. Was my interpretation wrong? > > This won't deadlock with disconnect caused by unplugging the device (or > > unbinding the hub driver!) because the device's state will be changed to > > USB_STATE_NOTATTACHED. It won't deadlock with disconnect caused by > > rmmod'ing the driver because that won't lock the hub. To prevent > > But it'd lock an ancestral hub ... same net effect yes, unless the > locking isn't really top-down (from root hub)? No, disconnect caused by rmmod'ing a device driver doesn't lock _anything_ except the bus subsystem's rwsem. And even if it did lock the device, there wouldn't be any reason for it to lock the device's parent hub or any higher ancestors. Top-down doesn't mean that you _always_ start from the root; it just means that you never acquire a parent's lock while holding a child's lock. > > Next we need to lock udev itself. However, if some other thread already > > has locked udev (for suspend or unbind) then we generally want to fail. > > So a simple down_trylock() will suffice. I no longer agree with this. Suspend isn't an issue because suspend will always lock the hub before locking the device. Unbind is ... well, it's a mess. > > The last problem is dealing with device resets during probe. The first > > part of this problem -- locking the hub -- might be easy. Is there any > > reason why usb_new_device() can't be called with the hub unlocked? > > If SET_CONFIGURATION errors didn't enter a retry loop, then the > failure modes should just cause "normal" re-enumeration. But the > downside is that they'd probably do it forever. And regardless, > something (a simple per-device locked flag could suffice) would > need to prevent concurrent SET_CONFIGURATION calls. That was > the "germ of an idea" I mentioned above. Actually, it's a lot simpler if the hub remains locked during usb_new_device(). Forget about that idea. As for per-device "locked" flags -- isn't that what serialize already does? Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
