On Fri, Jun 14, 2013 at 7:11 AM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: > Here are some of my notes from trying to sort this out, in chronological > order: > > 29594404 v3.7 > Bus scanned before requesting _OSC control > pre-1.1 ath5k has ASPM disabled (works fine) > > 8c33f51d "request _OSC control before scanning bus" > > 19f949f5 v3.8 > _OSC control requested before scanning bus > Now pre-1.1 ath5k has ASPM enabled and doesn't work > https://bugzilla.kernel.org/show_bug.cgi?id=55211 opened > > b8178f13 "revert 'request _OSC control before scanning bus' (8c33f51d)" > Bus now scanned before requesting _OSC control (as in v3.7) > > c1be5a5b v3.9 > pciehp claims slots first, even when both pciehp & acpiphp are > built-in, because pciehp module_init precedes acpiphp module_init > in link order > > 6037a803 "Convert acpiphp to be builtin only" > This also adds "acpiphp.disable" boot option > > 3b63aaa7 "Do not use ACPI PCI subdriver mechanism" > Now acpiphp claims slots first because we call > acpiphp_enumerate_slots() from pcibios_add_bus() during PCI device > enumeration. This happens before pciehp, which still uses > module_init. > > f722406f v3.10-rc1 > > ........ "Revert reverting of 'request _OSC control before scanning bus' (b8178f13)" > _OSC control requested before scanning bus (as in v3.8) > pre-1.1 ath5k probably has ASPM enabled and doesn't work > > ........ "Remove not needed check in disable aspm link" > Now pci_disable_link_state() unconditionally disables ASPM, > even when BIOS hasn't given us ASPM control > > > 1) The problem you're trying to fix is that when both acpiphp and > pciehp are supported for the same slot, acpiphp claims the slot first > and pciehp will not claim it. I think this problem was introduced by > 3b63aaa7, which was merged after v3.9. Therefore, v3.9 should work > correctly, and this regression appeared in v3.10-rc1. > > 2) As you say, acpiphp cannot be a module, so the user would have to > rebuild the kernel to remove it. However, 6037a803 *did* add a > "acpiphp.disable" boot option, so that should be a workaround that > allows pciehp to claim the slot. How about the same system that some slots need to be handled by acpiphp and some others need to be handled by pciehp ? for example: laptop that have dock that will need acpiphp, and also have pci express card that need pciehp. > > 3) I think your "revert reverting" patch gets us back to the same > situation we had after 8c33f51d, i.e., Roman's pre-1.1 ath5k device > will have ASPM enabled and won't work. I don't want to leave the tree > in this broken state, even though you intend to fix it in the next > patch. If you can reorder your patches so the ASPM fix is first, that > would be better. yes. We could apply your patch in [1] at first, and revert the reverting. and do not touch pcie_clear_aspm now. > > 4) Your "Remove not needed check in disable aspm link" patch makes > pci_disable_link_state() disable ASPM even when the OS doesn't have > permission to control ASPM. I think this is a mistake. I proposed a > similar change in [1], but Rafael and Matthew thought it was too > risky, and I agree. before all those changes, and in current state: quirk disable aspm is before _osc support and control are set. aka in pci_acpi_scan_root will allocate all link state struct, and quirk call pci_disable_link_state, and later will _osc support or control can not be set, pcie_no_aspm is called, can will block all aspm operation. That is risky too?, why booting path quirk could do that, but driver and hot-add quirk path can not do that ? or we can have another pci_disable_link_state always work on quirk path only? Yinghai -- 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
