Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755227AbXL1Fdf (ORCPT ); Fri, 28 Dec 2007 00:33:35 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751056AbXL1Fd1 (ORCPT ); Fri, 28 Dec 2007 00:33:27 -0500 Received: from smtp2.linux-foundation.org ([207.189.120.14]:33934 "EHLO smtp2.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750762AbXL1Fd0 (ORCPT ); Fri, 28 Dec 2007 00:33:26 -0500 Date: Thu, 27 Dec 2007 21:32:30 -0800 (PST) From: Linus Torvalds To: Daniel Barkalow cc: Kai Ruhnau , Loic Prylli , Robert Hancock , Jeff Garzik , Arjan van de Ven , 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 In-Reply-To: Message-ID: References: <4773EBB4.2020805@shaw.ca> <477414C9.3040906@myri.com> <47742498.1060900@tragetaschen.dyndns.org> 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: 1636 Lines: 34 On Thu, 27 Dec 2007, Daniel Barkalow wrote: > > I'd actually bet that the hardware bug is actually that any device that > gives a CRS response the first time will have its Vendor ID appear as 0001 > on subsequent mmconfig accesses, which means that it's actually a bus > quirk that probably only affects mmconfig access to something in the > conf1-visible space. The only per-device aspect would be that it uses CRS > (possibly correctly), and that doesn't mean that mmconfig won't be safe in > general for the device, or even that it won't be necessary. Actually, we > already know that per-driver enabling mmconfig is broken: sky2 is one that > wants to opt in but there are also reports of the Vendor ID 0001 bug with > it. Actually, having it be a per-device thing would have fixed this particular problem, if only because the device probing would have been done without MMCONFIG (thus avoiding the bug), and then after it has been probed, it wouldn't have mattered if the driver enabled MMCONFIG for the device, since it would now have the right ID in "struct pci_device". Sure, subsequent "lspci" users would still be confused, but the kernel itself would never have noticed anything strange. Of course, just doing *all* initial probing without MMCONFIG would also have fixed it, which is another thing I advocate (regardless of any per-device setting). 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/