On Tue, Aug 27, 2013 at 03:34:11PM -0600, Bjorn Helgaas wrote: > [+cc Stefan] > > On Mon, Aug 26, 2013 at 9:39 AM, Neil Horman <nhorman@xxxxxxxxxxxxx> wrote: > > Somewhere between 3.9 and 3.10 it seems the order in which pcie and acpi probed > > slots for hotplug capabilites got reversed. While this isn't a big deal, it did > > uncover a bug in the ACPI bus setup path. Specifically, acpi_pci_root_add calls > > pci_acpi_scan_root before setting the osc flags for the device handle. > > pci_acpi_scan_root, among other things uses device_is_managed_by_native_pciehp() > > to determine if a given slot has pcie hotplug capabilties, whcih checks the > > devices OSC_PCI_EXPRESS_NATIVE_HP_CONTROL flag. Since that flag is not set > > until after pci_acpi_scan_root_completes, the acpi code never sees that pcie > > slots are hotplug capable and configures them all to use acpi instead. > > I'd like to make it more explicit what we're fixing. Apparently this > is a regression between v3.9 and v3.10. > > Is this a fix for problems like > https://bugzilla.kernel.org/show_bug.cgi?id=60736 ? That bug is that > an ExpressCard slot doesn't work unless we boot with > "acpiphp.disable=1". I think what happens there is that acpiphp > claims the slot before we run _OSC, so pciehp doesn't claim it, even > though _OSC did grant us control over native PCIe hotplug. > Yes, that bug is precisely what I am trying to fix (although your wording above is inverted from the problem in the bug). What happens is that acpiphp claims the pcie ports, because acpiphp init runs first, and we haven't yet parsed _OSC, which would have told acpiphp to yield control to pciehp. The initial fix I proposed fixed this by parsing _OSC prior to running the acpiphp bus scan, but that reintroduced the problem of not handling pcie 1.1 aspm properly. That has been fixed in v2/v3 by deferring the setting of aspm_disable until after the bus scan. Shall I submit a v4 with an updated changelog? Best Neil -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
