> I'd love it to be atomic, but is that really practical/possible? Certainly. I'm told some USB stacks do it by setting a driver halt state on error, so that submitting subsequent requests will fail automagically. That's really the only problem case; if there's no error, there's no way a problem would show up..
> We'd wind > up delaying the submission of the first URB until we were sure a chain of > them was complete, and that means likely introducing either (a) some sort > of "end of bulk-queue" chain flag, Simpler yet: if the "do bulk queue" flag is set in the URB, and it gets an error, halt the endpoint. Queuing the next URB would fail, and by defninition any already-submitted URBs would be getting canceled automatically. That "halt" might need to be magic, so clearing it doesn't normally talk to the device ... there's some old code in usbcore that looks like that was the original idea, but which has since morphed. > ... (again), this is a place where consistancy across HCDs is lacking. And testing will be an issue, too. I should be able to make sure that the EHCI driver handles queued bulk requests reasonably, since I've got a device I can program easily enough, but doing so for other HCDs will need more effort. Has anyone done anything with "usbstress" lately? - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
