From owner-freebsd-arch@FreeBSD.ORG Thu Dec 11 15:24:13 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9447816A4CE; Thu, 11 Dec 2003 15:24:13 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id E003C43D37; Thu, 11 Dec 2003 15:24:10 -0800 (PST) (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 hBBNO85h010510; Thu, 11 Dec 2003 16:24:08 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 11 Dec 2003 16:21:19 -0700 (MST) Message-Id: <20031211.162119.128604849.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <20031211145311.Q51054@root.org> References: <20031211145311.Q51054@root.org> X-Mailer: Mew version 2.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: Common device driver classes? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2003 23:24:13 -0000 In message: <20031211145311.Q51054@root.org> Nate Lawson writes: : This leaves my second question, which is how to make multiple hw-dependent : drivers that implement the same interface (sysctls) such that if one : probes ok, others of the same "type" don't attach. For instance, there : are multiple ways to control the Centrino -- both SpeedStep and ACPI : performance states. However, if the speedstep driver has attached, it : should supersede the ACPI driver since it offers more hw-aware control. acpi driver's probe returns -100, speedstep returns -10. attach routine does the dynamic sysctl creation, detach does the destroy. Only one of the attach routines will get called. This is exactly the same as the pci and the acpi pci goo. : So each CPU should have exactly one cpufreq driver attached and the one : that provides the best control. Warner suggested making a bus driver for : cpufreq that attaches to the "winner" of the probe and provides the : generic interface like this: cpu freq bus not needed, since all the frequency things would attach to a cpu. : Is that how miibus works? Is that an appropriate approach here? Yes and I don't think so. miibus has lots of upstream attachments, which isn't the case here. : One : issue is that other systems in the kernel will need a generic way to : control the cpu. For instance, passive cooling by acpi_thermal needs to : be able to use the cpufreq0 interface (through devclass_get_device) to : find what clock rates are available and adjust the clock rate without : caring about the underlying hardware. Advice on the above approach is : welcome. Sounds like a .m interface to me, but your milage may vary. Warner