On 1/19/26 11:59, Mario Limonciello (AMD) (kernel.org) wrote:

On 1/17/2026 10:57 AM, Katiyar, Pooja wrote:

quoted

quoted

I have confirmation the hack patch does help the issue for us too.

If your patch doesn't work another logical solution could be to destroy
all the tunnels as part of the PM freeze callback (not just the DP
resources).  Maybe even unify the suspend and freeze codepaths for more
opportunities for code reuse?

Thanks for confirming the hack patch helps!

We are actually working on a solution that releases the DP resources and
suspends the switch as part of the freeze sequence. This way the 
hibernation
image that is stored doesn't contain any active tunnels, and during 
resume
we get a DP hotplug notification for a new tunnel, similar to S5. So far
this patch is working fine but is under review.

Thanks.  If you want early testing from us too before you're ready to 
post publicly feel free to ping it offline to me too.

I'd like to get a CC: on that, too.

I've been testing that hack patch and will test further later tonight.

The issue I'm trying to chase down (and not sure if any of this will 
help with this, I wonder if it's really BIOS/EC related) is often times 
that after a suspend (or hibernate, but I use "suspend then hibernate", 
which I think does both and chooses which to use upon resume) and then 
connect to a different dock (or setup) from the one I'd suspended with, 
sometimes I have to unplug/replug my TB cable, otherwise I either get no 
recognition of my new display setup (and sometimes TB devices) or it'll 
try and use the same monitor resolution of the previously-connected 
monitor (as if the TB subsystem doesn't recognize things have changed).

-Kenny

-- 
Kenneth R. Crudup / Sr. SW Engineer, Scott County Consulting, Orange 
County CA