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 <[email protected]>
AuthorDate: 2026-05-21 12:49:42 +0000
Commit: ShengYi Hung <[email protected]>
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;
}
