On Mon, Jun 24, 2024 at 01:41:09PM -0500, Mario Limonciello wrote: > > > > > > 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. Sure, we will.
