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

On 6/13/26 11:26, Michal Pecio wrote:
> 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.

Was this regression ever resolved? Looks a bit like this fell through
the cracks, but I might have missed something.

Or is that no regression at all? From the initial mail in the thread is
sounded like one, but it was never bisected afaics.

Ciao, Thorsten

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