Date: Sun, 29 Jan 2012 16:31:59 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: Stefan Bethke <stb@lassitu.de> 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 Message-ID: <20120129153159.GA44362@alchemy.franken.de> In-Reply-To: <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%2BYsFqNm9d_T3Tq583uV_pabMV6ozuaytSRLivg@mail.gmail.com> <20120129001251.7e4cfe83.ray@ddteam.net> <CACVs6=-U9rr7cpeJ%2BVUgP3Xq1yRB=Xk1GjuzEOuXiEUoqGFq_Q@mail.gmail.com> <DBAB0C5C-5B2D-4430-8096-9E4DC7233961@bsdimp.com> <81B88904-6894-4AC3-80F3-2866216E494B@lassitu.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 29, 2012 at 02:14:42PM +0100, Stefan Bethke wrote: > 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? This would break the concept of knowing that when mii_attach() returns success you can talk to all the hardware necessary to present a working interface. So you'll just need another way instead to ensure that there's also at least a single PHY before attaching the whole thing which I don't see getting us further with the attach ordering problem of the MDIO provider. > > 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. > How about adding the MDIO provider via multi-pass probing? That idea of that model was to attach things like drivers for interrupt controllers before any other driver that requires that resource. This seems like a perfect match here and requires neither a specific hack to the nexus (the platform generally needs to be multi-pass aware though and the thing enabled in subr_bus.c) nor a hack to miibus(4). 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. Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120129153159.GA44362>