From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Esther Shimanovich <eshimanovich@chromium.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Mario Limonciello <mario.limonciello@amd.com>,
Lukas Wunner <lukas@wunner.de>,
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
Date: Mon, 22 Jan 2024 08:10:05 +0200 [thread overview]
Message-ID: <20240122061005.GF2543524@black.fi.intel.com> (raw)
In-Reply-To: <CA+Y6NJHhTaroqJKEvOebRvbTdgkxW8tqFvq5MrOVE9swmwmtOw@mail.gmail.com>
On Fri, Jan 19, 2024 at 11:03:18AM -0500, Esther Shimanovich wrote:
> On Thu, Jan 18, 2024 at 1:01 AM Mika Westerberg
> <mika.westerberg@linux.intel.com> wrote:
> >
> > Well that's pretty much all Intel Titan Ridge and Maple Ridge based
> > systems. Some early ones did not use IOMMU but all the rest do.
> ...
> > Before Intel Ice Lake it was all discrete and it is still discrete with
> > the Barlow Ridge controller who will have exact same ExternalFacing port
> > as the previous models.
>
> Next week I'll try those devices in our inventory to see if I can find
> another one with this bug. I'll get back to you on that!
>
> On Fri, Jan 19, 2024 at 2:58 AM Mika Westerberg
> <mika.westerberg@linux.intel.com> wrote:
> >
> > Now if I understand the reason behind this patch is actually not about
> > "removability" that much than about identifying a trusted vs. untrusted
> > device and attaching a driver to those. I was under impression that
> > there is already a solution to this in ChromeOS kernel. It has an
> > allowlist of drivers that are allowed to attach these devices and that
> > includes the PCIe port drivers, xhci_hcd and the thunderbolt driver,
> > possibly something else too. Is this not working for your case?
>
> This device shouldn’t be treated as a removable thunderbolt device
> that is enabled by policy because it is an internal device that should
> be trusted in the first place.
> Even so, while learning about this problem I tried modifying the
> ChromeOS policy but it ended up not fixing the issue because it seems
> like there is an expectation for it to see an existing “fixed”
> thunderbolt port before it loads anything else. But the fixed
> thunderbolt port is prevented from enumerating during bootup, before
> the policy has a chance to work.
Have you contacted the Chrome kernel folks about this? Perhaps they
have thought about this already?
> On Fri, Jan 19, 2024 at 5:23 AM Mika Westerberg
> <mika.westerberg@linux.intel.com> wrote:
> >
> > The below "might" work:
> >
> > 1. A device that is directly behind a PCIe root or downstream port that
> > has ->external_facing == 1.
> >
> > 2. It is a PCIe endpoint.
> >
> > 3. It is a sibling to or has any of the below PCI IDs (see
> > drivers/thunderbolt/nhi.h for the definitions):
>
> External pci devices seem to have the same kinds of chips in them. So
> this wouldn’t distinguish the “fixed but discrete” embedded pci
> devices from the “removable” pcie through usb devices. My monitor with
> thunderbolt capabilities has the JHL7540 chip in it. From the kernel's
> perspective, I have only found that the subsystem id is what
> distinguishes these devices.
>
> That is, unless I am missing something in your proposal that would
> distinguish a fixed JHL6540 chip from an external JHL6540 chip. Please
> correct me on any assumptions I get wrong!
Yes, you are missing the 1. that it needs to be directly behind the PCIe
root or downstream port that is marked as ->external_facing, and the
fact that there can't be NHI's (that's the host controller with the IDs
I listed in 3.) anywhere else except starting the topology according the
USB4 spec (and the same applies to Thunderbolt 1-3).
next prev parent reply other threads:[~2024-01-22 6:10 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-21 20:53 [PATCH v4] PCI: Relabel JHL6540 on Lenovo X1 Carbon 7,8 Esther Shimanovich
2023-12-21 23:15 ` Dmitry Torokhov
2023-12-27 0:15 ` Bjorn Helgaas
2023-12-28 13:25 ` Lukas Wunner
2023-12-28 13:39 ` Mika Westerberg
2024-01-17 21:21 ` Esther Shimanovich
2024-01-18 6:00 ` Mika Westerberg
2024-01-18 15:47 ` Mario Limonciello
2024-01-18 16:12 ` Dmitry Torokhov
2024-01-18 16:21 ` Dmitry Torokhov
2024-01-19 5:37 ` Mika Westerberg
2024-01-19 7:48 ` Mika Westerberg
2024-01-19 10:22 ` Mika Westerberg
2024-01-19 16:03 ` Esther Shimanovich
2024-01-22 6:10 ` Mika Westerberg [this message]
2024-01-22 23:50 ` Mario Limonciello
2024-01-23 6:18 ` Mika Westerberg
2024-01-25 23:45 ` Esther Shimanovich
2024-04-15 22:34 ` Esther Shimanovich
2024-04-16 5:03 ` Mika Westerberg
2024-04-18 19:43 ` Esther Shimanovich
2024-04-19 4:49 ` Mika Westerberg
2024-04-22 19:17 ` Esther Shimanovich
2024-04-22 19:21 ` Mario Limonciello
2024-04-23 5:33 ` Mika Westerberg
2024-04-23 8:31 ` Lukas Wunner
2024-04-23 8:40 ` Mika Westerberg
2024-04-23 16:59 ` Mario Limonciello
2024-04-24 8:56 ` Mika Westerberg
2024-04-25 21:16 ` Esther Shimanovich
2024-04-26 4:52 ` Mika Westerberg
2024-04-26 15:58 ` Esther Shimanovich
2024-04-27 5:35 ` Lukas Wunner
2024-04-27 7:41 ` Mika Westerberg
2024-04-27 7:08 ` Lukas Wunner
2024-04-27 15:09 ` Lukas Wunner
2024-05-01 22:23 ` Esther Shimanovich
2024-05-02 4:38 ` Mika Westerberg
2024-05-02 9:54 ` Mario Limonciello
2024-05-02 10:07 ` Mika Westerberg
2024-05-08 5:14 ` Lukas Wunner
2024-05-10 5:26 ` Mika Westerberg
2024-05-10 15:44 ` Esther Shimanovich
2024-05-11 4:38 ` Mika Westerberg
2024-05-11 5:43 ` Mika Westerberg
2024-05-15 18:53 ` Esther Shimanovich
2024-05-15 20:35 ` Lukas Wunner
2024-05-15 20:51 ` Lukas Wunner
2024-05-15 21:44 ` Esther Shimanovich
2024-05-16 8:30 ` Mika Westerberg
2024-05-16 10:03 ` Mika Westerberg
2024-05-16 9:16 ` Mika Westerberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240122061005.GF2543524@black.fi.intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=dmitry.torokhov@gmail.com \
--cc=eshimanovich@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mario.limonciello@amd.com \
--cc=rajatja@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.