> > > There are hundreds of drivers, and three hcds. Surely it would be better > > > to let the HCD do the relevant hoop jumping in these cases. > > > > They do. Apart from some massive (and it "really serioiusly" > > appears to me, intentional) confusion on Oliver's part, I don't > > see a problem. > > No, the real simple solution here would be to state that an urb that has > been passed to a completion handler is referenced and must not be freed, > not even by the complition handler itself.
Are you aware of how much you're contradicting yourself? If it's a pure refcount scheme, then a completion handler _could_ very reasonably decrement the count to zero -- causing a kfree. > In the literal sense there are two references to that urb. > One is held by the complition handler/usbcore Let's see, completion handler == driver, usbcore == not driver. So which is it? I'd say "driver" ... The current policy, for the record, is that (except for the periodic URB resubmission case) the HCD doesn't have any further claim on an URB starting with the completion callback. (The callback can always tell if it's a periodic URB that'll be resubmitted.) > and the second is held by the driver. Driver holds two refcounts? That won't typically be necessary. > The driver must retain a reference to an urb it has submitted, because > it needs a reference to unlink it. Or it can use just one, with an appropriate locking policy. - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
