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. :)
Do you have a clear picture of how to make top-down suspend work in concert with device-to-parent port reset? I don't. The only approach
I can make lots of fragments of pictures, enough to eventually assemble into a whole ... :)
I've been able to make work is like what was described before: Try to suspend all the children, then lock the hub, then unlock and go back if it turns out another child was added while you weren't looking.
I think the notion of device-to-parent reset locking is the problem. What if the device gets unplugged while you try to reset it, or it was already reset and that's why it failed, making the driver try to reset it?
Just define usb_reset_device() so the calling task may not hold the dev->serialize lock, and have its first act be to get the lock for the hub. That would imply that probe() paths would (still) not be able to call it directly though. Maybe the reset should always be queued for later.
- Dave
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
