> > No HCD could resolve that race, any more than other > > parts of usbcore could, since it happens after the HCD > > has given up ownership of the URB. > > > > > (or the completion handler could) > > > > ONLY completion handlers can do that. HCDs can't, as I > > just explained above. > > Ok, it has to happen as a part of the interrupt service routine.
An ISR would be part of the HCD ... so my earlier comments apply. That can't work. And the work doesn't actually need to be done in_irq(), fwiw. > Thus, doing it with a flag (and both the urb->dev and the > urb->status methods are effectively flags) is difficult "not possible" ... as with the "urb->users" flag you sketch. The race begins when such a flag's value changes (in the hcd parts of usbcore) and ends when the completion routine finishes its work on the URB. > and we should really > move to usage counting, where the counter is decremented after > the completion handler (here refering to the user supplied part) > returns to the HCD based part of the isr. In the context of the race I described, a usage counter would be just another kind of flag that can't eliminate the race. Simpler to just have completion handlers explicitly put urbs on lists when they're available for reuse. - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
