> Here's how I see it. > > dev->serialize is meant to protect significant state changes, things like > set_configuration and device disconnect. ps->devsem is meant to protect > against usbfs trying to do two things to the device at the same time.
Actually no: it is a read lock and all routines take it with down_read except for the disconnect routine. So it is only there to guard against disconnect. > But you also want to protect against usbfs using the device during a state > change. (The normal protection mechanisms don't work because usbfs might > be using a device without having a driver bound to any of its interfaces.) > Given that, there's no reason usbfs shouldn't just use serialize instead > of devsem. > > The fact that the core calls driver_disconnect with serialize already held > then just makes your life simpler: You don't need to acquire the lock > yourself! > > The only tricky part is that you have to release serialize (which now is > your only lock) before calling set_configuration. But as you said, you > would have to release ps->devsem anyway, so nothing's lost there. > > Anything wrong with this approach? Nothing - that is exactly what my patch does. And it works... except for the Oops in usb_put_dev. All the best, 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
