That was another good analysis, and I don't think I much want to disagree with any of it. Though I'll note that the timescales differ ... in particular the enumeration part of (6) is commonly at least 200 msec, sometimes more. while most everything else is 1 msec or so (except for suspend/resume/reset, at tens of msec) assuming that the driver callbacks don't delay things.
Also, (4) suspend/resume and (5) reset are mutually exclusive types of signaling. For consistency, you should group them together as you did for (7).
Alan Stern wrote:
This means that (6)-(7) on a port can be treated as though they belong to the child device. In other words, for any device we can imagine the possible actions are (1)-(5) plus (6) & (7) on the upstream port. When viewed this way, it turns out for any device all the actions must be mutually exclusive.
True, though during most of (6) -- debounce! -- there is no struct usb_device.
I'm thinking that's fine, since debouncing is done only once per connection. And I like the notion of avoiding any more concurrent power-related operations (per hub) than necessary. (That's an easy place for hub vendors to shave costs...)
There are some other considerations too. Like, while suspending the
entire subtree below a hub you don't want some other process to start
resuming the devices you've just suspended. To prevent this sort of thing both usb_suspend_device() and usb_resume_device() should use the locktree algorithm. I don't think it's needed for reset or disconnect, though.
Disconnect, sure -- assuming we mark trees dead ASAP, so that further operations on those devices fail ASAP.
I'm not sure I see why it wouldn't apply for reset() though; your group (7) was "port suspend/resume/reset", so consistency would argue they should all apply the same locking policy.
There's also khubd to consider. Shouldn't it also use the same policy?
Now maybe I've overlooked something here or oversimplified in some way. But altogether I think this makes a good case that using a single lock is
the way to go.
That is, one per device, not changing away from dev->serialize? And hub->khubd_sem vanishing? I'd be fine with that. We may need to address some corner cases, but the analysis I snipped suggests there shouldn't be any.
- 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
