From patchwork Mon Jul 30 20:40:32 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Rafael J. Wysocki" X-Patchwork-Id: 174087 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 1CD112C009B for ; Tue, 31 Jul 2012 06:34:56 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754923Ab2G3Uey (ORCPT ); Mon, 30 Jul 2012 16:34:54 -0400 Received: from ogre.sisk.pl ([193.178.161.156]:35260 "EHLO ogre.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754726Ab2G3Uex (ORCPT ); Mon, 30 Jul 2012 16:34:53 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by ogre.sisk.pl (Postfix) with ESMTP id 735CA1DB3BF; Mon, 30 Jul 2012 22:27:15 +0200 (CEST) Received: from ogre.sisk.pl ([127.0.0.1]) by localhost (ogre.sisk.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26149-01; Mon, 30 Jul 2012 22:26:58 +0200 (CEST) Received: from ferrari.rjw.lan (62-121-64-87.home.aster.pl [62.121.64.87]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ogre.sisk.pl (Postfix) with ESMTP id 090C31DB2BC; Mon, 30 Jul 2012 22:26:56 +0200 (CEST) From: "Rafael J. Wysocki" To: Len Brown Subject: [PATCH] ACPI / PCI: Do not try to acquire _OSC control if that is hopeless Date: Mon, 30 Jul 2012 22:40:32 +0200 User-Agent: KMail/1.13.6 (Linux/3.5.0+; KDE/4.6.0; x86_64; ; ) Cc: Matthew Garrett , Bjorn Helgaas , ACPI Devel Mailing List , linux-pci@vger.kernel.org, LKML MIME-Version: 1.0 Message-Id: <201207302240.32480.rjw@sisk.pl> X-Virus-Scanned: amavisd-new at ogre.sisk.pl using MkS_Vir for Linux Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org If acpi_pci_osc_support() fails for the given flags, it doesn't make sense to call acpi_pci_osc_control_set() down the road for the same flags, because it will certainly fail too. Moreover, problem diagnostics is then harder, because it is not too easy to identify the reason of the _OSC failure in those cases. For this reason, check the status returned by acpi_pci_osc_support() for PCIe support flags and do not attempt to execute acpi_pci_osc_control_set() for those flags and print a message if it's "failure". For compatibility with the existing code, disable ASPM in that case too. Signed-off-by: Rafael J. Wysocki --- drivers/acpi/pci_root.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Index: linux/drivers/acpi/pci_root.c =================================================================== --- linux.orig/drivers/acpi/pci_root.c +++ linux/drivers/acpi/pci_root.c @@ -573,8 +573,15 @@ static int __devinit acpi_pci_root_add(s OSC_CLOCK_PWR_CAPABILITY_SUPPORT; if (pci_msi_enabled()) flags |= OSC_MSI_SUPPORT; - if (flags != base_flags) - acpi_pci_osc_support(root, flags); + if (flags != base_flags) { + status = acpi_pci_osc_support(root, flags); + if (ACPI_FAILURE(status)) { + dev_info(root->bus->bridge, "ACPI _OSC support " + "notification failed, disabling PCIe ASPM\n"); + pcie_no_aspm(); + flags = base_flags; + } + } if (!pcie_ports_disabled && (flags & ACPI_PCIE_REQ_SUPPORT) == ACPI_PCIE_REQ_SUPPORT) {