Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751392AbWJMRIs (ORCPT ); Fri, 13 Oct 2006 13:08:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751394AbWJMRIs (ORCPT ); Fri, 13 Oct 2006 13:08:48 -0400 Received: from outpipe-village-512-1.bc.nu ([81.2.110.250]:9619 "EHLO lxorguk.ukuu.org.uk") by vger.kernel.org with ESMTP id S1751392AbWJMRIr (ORCPT ); Fri, 13 Oct 2006 13:08:47 -0400 Subject: Re: [linux-pm] Bug in PCI core From: Alan Cox To: Matthew Wilcox Cc: Adam Belay , Arjan van de Ven , Alan Stern , Benjamin Herrenschmidt , Greg KH , linux-pci@atrey.karlin.mff.cuni.cz, Linux-pm mailing list , Kernel development list In-Reply-To: <20061013164933.GD11633@parisc-linux.org> References: <1160753187.25218.52.camel@localhost.localdomain> <1160753390.3000.494.camel@laptopd505.fenrus.org> <1160755562.25218.60.camel@localhost.localdomain> <1160757260.26091.115.camel@localhost.localdomain> <1160759349.25218.62.camel@localhost.localdomain> <20061013164933.GD11633@parisc-linux.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 13 Oct 2006 18:34:27 +0100 Message-Id: <1160760867.25218.77.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1725 Lines: 44 Ar Gwe, 2006-10-13 am 10:49 -0600, ysgrifennodd Matthew Wilcox: > No it didn't. It's undefined behaviour to perform *any* PCI config > access to the device while it's doing a D-state transition. It may have I think you missed the earlier parts of the story - the kernel caches the base config register state. > happened to work with the chips you tried it with, but more likely you > never hit that window because X simply didn't try to do that. Which is why the kernel caches the register state. This all came up long ago and the solution we currently have was the one chosen after considerable debate and analysis about things like locking. We preserved the historical reliable interface going back to the early Linux PCI support and used by all the apps. There are several problems with making it return an error - What does user space do ? while(pci_...() == -EAGAIN) yield(); which is useful how - there is no select operation for waiting here, and while it could be added it just gets uglier - Who actually wants to get an error in that specific case ? If you can find someone who desperately wants an error code then code in O_DIRECT support to do it and preserve the existing sane API. The job of the kernel is not to expose hardware directly, it is to provide sane interfaces to it. We don't have separate interfaces to conf1, conf2, pcibios etc for good reason. Exposing everyone to ugly minor details of the PCI transition handling isn't progress. Alan - 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/