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

[Mika Westerberg]

Hi,

On Wed, Sep 02, 2026 at 03:53:42PM -0500, Mario Limonciello wrote:
> 
> 
> 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.

Okay thanks.

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

I don't think that's any better that the reset.

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

The XDomain paths can be brought down also without unplug. Networking does
that when you "down" the interface and USB4STREAM does that when you close
the device node.