public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: Mario Limonciello <mario.limonciello@amd.com>
To: Bjorn Helgaas <bhelgaas@google.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	"open list:PCI SUBSYSTEM" <linux-pci@vger.kernel.org>,
	"open list:THUNDERBOLT DRIVER" <linux-usb@vger.kernel.org>,
	"open list:RADEON and AMDGPU DRM DRIVERS" 
	<amd-gfx@lists.freedesktop.org>,
	"open list:DRM DRIVERS" <dri-devel@lists.freedesktop.org>,
	"open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS" 
	<nouveau@lists.freedesktop.org>
Cc: Andreas Noever <andreas.noever@gmail.com>,
	Michael Jamet <michael.jamet@intel.com>,
	Yehezkel Bernat <YehezkelShB@gmail.com>,
	"Lukas Wunner" <lukas@wunner.de>, <Alexander.Deucher@amd.com>,
	Hans de Goede <hdegoede@redhat.com>,
	Mario Limonciello <mario.limonciello@amd.com>
Subject: [PATCH v4 04/10] PCI: Detect PCIe root ports for discrete USB4 controllers
Date: Mon, 14 Feb 2022 18:01:54 -0600	[thread overview]
Message-ID: <20220215000200.242799-5-mario.limonciello@amd.com> (raw)
In-Reply-To: <20220215000200.242799-1-mario.limonciello@amd.com>

Discrete USB4 controllers won't have ACPI nodes specifying which
root ports they are linked with when the software connection manager
creates tunnels.  These PCIe root ports should be marked as external
so that existing logic will mark tunneled devices as removable.

In order to set the external attribute, use the USB4 DVSEC extended
capabability set on these root ports to determine if they are located
on a discrete USB4 controller.

Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://usb.org/sites/default/files/USB4%20Specification%2020211116.zip
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
 drivers/pci/probe.c     | 50 +++++++++++++++++++++++++++++++++++++++++
 include/linux/pci_ids.h |  2 ++
 2 files changed, 52 insertions(+)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 17a969942d37..a07859c8675f 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -25,6 +25,8 @@
 #define CARDBUS_LATENCY_TIMER	176	/* secondary latency timer */
 #define CARDBUS_RESERVE_BUSNR	3
 
+#define PCI_DVSEC_ID_USB4	0x23
+
 static struct resource busn_resource = {
 	.name	= "PCI busn",
 	.start	= 0,
@@ -1600,6 +1602,52 @@ static void set_pcie_untrusted(struct pci_dev *dev)
 		dev->untrusted = true;
 }
 
+/*
+ * Use the fields from the USB4 Designated Vendor Specific Extended Capability
+ * (DVSEC) for Power Management 1.0 to identify PCIe root ports that are for
+ * XHCI and PCIe tunneling
+ */
+static void pci_set_usb4_external(struct pci_dev *dev)
+{
+	int dvsec_val = 0, pos;
+	u32 hdr;
+
+	/*
+	 * Table 3-1 "USB4 DVSEC Header fields" says vendors can use
+	 * either the Intel or USB IF vendor ID but should look for
+	 * the appropriate DVSEC ID.
+	 */
+	pos = pci_find_dvsec_capability(dev,
+					PCI_VENDOR_ID_INTEL,
+					PCI_DVSEC_ID_USB4);
+	if (pos) {
+		dvsec_val = 0x06;
+	} else {
+		pos = pci_find_dvsec_capability(dev,
+						PCI_VENDOR_ID_USB_IF,
+						PCI_DVSEC_ID_USB4);
+		if (pos)
+			dvsec_val = 0x01;
+	}
+	if (!dvsec_val)
+		return;
+
+	pci_read_config_dword(dev, pos + PCI_DVSEC_HEADER2, &hdr);
+	if ((hdr & GENMASK(15, 0)) != dvsec_val)
+		return;
+	/*
+	 * Look at the port type field for the expected bits for PCIe tunneling
+	 * and XHCI tunneling
+	 *
+	 * 0x0 - Native Host Interface
+	 * 0x1 - PCIe Tunneled Port
+	 * 0x2 - USB Tunneled Port
+	 * 0x3-0x7 - Reserved
+	 */
+	if (hdr & GENMASK(17, 16))
+		dev->external_facing = true;
+}
+
 static void pci_set_removable(struct pci_dev *dev)
 {
 	struct pci_dev *parent = pci_upstream_bridge(dev);
@@ -1870,6 +1918,8 @@ int pci_setup_device(struct pci_dev *dev)
 	/* Early fixups, before probing the BARs */
 	pci_fixup_device(pci_fixup_early, dev);
 
+	pci_set_usb4_external(dev);
+
 	pci_set_removable(dev);
 
 	pci_info(dev, "[%04x:%04x] type %02x class %#08x\n",
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 61b161d914f0..3faee1af9ace 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2567,6 +2567,8 @@
 #define PCI_VENDOR_ID_TEKRAM		0x1de1
 #define PCI_DEVICE_ID_TEKRAM_DC290	0xdc29
 
+#define PCI_VENDOR_ID_USB_IF		0x1ec0
+
 #define PCI_VENDOR_ID_TEHUTI		0x1fc9
 #define PCI_DEVICE_ID_TEHUTI_3009	0x3009
 #define PCI_DEVICE_ID_TEHUTI_3010	0x3010
-- 
2.34.1


  parent reply	other threads:[~2022-02-15  0:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-15  0:01 [PATCH v4 00/10] Overhaul `is_thunderbolt` Mario Limonciello
2022-02-15  0:01 ` [PATCH v4 01/10] PCI: Add USB4 class definition Mario Limonciello
2022-02-15  0:01 ` [PATCH v4 02/10] PCI: Move `is_thunderbolt` check for lack of command completed to a quirk Mario Limonciello
2022-02-15  0:01 ` [PATCH v4 03/10] PCI: Detect root port of internal USB4 controllers Mario Limonciello
2022-02-15  0:01 ` Mario Limonciello [this message]
2022-02-15  0:01 ` [PATCH v4 05/10] PCI: Move check for old Apple Thunderbolt controllers into a quirk Mario Limonciello
2022-02-15  0:01 ` [PATCH v4 06/10] PCI: Drop the `is_thunderbolt` attribute from PCI core Mario Limonciello
2022-02-15  0:01 ` [PATCH v4 07/10] drm/amd: drop the use of `pci_is_thunderbolt_attached` Mario Limonciello
2022-02-15  0:01 ` [PATCH v4 08/10] drm/nouveau: " Mario Limonciello
2022-02-15  0:01 ` [PATCH v4 09/10] drm/radeon: " Mario Limonciello
2022-02-15  0:02 ` [PATCH v4 10/10] PCI: drop `pci_is_thunderbolt_attached` Mario Limonciello
2022-02-15  7:29 ` [PATCH v4 00/10] Overhaul `is_thunderbolt` Lukas Wunner
2022-02-15 19:07   ` Limonciello, Mario
2022-02-16 14:34     ` Mika Westerberg
2022-02-16 14:44       ` Alex Deucher
2022-02-16 16:50         ` Limonciello, Mario
2022-02-17  9:33           ` 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=20220215000200.242799-5-mario.limonciello@amd.com \
    --to=mario.limonciello@amd.com \
    --cc=Alexander.Deucher@amd.com \
    --cc=YehezkelShB@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=andreas.noever@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hdegoede@redhat.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=michael.jamet@intel.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=nouveau@lists.freedesktop.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox