> > Hi Oliver, I agree, except that there are several layers of locking: > > dev->serialize but also the bus rwsem. So does "physical" mean no > > subsys.rwsem or no dev->serialize or both? > > "physical" means no locking at all. It's the caller's responsibility. ...
> That's what the core cares about. No probe() while a reset is in > progress. Taking the semaphore ensures that. Hi Oliver, I'm a bit confused about the locking rules. I suppose (1) If both subsys.rwsem and dev->serialize are taken, then subsys.rwsem must be taken first. (2) dev->serialize atomizes changes to the struct usb_device. Why then is dev->serialize not taken in usb_reset_device (except in a dud code path)? Also, why isn't dev->serialize enough to protect against probe() during usb_reset_device? After all, won't dev->serialize be held during the probe calls (I didn't check this and I'm in need of coffee - I hope I'm on the right planet...) Ciao, Duncan. ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
