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.
That doesn't seem to be the way the code is heading -- in your CONFIG_USB_SUSPEND patches it's up to the caller (presumably some userspace process) to suspend everything below the hub before suspending the hub itself. A user process can't hold a topology lock. It can suspend the children, one by one, but in between them and then again just before suspending the hub the ->serialize lock will be released, leaving the hub free to add another child.
If another child was added, the suspend would (safely) fail. That's what I mean when I said dev->serialize protected things.
That preliminary hub support was just to avoid needless failure in a common and obviously safe case: nothing active, so the suspend state wouldn't get out of sync. Like a root hub with nothing connected ... or a subtree where I manually suspended some links to make sure they'd re-activate with remote wakeup.
I've got some updates to that code to support top-down suspend and resume, so that's not really the way that code is heading. The serialize lock can be held while suspending hubs children. It was a case of walking before running. :)
- 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
