On Tue, Jul 27, 2021 at 11:58:56AM +0200, Christophe de Dinechin wrote:
On 26 Jul 2021, at 11:44, David Gibson <kata-dev@gibson.dropbear.id.au> wrote:
Hello all,
I recently discovered that the kernel config generated by tools/packaging/kernel has CONFIG_PCI_MMCONFIG disabled.
I'm curious how much difference it makes in memory size (if at all). I suspect things that were configured out were most likely selected to reduce the kernel size more than for any other reason.
That's probably not a good idea, since that's a very atypical config for modern systems, and for complicated reasons it completely stops SHPC hotplug from working.
That's weird. Shouldn't that be abstracted behind pci_read_config_byte() and the like? Now you make me curious why this breaks SHPC hotplug. If you have the time to explain ;-) Does this seem like a kernel bug or some hardware / architectural limitation?
Yeah, it's not as direct as that, hence "complicated reasons". *checks notes* specifically the path is: When mmconfig is disabled, raw_pci_ext_ops is never set by pci_mmcfg_arch_init(). That makes pci_ext_cfg_avail() return 0, which makes the 'support' variable in negotiate_os_control() lack the OSC_PCI_EXT_CONFIG_SUPPORT bit - a.k.a. the ACPI_PCIE_REQ_SUPPORT bit. That makes negotiate_os_control() exit early (" _OSC: not requesting OS control; OS requires [ExtendedConfig ASPM ClockPM MSI]"). So, it never gets to acpi_pci_osc_control_set(), which would set root->osc_control_set. That means that host_bridge->native_shpc_hotplug is set to 0 later in acpi_pci_root_create(). That means that acpi_get_hp_hw_control_from_firmware() will return -ENODEV, and therefore so will shpc_probe(). I don't know enough about ACPI or PCI on x86 to know if this is a kernel bug per se. If it is, Kata's in more trouble, since if the kernel bug is fixed it will break us (since we're actually relying on SHPC not working properly). -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson