From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 20:43:39 2007 Return-Path: Delivered-To: embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B3CD16A417 for ; Fri, 28 Dec 2007 20:43:39 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id A3F3C13C45A for ; Fri, 28 Dec 2007 20:43:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBSKb6Ns076818; Fri, 28 Dec 2007 13:37:09 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 28 Dec 2007 13:41:54 -0700 (MST) Message-Id: <20071228.134154.1136083975.imp@bsdimp.com> To: marcelm@juniper.net From: "M. Warner Losh" In-Reply-To: <595F307F-8FC5-48D5-A69C-84660A768F23@juniper.net> References: <20071228.125020.-1962668065.imp@bsdimp.com> <595F307F-8FC5-48D5-A69C-84660A768F23@juniper.net> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: embedded@FreeBSD.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 20:43:39 -0000 In message: <595F307F-8FC5-48D5-A69C-84660A768F23@juniper.net> Marcel Moolenaar writes: : : On Dec 28, 2007, at 11:50 AM, M. Warner Losh wrote: : : > : Existing drivers that only check DEVTYPE (which I'm sure : > : we'll start with) will have to check DEVCLASS as well if : > : there's going to be variation within DEVTYPE. : > : > Are there existing drivers right now? : : The e500 port uses ocpbus(4) and if we make it generic, : I can merge it into CVS independently of the e500 code : itself. True. : > FreeBSD has two models for device enumeration. One is where the : > parent bus decides, by whatever means, and one where the device itself : > has enough information to allow the driver to decide. I think that : > trying to shoe-horn the second model into a situation where the first : > model is actually better would be a disservice. : : When would the first be better? When there's no information about the children in the children. For example, pure ISA bus one must have an external enumeration. Likewise for devices on a SPI bus, a SSC bus or an I2C bus. These "busses" are impossible to enumerate through any method other than some kind of table that's supplied externally. In these cases, you cannot probe the device at all. In many cases, one can't touch the hardware at all in a reliable way to determine if it is there or not without potentially disrupting other devices on the bus. Unlike PCI, in this domain these devices don't have a device ID. What we do with them is use the hints mechanism to wire devices on the bus to addresses on the bus (if applicable). Since this is text based on the driver name, the actual bus has no special knowledge of the devices that can be on the bus. The text name is passed through more or less directly to newbus, which does the right thing. If there's a driver of that name, then it uses it. Otherwise the device is ignored. With an enumeration like you suggest, one would need to create an enumeration for each and every one of these things, compile it into the kernel and then have some kind of translation layer that we get for free today with newbus and bus_enumerate_hinted_bus(). Warner