On Wed, 12 Mar 2003, David Brownell wrote: > > I only put it in the driver because strictly speaking, this needs to be > > stored as per-interface state rather than per-device. If there's no > > problem with the core maintaining per-interface data, then fine. It would > > still require an additional argument to usb_bulk/control_msg(), to specify > > the interface. > > Except for control messages, urb->pipe easily lets you track > which endpoint and hence which interface the request is for.
Okay, so the extra argument is only needed for usb_control_msg(). But it wouldn't hurt to have it for both; there must be a certain overhead involved in iterating through all the interfaces' lists of endpoints to see which contains the endpoint of interest. Unless you've added a data structure to speed up that process... > Actually the relevant primitive is "unlink all the requests > to this endpoint"; they're owned by the hardware, and some > of them are likely partially completed. That's the primitive > which is generally useful, in the "driver unbind" cases (not > necessarily just disconnect) as well as for config changes. What about requests for endpoint 0? They may have been submitted by several different drivers. > > If you mean that nobody has ever needed to cancel just a single > > synchronous message except as part of cancelling all of them for a > > disconnect, I agree. > > Yes. Same is true when the driver uses asynchronous models too. Surely you don't mean to say that drivers call usb_unlink_urb() with the URB_ASYNC_UNLINK flag set only during disconnect()? > > How does your patch know which interface a request is intended for? > > Looks at the endpoint addressing information. Again, what about requests for endpoint 0? > > Also, perhaps it would be better to unlink them _after_ disconnect(). > > That way the driver won't be tempted to try to re-issue the requests when > > they complete with an error. > > That last patch of mine makes submits fail ASAP, even before > disconnect() is called ... so "reissue" can't happen, at > least in the device disconnect code paths. Reconfig has never > worked right AFAICT, needs work still. > > Unlinking them _before_ is likely to make some drivers unhappy, > but this is a case where I think the cleaner solution is to be > preferred ... fewer ways that things can go haywire is Good. Hmm... I still think it might better be done after. But either way seems about equally clean and reliable. Maybe you're just trading off the possibility of things going haywire in the core against things going haywire in the driver. Of course, neither will actually happen ;-) Alan Stern ------------------------------------------------------- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
