From owner-freebsd-net@FreeBSD.ORG Sun Jan 29 17:32:23 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A25BF106564A; Sun, 29 Jan 2012 17:32:23 +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 17F1B8FC13; Sun, 29 Jan 2012 17:32:22 +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 q0THWHLE044852; Sun, 29 Jan 2012 18:32: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 q0THWHrX044851; Sun, 29 Jan 2012 18:32:17 +0100 (CET) (envelope-from marius) Date: Sun, 29 Jan 2012 18:32:17 +0100 From: Marius Strobl To: Stefan Bethke Message-ID: <20120129173217.GF39861@alchemy.franken.de> References: <0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE@lassitu.de> <20120129001251.7e4cfe83.ray@ddteam.net> <81B88904-6894-4AC3-80F3-2866216E494B@lassitu.de> <20120129153159.GA44362@alchemy.franken.de> <3B5A749B-9553-4152-9441-3F343BA219FB@lassitu.de> <20120129161938.GD39861@alchemy.franken.de> <5785C7EF-B886-459B-911C-870A4594AC4C@lassitu.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5785C7EF-B886-459B-911C-870A4594AC4C@lassitu.de> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Net , Aleksandr Rybalko , Adrian Chadd , Warner Losh , FreeBSD-arch Subject: Re: Ethernet Switch Framework X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 17:32:23 -0000 On Sun, Jan 29, 2012 at 05:21:52PM +0100, Stefan Bethke wrote: > > Am 29.01.2012 um 17:19 schrieb Marius Strobl: > > >>> We really need > >>> to find a proper way of dealing with the constraints of the embedded- > >>> world rather than to sprinkle hacks all over the place. > >> > >> Why is the above is less of a hack than making the ordering in nexus configurable through a hint? > >> > > > > If it's generally true that driver A must be attached before driver > > B as B has a dependency on A than this should be expressed and > > configured in the drivers themselves and not need an extra hint to > > configure it at the runtime of the kernel. > > Except that it is not generally true, but only in specific configurations. Other boards have other combinations of devices. The Atheros family of switches is available both embedded into certain SoC as well as separate silicon. > It still seems to be true to me that as soon as you have a separate MDIO driver that this one needs to be attached before any Ethernet, switch or whatever driver that needs to talk via the MDIO lines of the former. Similarly, if the switch attaches to an MDIO instance directly, that switch would need to be attached before the Ethernet driver (if there is one) that the switch is the MDIO master for (this isn't exactly the problematic arge-case). Multi-pass is per driver module, so if the switch attaches to a "regular" Ethernet driver providing both the MAC and the MDIO master instead, you can leave the default probe order and attach the switch after the Ethernet driver. So for the problematic arge-case you would attach the MDIO driver first (corresponding to the MDIO of arge1), then the switch to the MDIO driver and both arge0 and arge1 in whatever order last. Allowing that one special case to work properly shouldn't interfere with other device combinations as it basically boils down to the presence of a separate MDIO instance. Actually that should also work just fine when the MDIO master sits on the IIC bus as that again would mean that it needs to be attached before a Ethernet or switch driver can use it. Marius