From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 6 19:09:20 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 43B061065670 for ; Fri, 6 Jul 2012 19:09:20 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 22EFF8FC14 for ; Fri, 6 Jul 2012 19:09:20 +0000 (UTC) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta01.emeryville.ca.mail.comcast.net with comcast id X50f1j0061wfjNsA179EGK; Fri, 06 Jul 2012 19:09:14 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta23.emeryville.ca.mail.comcast.net with comcast id X79C1j00c4NgCEG8j79DN0; Fri, 06 Jul 2012 19:09:13 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q66J9BUD008889; Fri, 6 Jul 2012 13:09:11 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Arnaud Lacombe In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Fri, 06 Jul 2012 13:09:11 -0600 Message-ID: <1341601751.70246.7.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: Interfacing devices with multiple parents within newbus X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 19:09:20 -0000 On Fri, 2012-07-06 at 14:46 -0400, Arnaud Lacombe wrote: > Hi, > > On Fri, Jul 6, 2012 at 11:33 AM, Arnaud Lacombe wrote: > > That's neither correct nor robust in a couple of way: > > 1) you have no guarantee a device unit will always give you the same resource. > this raises the following question: how can a device, today, figure > out which parent in a given devclass would give it access to resources > it needs. > > Say, you have gpiobus0 provided by a superio and gpiobus1 provided by > the chipset and a LED on the chipset's GPIO. Now, say gpiobus0 > attachment is conditional to some BIOS setting. How can you tell > gpioled(4) to attach on the chipset provided GPIO without hardcoding > unit number either way ? > > AFAIK, you can not. > > Even hints provided layout description is defeated. Each device in a > given devclass need to have a set of unique attribute to allow a child > to distinguish it from other potential parent in the same devclass... > > - Arnaud Talking about a child being unable to choose the correct parent seems to indicate that this whole problem is turned upside-down somehow; children don't choose their parents. Just blue-sky dreaming here on the fly... what we really have is a resource-management problem. A device comes along that needs a GPIO resource, how does it find and use that resource? Well, we have a resource manager, could that help somehow? Could a driver that provides access to GPIO somehow register its availability so that another driver can find and access it? The "resource" may be a callable interface, it doesn't really matter, I'm just wondering if the current rman stuff could be leveraged to help make the connection between unrelated devices. I think that implies that there would have to be something near the root of the hiearchy willing to be the owner/manager of dynamic resources. -- Ian