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
