Re: Support for USBD_FORCE_SHORT_XFER for xhci
sc dying <[email protected]>
| Newsgroups | gmane.os.netbsd.devel.kernel |
|---|---|
| Message-ID | <CA+16TwLkhpY6QTTSj742QYPYx=jadFf8cDq51kV88o_LmDYVNQ@mail.gmail.com> |
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?