Re: Support for USBD_FORCE_SHORT_XFER for xhci

[sc dying <sc.dying%gmail.com@localhost>]

hi,

On Fri, Aug 22, 2025 at 2:06 PM 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.
>
>
> There is some previous artwork for ehci/uhci/ohci that has special handling
> for this particuar flag.
>
> Attached is my attempt at fixing this - this would also make possible for me to
> revert the last 2 commits to urtwn as I would no longer have to send zero
> lengh xfers in the driver.
>
> Thoughts?

If an error occurs on sending zero-length packet, or transfer is
stopped on ZLP, normal transfer and ZLP generates transfer event each.
xhci_event_transfer() would call usb_transfer_complete for same xfer,
actually, second event will be ignored since first event dequeues
xfer->ux_pipe->up_queue and event handler simply quits if pipe
is empty.

Does this ZLP always need to be sent when FORCE_SHORT is set?
Should be only when !isread && FORCE_SHORT && (len % wMaxPacketSize) == 0 ?