> There is one small problem with uhci.c (patch appended) where it checks > urb->status after the completion handler. It should only do this if it's > an auto resubmitting interrupt URB, but we always checked it. > > Other than that, it does not touch the URB after calling the completion > handler *unless* it's an auto resubmitting interrupt URB ...
Right, that's my understanding of the right thing to do; and I'm glad to see that patch. :) > > I think that completion handlers should be able to free URBs, > > except for periodic URBs that are being resubmitted, but I > > know that Oliver has problems with that position. > > They can't. We need to check to see if it got unlinked and to do that, > we need to check urb->status. Erm ... weren't you just agreeing with what I wrote, though? The URBs that would be resubmitted are the ones that aren't being "given back" to the driver. The others can be freed by that handler, since the HCD knew they were unlinked before that callback and so wouldn't need to check urb->status. The "would be resubmitted" ones could be unlinked in completion, but not freed at that time. (A later "give it back" callback would then reflect their new "will not be resubmitted, now fully unlinked" mode.) > All of these exceptions are one of the reasons I dislike the current > (2.4) URB interface. I'm not entirely sure what you mean by that ... although I've begun to dislike "automagic resubmit" more. The ISO ring stuff is particularly annoying, there's no clean way to report some errors. And it's very awkward for INTR-OUT transfers. I suspect that what you mean is at least that you'd like to see a simpler model for periodic URBs ... with no "automagic resubmit", but with each type of URB being queuable in the HCD. That'd likely make sense to me as a 2.5 change, once the bandwidth reservation issues get worked. (Reserve at set_config/set_interface time?? :) > > In practical terms, I believe some of the HC drivers (I thought > > it was only usb-uhci, actually) continue to access URBs in > > some cases after they are returned to drivers. I call that sort > > of behavior buggy, but for now drivers in 2.4 need to cope. > > I think the HCD's should be fixed, there's less of them :) Plus, it's > the rule of least surprise. We shouldn't expect drivers to workaround > bugs or inconsistencies with HCD's. That's why I said "for now" ... :) I agree. But HCDs have a deservedly notorious reputation for fragility. We could really use a good regression test framework there. As well as a simpler and more testable API for the HCDs! - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
