| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20170108134751.GA23120@wunner.de>
Date: Sun, 8 Jan 2017 14:47:51 +0100
From: Lukas Wunner <lukas@...ner.de>
To: "Winkler, Tomas" <tomas.winkler@...el.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Andreas Noever <andreas.noever@...il.com>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
"Chen, Yu C" <yu.c.chen@...el.com>,
"Levy, Amir (Jer)" <amir.jer.levy@...el.com>,
Bjorn Helgaas <helgaas@...nel.org>
Subject: Re: [PATCH v4 1/8] PCI: Recognize Thunderbolt devices
On Sun, Jan 08, 2017 at 10:23:03AM +0000, Winkler, Tomas wrote:
> > 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 <andreas.noever@...il.com>
> > Cc: Tomas Winkler <tomas.winkler@...el.com>
> > Cc: Amir Levy <amir.jer.levy@...el.com>
> > Signed-off-by: Lukas Wunner <lukas@...ner.de>
> > ---
> > 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 ?
That file is solely intended for IDs used in multiple places, as
explained in the comment at its top. This particular ID is only used
in the PCI core, hence it's in the PCI core's private drivers/pci/pci.h.
However the line is formatted such that it can just be moved to the
global include/linux/pci_ids.h should it be needed someplace else in
the future.
> > 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 ?
The is_thunderbolt bit signifies whether a given PCI device is part
of a Thunderbolt daisy chain. (As explained in the comment in
include/linux/pci.h, see below.) So it is set on all the PCI devices
that comprise a Thunderbolt controller, but also on all endpoint devices
that are attached via Thunderbolt.
Consequently this function needs to be executed for all PCI devices,
not just for a subset that could be identified by a vendor, device or
class ID.
In the DRM drivers nouveau, radeon and amdgpu I need to prevent calls
to vga_switcheroo_register_client() and vga_switcheroo_init_domain_pm_ops()
if the device in question is attached via Thunderbolt. That's because
external GPUs can't drive the panel of a laptop or be powered down like an
on-board Optimus/PowerXpress GPU. We've got a bug there right now that
manifests itself once someone attaches an eGPU to a dual GPU laptop.
With this patch I'll be able to just skip registration with vga_switcheroo
if is_thunderbolt is set on a GPU's pci_dev, thereby fixing the bug.
BTW do you have information on the contents/meaning of the VSEC that you
would be able/allowed to share? What I've seen so far is that its length
is 0x1c bytes on older controllers (e.g. Light Ridge, Port Ridge) and its
contents are always the same, regardless if the controller is used in
host mode or endpoint mode:
500: 0b 00 01 00 34 12 c1 01|50 09 00 00 39 00 00 00
510: 00 00 00 00 00 00 00 00 00 00 00 00
However on Alpine Ridge the size of the VSEC has increased significantly
to 0xd8 bytes, even though the version stayed at 1 as before:
500: 0b 00 01 60 34 12 81 0d 50 09 b0 0c b9 06 18 08
510: 00 38 00 01 00 00 00 00 00 00 00 00 32 02 10 00
520: ef d3 00 40 00 00 00 00 f0 f0 30 c1 00 02 30 00
530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
590: 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00
5a0: 00 00 00 00 00 00 00 00 00 00 00 00 38 24 01 00
5b0: 08 40 00 1c 00 00 01 18 04 03 00 f0 06 00 00 00
5c0: 00 00 08 40 06 00 00 01 90 00 08 1b 00 08 80 08
5d0: 80 7f 08 00 00 00 00 00
Thanks,
Lukas
>
> > + 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
Powered by blists - more mailing lists