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:   Wed, 30 Mar 2022 16:43:08 +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 Wed, Mar 30, 2022 at 09:19:52PM +0800, Brad Campbell wrote:
> Hey Mika,
> 
> On 30/3/22 18:18, Mika Westerberg wrote:
> > 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,
> 
> This one works from cold boot on both machines regardless of the port the chain is plugged into.
> It fails on both machines on any hotplug with the symptoms of allocating them both the same link.
> I added an extra debug into tunnel.c and verified that.

Hm, okay. What if you change this:

  link_nr = in->port == 11 ? 1 : 0;

to this

  link_nr = in->port == 11 ? 0 : 1;

Please also keep the debugging you added too so we can see if it now
uses both lanes.