[PATCH 1/2] xhci: add helper to check for pending interrupt

[PATCH 1/2] xhci: add helper to check for pending interrupt

[Paul Menzel]

From: Mathias Nyman <mathias.nyman@linux.intel.com>

xhci driver needs to manually check if xHC has raised an interrupt in
several places. Add a helper for it, use it in `xhci_pending_portevent()`.

Return 1 if there is a pending interrupt, -ENODEV on error (dead device),
0 otherwise.

Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
(cherry picked from commit 741aeecfd9a1b2437c5ee1d70745b1bfd90fb7d6
git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git for-usb-next)

[pmenzel: As of 7.1-rc4, the commit is not Linus’ master branch, so port
  it from the ChromiumOS Linux kernel branch chromium/chromeos-6.12.]

BUG=b:192925463
TEST=Test S0ix for 500 cycles on brya.

Signed-off-by: George D Sworo <george.d.sworo@intel.com>
Change-Id: If7d584369e107a6497b10f3346c05e0c32920bcb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3313527
Reviewed-by: Rajat Jain <rajatja@google.com>
Commit-Queue: Rajat Jain <rajatja@google.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3399807
Tested-by: Rajat Jain <rajatja@google.com>

Origin-6-6: 8651d395a93eba47285700a373c12aa53be047ea
Signed-off-by: Tzung-Bi Shih <tzungbi@chromium.org>

Link: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9fc38e27c31ae70d7b7829ff61cfcd18c18d3514
Assisted-by: Claude Sonnet 4.6
Cc: Matt DeVillier <matt.devillier@gmail.com>
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
---
 drivers/usb/host/xhci.c | 17 ++++++++++++++---
 drivers/usb/host/xhci.h |  1 +
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index a54f5b57f205..8d4d6a524d05 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -97,6 +97,19 @@ int xhci_handshake(void __iomem *ptr, u32 mask, u32 done, u64 timeout_us)
 	return ret;
 }
 
+/* return 1 if there is a pending interrupt, -ENODEV on error, 0 otherwise */
+int xhci_pending_interrupt(struct xhci_hcd *xhci)
+{
+	u32 status;
+
+	status = readl(&xhci->op_regs->status);
+
+	if (status == ~(u32)0)
+		return -ENODEV;
+
+	return !!(status & STS_EINT);
+}
+
 /*
  * Disable interrupts and begin the xHCI halting process.
  */
@@ -918,11 +931,9 @@ static bool xhci_pending_portevent(struct xhci_hcd *xhci)
 {
 	struct xhci_port	**ports;
 	int			port_index;
-	u32			status;
 	u32			portsc;
 
-	status = readl(&xhci->op_regs->status);
-	if (status & STS_EINT)
+	if (xhci_pending_interrupt(xhci) > 0)
 		return true;
 	/*
 	 * Checking STS_EINT is not enough as there is a lag between a change
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index aeecd301f207..82a0596c0ae9 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1955,6 +1955,7 @@ void xhci_ring_doorbell_for_active_rings(struct xhci_hcd *xhci,
 void xhci_cleanup_command_queue(struct xhci_hcd *xhci);
 void inc_deq(struct xhci_hcd *xhci, struct xhci_ring *ring);
 unsigned int count_trbs(u64 addr, u64 len);
+int xhci_pending_interrupt(struct xhci_hcd *xhci);
 int xhci_stop_endpoint_sync(struct xhci_hcd *xhci, struct xhci_virt_ep *ep,
 			    int suspend, gfp_t gfp_flags);
 void xhci_process_cancelled_tds(struct xhci_virt_ep *ep);
-- 
2.53.0

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

[Paul Menzel]

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.]
Cc: Matt DeVillier <matt.devillier@gmail.com>
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
---
 drivers/usb/host/xhci-ring.c | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index e47e644b296e..7f023558af22 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1714,6 +1714,28 @@ void xhci_cleanup_command_queue(struct xhci_hcd *xhci)
 		xhci_complete_del_and_free_cmd(cur_cmd, COMP_COMMAND_ABORTED, 0);
 }
 
+static bool xhci_pending_command_completion(struct xhci_hcd *xhci)
+{
+	struct xhci_segment	*seg = xhci->interrupters[0]->event_ring->deq_seg;
+	union xhci_trb		*deq = xhci->interrupters[0]->event_ring->dequeue;
+	u32			deq_flags = le32_to_cpu(deq->event_cmd.flags);
+	u32			cycle = xhci->interrupters[0]->event_ring->cycle_state;
+	int			i = 0;
+
+	/* Check if event ring contains an unhandled command completion */
+	while ((deq_flags & TRB_CYCLE) == cycle) {
+		if ((deq_flags & TRB_TYPE_BITMASK) == TRB_TYPE(TRB_COMPLETION))
+			return true;
+		if (last_trb_on_ring(xhci->interrupters[0]->event_ring, seg, deq))
+			cycle ^= 1;
+		next_trb(&seg, &deq);
+		deq_flags = le32_to_cpu(deq->event_cmd.flags);
+		if (i++ > TRBS_PER_SEGMENT)
+			break;
+	}
+	return false;
+}
+
 void xhci_handle_command_timeout(struct work_struct *work)
 {
 	struct xhci_hcd	*xhci;
@@ -1736,6 +1758,14 @@ void xhci_handle_command_timeout(struct work_struct *work)
 		return;
 	}
 
+	/* Did hw complete the command but event handler was blocked? */
+	if (xhci_pending_interrupt(xhci) > 0 &&
+	    xhci_pending_command_completion(xhci)) {
+		xhci_dbg(xhci, "Command timeout with unhandled command completion\n");
+		xhci_mod_cmd_timer(xhci);
+		goto time_out_completed;
+	}
+
 	cmd_field3 = le32_to_cpu(xhci->current_cmd->command_trb->generic.field[3]);
 	usbsts = readl(&xhci->op_regs->status);
 	xhci_dbg(xhci, "Command timeout, USBSTS:%s\n", xhci_decode_usbsts(str, usbsts));
-- 
2.53.0

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@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?

confused,

greg k-h

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

[Paul Menzel]

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.


Kind regards,

Paul

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

[Greg Kroah-Hartman]

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.

thanks,

greg k-h

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@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

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

[Paul Menzel]

Dear Mathias,


Thank you for your response.

Am 22.05.26 um 13:11 schrieb 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:

>>> 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.
The ChromiumOS folks still carry it, and I am unable to look at the bug 
reports to see what device it was seen with. Do you have any more 
insight, if these bugs still happen?


Kind regards,

Paul