On Wed, Jul 20, 2016 at 02:52:42PM +0200, Rafael J. Wysocki wrote:

On Wednesday, July 20, 2016 08:24:50 AM Lukas Wunner wrote:

quoted

On Wed, Jul 20, 2016 at 02:33:18AM +0200, Rafael J. Wysocki wrote:

quoted

On Friday, June 17, 2016 04:07:38 PM Lukas Wunner wrote:

quoted

On Fri, Jun 17, 2016 at 02:54:56PM +0200, Rafael J. Wysocki wrote:

quoted

On Fri, Jun 17, 2016 at 12:36 PM, Lukas Wunner [off-list ref] wrote:

quoted

On Fri, Jun 17, 2016 at 08:26:52AM +0200, Marek Szyprowski wrote:

quoted

From: "Rafael J. Wysocki" <redacted>

We also have such a functional dependency for Thunderbolt on Macs:
On resume from system sleep, the PCIe hotplug ports may not resume
before the thunderbolt driver has reestablished the PCI tunnels.
Currently this is enforced by quirk_apple_wait_for_thunderbolt()
in drivers/pci/quirks.c. It would be good if we could represent
this dependency using something like Rafael's approach instead of
open coding it, however one detail in Rafael's patches is problematic:

quoted

New links are added by calling device_link_add() which may happen
either before the consumer device is probed or when probing it, in
which case the caller needs to ensure that the driver of the
supplier device is present and functional and the DEVICE_LINK_PROBE_TIME
flag should be passed to device_link_add() to reflect that.

The thunderbolt driver cannot call device_link_add() before the
PCIe hotplug ports are bound to a driver unless we amend portdrv
to return -EPROBE_DEFER for Thunderbolt hotplug ports on Macs
if the thunderbolt driver isn't loaded.

It would therefore be beneficial if device_link_add() can be
called even *after* the consumer is bound.

I don't quite follow.

Who's the provider and who's the consumer here?

thunderbolt.ko is the supplier.

But it binds to the children of the ports that are supposed to be its
consumers?

Why is that even expected to work?

No, the consumers are aunts (or uncles) of the supplier, if you will. :-)

The consumers are the hotplug ports (named "Downstream Bridge 1 / 2" in
the drawing below). The supplier is the NHI:

      (Root Port) ---- Upstream Bridge --+-- Downstream Bridge 0 ---- NHI
                                         +-- Downstream Bridge 1 --
                                         +-- Downstream Bridge 2 --
                                         ...

We're calling pci_power_up() and pci_restore_state() from
pci_pm_resume_noirq(). And that will fail for devices below
the hotplug ports if the PCI tunnels haven't been re-established
yet by the NHI.

So the NHI is a PCIe device, right?

Does the Thunderbolt driver bind to that device?

The NHI is a PCI device but not a bridge. It has class 0x88000.
Yes, thunderbolt.ko binds to the NHI.

And portdrv binds to the upstream bridge and downstream bridges.
Those have class 0x60400.

Best regards,

Lukas