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

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

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 :)