On Wed, Dec 05, 2018 at 11:20:34AM +0200, Mika Westerberg wrote: > On Tue, Dec 04, 2018 at 09:40:49PM +0100, Lukas Wunner wrote: > > > I wonder if our pci_bridge_d3_possible() heuristics would need to be > > > refined somehow? At least if this blacklist starts growing. > > > > We do blacklist such non-native hotplug ports, but of course only if > > the Hot-Plug Capable bit is set: > > > > /* > > * Hotplug ports handled by firmware in System Management Mode > > * may not be put into D3 by the OS (Thunderbolt on non-Macs). > > */ > > if (bridge->is_hotplug_bridge && !pciehp_is_native(bridge)) > > return false; > > > > I guess your question boils down to, is there any better way to recognize > > ports which are handled by the platform firmware? > > Does acpiphp bind to this port? > > It does, yes but AFAIK it binds to any PCI bus (bridge) if it has an > ACPI companion. Does the root port have a _RMV and/or _SUN object? We could e.g. disallow runtime PM for any bridge with _RMV present and the HPC bit not set in the Slot Capabilities. This could be checked by extending acpi_pci_bridge_d3() to return either true, false or a "don't know" value. Or by adding another platform_pci_bridge_no_d3() hook. Thanks, Lukas
