On Tuesday 10 May 2005 8:55 am, Alan Stern wrote: > On Mon, 9 May 2005, David Brownell wrote: > > > Won't it > > > be enough to rely on the HCDs to reject submissions when they are unable > > > to accept them? (Plus the fact that thanks to all the cleanups made in > > > the last couple of years, hardly any submissions are made at inappropriate > > > times.) > > > > 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 ... > > > If you really want to do this from within usbcore, consider restricting > > > hcd->state to only three possible values: > > > > > > Okay to submit and unlink (running normally); > > > Okay to unlink but not to submit (quiescing); > > > Not okay to unlink or submit (any other 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!) > > > And even the PCI glue info should be kept separate from things used only > > > by HCDs. Right now hcd->state mixes all these different categories > > > together in a confusing and error-prone way. > > > > It's called "evolution in action". ;) > > As you wish... :-) > > Alan "Natural Selection" Stern Don't you mean "Selector" not "Selection"? :) - Dave ------------------------------------------------------- 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
