On Fri, Jul 20, 2018 at 07:53:33AM +0800, kbuild test robot wrote: > commit: 50b623f07b02fc48e4d7d3e8b5a302abf40b3a7a [34/35] PCI: Whitelist native hotplug ports for runtime D3 > > drivers/pci/pci.c: In function 'pci_bridge_d3_possible': > >> drivers/pci/pci.c:2311:37: error: implicit declaration of function 'pciehp_is_native'; did you mean 'pcie_ports_native'? [-Werror=implicit-function-declaration] > if (bridge->is_hotplug_bridge && !pciehp_is_native(bridge)) > ^~~~~~~~~~~~~~~~ > pcie_ports_native > cc1: some warnings being treated as errors Hm, there is a conflict on the pci/hotplug branch wherein commit "PCI: hotplug: Implement hotplug_is_native() only when CONFIG_ACPI=y" removes the pciehp_is_native() declaration for the CONFIG_ACPI=n case (because there was previously only one caller of that function and that caller depended on CONFIG_ACPI=y), but the succeeding commit "PCI: Whitelist native hotplug ports for runtime D3" now adds another caller of that function which also exists in the CONFIG_ACPI=n case. Can the former commit be amended to leave the pciehp_is_native() declaration in place for CONFIG_ACPI=n? I'm wondering if we should be checking hotplug_is_native() instead of pciehp_is_native() in pci_bridge_d3_possible(). There appears to be an ordering issue if we do that because shpchp_is_native() checks bridge->shpc_managed, but that is only set to true by shpc_probe(). Now the problem is, the shpc pci_driver is registered with module_init(). If shpc is built-in, that becomes a device_initcall(). And pci_bridge_d3_possible() is called from pcie_portdrv_probe(), and portdrv is also registered with a device_initcall(). Thus, if hotplug_is_native() is called from pci_bridge_d3_possible(), it's result in the shpc case depends on the link order if shpc is built-in. If shpc is a module, it will always return false for the shpc case. I'm sorry, I'm pretty clueless about shpc and whether or not portdrv should activate runtime PM whether an shpc port is controlled by the firmware. Thanks, Lukas
