Re: [PATCH 2/2] xhci: check for a pending command completion during command timeout

[Greg Kroah-Hartman]

On Fri, May 22, 2026 at 10:58:27AM +0200, Paul Menzel wrote:
> From: Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx>
> 
> It's possible a command times out even if xHC hardware already completed
> the command. Driver is unaware of the command completion if interrupt
> handler is blocked for a long time.
> 
> Check if there is an unhandled command completion on the event ring during
> command timeout.
> 
> In this case just give the command additional time to complete. There's no
> point in aborting the command ring to move past a stuck command.
> 
> Signed-off-by: Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx>
> Signed-off-by: George D Sworo <george.d.sworo@xxxxxxxxx>
> Link: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/478ab723af9414b0a2a2fbc59ac34f5d319a4fc3
> [pmenzel: one adaptation for mainline 7.1: next_trb() uses the
>   2-argument form next_trb(&seg, &deq) — the mainline 7.1 signature
>   dropped the xhci and ring arguments present in the 6.12 source the
>   patch was ported from.  xhci_pending_interrupt() is used directly as
>   it is now committed as the preceding prerequisite.]
> Assisted-by: Claude Sonnet 4.6
> [pmenzel: No devices with the problem available, but no regressions on
>   Dell XPS 13 9360 and QEMU 7.2.0.
> 
>       qemu-system-x86_64 -enable-kvm -cpu host -m 3G -device qemu-xhci,id=xhci -device usb-storage,bus=xhci.0
> 
>   xHCI host controller initialised cleanly, USB 3.0 SuperSpeed root
>   hubs and USB mass storage device enumerated without errors.
>   The specific race (command timeout with blocked interrupt handler)
>   cannot easily be forced in QEMU, but no regressions in the normal
>   command path were observed.]

What are these additions from?  Did you mean to send these out to the
lists?

confused,

greg k-h