Date: Sat, 11 Jul 2026 22:21:35 -0500 From: Kyle Evans <kevans@FreeBSD.org> To: ShengYi Hung <aokblast@FreeBSD.org>, src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org Cc: Vladimir Kondratyev <wulf@FreeBSD.org> Subject: Re: git: 28d85db46b48 - main - xhci: Do not drop and add bits in xhci Message-ID: <49761290-2d6c-403f-acdd-48b5b536804c@FreeBSD.org> In-Reply-To: <6a1008a0.3f79c.1d455f29@gitrepo.freebsd.org>
index | next in thread | previous in thread | raw e-mail
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; > } >home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49761290-2d6c-403f-acdd-48b5b536804c>