Right - that sounds like a good plan for a real driver. Using the usbdevfs code however, if you call proc_reapurb() the completed request is freed before the call returns to you, so there is still a chance the urb will interrupt again before you get to cancel it.
since usbdevfs always frees that urb, it doesn't seem it would work on any urb which resubmits itself for any reason. Perhaps the free_async() code should explicitly unlink the urb before freeing the memory. Roland On Thu, 14 February 2002, David Brownell wrote: > > > It's odd that the two types of hardware treat the interrupt case where > > interval == 0 differently. Is either of them wrong by the specification > > or are they both right? > > My take is that the interval==0 behavior is a UHCI driver behavior > that should not be relied on. Magic values like that are trouble. > > The portable way to get a one-shot interrupt transfer should be > to submit the transfer as usual (real period) then unlink it in the > completion handler for that transfer. _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
