From owner-freebsd-current@FreeBSD.ORG Fri Jul 6 20:46:03 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4174E106566B; Fri, 6 Jul 2012 20:46:03 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 960758FC08; Fri, 6 Jul 2012 20:46:02 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so9517061wgb.31 for ; Fri, 06 Jul 2012 13:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QAYZapSJexHMMVubfb7Go0srs3GpVg9RSlurht4Qmhc=; b=rcATSVVSqkcQXA3GPU1tUSYXULmmzJ8miq20NAk1Q1sxRHPE9oIHUmyK84dSU5RD1n Ymlhuc8xHNq8DA/qxj8RNXYSjxPC7N5u27PzIK/H7FZJiuDTJ0A4H39BadIs/SstTxjy 3mCqPyBHGhhsL5884czXJadLBnLw0lbk621ctVUJCeI1VbYF/9wZaxZ6PK6420gLGV2j A7o4nDfIJ5qitd4456mB83UBO8U4Y9Al9t1tDVlhFDFuk3FidXrmi4raQYuraM0IRI8T iE5zJT+4yJndkR3vzysotsIofo5P5w85qRKXuFm4q8mZK9BuKx3CbjUbJmWojWqsXY0z fMsQ== MIME-Version: 1.0 Received: by 10.181.13.142 with SMTP id ey14mr10401225wid.19.1341607555784; Fri, 06 Jul 2012 13:45:55 -0700 (PDT) Received: by 10.216.23.200 with HTTP; Fri, 6 Jul 2012 13:45:55 -0700 (PDT) In-Reply-To: <1341601751.70246.7.camel@revolution.hippie.lan> References: <1341601751.70246.7.camel@revolution.hippie.lan> Date: Fri, 6 Jul 2012 16:45:55 -0400 Message-ID: From: Arnaud Lacombe To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: Interfacing devices with multiple parents within newbus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 20:46:03 -0000 Hi, On Fri, Jul 6, 2012 at 3:09 PM, Ian Lepore wrote: > 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. > actually, I think I was wrong, I thought device were attached to a devclass, but they are truly attached to a given device. My mistake. > 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. > AFAIR, rman is mostly there to manage memory vs. i/o mapped resources. The more I think about it, the more FTD is the answer. The open question now being "how to map a flexible device structure (FTD) to a less flexible structure (Newbus)" :/ - Arnaud