From owner-cvs-src@FreeBSD.ORG Fri May 21 07:22:01 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC0E616A4CE; Fri, 21 May 2004 07:22:01 -0700 (PDT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0474643D46; Fri, 21 May 2004 07:22:01 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i4LEK5fB045368; Fri, 21 May 2004 08:20:05 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 21 May 2004 08:20:06 -0600 (MDT) Message-Id: <20040521.082006.70223536.imp@bsdimp.com> To: bms@spc.org From: "M. Warner Losh" In-Reply-To: <20040521134038.GE90068@empiric.dek.spc.org> References: <20040521.020412.118756775.imp@bsdimp.com> <40ADBC15.6040004@freebsd.org> <20040521134038.GE90068@empiric.dek.spc.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: scottl@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/pci pci.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2004 14:22:01 -0000 In message: <20040521134038.GE90068@empiric.dek.spc.org> Bruce M Simpson writes: : On Fri, May 21, 2004 at 02:21:41AM -0600, Scott Long wrote: : > Well, the 8.3.3 paragraph only specifically mentions the command : > register and the BARs. I'm just worried that by touching stuff outside : > of this range that you open up the risk of tickling latent buggy : > silicon. Exception cases like the ATA hardware doing magic things with : > the progif register should be left up to the ATA driver. It's exactly : > those kinds of bent-rules that makes me nervous =-) This isn't ata specific. That was just the example that made me think of updating the cache and saving/restoring those registers. I can understand that it makes you nervous, but I don't think we'll find any silicon that's that brain damaged given that the standard specifically says that writes to read-only registered must succeed (although it says so in a round about way). Also, it specifically said 'but not limited to' which implies more needs to be done. : Maybe this behaviour could be enabled or disabled with an instance variable? : I can think of one example of hardware which might need this. I owned an : IBM ThinkPad T22 with an xl(4) NIC for about a year, and one of the things : which annoyed me about suspend/resume was the tendency for it to lose its : PCI configuration. No. That's even worse. The code is going to be uniform accross all devices until someone can produce a legitimate example of a real device that breaks and that we care about supporting. The linux code and the Windows code I'm told, behaves in a similar manner to what we're doing. All I added was a few more registers that we save/restore that are defined in the spec. Having said all that, I'm still contemplating not doing the vendor/subvendor registers. Warner