It's a tricky problem, and I haven't figured out all the ramifications yet...
Me either. That means we haven't hit on the right simplifications yet ... :)
That's not what I had in mind. Suppose we want to suspend hub B. Then first we have to go through all of B's children and suspend them. While that's happening, another child could be connected to B. It would then be necessary to go back and suspend that child. Not too bad, I suppose.
Unless some appropriate topology lock were held, preventing khubd from enumerating that port. In my scenario before, that was dev->serialize.
But consider this scenario:
khubd some other thread ----- ----------------- Suspend all of B's children Suspend B: Acquire B->serialize Receive port-connect- change message from B Try to acquire B->serialize Tell A to suspend B's port Release B->serialize Process connect-change on B ???
That'd get -EHOSTUNREACH when it tried to do anything like clearing the connect status change feature. Which would be a hint to usb_resume_device(B) and restart using current port status.
Your use of B->serialize in "other" thread isn't quite what I described, fwiw.
- Dave
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
