Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755171AbXLWFKK (ORCPT ); Sun, 23 Dec 2007 00:10:10 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750815AbXLWFJ6 (ORCPT ); Sun, 23 Dec 2007 00:09:58 -0500 Received: from srv5.dvmed.net ([207.36.208.214]:47846 "EHLO mail.dvmed.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750777AbXLWFJ5 (ORCPT ); Sun, 23 Dec 2007 00:09:57 -0500 Message-ID: <476DED9D.7070604@garzik.org> Date: Sun, 23 Dec 2007 00:09:49 -0500 From: Jeff Garzik User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Linus Torvalds CC: 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: <20071222043139.0cd59804@laptopd505.fenrus.org> <476D1D16.5090703@garzik.org> <20071222064719.73fdd9a4@laptopd505.fenrus.org> <476DB95F.3090801@garzik.org> <476DDFEE.3010009@garzik.org> <476DE98F.2010009@garzik.org> 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: 1425 Lines: 43 Linus Torvalds wrote: > > On Sat, 22 Dec 2007, Jeff Garzik wrote: >> But regardless of problems, enabling should be done globally, not per >> device... > > I'm ok with trying the "globally" idea, but it has to be "globally but > only if absolutely required". > > And quite frankly, how do you tell whether it's absolutely required or > not? > > I have an idea: the drivers that really need it will do a "please enable > MMCONFIG, because I will need it" thing? > > Ok? > > And then, since we *need* such a "pci_enable_mmconfig()" call anyway, why > not let the driver give which device it controls too, so that we can print > out the information (in case the machine then hangs immediately > afterwards), and perhaps - if it is shown to help - only do the MMCONFIG > cycles for that particular device? > > Sounds like a plan? As long as pci_enable_ext_cfg_space(pdev) enables extended accesses for -all- devices, the plan is mostly sound. That largely eliminates the inconsistency issue. The only thing I would worry about is whether "config space suddenly grew larger" condition will confuse userspace -- but that is NOT an objection, just a worry. 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/