From owner-freebsd-net@FreeBSD.ORG Sun Jan 29 13:14:44 2012 Return-Path: <owner-freebsd-net@FreeBSD.ORG> 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 804E51065672; Sun, 29 Jan 2012 13:14:44 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 3930A8FC0A; Sun, 29 Jan 2012 13:14:44 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id EE9D827A42; Sun, 29 Jan 2012 13:14:42 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke <stb@lassitu.de> In-Reply-To: <DBAB0C5C-5B2D-4430-8096-9E4DC7233961@bsdimp.com> Date: Sun, 29 Jan 2012 14:14:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <81B88904-6894-4AC3-80F3-2866216E494B@lassitu.de> References: <20120120221319.ca8b631f.ray@freebsd.org> <30A45A1E-CA13-4AC8-86FB-F8E06301D1F6@lassitu.de> <20120122195130.360261ce.ray@freebsd.org> <CAJ-VmokTh2q0ZH=kwU6GzJm5Mr4k7geJiFsoX_A9hcLhMZNxsg@mail.gmail.com> <0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE@lassitu.de> <CAJ-Vmo=GRKRf+YsFqNm9d_T3Tq583uV_pabMV6ozuaytSRLivg@mail.gmail.com> <20120129001251.7e4cfe83.ray@ddteam.net> <CACVs6=-U9rr7cpeJ+VUgP3Xq1yRB=Xk1GjuzEOuXiEUoqGFq_Q@mail.gmail.com> <DBAB0C5C-5B2D-4430-8096-9E4DC7233961@bsdimp.com> To: Warner Losh <imp@bsdimp.com> X-Mailer: Apple Mail (2.1251.1) Cc: FreeBSD Net <freebsd-net@FreeBSD.org>, Aleksandr Rybalko <ray@ddteam.net>, Adrian Chadd <adrian@FreeBSD.org>, FreeBSD-arch <freebsd-arch@FreeBSD.org> 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 <freebsd-net.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>, <mailto:freebsd-net-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net> List-Post: <mailto:freebsd-net@freebsd.org> List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>, <mailto:freebsd-net-request@freebsd.org?subject=subscribe> X-List-Received-Date: Sun, 29 Jan 2012 13:14:44 -0000 Am 29.01.2012 um 08:05 schrieb Warner Losh: > I think that the main issue here is that we have an assumption that we = have a tree structure. However, it is more of a DAG across different = domains. The hierarchy works well when each device owns all the devices = below it and only interacted with them. Most devices are that way. = However, in the embedded world, there's lots of reach-accrosses that are = expected that break the model. What do people think would be a good approach to solve the concrete = issue without too much hackery? Aleksandr and I have presented three = possible approaches: 1. have a PHY driver that acts as a proxy and talks to a separate MDIO = master 2. have a proxy between the ethernet driver and the miibus driver 3. modify miibus to have a separate device for mediachg() etc. All three suffer from a dependency problem: miibus attachment can only = complete successfully when both the ethernet driver and the mdio driver = have been attached. In the current model, the ethernet driver provides = both the MDIO access as well as the target for the mediachg, etc. = messages, so there's no attachment ordering issue. In my miiproxy patch (2.), it is necessary for the ethernet driver to = cooperate in this delayed attachment, by splitting out the miibus = attachment from the device_attach method implementation. That's a = fairly intrusive change, and that would need to be made to any ethernet = driver that is to support such a split MDIO/MII setup. I tried delaying just the call to mii_attach(), but it seems that = interacts badly with an already attached interface. Specifically, I got = a non-working interface when I tried to call mii_attach() long after = if_etherattach(). Additionally, if_arge (and probably most other = drivers) assumes that the miibus is attached after they've successfully = attached themselves, and subsequently runs into null pointer issues when = it isn't. Would it be possible to attach miibus without having a working PHY, and = only attach the PHYs once the MDIO device has been attached? For the mips/atheros platforms, we could introduce ordering hints for = nexus to make sure the mdio driver gets attached before the arge's. = That's a fairly small changes (two lines), and does work, but it's more = a hack than a general solution. With my proposed change to miibus = (split devices), that would bring down the necessary changes to just a = handful of lines. Stefan --=20 Stefan Bethke <stb@lassitu.de> Fon +49 151 14070811