From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1163151AbdAHKXW convert rfc822-to-8bit (ORCPT ); Sun, 8 Jan 2017 05:23:22 -0500 Received: from mga04.intel.com ([192.55.52.120]:22378 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161003AbdAHKXI (ORCPT ); Sun, 8 Jan 2017 05:23:08 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,334,1477983600"; d="scan'208";a="51343797" From: "Winkler, Tomas" To: Lukas Wunner , Greg Kroah-Hartman , "linux-kernel@vger.kernel.org" CC: Andreas Noever , "linux-pci@vger.kernel.org" , "linux-pm@vger.kernel.org" , "Chen, Yu C" , "Levy, Amir (Jer)" , Bjorn Helgaas Subject: RE: [PATCH v4 1/8] PCI: Recognize Thunderbolt devices Thread-Topic: [PATCH v4 1/8] PCI: Recognize Thunderbolt devices Thread-Index: AQHSaYsiGVM8U1l34Uy4pkMdJEFVl6EuXYvQ Date: Sun, 8 Jan 2017 10:23:03 +0000 Message-ID: <5B8DA87D05A7694D9FA63FD143655C1B54376D27@hasmsx108.ger.corp.intel.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOWZmMzIyZjYtZjg5MS00Y2E1LWIyZDktYzVmZDVhZjkzYTFjIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6ImhuNENjWTFWRllXZ3pnQTdKS1FuZ3BlblFWdHhweUlBMndhVkRYYzR5aVE9In0= x-originating-ip: [10.184.70.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > We're about to allow runtime PM on Thunderbolt ports in > pci_bridge_d3_possible() and unblock runtime PM for Thunderbolt host > hotplug ports in pci_dev_check_d3cold(). In both cases we need to uniquely > identify if a PCI device belongs to a Thunderbolt controller. > > We also have the need to detect presence of a Thunderbolt controller in > drivers/platform/x86/apple-gmux.c because dual GPU MacBook Pros cannot > switch external DP/HDMI ports between GPUs if they have Thunderbolt. > > Furthermore, in multiple places in the DRM subsystem we need to detect > whether a GPU is on-board or attached with Thunderbolt. As an example, > Thunderbolt-attached GPUs shall not be registered with vga_switcheroo. > > Intel uses a Vendor-Specific Extended Capability (VSEC) with ID 0x1234 on > devices belonging to a Thunderbolt controller which allows us to recognize > them. > > Detect presence of this VSEC on device probe and cache it in a newly added > is_thunderbolt bit in struct pci_dev which can then be queried by > pci_bridge_d3_possible(), pci_dev_check_d3cold(), apple-gmux and others. > > Cc: Andreas Noever > Cc: Tomas Winkler > Cc: Amir Levy > Signed-off-by: Lukas Wunner > --- > drivers/pci/pci.h | 2 ++ > drivers/pci/probe.c | 34 ++++++++++++++++++++++++++++++++++ > include/linux/pci.h | 1 + > 3 files changed, 37 insertions(+) > > diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h index cb17db2..45c2b81 > 100644 > --- a/drivers/pci/pci.h > +++ b/drivers/pci/pci.h > @@ -3,6 +3,8 @@ > > #define PCI_FIND_CAP_TTL 48 > > +#define PCI_VSEC_ID_INTEL_TBT 0x1234 /* Thunderbolt */ Shouldn't bet this defined in pci_ids.h ? > extern const unsigned char pcie_link_speed[]; > > bool pcie_cap_has_lnkctl(const struct pci_dev *dev); diff --git > a/drivers/pci/probe.c b/drivers/pci/probe.c index e164b5c..891a8fa 100644 > --- a/drivers/pci/probe.c > +++ b/drivers/pci/probe.c > @@ -1206,6 +1206,37 @@ void set_pcie_hotplug_bridge(struct pci_dev > *pdev) > pdev->is_hotplug_bridge = 1; > } > > +static void set_pcie_vendor_specific(struct pci_dev *dev) { Why don't u implement this in quirk.c ? > + int vsec = 0; > + u32 header; > + > + while ((vsec = pci_find_next_ext_capability(dev, vsec, > + PCI_EXT_CAP_ID_VNDR))) { > + pci_read_config_dword(dev, vsec + PCI_VNDR_HEADER, > &header); > + > + /* Is the device part of a Thunderbolt controller? */ > + if (dev->vendor == PCI_VENDOR_ID_INTEL && > + PCI_VNDR_HEADER_ID(header) == PCI_VSEC_ID_INTEL_TBT) > + dev->is_thunderbolt = 1; > + } > + > + /* > + * Is the device attached with Thunderbolt? Walk upwards and check > for > + * each encountered bridge if it's part of a Thunderbolt controller. > + * Reaching the host bridge means dev is soldered to the mainboard. > + */ > + if (!dev->is_thunderbolt) { > + struct pci_dev *parent = dev; > + > + while ((parent = pci_upstream_bridge(parent))) > + if (parent->is_thunderbolt) { > + dev->is_thunderbolt = 1; > + break; > + } > + } > +} > + > /** > * pci_ext_cfg_is_aliased - is ext config space just an alias of std config? > * @dev: PCI device > @@ -1358,6 +1389,9 @@ int pci_setup_device(struct pci_dev *dev) > /* need to have dev->class ready */ > dev->cfg_size = pci_cfg_space_size(dev); > > + /* need to have dev->cfg_size ready */ > + set_pcie_vendor_specific(dev); > + > /* "Unknown power state" */ > dev->current_state = PCI_UNKNOWN; > > diff --git a/include/linux/pci.h b/include/linux/pci.h index e2d1a12..3c775e8 > 100644 > --- a/include/linux/pci.h > +++ b/include/linux/pci.h > @@ -358,6 +358,7 @@ struct pci_dev { > unsigned int is_virtfn:1; > unsigned int reset_fn:1; > unsigned int is_hotplug_bridge:1; > + unsigned int is_thunderbolt:1; /* part of Thunderbolt daisy chain > */ > unsigned int __aer_firmware_first_valid:1; > unsigned int __aer_firmware_first:1; > unsigned int broken_intx_masking:1; > -- > 2.11.0