So I think the problem is you will have an ordering dependency between the
two drivers for when the link gets created.
Like if thunderbolt.ko loads you would end up with links to PCIe root port
for tunneling as well as XHCI controller.
With this patch we only create links to PCIe Root/Downstream ports from
Thunderbolt side and the USB core will deal with the USB ones.
Then xhci loads and you end up also adding links to individual ports.
Would you remove the link to the controller?
See above.
And if the order is the other way around you end up with a larger state
machine.
How about PCIe core provides a helper to know whether or not a PCIe device
will support the proprietary register?
I think the xHCI can be non-PCIe device too (Apple silicon for
instance). The links here are created dynamically and only if there is
need (and support from the hardware) so we can let the USB4 controller
enter D3hot if there is no USB 3.x tunnel needed.
When I replied I was under the presumption that the next version the
link creation code for XHCI controller would stay in thunderbolt.ko and
the XHCI port would be in xhci.ko. But if you move both non-Intel and
Intel cases to xhci.ko this should be totally fine. If you can CC me on
the next version of the series I'll get that tested for AMD case.
Thanks!
