Re: Support for USBD_FORCE_SHORT_XFER for xhci

[Nat Sloss <nathanialsloss%yahoo.com.au@localhost>]

On Mon, 1 Sep 2025 18:12:18 sc dying wrote:
> On Sun, Aug 31, 2025 at 11:49 AM Jason Thorpe <thorpej%me.com@localhost> wrote:
> > > On Aug 22, 2025, at 10:06 AM, Nat Sloss <nathanialsloss%yahoo.com.au@localhost>
> > > 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