Date: Wed, 4 Jan 2012 17:03:41 +0100 From: Stefan Bethke <stb@lassitu.de> To: freebsd-arch@freebsd.org, Marius Strobl <marius@freebsd.org> Subject: Extending sys/dev/mii Message-ID: <8D025847-4BE4-4B2C-87D7-97E72CC9D325@lassitu.de>
next in thread | raw e-mail | index | archive | help
As discussed recently, ray@, adrian@ and myself are trying to get a = framework and utility into the tree that allows the use and = configuration of ethernet switch chips. The switch controllers we've = looked at so far share a number of features, in particular they use = 802.3 MII, MDIO and PHYs to implement and configure the ports they = offer. In addition to being a switch, some of them also offer one of = the built-in PHYs to the ethernet controller as a classical PHY. Since the switch is already using MDIO and PHYs, it seems sensible to = reuse the existig sys/dev/mii code. However, the current code assumes a = simple model where the ethernet controller has one MAC and an MDIO = master, and the PHYs are attached to these two busses. In addition, the = code assumes that all attached child drivers of an miibus will always be = PHY drivers (using custom dispatch table, specific ivars, etc.) I'd like to extend miibus in such a way that the one-to-one mapping = between MDIO and MII is broken up. For that, I propose to add a new bus = driver "mdiobus" (with appropriate resource management) that uses = methods similar to miibus_if.m readreg and writereg to access an = ethernet controllers' MDIO master. miibus then attaches to it as a = child, claims one or more PHY addresses and attaches PHYs to itself (as = currently implemented). This allows our new switch drivers to attach to the mdiobus as children = and claim appropriate PHY addresses as resources, as well. The current miibus code assumes that it is attached to the ethernet = driver, and will call MIIBUS_STATCHG on its parent to inform it of PHY = link changes. Since the parent will now be the mdiobus, miibus needs = effectively two attachments, one to the provider of the MDIO access, the = other for the ethernet interface. I propose to associate the ethernet = interface by a modified mii_attach() function that takes a device_t (of = the ethernet driver) instead of the two callback function pointers. At the same time, I'd like to unravel the use of callbacks in miibus and = in the PHY drivers. On the one hand the miibus_if.m has three callbacks = (statchg, linkchg, mediainit), on the other hand the bus keeps three = function pointers (mii_data.mii_readreg, mii_writereg, mii_statchg) that = it never uses(?), plus two others (miibus_ivars.ifmedia_upd and = ifmedia_sts) that are regularly called to provide link updates to the = interface. I would be interested to learn why these are spread out like = this (hysterical raisins?), and why they can't just be handled in the = usual bus method manner. (Documentation wouldn't hurt either :-) Despite this long description, I believe that the code changes are = relatively minor. The major issue is the proposed ABI change for the = callback functions, which probably will involve updating all drivers = calling mii_attach(). It might be possible to have the existing = function provide a compatibility wrapper around the new attachment code. There's one issue that I don't have a proposal for yet: in one platform = (AR7241), we have PHY4 of the SoC talking via MII to arge0's MAC, while = it is being controlled via the switch controller's MDIO master, and the = switch controller being attached to arge1's MDIO. If we want to attach = an miibus for PHY4, we'd have to defer attachment of arge0 until arge1 = has been probed and can provide the MDIO attachment (and transitively = the switch and it's mdio). Note that we also have boards without a = switch, but the two PHYs still being attached to only a single MDIO. = One possible way would be for the MDIO driver to be separate from the = ethernet driver, so that the normal newbus dependency resolution can be = used to ensure that mdio1 is attached before arge0 is probed. For the = time being, I've worked around this through hackery in if_arge.c. I currently have some parts of this implemented to the point where the = PHY in the switch is properly working together with arge0. I hope to = have a complete patch for review in a couple of weeks, but I'd = appreciate comments on the general approach I have outlined here. You can find my current code in the work/ath branch at = http://www.gitorious.org/~stb/freebsd/stb-adrianchadd-freebsd-work. = I've written up a couple of points about the ethernet switch work at = http://wiki.freebsd.org/StefanBethke/EtherSwitch. Stefan --=20 Stefan Bethke <stb@lassitu.de> Fon +49 151 14070811
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8D025847-4BE4-4B2C-87D7-97E72CC9D325>