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. 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? > > > Is there a bugzilla or any other URL we could include here to help with > > > future changes in this area? > > > > No, this was reported internally. > > > > I can file one if you think it is helpful. > > I think a kernel.org bugzilla that archived the "lspci -vv", a dmesg > log, and an acpidump might be helpful. Here it is: https://bugzilla.kernel.org/show_bug.cgi?id=202031
