On Wed, May 22, 2024, Alan Stern wrote: > On Wed, May 22, 2024 at 01:41:42AM +0000, Thinh Nguyen wrote: > > On Wed, May 22, 2024, Michael Grzeschik wrote: > > > On Fri, May 17, 2024 at 01:44:05AM +0000, Thinh Nguyen wrote: > > > > For isoc endpoint IN, yes. If the host requests for isoc data IN while > > > > no TRB is prepared, then the controller will automatically send 0-length > > > > packet respond. > > > > > > Perfect! This will help a lot and will make active queueing of own > > > zero-length requests run unnecessary. > > > > Yes, if we rely on the current start/stop isoc transfer scheme for UVC, > > then this will work. > > You shouldn't rely on this behavior. Other device controllers might not > behave this way; they might send no packet at all to the host (causing a > USB protocol error) instead of sending a zero-length packet. I agree. The dwc3 driver has this workaround to somewhat work with the UVC. This behavior is not something the controller expected, and this workaround should not be a common behavior for different function driver/protocol. Since this behavior was added a long time ago, it will remain the default behavior in dwc3 to avoid regression with UVC (at least until the UVC is changed). However, it would be nice for UVC to not rely on this. Side note, when the dwc3 driver reschedules/starts isoc transfer again, the first transfer will be scheduled go out at some future interval and not the next immediate microframe. For UVC, it probably won't be a problem since it doesn't seem to need data going out every interval. BR, Thinh > > On the other hand, it may not make any difference. The host's UVC > driver most likely won't care about the difference between no packet and > a 0-length packet. :-) > > Alan Stern
