Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755350AbXLWRdT (ORCPT ); Sun, 23 Dec 2007 12:33:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752615AbXLWRdH (ORCPT ); Sun, 23 Dec 2007 12:33:07 -0500 Received: from smtp2.linux-foundation.org ([207.189.120.14]:50332 "EHLO smtp2.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752852AbXLWRdF (ORCPT ); Sun, 23 Dec 2007 12:33:05 -0500 Date: Sun, 23 Dec 2007 09:32:28 -0800 (PST) From: Linus Torvalds To: Ivan Kokshaysky cc: Jeff Garzik , Loic Prylli , Arjan van de Ven , linux-kernel@vger.kernel.org, gregkh@suse.de, linux-pci@atrey.karlin.mff.cuni.cz, Benjamin Herrenschmidt Subject: Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue In-Reply-To: <20071223110337.GA25441@jurassic.park.msu.ru> Message-ID: References: <476D1D16.5090703@garzik.org> <20071222064719.73fdd9a4@laptopd505.fenrus.org> <476DB95F.3090801@garzik.org> <476DDFEE.3010009@garzik.org> <476DE98F.2010009@garzik.org> <476DF1A6.3060900@myri.com> <476DF5BE.5030004@garzik.org> <20071223110337.GA25441@jurassic.park.msu.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1901 Lines: 41 On Sun, 23 Dec 2007, Ivan Kokshaysky wrote: > > This is a result of all-or-none approach, as mmconfig is fundamentally > unsafe until after PCI init is done. Yes. One of the things I want to have happen (and which "pci_enable_mmconf()" would do automatically) is that we always probe using conf1 cycles in any machine where conf1 works at all. Then, some late PCI quirk or some per-device quirk (or driver) can decide to enable mmconf later, and that avoids the current nightmare with the whole resource ordering. Of course, if there really are machines that have somehow disabled conf1 accesses, we'd have to use mmconfig early, but that should automatically be handled by the PCI config probing stuff (ie we already test whether conf1 accesses seem to work, and would fall back on alternate config cycle accesses if conf1 looks broken). Right now, the check that MMCONF space has to be in e820-reserved memory space protects us from *most* of the probe-time problems, but that's also obviously the check that actually means that MMCONF isn't actually used on the vast majority of machines out there. (For example: I have three machines that I know have working MMCONF. On only one of theose does Linux actually even enable MMCONF accesses, because on the two other ones the BIOSes do the crazy "put it in some space that is reserved by PnP crap later", so we actually refuse to touch it. So at least in my limited environment, we hardly get any MMCONFIG test coverage, exactly because we have to be so totally anal about not enabling it early, because we cannot guarantee that it's not clashing with anything else). Linus -- 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/