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

[Mathias Nyman <mathias.nyman@linux.intel.com>]

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@linux.intel.com>
>>>>
>>>> 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@linux.intel.com>
>>>> Signed-off-by: George D Sworo <george.d.sworo@intel.com>
>>>> 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