From owner-freebsd-arch@FreeBSD.ORG Wed Jan 25 23:22:06 2012 Return-Path: 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 C2D0E106566C for ; Wed, 25 Jan 2012 23:22:06 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 554C48FC0C for ; Wed, 25 Jan 2012 23:22:05 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q0PNM16Q018453; Thu, 26 Jan 2012 00:22:01 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q0PNM13M018452; Thu, 26 Jan 2012 00:22:01 +0100 (CET) (envelope-from marius) Date: Thu, 26 Jan 2012 00:22:01 +0100 From: Marius Strobl To: Warner Losh Message-ID: <20120125232201.GP44286@alchemy.franken.de> References: <20120106182756.GA88161@alchemy.franken.de> <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> <20120106214741.GB88161@alchemy.franken.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> <20120125221753.GA17821@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Stefan Bethke , FreeBSD-arch 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 23:22:06 -0000 On Wed, Jan 25, 2012 at 03:28:38PM -0700, Warner Losh wrote: > > On Jan 25, 2012, at 3:17 PM, Marius Strobl wrote: > > Yes, architecture of newbus is built around the assumption that > > there's a single device tree and all you ever need are child- > > parent-relationships. AFAICT this assumption dates back to at > > least the device configuration in 4.4BSD and apart from the > > embedded world it held true just fine so far ... > > Even in the embedded world it is true. The problem is that in the embedded world multiple devices use the service of another device which is why we're seeing teething pain with the MDIO bus (which shares all the management lines between the PHY rather than having each MAC have its own connection to the PHY). So while the basic resources are still hierarchical, the interconnects have become more complicated. The issue we're facing here is that we'd assumed that the MAC PHY connection could provide management services since you knew you had to have data services or else you'd have no packet flow... > > We're seeing the same struggles with gpio and interrupt pins... > Hrm, is there a proper solution to this? Could resource-multiplexers ala puc(4) that are attached before all their consumers via multi- pass be one? Marius