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

[Mika Westerberg <mika.westerberg@linux.intel.com>]

+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@amd.com/

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@black.igk.intel.com/

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.

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