From owner-cvs-src@FreeBSD.ORG Fri Apr 9 13:54:13 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 ED8CA16A4CF; Fri, 9 Apr 2004 13:54:12 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8633343D39; Fri, 9 Apr 2004 13:54:12 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i39KsBkj044380; Fri, 9 Apr 2004 14:54:11 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 09 Apr 2004 14:54:52 -0600 (MDT) Message-Id: <20040409.145452.24901640.imp@bsdimp.com> To: scottl@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20040409.103449.122315793.imp@bsdimp.com> References: <200404091544.i39FiYDY061986@repoman.freebsd.org> <4076CE28.1020705@freebsd.org> <20040409.103449.122315793.imp@bsdimp.com> 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: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/pci pci.c pci_pci.c pci_private.h src/sys/dev/acpica acpi_pci.c acpi_pcib_acpi.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, 09 Apr 2004 20:54:13 -0000 : : I'm really really uncomfortable with the part of this that does the : : power state changes. It's going to require a _lot_ of testing with as : : much hardware as we all can get our hands on. It will be an interesting : : experiment =-) : : Yes. I agree witht he power state changes being risky. That's why : I'm committing them now rather than in 4 months so that we can get : some milage on -current with it. If it is really bad, we can back off : that part of the change, or refine it to overcome the problems. Also, the power state changes should typically be no-ops (no cycles to hardware) since all that's added in the 'typical' case that I've seen is D0->D3 for some devices w/o drivers. This may impact kldload/kldunload of drivers, however, and there are several laptops that power up all their pci devices in D3 state which may see them turned on and off where before they stated off. On resume, we now set the state do D0 (obsoleting hundreds of lines of driver code, but I've not yet removed that code from the tree). So it isn't as huge a change as the change made it sound. However, even having said that, I agree that we may find it causes issues. Warner