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

On 7/12/26 10:43, Adrian Chadd wrote:
> On Sat, 11 Jul 2026 at 20:21, Kyle Evans <kevans@freebsd.org> wrote:
>>
>> 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
> 
>> 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.
>>
> 
> My guess is the yubikey device firmware pays attention to this bit and
> the state is
> only reset when the state cycles through STOP. If you're curious, try
> comparing usbdump
> captures before/after the fix and look for explicit differences in
> things and then
> guess what the firmware is doing.
> 

Solid suggestion, thanks- I forgot that usbdump is even a thing, so I'll
play with this a bit.

Thanks,

Kyle Evans