On Sat, 1 May 2004, David Brownell wrote: > Alan Stern wrote: > > > 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. > > 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. This no longer is a problem if khubd is smart enough to check B's state after acquiring the semaphore. Alan Stern ------------------------------------------------------- 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
