linux-kernel - Re: Apple Thunderbolt Display chaining

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 4 Apr 2022 15:53:03 +0300
From:   Mika Westerberg <mika.westerberg@...ux.intel.com>
To:     Brad Campbell <lists2009@...rfbargle.com>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: Apple Thunderbolt Display chaining

Hi,

On Mon, Apr 04, 2022 at 07:38:06PM +0800, Brad Campbell wrote:
> > Hm, you mean you don't see the timeout errors and stuff with the first
> > patch applied?
> 
> I see the config timeout errors and the controller locking up after a
> couple of unplugs, but when it does configure the DP channels, they
> both come up every time.
> 
> So, with the original patch when thunderbolt discovery works, displays
> both work. With the latest patch, whether or not the hotplug works,
> the radeon driver fails to bring up the parent head.
> 
> Both suffer from the controller config timeout reads on unplug causing
> it to become unresponsive after a couple of re-plug cycles (3 if I'm
> lucky).

I suspect the same issue is even with the first patch but it just
manifests differently. I think the timeouts are the key here and we need
to figure out why they happen.

> > I think I will make this current one a proper patch and submit upstream
> > later this week (will CC you too). For the iMac issue we may need to
> > debug it further. Not sure if you answered this one already but on iMac
> > on macOS does it work always when you plug in the whole chain?
> > 
> Yes, MacOS works fine in any order on any port.
> 
> There is a difference in the way something is set up between what the
> EFI does and what Linux does.

Agree.

> If I wait for the Chime, then a bit longer and plug the chain in
> (before the bootloader starts), Linux sets up both heads and hotplug /
> replug works.
> 
> If I cold boot with the chain plugged in, the EFI sets up one head and
> Linux configures the other. Replug fails with the clock-recovery error
> in that case.
> 
> The difference seems to be when EFI sets up, on re-plug it sets up the
> child display first (303 vs 3) and that causes the issue. Repeated
> tests can get difficult as often on the second or third plug (or
> unplug) the controller locks up and no longer responds to events.
> 
> I'll try and get a couple of clear dmesg with your last debug patch
> because it appear the chain is being discovered in a different order
> depending on whether or not the EFI set it up.

That would be helpful.

> I received my brand new Titan Ridge board today (Gigabyte B550
> Vision-d-p) and with a modified Thunderbolt rom and the last patch it
> detects and runs both Thunderbolt displays from a cold boot. Hotplug
> fails, and there are other issues related to warm boot, but they'll
> all have to wait until I get a serial console up.

Hehe, OK.

> Appreciate the persistence with this.

My pleasure ;-)