Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755054AbXL1QRn (ORCPT ); Fri, 28 Dec 2007 11:17:43 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754075AbXL1QRe (ORCPT ); Fri, 28 Dec 2007 11:17:34 -0500 Received: from pentafluge.infradead.org ([213.146.154.40]:35892 "EHLO pentafluge.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753936AbXL1QRd (ORCPT ); Fri, 28 Dec 2007 11:17:33 -0500 Date: Fri, 28 Dec 2007 08:14:18 -0800 From: Arjan van de Ven To: Ivan Kokshaysky Cc: Daniel Barkalow , Linus Torvalds , Kai Ruhnau , Loic Prylli , 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 Message-ID: <20071228081418.08b60228@laptopd505.fenrus.org> In-Reply-To: <20071228103451.GA28694@jurassic.park.msu.ru> References: <4773EBB4.2020805@shaw.ca> <477414C9.3040906@myri.com> <47742498.1060900@tragetaschen.dyndns.org> <20071228103451.GA28694@jurassic.park.msu.ru> Organization: Intel X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.1; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1491 Lines: 36 On Fri, 28 Dec 2007 13:34:51 +0300 Ivan Kokshaysky wrote: > On Fri, Dec 28, 2007 at 01:07:09AM -0500, Daniel Barkalow wrote: > > So would always using conf1 for the non-extended space (unless the > > platform only uses mmconfig), or at least for the first 64 bytes. > > I'd bet all the subtle bugs are in the first few words, anyway. > > (With blatant bugs in the rest, of course, where we want to > > blacklist busses and devices) > > Yes. Though limiting conf1 to the first 64 bytes is simply not worth > a pain - we would still have to deal with buses that are unreachable > via mmconf. > > Always using legacy configuration mechanism for the legacy config > space and extended mechanism (mmconf) for the extended config space > is a simple and very logical approach. It's supposed to resolve *all* > known mmconf problems. And it still allows per-device quirks > (tweaking dev->cfg_size). And it does *remove* code, not add anything > new/untested. > it removes code by removing quirks / known not working stuff.. I really don't like it.. sorry. -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org -- 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/