All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: Andreas Noever <andreas.noever@gmail.com>
Cc: Xavier Gnata <xavier.gnata@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: [PATCH] thunderbolt: Add support for INTEL_FALCON_RIDGE_2C controller
Date: Wed, 13 Jul 2016 19:04:59 +0200	[thread overview]
Message-ID: <20160713170459.GA5840@wunner.de> (raw)
In-Reply-To: <CAMxnaaU1eMw5o9nJRmEgyw97oD25fRnjTcB_i+xAgc-V6m5HvA@mail.gmail.com>

On Wed, Jul 13, 2016 at 12:17:33AM +0200, Andreas Noever wrote:
> Are thunderbolt controllers always installed directly below the root
> port? In theory there could be more bridges in between (a candidate
> for such a topology would be the mac pro which has 3 controllers).

Hm, good point. I failed to find lspci or dmesg output for a MacPro6,1
but I did find this diagram:
http://i.imgur.com/ItIqxDY.png

Turns out the 3 controllers are connected to a PCIe switch.
And according to the PCIe spec, a switch consists of an upstream
bridge and downstream bridges. So the parent of the Thunderbolt
upstream port would be a downstream port and not a root port. :-/


Another idea would be to detect if the parent of the Thunderbolt
upstream port has the VSEC 0x1234. This is only present on Thunderbolt
devices, so a host controller is identifiable by the non-presence of
that VSEC on its parent. Patch [01/13] of my runpm series adds a
convenient is_thunderbolt flag to detect the VSEC:
https://github.com/l1k/linux/commit/8148c395ef6e

Generally I think it would be beneficial to replace the PCI quirk
with code that lives in drivers/thunderbolt/. Here's an example what
I have in mind, this is based on top of the runpm series and ensures
that the NHI resumes before the hotplug ports by waking it directly
from the upstream bridge:
https://github.com/l1k/linux/commit/c596932608cd

An even better approach would probably be Rafael's "device links"
series which allows the PM core to take care of device dependencies
beyond the mere parent/child relationship:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1170039.html

Best regards,

Lukas

  reply	other threads:[~2016-07-13 17:05 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-12 19:38 [PATCH] thunderbolt: Add support for INTEL_FALCON_RIDGE_2C controller Xavier Gnata
2016-07-12 21:13 ` Lukas Wunner
2016-07-12 21:21   ` Lukas Wunner
2016-07-12 22:17   ` Andreas Noever
2016-07-13 17:04     ` Lukas Wunner [this message]
2016-07-13 21:46       ` Xavier Gnata

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=20160713170459.GA5840@wunner.de \
    --to=lukas@wunner.de \
    --cc=andreas.noever@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=xavier.gnata@gmail.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.