From owner-freebsd-arch@FreeBSD.ORG Sun Jan 29 22:13:19 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 C01AF1065787; Sun, 29 Jan 2012 22:13:19 +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 321A58FC17; Sun, 29 Jan 2012 22:13:18 +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 q0TMDGq3046343; Sun, 29 Jan 2012 23:13:17 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q0TMDGhq046342; Sun, 29 Jan 2012 23:13:16 +0100 (CET) (envelope-from marius) Date: Sun, 29 Jan 2012 23:13:16 +0100 From: Marius Strobl To: Adrian Chadd Message-ID: <20120129221316.GG39861@alchemy.franken.de> References: <20120122195130.360261ce.ray@freebsd.org> <0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE@lassitu.de> <20120129001251.7e4cfe83.ray@ddteam.net> <81B88904-6894-4AC3-80F3-2866216E494B@lassitu.de> <20120129153159.GA44362@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: FreeBSD Net , Aleksandr Rybalko , Stefan Bethke , FreeBSD-arch Subject: Re: Ethernet Switch Framework 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: Sun, 29 Jan 2012 22:13:19 -0000 On Sun, Jan 29, 2012 at 11:00:22AM -0800, Adrian Chadd wrote: > I think for switches, that doesn't necessarily hold. Err, what exactly doesn't hold? The suggestion about using multi-pass probing was just for the case when there's a separate MDIO master other drivers depend on. The latter would just use the default ordering (unless there are again ordering constraints whithin them). So if there's no separate MDIO master driver invovled that is attached first, the other drivers would still just be attached in the default ordering. > > ie, mii_attach() for single-PHY devices may work that way, but the weird What way? > and wonderful world of embedded switch SoC's doesn't. You're lucky in most > instances since the bootloader does give you a mostly-working switch > config. But I doubt that's a guarantee on all platforms. > > So for those (ethernet) devices, splitting out the mii/mdio stuff and _not_ > necessarily presenting a working PHY may be acceptable. For now it's going If there isn't a single working PHY, why would one want to attach miibus(4) in the first place? What is about the opposite case, when all you have is a MDIO master and a switch connected to it, but no MAC on the MII lines of the switch? > to be a subset, to having it export an MDIO bus and doing late MII > attachment may not be as architecturally "no-no" as I interpret your post. > Originally, Stefan said that he wants to find a way to support all the odd combinations found in the embedded-world and I try to come up with model that is able to do that without needing hacks and hints left and right. As imp@ said, interrupt controllers and GPIO basically suffer the same dependency constraints across otherwise unrelated devices there, so we really should find a way to properly deal with that situation without again needing another set of hacks and hints in other types of drivers. As for MDIO you actually can have another layer of dependencies between MDIO master, Ethernet switch and PHY, f.e. at work we use a single MDIO master and switch it to different slave busses using a multiplexer managed via GPIO ... not that I'd ever wanted to support this via generic means in FreeBSD. Marius