From owner-p4-projects@FreeBSD.ORG Tue Dec 9 10:44:32 2003 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id B368E16A4D0; Tue, 9 Dec 2003 10:44:31 -0800 (PST) Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BE9416A4CE for ; Tue, 9 Dec 2003 10:44:31 -0800 (PST) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CA3443D21 for ; Tue, 9 Dec 2003 10:44:30 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 3022 invoked from network); 9 Dec 2003 18:44:28 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 9 Dec 2003 18:44:28 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id hB9IiPie069349; Tue, 9 Dec 2003 13:44:25 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20031208.175500.36934037.imp@bsdimp.com> Date: Tue, 09 Dec 2003 13:44:26 -0500 (EST) From: John Baldwin To: "M. Warner Losh" X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: perforce@freebsd.org cc: nate@root.org Subject: Re: PERFORCE change 43464 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2003 18:44:32 -0000 On 09-Dec-2003 M. Warner Losh wrote: > In message: > John Baldwin writes: >: >: On 05-Dec-2003 Nate Lawson wrote: >: > On Fri, 5 Dec 2003, John Baldwin wrote: >: >> Change 43464 by jhb@jhb_blue on 2003/12/05 12:59:01 >: >> >: >> More updates. Closer to working than I thought. In theory >: >> PCI devices should all just work now. >: > >: > This handles PCI. Are you ok with me adding the call to >: > acpi_pwr_switch_consumer() for non-PCI devices like the embedded >: > controller? I think we need to do this at the top \\_SB level. I'm a bit >: > confused as to the handoff between the general tree walk and the ACPI-PCI >: > driver though. >: >: It won't hurt to switch a device on twice. It should be ok to >: do a top-level tree walk of all device objects and turn them on >: before probing child devices I think. ACPI shouldn't turn off >: devices that don't probe like PCI does though because ACPI has >: duplicate objects of things like the entire PCI device tree. :-/ > > Actually, there can be times when you don't want to turn on devices at > all. Walking the whole tree turning them on might be the wrong to > do... > > Sometimes I think that things in the newbus tree should have a pointer > to the acpi power methods that are used in coordination with the bus > code that is 'activating' the device before the 'probe' and 'attach' > happens. I think having a 'bus_set_power_state()' method in the bus layer and having device_probe_and_attach() do 'bus_set_power_state(child, ON)' would be sufficient. ACPI busses would then perform the correct hooks via their bus_set_power_state() methods. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/