On Wed, Jun 12, 2013 at 10:05 AM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: >> current code from acpi_pci_root_add we have >> 1. pci_acpi_scan_root >> ==> pci devices enumeration and bus scanning. >> ==> pci_alloc_child_bus >> ==> pcibios_add_bus >> ==> acpi_pci_add_bus >> ==> acpiphp_enumerate_slots >> ==> ...==> register_slot >> ==> device_is_managed_by_native_pciehp >> ==> check osc_set with >> OSC_PCI_EXPRESS_NATIVE_HP_CONTROL >> 2. _OSC set request >> >> so we always have acpiphp hotplug slot registered at first. >> >> so either we need to >> A. revert reverting about _OSC >> B. move pcibios_add_bus down to pci_bus_add_devices() >> as acpiphp and apci pci slot driver are some kind of drivers for pci_bus >> C. A+B > > It doesn't surprise me at all that there are problems in the _OSC code > and the acpiphp/pciehp interaction. That whole area is a complete > disaster. It'd really be nice if somebody stepped up and reworked it > so it makes sense. > > But this report is useless to me. I don't have time to work out what > the problem is and how it affects users and come up with a fix. effects: without fix the problem, user can not use pcie native hotplug if their system's firmware support acpihp and pciehp. And make it worse, that acpiphp have to be built-in, so they have no way to blacklist acpiphp in config. > > My advice is to simplify the path first, and worry about fixing the > bug afterwards. We've already done several iterations of fiddling > with things, and I think all we're doing is playing "whack-a-mole" and > pushing the bugs around from one place to another. We need to address regression at first. my suggestion is : revert the reverting and apply my -v3 version that will fix regression that Roman Yepishev met. please check attached two patches, hope it could save your some time. Yinghai
Attachment:
revert_revert_osc_change_linus.patch
Description: Binary data
Attachment:
disable_aspm_3_linus.patch
Description: Binary data
