Received-SPF: pass (google.com: domain of linux-kernel+bounces-180349-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Wed, 15 May 2024 22:35:22 +0200
From: Lukas Wunner <lukas@wunner.de>
To: Esther Shimanovich <eshimanovich@chromium.org>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>,
	Mario Limonciello <mario.limonciello@amd.com>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Bjorn Helgaas <bhelgaas@google.com>, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, Rajat Jain <rajatja@google.com>
Subject: Re: [PATCH v4] PCI: Relabel JHL6540 on Lenovo X1 Carbon 7,8
Message-ID: <ZkUcihZR_ZUUEsZp@wunner.de>
References: <20240424085608.GE112498@black.fi.intel.com>
 <CA+Y6NJFyi6e7ype6dTAjxsy5aC80NdVOt+Vg-a0O0y_JsfwSGg@mail.gmail.com>
 <Zi0VLrvUWH6P1_or@wunner.de>
 <CA+Y6NJE8hA+wt+auW1wJBWA6EGMc6CGpmdExr3475E_Yys-Zdw@mail.gmail.com>
 <ZjsKPSgV39SF0gdX@wunner.de>
 <20240510052616.GC4162345@black.fi.intel.com>
 <CA+Y6NJF2Ex6Rwxw0a5V1aMY2OH4=MP5KTtat9x9Ge7y-JBdapw@mail.gmail.com>
 <20240511043832.GD4162345@black.fi.intel.com>
 <20240511054323.GE4162345@black.fi.intel.com>
 <CA+Y6NJF+sJs_zQEF7se5QVMBAhoXJR3Y7x0PHfnBQZyCBbbrQg@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+Y6NJF+sJs_zQEF7se5QVMBAhoXJR3Y7x0PHfnBQZyCBbbrQg@mail.gmail.com>

On Wed, May 15, 2024 at 02:53:54PM -0400, Esther Shimanovich wrote:
> On Wed, May 8, 2024 at 1:23???AM Lukas Wunner <lukas@wunner.de> wrote:
> > On Wed, May 01, 2024 at 06:23:28PM -0400, Esther Shimanovich wrote:
> > > On Sat, Apr 27, 2024 at 3:17AM Lukas Wunner <lukas@wunner.de> wrote:
> > > That is correct, when the user-visible issue occurs, no driver is
> > > bound to the NHI and XHCI. The discrete JHL chip is not permitted to
> > > attach to the external-facing root port because of the security
> > > policy, so the NHI and XHCI are not seen by the computer.
> >
> > Could you rework your patch to only rectify the NHI's and XHCI's
> > device properties and leave the bridges untouched?
> 
> So I tried a build with that patch, but it never reached the
> tb_pci_fixup function

That means that for some reason, the PCI devices are not associated with
the Thunderbolt ports.  Could you add this to the command line:

  thunderbolt.dyndbg ignore_loglevel log_buf_len=10M

and this to your kernel config:

  CONFIG_DYNAMIC_DEBUG=y

You should see "... is associated with ..." messages in dmesg.
This did work for Mika during his testing with recent Thunderbolt chips.
I amended the patches after his testing but wouldn't expect that to
cause issues.

@Mika, would you mind re-testing if you've got cycles to spare?


> even when NHI and XHCI were both labeled as
> fixed and external facing in the quirk.

Setting the two as fixed and trusted should be sufficient.
The external_facing bit should not be needed on the NHI and XHCI.


> Also, I don't see where you distinguish between an integrated
> Thunderbolt PCIe root port and a root port with no thunderbolt
> functionality built in. Could you point that out to me?

Hm, why would I have to distinguish between the two?

I distinguish between Thunderbolt PCIe Adapters on the root switch
and ones on non-root switches.  The latter are attached Device Routers,
the former is the Host Router.  I just set the ones on the former to
external_facing, fixed and trusted.  Everything downstream is untrusted
and removable.


> I'm not sure how your patch protects against the following case
> scenario I described earlier:
> > Let's say we have a TigerLake CPU, which has integrated
> > Thunderbolt/USB4 capabilities:
> >
> > TigerLake_ThunderboltCPU -> USB-C Port
> > This device also has the ExternalFacingPort property in ACPI and lacks
> > the usb4-host-interface property in the ACPI.
> >
> > My worry is that someone could take an Alpine Ridge Chip Thunderbolt
> > Dock and attach it to the TigerLake CPU
> >
> > TigerLake_ThunderboltCPU -> USB-C Port -> AlpineRidge_Dock
> >
> > If that were to happen, this quirk would incorrectly label the Alpine
> > Ridge Dock as "fixed" instead of "removable".

See above, the Alpine Ridge Dock is never the root switch.
The Tiger Lake CPU is.

Thanks,

Lukas