Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755283AbXLXHbe (ORCPT ); Mon, 24 Dec 2007 02:31:34 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751738AbXLXHbZ (ORCPT ); Mon, 24 Dec 2007 02:31:25 -0500 Received: from srv5.dvmed.net ([207.36.208.214]:40054 "EHLO mail.dvmed.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751550AbXLXHbY (ORCPT ); Mon, 24 Dec 2007 02:31:24 -0500 Message-ID: <476F6047.50100@garzik.org> Date: Mon, 24 Dec 2007 02:31:19 -0500 From: Jeff Garzik User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Linus Torvalds CC: Ivan Kokshaysky , 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 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) X-Spam-Report: SpamAssassin version 3.1.9 on srv5.dvmed.net summary: Content analysis details: (-4.4 points, 5.0 required) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1250 Lines: 33 Linus Torvalds wrote: > (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). Definitely. So, two questions: What's the preferred way to deal with the desire to view extended config space with "lspci -vvvxxx"? Right now, we enable mmconfig for the bus/domain range requested by the BIOS [heh, so by implication many early BIOSen stomp themselves]. Is there a path for hw vendors, after passing 1,001 anal checks, to maintain the current behavior as it exists today in arch/x86/pci/mmconfig_{32,64}.c? Jeff -- 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/