On Wed, Dec 19, 2018 at 08:45:19AM -0600, Bjorn Helgaas wrote: > On Wed, Dec 19, 2018 at 03:23:24PM +0200, Mika Westerberg wrote: > > On Tue, Dec 18, 2018 at 02:58:50PM -0600, Bjorn Helgaas wrote: > > > > > For example, it looks like PCI_EXP_FLAGS_SLOT is set, but Linux > > > > > basically ignores it. Maybe if PCI_EXP_FLAGS_SLOT is set but we > > > > > aren't using pciehp, we should assume any hotplug would be handled via > > > > > acpiphp? And in that case, we should avoid doing anything that would > > > > > prevent platform firmware from enumerating things below the bridge? > > > > > > > > I don't see why that would not work. This could cause "power regression" > > > > on some systems but I think that's better than systems that do not work > > > > at all. > > > > > > Yeah, I think that would be better, assuming it wouldn't cause a flood > > > of power regressions. I'd even rather have a whitelist of systems > > > where we use acpiphp and it's safe to do power management. > > > > Actually it looks like it would break power management of other > > components such as xHCI and Thunderbolt controller which are connected > > to a downstream port that has "Slot implemented" set as well. > > To be precise, I think you mean that if we avoided power management on > ports with "Slot Implemented", ports leading to xHCI and Thunderbolt > would consume more power but would work correctly, right? And the > theory is that those ports work even if the OS puts them into D3 > because the firmware is smart enough to wake them up before poking > things below them? Doesn't that make the port's power state out of > sync with what the OS thinks it is? I think better example where this fails is normal Thunderbolt device (not host) which includes PCIe switch and there is an PCIe endpoint, say network interface connected to one of the downstream ports. That downstream port has "Slot implemented" set but is not hotplug capable. So the device would work correctly but if you take the recent "Runtime D3, RTD3" system such as Lenovo Carbon X1 6th gen it keeps the whole PCIe hierarchy from entering D3cold. I would rather not to break that ;-) > > I have another idea, though. Windows says the Gigabyte system platform > > role is "Desktop" whereas on another system where Windows does power > > manage the ports the role is "Mobile". I think this maps directly to > > ACPI FADT table Preferred_PM_Profile field (there is sysfs attribute > > /sys/firmware/acpi/pm_profile exposing this as well). > > > > I wonder if we could use this information in pci_bridge_d3_possible() so > > that anything with "Desktop" profile returns false when native PCIe > > hotplug is not used? > > Hmmmm. I guess it's plausible that Windows might be more aggressive > about power management for "Mobile" roles as opposed to "Desktop". > But there's not really a logical connection to this situation (PCI > hotplug is a rare, non-latency sensitive event, so why wouldn't we > save power on the Desktop as well?), so it feels like a heuristic that > might coincidentally work sometimes but is liable to break at others. OK. > Popping back up to the top of the stack, what's the situation on other > systems? On this system, PCI_EXP_SLTCAP_HPC is not set. Do other systems > have that set but clear OSC_PCI_EXPRESS_NATIVE_HP_CONTROL so we don't use > pciehp? Should this be some sort of quirk? I guess that's morally > equivalent to the blacklist. But maybe it would be a more direct hint to > BIOS writers that this is a defect? Yes, typically these systems have PCI_EXP_SLTCAP_HPC set but BIOS does not allow "PCIeHotplug" in _OSC which prevents pciehp from controlling them. I'm not sure if this is actually a defect in BIOS because again this works fine in Windows and I don't see in any specs (ACPI/PCIe) saying you cannot do this. By a quirk you mean add DMI based quirk somewhere in drivers/pci/quirks.c which makes this root port to have ->is_hotplug_bridge set?
