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

[Mario Limonciello <mario.limonciello@amd.com>]

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

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.