>>And they might not time out, depending on how they're called. > > > What causes this ?
Caller didn't ask for a timeout. ;) >>>>>Races with probe: >>>>>usb_reset_device, a probe while resetting is bound to malfunction >>>> >>>>Like David said, I don't think this is a problem. >>> >>>Then usb_reset_device() should be removed from usbcore and added >>>to the storage driver. >> >>It can't be added to storage ... enumeration tweaks internal >>usbcore state that shouldn't be generally available. > > > Then it has to have proper locking, basically neither probe() > nor disconnect() must run concurrently to usb_reset_device() > and no other synchronous helper should run. That seems right to me. I'll be glad if that whole mess of device state management starts to get more sensible. It might be worth adding a field to the usb device struct, an enum with the various device states, and maintaining it. At least while debugging, some BUG_ON(state!=CONFIGURED) statements might help shake loose some of the less obvious issues. (Where the locking stuff you're working on has previously been in the "obviously broken" state!) - Dave ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
