Re: git: 28d85db46b48 - main - xhci: Do not drop and add bits in xhci

On 5/22/26 02:41, ShengYi Hung wrote:
> The branch main has been updated by aokblast:
> 
> URL: https://cgit.FreeBSD.org/src/commit/?id=28d85db46b484589e2ee74cf4b270db066821de1
> 
> commit 28d85db46b484589e2ee74cf4b270db066821de1
> Author:     ShengYi Hung <aokblast@FreeBSD.org>
> AuthorDate: 2026-05-21 12:49:42 +0000
> Commit:     ShengYi Hung <aokblast@FreeBSD.org>
> CommitDate: 2026-05-22 07:41:07 +0000
> 
>      xhci: Do not drop and add bits in xhci
>      
>      Drop and Add bits reset the data toggle for high-speed devices in XHCI.
>      The toggle bit represents the sequence number in USB 2.0 transfers. However,
>      a device can only recognize that the toggle bit has been reset while in
>      the HALT state. As a result, the host and device toggle values may
>      become mismatched, causing xHCI to reject the packet. This issue was
>      observed while testing the EZ-USB FX2 device.
>      
>      The transfer may then return to the original value after a
>      bi-directional TD because the toggle field is only one bit wide. This
>      explains the reson that we can only receive packets bi-transfer in some
>      case. Therefore, we do not reset the toggle bit here.
>      
>      Reviewed by:    adrian
>      MFC after:      2 weeks
>      Sponsored by:   The FreeBSD Foundation
>      Differential Revision: https://reviews.freebsd.org/D57146
> ---
>   sys/dev/usb/controller/xhci.c | 14 +++++++++-----
>   1 file changed, 9 insertions(+), 5 deletions(-)
> 

Hi,

This patch reliably fixes a bug I've been trying to track down in a u2f(4) patch
that I've been testing, and I'm wondering if you can help connect the dots.  I
have a Solo2 u2f(4) key that I find will inconsistently desync (for other reasons)
and hang, and the solution for *that* is to release this NOT_YET block[0] in
u2f_dtor().

The problem I was hunting down is that doing so subsequently broke my Yubikey in a
way that this patch alone seems to fix.  It would hang on every other ssh attempt, as
long as we issued usbd_transfer_stop on our interrupt endpoints upon last-close.  It
was known to work with uhid(4) reliably which issues a stop as well, and that's the
thing I can't really explain.  Is there something that uhid(4) / usb_dev.c is doing
that might have accidentally worked around this?

This was the only commit that looked relevant in the fast-forward I did for my latest
round of testing from 9c18d55a768a3 to 707ee7ff952c5, and reverting just this patch
reliably re-introduces the problem I was having with the Yubikey.

Thanks,

Kyle Evans

[0] https://cgit.freebsd.org/src/tree/sys/dev/hid/u2f.c#n303

> diff --git a/sys/dev/usb/controller/xhci.c b/sys/dev/usb/controller/xhci.c
> index 3dad0985b39d..b522c5fdc5a3 100644
> --- a/sys/dev/usb/controller/xhci.c
> +++ b/sys/dev/usb/controller/xhci.c
> @@ -3898,10 +3898,8 @@ xhci_configure_reset_endpoint(struct usb_xfer *xfer)
>   	 */
>   	switch (xhci_get_endpoint_state(udev, epno)) {
>   	case XHCI_EPCTX_0_EPSTATE_DISABLED:
> -		drop = 0;
> -		break;
>   	case XHCI_EPCTX_0_EPSTATE_STOPPED:
> -		drop = 1;
> +		drop = 0;
>   		break;
>   	case XHCI_EPCTX_0_EPSTATE_HALTED:
>   		err = xhci_cmd_reset_ep(sc, 0, epno, index);
> @@ -3910,9 +3908,15 @@ xhci_configure_reset_endpoint(struct usb_xfer *xfer)
>   			DPRINTF("Could not reset endpoint %u\n", epno);
>   		break;
>   	default:
> -		drop = 1;
> +		/*
> +		 * xHCI spec 4.6.8:
> +		 * The Drop and Add operation resets the toggle bit, which can
> +		 * cause a toggle mismatch between the device and host. As a
> +		 * result, xHCI may refuse to receive or process the packet.
> +		 */
>   		err = xhci_cmd_stop_ep(sc, 0, epno, index);
> -		if (err != 0)
> +		drop = (err != 0);
> +		if (drop)
>   			DPRINTF("Could not stop endpoint %u\n", epno);
>   		break;
>   	}
>