I've got a new HP ZBook 17 G2 here (have also tested with a ZBook 15, same problem), which has an expresscard slot. Out of the box, the expresscard slot doesn't allow hotplugging, as no hotplug driver successfully binds to it. Booting the system with a card inserted, or switching from PCIEHP_DETECT_ACPI to PCIEHP_DETECT_PCIE (pciehp_detect_mode=pcie) makes it function. Looking through the ACPI tables for the machine and the code for _ACPI mode, my first thought was that it was missing an _RMV object for the expresscard slot, and thus never binding. I posted a patch here to quirk around it via dmi matching: https://lkml.org/lkml/2015/5/14/666 However, discussion indicates the problem may lay elsewhere. I'll attach dmesg spew and an acpidump shortly, but I'll note that the system DOES indicate the operating system has been given full control over PCIeHotplug: [ 4.013326] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] [ 4.015860] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability] Perhaps pciehp_acpi should be setting PCIEHP_DETECT_PCIE when it sees the OS has full control of PCIeHotplug? Also of possible interest is this bit in drivers/acpi/pci_root.c: static const struct acpi_device_id root_device_ids[] = { {"PNP0A03", 0}, {"", 0}, }; static struct acpi_scan_handler pci_root_handler = { .ids = root_device_ids, .attach = acpi_pci_root_add, .detach = acpi_pci_root_remove, .hotplug = { .enabled = true, .scan_dependent = acpi_pci_root_scan_dependent, }, }; The device ID for the pcie bus is PNP0A08.
Created attachment 177201 [details] acpidump from HP ZBook 17 G2
Created attachment 177211 [details] dmesg dump with various acpi and pci debug enabled
As stated in a related e-mail discussion, hotplug should be controlled by the native PCIe mechanism anyway on the affected machine.
Patch posted: https://patchwork.kernel.org/patch/6436921/