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