Re: [PATCH] thunderbolt: Reset NHI during S4 restore_noirq() callback

["Mario Limonciello (AMD) (kernel.org)" <superm1@kernel.org>]

On 11/5/2025 1:06 PM, Kenneth Crudup wrote:
> 
> On 11/4/25 13:21, Mario Limonciello wrote:
> 
>> For the purposes of testing this patch works it's probably easiest to 
>> do pure S4.
> 
> Well, you were right ... the patch didn't (re-/properly) enumerate the 
> devices when I'd switched TB docks before coming out of suspend ... :|
> 
> That being said, I do "suspend-then-hibernate" AND "hybrid sleep" (which 
> I'm about to disable the former as I think that solves an unrelated 
> issue I have with "double suspend").

Yeah I would suggest either/or.

> 
> So, could this patch be applied for the coming out of (s0ix) sleep case 
> as well? (I swear that used to work properly until a few kernel revs 
> ago ....)
> 
> -Kenny
> 

Well the problems for suspend/resume and hibernate/resume are actually a 
bit different.

The hibernate/resume case is specifically because the system may have a 
Pre-OS CM that is running which had configured all the devices 
differently than the SW CM in Linux does.

For bootup we go through a reset to ensure Linux gets a chance to set up 
everything as intended.

This is /mostly/ for differences of opinions between FW and Linux for 
PCIe resource enumeration, but it also has implications for other tunnel 
types like DP.

So for hibernate/resume this patch aligns the policies for bootup and 
resume from hibernate.

For suspend, some tunnels are left active but not all of them.

DP tunnels are explicitly released through 
tb_disconnect_and_release_dp().  They come back up on resume plug events.

So if you're having problems unique to suspend/resume and DP tunnels 
there is either a problem with the handling of that hotplug event or a 
problem in the graphics driver most likely.


But I'm still wondering about pure S4.  Does it help there?