Extending sys/dev/mii

Stefan Bethke stb at lassitu.de
Wed Jan 4 16:03:43 UTC 2012


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

-- 
Stefan Bethke <stb at lassitu.de>   Fon +49 151 14070811



More information about the freebsd-arch mailing list