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]

Message-ID: <YkQuk7E8AbSEiw59@lahna>
Date:   Wed, 30 Mar 2022 13:18:59 +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 Tue, Mar 29, 2022 at 10:06:35PM +0800, Brad Campbell wrote:
> > Indeed, I did not add this to the "discovery" path yet.
> > 
> > I wonder what happens if you change this:
> > 
> > +       tunnel = tb_tunnel_alloc_dp(tb, in, out, available_up, available_down,
> > +                                   first ? 0 : 1);
> > 
> > to this in your tree:
> > 
> > +       tunnel = tb_tunnel_alloc_dp(tb, in, out, available_up, available_down,
> > +                                   first ? 1 : 0);
> > 
> 
> Here's where it gets all "Apple..y". On the iMac this does the job no matter which
> port the chain is plugged into. Boots and displays correctly first time, every time.
> 
> It turns out on the laptop, one port works and the other doesn't. Changing the order
> simply changes which port works. So I assume the EFI sets up the first display using
> the first lane if it's in the first port, and the second if it's in the second.
> 
> That means had I managed to perform the first test in the "other port" consistently,
> it would have worked there also.

Can you try the below patch too? I hard-code the lane based on the
DP adapter number in TBT gen1.

Let's first figure out proper solution to this issue and then look at
the other one.

diff --git a/drivers/thunderbolt/tunnel.c b/drivers/thunderbolt/tunnel.c
index a473cc7d9a8d..97d36a7bb527 100644
--- a/drivers/thunderbolt/tunnel.c
+++ b/drivers/thunderbolt/tunnel.c
@@ -865,6 +865,7 @@ struct tb_tunnel *tb_tunnel_alloc_dp(struct tb *tb, struct tb_port *in,
 	struct tb_tunnel *tunnel;
 	struct tb_path **paths;
 	struct tb_path *path;
+	int link_nr;
 
 	if (WARN_ON(!in->cap_adap || !out->cap_adap))
 		return NULL;
@@ -883,22 +884,32 @@ struct tb_tunnel *tb_tunnel_alloc_dp(struct tb *tb, struct tb_port *in,
 
 	paths = tunnel->paths;
 
+	/*
+	 * Hard code the lane for both DP IN adapters in first
+	 * generation hardware. This should follow what the Apple boot
+	 * firmware does.
+	 */
+	if (in->sw->generation == 1)
+		link_nr = in->port == 11 ? 1 : 0;
+	else
+		link_nr = 0;
+
 	path = tb_path_alloc(tb, in, TB_DP_VIDEO_HOPID, out, TB_DP_VIDEO_HOPID,
-			     1, "Video");
+			     link_nr, "Video");
 	if (!path)
 		goto err_free;
 	tb_dp_init_video_path(path);
 	paths[TB_DP_VIDEO_PATH_OUT] = path;
 
 	path = tb_path_alloc(tb, in, TB_DP_AUX_TX_HOPID, out,
-			     TB_DP_AUX_TX_HOPID, 1, "AUX TX");
+			     TB_DP_AUX_TX_HOPID, link_nr, "AUX TX");
 	if (!path)
 		goto err_free;
 	tb_dp_init_aux_path(path);
 	paths[TB_DP_AUX_PATH_OUT] = path;
 
 	path = tb_path_alloc(tb, out, TB_DP_AUX_RX_HOPID, in,
-			     TB_DP_AUX_RX_HOPID, 1, "AUX RX");
+			     TB_DP_AUX_RX_HOPID, link_nr, "AUX RX");
 	if (!path)
 		goto err_free;
 	tb_dp_init_aux_path(path);