Re: Support for USBD_FORCE_SHORT_XFER for xhci

sc dying <[email protected]>
Newsgroups gmane.os.netbsd.devel.kernel
Message-ID <CA+16TwJBueEmrcOCvvPN4gycwJ_UdOKraODcHk3YSwbvVbQxMQ@mail.gmail.com>
hi,

On Fri, Aug 22, 2025 at 2:06 PM 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.
>
>
> 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 ?
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.