> Not giving back the TD when we get an event for the last TRB in the > TD sounds risky. With this change we assume all old and future ETRON > hosts will trigger this additional spurious success event. error_mid_td can cope with hosts which don't produce the extra success event, it was done this way to deal with buggy NECs. The cost is one more ESIT of latency on TDs with error. I don't know how many Etron chips Kuangyi Chiang tested, but I have one here and it definitely has this double event bug. These are old chips, not sure if Etron is still making them or if anyone would want to buy (large chip, USB 3.0 only, barely functional streams, no UAS on Linux and on Windows with stock MS drivers). > I think we could handle this more like the XHCI_SPURIOUS_SUCCESS case > seen with short transfers, and just silence the error message. That's a little dodgy because it frees the TD before the HC is completely done with it. *Probably* no problem with data buffers (no sensible reason to DMA into them after an earlier error), but we could overwrite the transfer ring in rare cases and IDK if it would or wouldn't cause problems in this particular case. Same applies to the "short packet" case existing today. I thought about fixing it, but IIRC I ran into some differences between HCs or out of spec behavior and it got tricky. Maybe it would make sense to separate giveback (and freeing of the data buffer by class drivers) from transfer ring inc_deq(). Do the former when we reasonably believe the HC won't touch the buffers anymore, do the latter when we are sure that it's in the next TD. Not ideal, but easier and better than the status quo. Regards, Michal
