Re: [PATCH 1/2] thunderbolt: Do not warn when a reset clears ring interrupts

[Mario Limonciello]

On 9/2/26 07:50, Mika Westerberg wrote:
> +Mario
>
> Hi,
>
> On Wed, Sep 02, 2026 at 12:34:13PM +0000, Andrei Rusu de Castro wrote:
> > The AMD DMA-teardown quirk resets the host interface before USB4NET
> > stops its service rings. The reset clears ring interrupt bits while the
> > rings remain logically running. When tb_ring_stop() later disables the
> > interrupt, the register update is a no-op and emits a dev_WARN() splat.
>
> Yes it should not do that. It's too "big hammer" and we should avoid that
> if possible. There is also the deadlock that resulted this series:
>
> https://lore.kernel.org/linux-usb/20260825214237.4179813-1-juan.martinez@xxxxxxx/
>
> But that still kills the whole host interface if there are other users,
> like USB4STREAM using the rings at the same time. I suggested that we do
> the reset when the rings are idle and while they are not and we have spare
> rings we hand off those instead:
>
> https://lore.kernel.org/linux-usb/20260902054800.GI106095@xxxxxxxxxxxxxxxxxxx/
>
> We still need confirmation from AMD if this even solves the problem or is
> it hanging the whole host interface and not just a single ring.

I'll let Sanath and Basavaraj double check this on the affected failure 
case.

I believe think that the whole host interface hangs when this condition 
happens.  Another way to mitigate it can be to force a power state 
transition though.  If we can force the router into D3 and back out it 
should reset the condition that could lead to a host interface hang.

> > The path teardown order is required. Stopping a ring first clears its
> > descriptor base and unmaps its frame buffers, so pending path traffic
> > can no longer drain and some host routers never clear their pending bit.
> >
> > Keep the warning for genuine software-state drift. Increment a host
> > interface generation after each eligible reset and sample it when an
> > interrupt-backed ring starts. Excuse a redundant disable only when that
> > ring crossed a reset. Duplicate enables, duplicate disables without a
> > reset, rings started after a reset, ineligible resets, and double
> > software stops retain their existing warnings.
> >
> > The generation sample precedes interrupt enable while holding the NHI
> > lock. A reset racing with ring start is therefore observed as newer than
> > the sample and attributed to that ring.
> >
> > Source and call-graph analysis identified the reset and
> > ring-teardown ordering. The change was compile-tested; KUnit coverage is
> > added separately. It has not run on affected peer-host XDomain hardware
> > because the attached USB4 device is a hub and does not form that path.
>
> This looks pretty much like LLM generated so if that's the case you should
> add proper assisted-by.
>
> Anyways I don't think we want to do this just yet if we can avoid resetting
> the host interace behind everyones back.

The resetting host interface /should/ only really happen when unplugging 
the cable.  If it's happening in more cases, that's not intended at least.