On Tue, Oct 03, 2023 at 03:16:47PM -0500, Mario Limonciello wrote:
On 10/3/2023 15:00, Lukas Wunner wrote:
The pcie_find_root_port() function you're using here will walk up the hierarchy until it finds the Root Port, i.e. it's specifically for the case where there are switches between the USB controller and Root Port (which I think you want to exclude). I would have expected that you just call pci_upstream_bridge(dev) once and check whether the returned device is a PCI_EXP_TYPE_ROOT_PORT.
Is there an advantage to using pci_upstream_bridge() given it's just one step up with pcie_find_root_port()?
Not really, no. The information I was missing is that these Device IDs are unique to the SoC and will never appear in a Thunderbolt-attached device.
That's exactly what I was worried about - what if other callers end up using pci_d3cold_disable/pci_d3cold_enable for some reason. We're all fighting for the same policy bits.
This being said, I am tending to agree with Bjorn, it's better to just clear the PME bits.
Fair enough, I'm sorry I led you down the wrong path with that suggestion. I guess no_d3cold is generally only useful for the "D3cold is known to be broken *permanently*" use case. Incidentally, there's only a single driver in the tree calling pci_d3cold_enable() and that's i915. And it likewise disables and re-enables the flag at the Root Port, just like you did.
Thanks,
Lukas