For instance, is it guaranteed that probe and remove will never run simultaneously? Is it guaranteed that neither suspend nor resume will be called during either probe or remove? Is it guaranteed that suspend and resume will not overlap? These are all things I would expect, much as usbdev->serialize enforces similar guarantees for USB device drivers.
The driver model logic constrains probe/remove; only one task is going to have the bus rwsem at a time, so those won't be concurrent. As for the rest, I'd have to UTSL ... :)
For USB, usbdev->serialize should be much more focussed in what it protects. The PM code locks are also focussed in what they protect. The protection regions won't in general be overlapping except for short periods; which is why they each have their own locks.
Are you sure "running" is just two values? Seems to me that suspend/resume adds at least two more states...
Well, maybe one more state: stopped, suspended, and running. I'm not sure there's a significant difference between stopped and suspended, though. The only difference I can think of lies in the response to remote wakeup requests. Maybe that's enough.
Another difference is that a suspended bus should have a tree of USB devices (root hub down) but a dead one shouldn't have any.
- Dave
------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
