Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754841AbXIWBU1 (ORCPT ); Sat, 22 Sep 2007 21:20:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751446AbXIWBUV (ORCPT ); Sat, 22 Sep 2007 21:20:21 -0400 Received: from wa-out-1112.google.com ([209.85.146.178]:63880 "EHLO wa-out-1112.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751410AbXIWBUT (ORCPT ); Sat, 22 Sep 2007 21:20:19 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jAItCzwIQ9Hk2a1SM6ovbMV0B+QdbkqNDzRxuO977yNBmCvoie2Z5SGKcVqFIgLVRpMmCbSegfC0ZeDXthSm4dGxC+N0lbZuKhh9cBIQ+SHaM8EM3Kwt8lRnSso9ZOyr3RrHaBZ77tLLAovOGc2pl7uUzN/c0mGXupsjhhYPDP8= Message-ID: <86802c440709221820y5dfdca5fmd74da31146bf78d9@mail.gmail.com> Date: Sat, 22 Sep 2007 18:20:18 -0700 From: "Yinghai Lu" To: "Robert Hancock" Subject: Re: [PATCH] [9/50] i386: validate against ACPI motherboard resources Cc: "Andrew Morton" , "H. Peter Anvin" , "Thomas Gleixner" , "Andi Kleen" , rajesh.shah@intel.com, jbarnes@virtuousgeek.org, greg@kroah.com, patches@x86-64.org, linux-kernel@vger.kernel.org In-Reply-To: <46F588D7.2030109@shaw.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200709221231.836138000@suse.de> <20070921223207.7BBE71479D@wotan.suse.de> <86802c440709212349l3d968d1bgdc89e7c7415b54da@mail.gmail.com> <46F542A4.9080207@shaw.ca> <1190484117.4035.71.camel@chaos> <46F56208.90208@shaw.ca> <86802c440709221340h2cbbf423y239f399ab5da815d@mail.gmail.com> <46F588D7.2030109@shaw.ca> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3634 Lines: 95 On 9/22/07, Robert Hancock wrote: > Yinghai Lu wrote: > > On 9/22/07, Robert Hancock wrote: > >> Thomas Gleixner wrote: > >>> On Sat, 2007-09-22 at 10:28 -0600, Robert Hancock wrote: > >>>> Yinghai Lu wrote: > >>>>> No! > >>>>> > >>>>> MMCONFIG will not work with acpi=off any more. > >>>> I don't think this is unreasonable. The ACPI MCFG table is how we are > >>>> supposed to learn about the area in the first place. If we can't get the > >>>> table location via an approved mechanism, and can't validate it doesn't > >>>> overlap with another memory reservation or something, I really don't > >>>> think we should be using it. > >>> We all know how correct ACPI tables are. Specifications are nice, > >>> reality tells a different story. > >> MMCONFIG can't be used without ACPI in any case unless we know where the > >> table is using chipset-specific knowledge (i.e. reading the registers > >> directly). Doing that without being told that this area is really > >> intended to be used, via the ACPI table, is dangerous, i.e. we don't > >> necessarily know if the MMCONFIG is broken on the platform in some way > >> we can't detect. > > > > the BIOS get these info from the chipset too. > > for AMD Fam 10h opteron, we can read that MSR for MMCONFIG base. > > > >>>> I don't think it's much of an issue anyway - the chances that somebody > >>>> will want to run without ACPI on a system with MCFG are pretty low given > >>>> that you'll end up losing a bunch of functionality (not least of which > >>>> is multi-cores). > >>> acpi=off is an often used debug switch and it _is_ quite useful. Taking > >>> away debug functionality is not a good idea. > >> If someone has to turn ACPI off, disabling MMCONFIG is probably the > >> least of their worries.. > > > > MMCONFIG has nothing to do ACPI..., just becase MCFG in the ACPI, we > > must use ACPI for MMCONFIG? > > config PCI_MMCONFIG > bool > depends on PCI && ACPI && (PCI_GOMMCONFIG || PCI_GOANY) > default y > > We already depend on ACPI for MMCONFIG support at compile time. This > patch does not change that. > > We could conceivably skip the validation if ACPI was disabled, though > this would only make a difference in the few cases where we can detect > the MMCONFIG area without it (looks like currently only Intel E7520 and > 945, at least in mainline). can you make pci_mmcfg_late_init take one parameter about if acpi is there or not? so in acpi_init will be diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c index 9ba778a..a4a6a6f 100644 --- a/drivers/acpi/bus.c +++ b/drivers/acpi/bus.c @@ -746,6 +746,7 @@ static int __init acpi_init(void) if (acpi_disabled) { printk(KERN_INFO PREFIX "Interpreter disabled.\n"); + pci_mmcfg_late_init(0); return -ENODEV; } @@ -757,6 +758,7 @@ static int __init acpi_init(void) result = acpi_bus_init(); if (!result) { + pci_mmcfg_late_init(1); #ifdef CONFIG_PM_LEGACY if (!PM_IS_ACTIVE()) pm_active = 1; @@ -767,8 +769,10 @@ static int __init acpi_init(void) result = -ENODEV; } #endif - } else + } else { + pci_mmcfg_late_init(0); disable_acpi(); + } return result; } YH - 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/