Extending sys/dev/mii

Adrian Chadd adrian at freebsd.org
Wed Jan 4 17:08:16 UTC 2012


I'm including -net here so we can try and pull in further feedback
from network-cluey people.

On 4 January 2012 08:03, Stefan Bethke <stb at lassitu.de> wrote:
> 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.

[snip]

> 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 sounds like a good idea. I wonder what's stopping us from doing that. :)

> 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.

juli@ proposed something quite similar a few weeks ago. Now that I'm a
little more clued up on this whole area, I now understand why she
suggested it.

I'm happy with "hacky" being in if_arge for now (I mean, there already
_is_ ..) but this work seems like the right path to take to bring
sanity to this whole setup in the longer term.

Thanks for tackling this!


Adrian


More information about the freebsd-net mailing list