On Wed, 11 May 2005, David Brownell wrote: > > > Thing is there can be a window of around 10 msec there, unless this > > > is the autosuspend case. During those 10 msec, something needs to > > > prevent other code from using that device (e.g. on SMP). For now, > > > that something is hcd->state. Maybe it can be improved, but I don't > > > have timte to do it. > > > > You're talking about the case where the driver is being unloaded, right? > > No, what I recall is seeing this when suspending an HCD with devices > active when (a) CONFIG_USB_SUSPEND isn't set, and (b) their drivers > don't have suspend/resume methods. That's going to be a typical case > for some time ... until we have a solution for that dpm_sem deadlock. > > The delay is required to cope with URBs still in flight. Remember too > that we don't mark devices as being in USB_STATE_SUSPENDED unless they > actually _are_ in that state, so that without CONFIG_USB_SUSPEND there > is no way that usbcore knows to throttle submissions ...
I see. The HCD could reject new submissions during the delay, based on the setting of a new private flag. But at this point it's easier to retarget hcd->state. > > > That is, two bits to control submit and unlink capabilities, > > > rather than the various other ones that now compose hcd->state? > > > > Yes, although 3 states makes slightly more sense than 2 bits since I can't > > imagine a situation where you would allow submit and not unlink. > > So don't use that bit combination! The current states are built out > of bitmasks; same notion, different bits. (Which we can do now that > we collectively understand the problem better!) Okay. So let's assume that hcd->state will be converted into two bitflags: submit_ok and unlink_ok. A few other flags we could profitably add are hc_dead, hc_suspended, and irq_enabled. These could simply be stored along with the other bitflags in the structure. But what about concurrent access on SMP? It's not safe for different processors to write different bits in the same word at the same time, unless they use the set_bit()/clear_bit() routines. The bitflags in there now already have this problem. I'm not sure what the best solution is. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
