From owner-cvs-all@FreeBSD.ORG Mon Jul 21 20:23:00 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C507237B404 for ; Mon, 21 Jul 2003 20:23:00 -0700 (PDT) Received: from mail.speakeasy.net (mail7.speakeasy.net [216.254.0.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 145EF43FBD for ; Mon, 21 Jul 2003 20:22:59 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 20820 invoked from network); 22 Jul 2003 03:22:58 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 22 Jul 2003 03:22:58 -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 h6M3MuGI041027; Mon, 21 Jul 2003 23:22:56 -0400 (EDT) (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: <20030721144250.B34834@root.org> Date: Mon, 21 Jul 2003 23:23:12 -0400 (EDT) From: John Baldwin To: Nate Lawson cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: RE: cvs commit: src/sys/dev/acpica acpi_ec.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2003 03:23:01 -0000 On 21-Jul-2003 Nate Lawson wrote: > On Mon, 21 Jul 2003, John Baldwin wrote: >> On 21-Jul-2003 Nate Lawson wrote: >> > The sequence with ECDT is: >> > acpi_attach() >> > acpi_ec_ecdt_probe() >> > if ECDT present >> > device_add_child("acpi_ec") >> > device_probe_and_attach() >> > acpi_ec_probe() >> > if ECDT magic set in ivars >> > done >> >> The magic part seems evil. I'm not sure yet of a better way to handle >> that though. > > The reason this was done is that there are two paths for getting resources > about the EC: ECDT and namespace. They can share a common probe/attach > function if we take the same route (ivars) for passing the data to > probe/attach. Since the ivars are zeroed before device_probe() is called > and an already probed ACPI_DEVICE object is extremely unlikely to use the > same magic since it's a pointer to the acpi_ec_devclass, this is a low > risk approach. I understand the reason for the magic approach, I'm just uncomfortable with it. I won't object to it though unless I manage to think of something cleaner. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/