From: Esther Shimanovich <eshimanovich@chromium.org>
To: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Mario Limonciello <mario.limonciello@amd.com>,
Dmitry Torokhov <dmitry.torokhov@gmail.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, 15 Apr 2024 18:34:00 -0400 [thread overview]
Message-ID: <CA+Y6NJGz6f8hE4kRDUTGgCj+jddUyHeD_8ocFBkARr7w90jmBw@mail.gmail.com> (raw)
In-Reply-To: <CA+Y6NJFMDcB7NV49r2WxFzcfgarRiWsWO0rEPwz43PKDiXk61g@mail.gmail.com>
Hey!
Asking for some help on implementation.
So I implemented most of this, and successfully tested the quirk on 6
different devices with various types of discrete fixed JHL Thunderbolt
chips.
However I want to add an additional check. A device wouldn't need this
quirk if it already has Thunderbolt functionality built in within its
Root Port.
I tried to use "is_thunderbolt" as an identifier for that type of
device--- but when I tested on a device with a thunderbolt root port,
"is_thunderbolt" was false for all the Thunderbolt PCI components
listed below.
~ # lspci -nn | grep Thunderbolt
00:07.0 PCI bridge [0604]: Intel Corporation Tiger Lake-LP Thunderbolt
4 PCI Express Root Port #1 [8086:9a25] (rev 01)
00:07.2 PCI bridge [0604]: Intel Corporation Tiger Lake-LP Thunderbolt
4 PCI Express Root Port #2 [8086:9a27] (rev 01)
00:0d.0 USB controller [0c03]: Intel Corporation Tiger Lake-LP
Thunderbolt 4 USB Controller [8086:9a13] (rev 01)
00:0d.2 USB controller [0c03]: Intel Corporation Tiger Lake-LP
Thunderbolt 4 NHI #0 [8086:9a1b] (rev 01)
00:0d.3 USB controller [0c03]: Intel Corporation Tiger Lake-LP
Thunderbolt 4 NHI #1 [8086:9a1d] (rev 01)
The device I tested was the Lenovo carbon X1 Gen 9. When
set_pcie_thunderbolt is run, the devices listed above return false on
the pci_find_next_ext_capability check.
I have spent some time trying to see if there are any ACPI values or
any alternative indicators to reliably know if a root port has
thunderbolt capabilities. I do see that ADBG is often set to TBT but
that looks like a debugging tool in ACPI.
I also looked through lspci -vvv and compared the output with a device
that has no Thunderbolt built into its CPU, which gave me nothing.
I also tried looking through values in /sys/bus and searching through
the kernel, looking through logs etc. The only option I see now is
figuring out how to get the string value returned by the lspci and
parsing it, but I'm not 100% sure if all Thunderbolt CPUs would have
Root ports specifically labeled as "Thunderbolt Root Port". I'm also
not sure if that value is supposed to be used in that way.
I was hoping that someone may have a suggestion here.
Just for reference, this is the fix I have so far. I don't want to
submit it as a new patch, until I resolve the above question.
+static bool get_pci_exp_upstream_port(struct pci_dev *dev,
+ struct pci_dev **upstream_port)
+{
+ struct pci_dev *parent = dev;
+
+ // If the dev is an upstream port, return itself
+ if (pci_pcie_type(dev) == PCI_EXP_TYPE_UPSTREAM) {
+ *upstream_port = dev;
+ return true;
+ }
+
+ // Iterate through the dev's parents to find its upstream port
+ while ((parent = pci_upstream_bridge(parent))) {
+ if (pci_pcie_type(parent) == PCI_EXP_TYPE_UPSTREAM) {
+ *upstream_port = parent;
+ return true;
+ }
+ }
+ return false;
+}
+
+static void relabel_internal_thunderbolt_chip(struct pci_dev *dev)
+{
+ struct pci_dev *upstream_port;
+ struct pci_dev *upstream_ports_parent;
+
+ // Get the upstream port closest to the dev
+ if (!(get_pci_exp_upstream_port(dev, &upstream_port)))
+ return;
+
+ // Next, we confirm if the upstream port is directly behind a PCIe root
+ // port.
+ if (!(upstream_ports_parent == pci_upstream_bridge(upstream_port)))
+ return;
+ if (!(pci_pcie_type(upstream_ports_parent) == PCI_EXP_TYPE_ROOT_PORT))
+ return; // quirk does not apply
+
+ // If a device's root port already has thunderbolt capabilities, then
+ // it shouldn't be using this quirk.
+ // TODO: THIS CHECK DOES NOT WORK
+ // I ALSO TRIED USING pci_is_thunderbolt_attached WHICH DIDN'T
WORK EITHER
+ if (!(upstream_ports_parent->is_thunderbolt))
+ return; // thunderbolt functionality is built into root port
+
+ // Apply quirk
+ dev_set_removable(&dev->dev, DEVICE_FIXED);
+
+ // External facing bridges must be marked as such so that devices
+ // below them can correctly be labeled as REMOVABLE
+ if ((pci_pcie_type(dev) == PCI_EXP_TYPE_DOWNSTREAM)
+ && (dev->devfn == 0x08 | dev->devfn == 0x20))
+ dev->external_facing = true;
+}
next prev parent reply other threads:[~2024-04-15 22:34 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
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 [this message]
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=CA+Y6NJGz6f8hE4kRDUTGgCj+jddUyHeD_8ocFBkARr7w90jmBw@mail.gmail.com \
--to=eshimanovich@chromium.org \
--cc=bhelgaas@google.com \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mario.limonciello@amd.com \
--cc=mika.westerberg@linux.intel.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.