On Sat, Mar 31, 2018 at 11:30:44AM +0200, Rafael J. Wysocki wrote:
> > The whole point here is that those are *not* hotplug slots just regular
> > downstream ports.
>
> I'm not sure what scenario exactly you are referring to to be honest.
>
> Something related to Thunderbolt I suppose?
Here is an example that hopefully clarifies. This example is from a
system using Thunderbolt in "native" mode but I think it is not specific
to Thunderbolt. The idea is that when you don't have anything connected
to Thunderbolt ports you have following PCI topology:
00:1b.0 --
So a root port that is hotplug capable and handled by pciehp.
Next when you plug in a Thunderbolt enpdoint, you get native PCIe
hotplug event and after it is handled the topology looks like:
00:1b.0 --- 01:00.0 --+- 02:00.0 --
+- 02:01.0 (hotplug) --
\- 02:02.0 --
In other words there is a PCIe switch with one hotplug port (02:01.0)
that is again handled by pciehp (this is used to daisy chain further
devices). However, downstream ports 02:00.0 and 02:02.0 are not marked
as hotplug capable so pciehp is not controlling them.
To bring in xHCI and/or Thunderbolt host controller we get ACPI Notify()
to the root port 00:1b.0 which should result following topology after
handled by acpiphp:
00:1b.0 --- 01:00.0 --+- 02:00.0 -- Thunderbolt host controller
+- 02:01.0 (hotplug) --
\- 02:02.0 -- xHCI host controller
In other words ACPI Notify() is used to populate devices connected to
non-hotplug downstream ports. It is also used to "hot-unplug" them in
the same way (for example if you only connect standard USB-C device to
the port the Thunderbolt host controller is hot-unplugged using this
mechanism).
Rest of the devices in the chain are hotplugged using standard native
PCIe hotplug so pciehp will be controlling then.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
