On Mon, 1 Sep 2025 18:12:18 sc dying wrote: > On Sun, Aug 31, 2025 at 11:49 AM Jason Thorpe <[email protected]> wrote: > > > On Aug 22, 2025, at 10:06 AM, Nat Sloss <[email protected]> > > > wrote: > > > > > > Hi, > > > > > > I've done recent work on urtwn that fixes transfers when the device is > > > used with xhci. > > > > > > It turns out the root of the problem was a lack of support in the xhci > > > stack for the flag USBD_FORCE_SHORT_XFER. > > > > Related to this: What about USBD_SHORT_XFER_OK? It’s effectively the > > inbound direction of USBD_FORCE_SHORT_XFER. This seems to have some > > special handling in uhci, and I’m wondering if this is related to the > > issues I’ve been having with TL866II “minipro” EEPROM programmers on > > xhci on NetBSD. > > Host contoller drivers including xhci (but dwc2) look like returning > USBD_NORMAL_COMPLETION on receiving both full size and short packet. > usb_transfer_complete in usbdi.c makes ux_status = USBD_SHORT_XFER > when actual transferred length < requested length && USBD_SHORT_XFER_OK > is not set on inbound pipe. > > BTW is it due to clearing data toggle?
Just wondering I had a good look at ugen(4) and found that it uses usbd_bulk_transfer which will sets USBD_SYNCHRONOUS on all xfers receieved. I wonder what would happen if usbd_bulk_transfer was replaced with usbd_setup_xfer/usbd_xfer without setting SYCHRONOUS/SYNCRONOUS_SIG? Best regards, Nat
