Re: xhci_hcd: AMD Raphael/Granite Ridge USB 2.0 xHCI [1022:15b8] dies on resume from suspend

[Michal Pecio <michal.pecio@gmail.com>]

On Sat, 6 Jun 2026 14:12:22 +0100, Martin Alderson wrote:
> So the ordering that kills the controller is:
> 
> 1. dj work issues a control SET_REPORT on ep0; the URB lands on the ring
> 2. usb_suspend_both() → usb_suspend_device() drives the port to U3
> 3. only afterwards does usb_suspend_both() set udev->can_submit = 0
> and call usb_hcd_flush_endpoint() (drivers/usb/core/driver.c) — and
> that flush unlinks the still-pending ep0 URB
> 4. xhci issues Stop Endpoint to an endpoint on a U3 port → 5s timeout → HC died
> 
> That matches the trace exactly: the "Cancel URB ... ep 0x0" appears
> after "Set port 7-1 link state ... U3", and the debugfs command ring
> shows the single stuck Stop Endpoint TRB (slot 1, ep 1).

Makes sense. And good point about usb_hcd_flush_endpoint() - if this
gets stuck then usb_suspend_both() can't complete, which explains why
the HC still isn't suspended either.

> I had Claude patch the driver and this seems to fix it:
> 
> --- /tmp/hid-logitech-dj.orig.c 2026-06-06 14:08:26.580516662 +0100
> +++ hid-logitech-dj.c 2026-06-06 13:42:15.702948099 +0100

Improving HID drivers is one thing (which should be discussed with HID
maintainers - see Documentation/process/submitting-patches.rst), but
other drivers may behave similarly and it would be nice if this didn't
crash xHCI controllers.

While URBs on a suspended device are weird, it turns out that xHCI
spec (4.15.1) doesn't prohibit that, it only says that endpoints should
be stopped. Which they are - problem happens when we try to stop again.
I'd expect such a command to simply complete with Context State Error,
which it does in my tests on different HW, but yours gets stuck.

I'm not sure what specifically triggers this failure - is it stopping
a stopped endpoint always in general, or only after using the SP flag,
or on a device behind a suspended root port, or something else.

Would you mind testing some patches? I'm thikning about reordering
things in usb_suspend_both() so that URBs are flushed before suspending
the port, or investigating what exactly breaks your chip and adding
some workarounds. We don't need to stop a stopped endpoint, we could
proceed immediately to Set TR Dequeue, but it's uncertain if your HW
would accept that.

BTW, you initially stated that this happens on the first suspend after
new boot, but are you sure that it can't happen later? This would make
it possible to test patches by suspending repeatedly until failure.

Regards,
Michal