You're saying that usb_reset_device() doesn't really need to lock the hub? Doesn't this contradict what you wrote earlier:
If various things changed, it wouldn't need to. And the last suspend patch I posted did actually change one of them: to use the top-down (from the root) locking. I perhaps should have drawn out the consequence at that point, but reset() was not my focus at that moment. See below.
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?
Maybe a bit strong. I'm also not sure they _can't_ either ... right now the discussion is pushing constraints around, so that some issues can be shaken into slightly different boxes. So "later" became "sooner", and if there's a problem then we can find and deal with it then.
For example, I mostly view that locktree() routine as affecting the upstream link from a given device. So it correspondingly serves as a lock on the other side of the link, downstream from its hub port. That's not the kind of finer grained locking that I understood you to be talking about, FWIW, but it does help converge our perspectives. (Converging being IMO one of the key points of this discussion!)
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.
Hmm, I guess that's a different definition than I was using. The reason for that locktree() was specifically to provide certain global integrity constraints by requiring from-the-root locking. Now, there may actually be cases where those constraints aren't needed, but just now I'm not ready to think about exceptions-to-the-rule while we're still working on defining the rule in the first place!
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?
Well, selectively locked: just against other SET_CONFIGURATION calls. I'm sketching a way to get dev->serialize locking out of one of the paths you're concerned with, that's all.
- Dave
-------------------------------------------------------
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
