From owner-freebsd-arch@FreeBSD.ORG Sat Jan 21 04:34:40 2012
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
by hub.freebsd.org (Postfix) with ESMTP id 9F39D1065670
for <freebsd-arch@freebsd.org>; Sat, 21 Jan 2012 04:34:40 +0000 (UTC)
(envelope-from gonzo@hq.bluezbox.com)
Received: from hq.bluezbox.com (hq.bluezbox.com [70.38.37.145])
by mx1.freebsd.org (Postfix) with ESMTP id 2A9998FC17
for <freebsd-arch@freebsd.org>; Sat, 21 Jan 2012 04:34:39 +0000 (UTC)
Received: from localhost ([127.0.0.1])
by hq.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256)
(Exim 4.73 (FreeBSD)) (envelope-from <gonzo@hq.bluezbox.com>)
id 1RoSKD-0005Sm-D6; Fri, 20 Jan 2012 20:13:11 -0800
Message-ID: <4F1A3B58.7040001@freebsd.org>
Date: Fri, 20 Jan 2012 20:13:12 -0800
From: Oleksandr Tymoshenko <gonzo@freebsd.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1;
rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: freebsd-arch@freebsd.org, Ben Gray <ben.r.gray@gmail.com>
References: <8D025847-4BE4-4B2C-87D7-97E72CC9D325@lassitu.de>
<20120104215930.GM90831@alchemy.franken.de>
<47ABA638-7E08-4350-A03C-3D4A23BF2D7E@lassitu.de>
<1763C3FF-1EA0-4DC0-891D-63816EBF4A04@lassitu.de>
<20120106182756.GA88161@alchemy.franken.de>
<95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de>
<20120106214741.GB88161@alchemy.franken.de>
<F60B2B70-049F-4497-BBA8-3C421088C1EA@lassitu.de>
<20120108130039.GG88161@alchemy.franken.de>
<23477898-8D85-498C-8E30-192810BD68A8@lassitu.de>
<20120111193738.GB44286@alchemy.franken.de>
<66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de>
<8EF24110-C985-400F-ADDF-B1D63C4E304B@bsdimp.com>
In-Reply-To: <8EF24110-C985-400F-ADDF-B1D63C4E304B@bsdimp.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: gonzo@hq.bluezbox.com
X-Spam-Level: ----
X-Spam-Report: Spam detection software, running on the system "hq.bluezbox.com",
has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or
label similar future email. If you have any questions, see
The administrator of that system for details.
Content preview: On 20/01/2012 5:43 PM,
Warner Losh wrote: > > On Jan 20, 2012, at 5:08 PM,
Stefan Bethke wrote: >> The second problem is that there's currently
no way to express a dependency between two devices other than a
parent-child
relationship. I would be interested to learn why this appears to be so
uncommon
that I could not find any discussion of such a feature. Has it really
never
before come up? > > Sure there is: you can do it by name. I wrote a
driver that attached to the ISA bus,
but also needed to talk to the ppbus that was
attached to the printer. My solution was to have a post-attach
name-lookup
so that it could then call methods on the other driver's device_t. I
wonder why we can't do that here? [...]
Content analysis details: (-4.4 points, 5.0 required)
pts rule name description
---- ----------------------
--------------------------------------------------
-1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP
-2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1%
[score: 0.0000]
0.0 AWL AWL: From: address is in the auto white-list
Cc:
Subject: Re: Extending sys/dev/mii
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Jan 2012 04:34:40 -0000
On 20/01/2012 5:43 PM, Warner Losh wrote:
>
> On Jan 20, 2012, at 5:08 PM, Stefan Bethke wrote:
>> The second problem is that there's currently no way to express a dependency between two devices other than a parent-child relationship. I would be interested to learn why this appears to be so uncommon that I could not find any discussion of such a feature. Has it really never before come up?
>
> Sure there is: you can do it by name. I wrote a driver that attached to the ISA bus, but also needed to talk to the ppbus that was attached to the printer. My solution was to have a post-attach name-lookup so that it could then call methods on the other driver's device_t. I wonder why we can't do that here?
I've been thinking about it recently in regard to GPIO subsystem.
And the same issue appeared during OMAP code import: there are at least
two subsystems that are used by the rest of the drivers. Ben's suggested
following solution: define kobj interface if_SUBSYTEM.m and then
provide API call in form:
int omap_prcm_clk_enable(clk_ident_t clk)
{
device_t prcm_dev;
prcm_dev = devclass_get_device(devclass_find("omap_prcm"), 0);
if (prcm_dev == NULL) {
printf("Error: failed to get the PRCM device\n");
return (EINVAL);
}
return OMAP_PRCM_CLK_ENABLE(prcm_dev, clk);
}
So it might make sense to create some kind of upper-level API for
defining this kind of subsystems' APIs since every implementation
would duplicate a lot of code: look for instance of specific
devclass, check if it exists. Not sure how to do it at the moment
though.