Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752754Ab3FNQSB (ORCPT ); Fri, 14 Jun 2013 12:18:01 -0400 Received: from mail-oa0-f43.google.com ([209.85.219.43]:57131 "EHLO mail-oa0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751699Ab3FNQR7 (ORCPT ); Fri, 14 Jun 2013 12:17:59 -0400 MIME-Version: 1.0 In-Reply-To: <20130614141101.GA29452@google.com> References: <20130401235256.GA31966@google.com> <20130614141101.GA29452@google.com> Date: Fri, 14 Jun 2013 09:17:58 -0700 X-Google-Sender-Auth: ftUXpFaO-Aaj5pflTL12Uzz5ANA Message-ID: Subject: Re: [PATCH] PCI: Remove not needed check in disable aspm link From: Yinghai Lu To: Bjorn Helgaas Cc: Jiang Liu , Roman Yepishev , "Rafael J. Wysocki" , "linux-pci@vger.kernel.org" , "linux-acpi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Linus Torvalds , Andrew Morton , Greg Kroah-Hartman Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4076 Lines: 97 On Fri, Jun 14, 2013 at 7:11 AM, Bjorn Helgaas 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/