Re: AMD Strix Halo USB4: 20/40 Gbit/s negotiation with RJ45 and original host-reset patch regression

[Mario Limonciello <superm1@kernel.org>]

On 9/16/26 08:35, Mika Westerberg wrote:
> On Wed, Sep 16, 2026 at 08:26:07AM -0500, Mario Limonciello wrote:
>> On 9/16/26 02:38, Mika Westerberg wrote:
>>> Hi,
>>>
>>> On Tue, Sep 15, 2026 at 03:42:43PM -0500, Mario Limonciello wrote:
>>>> On 9/15/26 07:49, Mika Westerberg wrote:
>>>>> Hi,
>>>>>
>>>>> On Tue, Sep 15, 2026 at 01:21:39PM +0200, Nils Arnold wrote:
>>>>>> Hello Sanath, Mario, Mika and Basavaraj,
>>>>>>
>>>>>> I would like to add test evidence from two Strix Halo hosts to this
>>>>>> USB4 reset discussion. My reset test used a backport of the ORIGINAL
>>>>>> f1de1fc5f632 commit, not the newer deferred-reset implementation.
>>>>>> I have not tested the revisions discussed on September 15.
>>>>>
>>>>> Okay the last message on the thread I asked if we should revert the commit
>>>>> for v7.3-rcX and then try to get the "better" fix into v7.4. At least what
>>>>> I understood it seems to solve the issue without the deadlock and killing
>>>>> the whole host interface underneath everybody else.
>>>>
>>>> FWIW to Nils I left a note on that thread and agree with Mika.
>>>>
>>>>>
>>>>> Once we have that patch, you can test and see if that helps in your case
>>>>> too. Now that we know AMD guys can CC you when they submit it.
>>>>
>>>> One thing I'd like to note though; I would rather that we keep out of tree
>>>> modules out of the conversation on the kernel mailing list when it comes to
>>>> upstream behavior.
>>>>
>>>> There are multiple ways to do xdomain tunnels in the kernel, and we should
>>>> collectively fixate our time and energy on bugs related to those instead of
>>>> PoC out of tree drivers.
>>>
>>> Fully agree. But the same behaviour is with the in-tree Thunderbolt
>>> networking and stream (and maybe DMA test) drivers so those should at least
>>> be working with the AMD controller without wedging.
>>
>> Yes and no.  That out of tree driver might be configured as a module, but at
>> least I haven't audited it.  It could be causing other problems too when it
>> accesses certain symbols.
> 
> Yes agree this but I mean if the issue happens with the in-tree drivers we
> should try to fix it the best way possible. And my understanding is that it
> happens in your own validation too, right? This is the same AMD controller
> wedge issue we are talking about where the fix was just reverted by you and
> now you (AMD) are working on better one? Or I'm missing something :)

Yep, totally!