Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755552AbXL1Rmt (ORCPT ); Fri, 28 Dec 2007 12:42:49 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753159AbXL1Rml (ORCPT ); Fri, 28 Dec 2007 12:42:41 -0500 Received: from mailbox2.myri.com ([64.172.73.26]:1882 "EHLO myri.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752969AbXL1Rmk (ORCPT ); Fri, 28 Dec 2007 12:42:40 -0500 Message-ID: <47753525.3010701@myri.com> Date: Fri, 28 Dec 2007 12:40:53 -0500 From: Loic Prylli User-Agent: Thunderbird/2.0.0.4 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Ivan Kokshaysky CC: Arjan van de Ven , Daniel Barkalow , Linus Torvalds , Kai Ruhnau , Robert Hancock , Jeff Garzik , Linux Kernel Mailing List , gregkh@suse.de, linux-pci , Benjamin Herrenschmidt , Martin Mares , Matthew Wilcox Subject: Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in References: <477414C9.3040906@myri.com> <47742498.1060900@tragetaschen.dyndns.org> <20071228103451.GA28694@jurassic.park.msu.ru> <20071228081418.08b60228@laptopd505.fenrus.org> <20071228163841.GA9409@jurassic.park.msu.ru> In-Reply-To: <20071228163841.GA9409@jurassic.park.msu.ru> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2155 Lines: 59 On 12/28/2007 11:38 AM, Ivan Kokshaysky wrote: > On Fri, Dec 28, 2007 at 08:14:18AM -0800, Arjan van de Ven wrote: > >> it removes code by removing quirks / known not working stuff.. >> > > The only quirk I see removed is a bitmap with an arbitrary size (that we don't really know is sufficient for every system), and that is only built using comparison between mmconf and type1 accesses. IMHO, there is zero knowledge in that removed code (no knowledge about specific chipsets that work or don't work, or misleading BIOSes). > This not working stuff gets detected at probe time - see > drivers/pci/probe.c:pci_cfg_space_size(). > This indeed avoids most mmconf invalid attempts (for extended-conf-space probing that goes through pci_find_ext_capability() or from user-space). One could think of adding a cfg_size check in pci_read_config_{read/write), but IMHO that would be useless, since direct read/write into a known extended-conf-space register in the extended-config-space can only happen for a pci-express device, and there is ample evidence that such accesses always work (more exactly MCFG can always be trusted for pcie devices). One thing that could be changed in pci_cfg_space_size() is to avoid making a special case for PCI-X 266MHz/533Mhz (assume cfg_size == 256 for such devices too, reserve extended cfg-space for pci-express devices). There is good reasons to think no such PCI-X 266Mhz/533 device will ever have an extended-space (no capability IDs was ever defined in the PCI-X 2.0 spec, no new revision is planned). Such a check would avoid the possibility of trying extended-conf-space access for PCI-X 2.0 devices behind a amd-8132 or similar (such accesses would just returnd -1, but there was some objections raised about doing anything like that other than at initialization time, even if there is ample reasons to argue it would be harmless). Loic -- 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/