Hi,
I'm just wondering about what would be considered a sane assumption wrt. completion call ordering. I do not care for completion callbacks for different endpoints - if there were ordering requirements, it would IMHO be the drivers' job to implement whatever is needed. But I do care for completion of several urbs which are queued for a common endpoint. Of course, these urbs are scheduled in the particular order they were submitted. But with sufficiently small transfer size it is pretty likely to run into situations were several urbs get completed at the same time. "At the same time" refers to the fact that the HC notifies all completed urbs only once per frame so the HCD will find several finished urbs for one single interrupt. My concern is what (if any) assumptions a driver might take about the order in which the corresponding completion callbacks are invoked. Would it be valid to rely on a fifo-like operation, i.e. the urb which was submitted first get completed first? If not, for example an approach using a pool of urbs might be subject to some interesting races if it simply advances pool->tail on submission and pool->head to recycle completed urb. Martin _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
