Re: [PATCH 2/3] thunderbolt: Reset the host interface before reusing a DMA HopID

[Basavaraj Natikar <bnatikar@amd.com>]

Hi Mika,


On 10/6/2026 10:03 AM, Mika Westerberg wrote:
> Hi,
>
> On Mon, Oct 05, 2026 at 07:13:40PM +0530, Basavaraj Natikar wrote:
>> Reusing a DMA HopID without an intervening host interface reset can hang
>> the TX ring on some host routers. Resetting on every DMA tunnel teardown
>> clears the state but, as the reset affects all rings, also disturbs
>> unrelated active tunnels.
>>
>> Hence, track the DMA HopIDs programmed since the last reset, prefer unused
>> HopIDs when allocating rings, and check for reuse at tb_ring_start() too,
>> since networking retains its rings across reconnect. Return -EAGAIN instead
>> of programming a HopID that still needs a reset.
>>
>> Run the reset from a work item once all DMA rings are idle: serialize it
>> with the connection manager, stop the control channel around it, and block
>> DMA rings from starting during the reset. Fence the work across domain
>> removal and PM transitions, preserve live DMA rings across freeze/thaw, and
>> restore the interrupt-mask shadow under the NHI lock after the reset.
>>
>> On -EAGAIN, retry the networking login asynchronously and block the work
>> producers before teardown cancels the workers. Keep peer disconnection
>> separate from administrative shutdown so it cannot reopen the login gate,
>> while stream and DMA-test callers unwind immediately and return the error
>> to userspace.
>>
>> Enable this only for reset-capable host interfaces marked with
>> QUIRK_RESET_DMA_ON_REUSE. A competing DMA tunnel must stop before its dirty
>> HopID can be reused, and retrying does not interrupt that tunnel.
>>
>> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> Yeah, I'm not really sure I suggested this :(
>
> My idea was to done it so that it is nicely contained inside nhi.c without
> distracting the service drivers. What you are doing is complete opposite of
> that.
>
> Given the complexity I would then rather just take the previous quirk with
> the deadlock fixed.

Agreed. The current approach spreads the handling into the service drivers
and is more complex than intended.

Thanks,
--
Basavaraj