On Wed, Apr 19, 2023, Alan Stern wrote: > On Wed, Apr 19, 2023 at 09:49:35PM +0000, Thinh Nguyen wrote: > > By the usb spec, for IN direction, if there's no data available and the > > host requests for data, then the device will send a zero-length data > > packet. > > I'm not aware of any such requirement in the USB-2 spec. The closest I > can find is in section 5.6.4: > > An isochronous IN endpoint must return a zero-length packet > whenever data is requested at a faster interval than the > specified interval and data is not available. > > But this specifically refers only to situations where the host asks for > isochonous data more frequently than the endpoint descriptor's bInterval > describes. This is from usb 3.2 section 4.4.8.2: Note, if an endpoint has no isochronous data to transmit when accessed by the host, it shall send a zero length packet in response to the request for data. > > > This is what the dwc3 controller will do. So regardless whether > > you prepare and queue a 0-length request or not, the host will receive > > it. > > Even so, whether the function driver submits these 0-length isochronous > requests makes a difference in terms of filling the slots in the > schedule and preventing later requests from becoming stale. > That's not my point. Avi concern was how the host may interpret 0-length packet. My point was to note that it should behave the same as before. Because even without sending 0-length requests, the controller would already respond with 0-length packet already. In fact, that's what the UVC driver should be doing, by maintaining the request queue with dummy requests as suggested in the beginning. Perhaps there was some misunderstanding. Sending 0-length request you suggested is a perfectly good suggestion and UVC gadget driver should do that instead of relying on the workaround in the dwc3 driver. Thanks, Thinh
