Re: [PATCH v4] PCI: Relabel JHL6540 on Lenovo X1 Carbon 7,8

Esther Shimanovich
2024-05-15T18:54:07Z

I tried both patches!

Build with Lukas's commits:

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, even when NHI and XHCI were both labeled as
fixed and external facing in the quirk.
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?

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".

Build with Mika's Patch:

On Sat, May 11, 2024 at 1:43 AM Mika Westerberg
<mika.westerberg@linux.intel.com> wrote:
>
> On Sat, May 11, 2024 at 07:38:32AM +0300, Mika Westerberg wrote:
> > They are not integrated Thunderbolt PCIe root ports.m
>
> For the clarity, Intel integrated Thunderbolt 3 controller first in Ice
> Lake, then Thunderbolt 4 controller in Tiger Lake and forward (Alder
> Lake, Raptor Lake, Meteor Lake). Anything else, including Comet Lake and
> the like are using discrete controllers such as Alpine Ridge, Titan
> Ridge (both Thunderbolt 3) and Maple Ridge (Thunderbolt 4), and Barlow
> Ridge (Thunderbolt 5) where the controller is either soldered on the
> motherboard or connected to a PCIe slot.

Thanks for the explanation!
This patch worked smoothly on the device I tried. I'd be happy to go
forward with this patch, and test it on more devices.
Is that fine? Or should I try something else on the build I made with
Lukas's commits?