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@xxxxxxxxxxxxxxx/msg1170039.html
Best regards,
Lukas
I agree that it would be a good idea to get rid of both the subsystem
vendor/device id and the quirk.
I quite like the approach of
https://github.com/l1k/linux/commit/c596932608cd : Do you want me to
give it a try on my hardware?
Rafael's approach is more ambitious and complex but even cleaner.
Maybe a two step approach : First we get rid of the quirk and we support
INTEL_FALCON_RIDGE_2C controller and, in a longer run, we try to
implement these functional dependencies in PCI core.
Anyway you are the experts :)
Xavier
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html