On 9/6/2023 07:24, Hans de Goede wrote:
"XHCI tunneling" is an unfamiliar term for me. Are we talking about a XHCI controller inside a USB4/thunderbold dock here which is connected to the laptop over PCIe tunneling over thunderbolt ? Or do you mean the XHCI controller inside the laptop which is connected to a USB4/thunderbolt capable Type-C port which is used when that port is in USB3/USB2 mode ? As long as the XHCI controller is inside the laptop (and not in the dock), presumably you can identify it by say a set of PCI device-ids of the "tunneling" XHCI controllers on affected AMD platforms. So you could then still call pci_d3cold_disable() from the XHCI driver on only those controllers.
XHCI tunneling refers to XHCI over USB4 fabric. The problem isn't with the XHCI controllers going to D3 - it's with the root ports they are connected to. And the issue occurs with D3hot.
An earlier version of the series did do something like this where it was quirks for the PCI IDs for the root ports but it has two problems:
1) It covers too many things. The same PCI ID is used for a second root port that is unaffected by the issue. So this means the quirk needs to look at the topology to make sure the right device combination is quirked.
2) It doesn't scale. I don't have any reason to believe the constraints requirements change which means we'll be adding new quirks with every single new CPU.
Note I'm not saying this is the best solution. I'm just trying to understand what you mean with " the PCIe root port that is used for XHCI tunneling" . I also see that Rafael has said elsewhere in the thread that he needs to think a bit about how to best handle this ...
I have done a prototype for your callback proposal, and I've got something working at least for amd-pmc. It only calls the callback one time rather than at suspend.
Unless I get some feedback from Bjorn that the callback proposal is a bad idea I'll post something later today.
