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

[Mathias Nyman]

On 5/22/26 13:39, Greg Kroah-Hartman wrote:
> On Fri, May 22, 2026 at 11:35:47AM +0200, Paul Menzel wrote:
> > Dear Greg,
> >
> >
> > Am 22.05.26 um 11:23 schrieb 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?
> >
> > Yes, they are authored by me and meant for the list. I wanted to document,
> > where I got the patch from and how I tested the change. Feel free to remove
> > them.
>
> These make no sense, please remove them yourself and resend.

I do remember writing these as part of debugging and/or a temporary workaround,
but they were not supposed to go upstream, or become a permanent solution.

These patches just hide the fact that xhci event handler isn't run when we expect
it to. rootcause is unknown.

Thanks
-Mathias