Ethernet Switch Framework

Aleksandr Rybalko ray at
Sun Jan 29 11:14:55 UTC 2012

On Sat, 28 Jan 2012 15:00:01 -0800
Juli Mallett <jmallett at> wrote:

> On Sat, Jan 28, 2012 at 14:12, Aleksandr Rybalko <ray at>
> wrote:
> > As I see from your patch, mdio/miiproxy require special bits in MAC
> > driver. When I design switch framework, I keeping in mind that
> > MAC drivers should be standard as possible
> I don't understand why this is desirable in practice.  It's a nice
> theory, but it falls down when one thinks in depth about how Ethernet
> interfaces are used and administered vs. how switches are used and
> administered.  What should media report?  What should media changes
> do?  What is link status?  Do you show the CPU-to-switch port, or all
> switch ports?

IMO, if we about why to make MAC driver more "standard", it is desired
because most MAC, used in SoC's, used also in NIC cards or other SoC's
which have no switch, but MII and MDIO pins to attach external PHY.

Real example bfe(4), it is supported long ago as PCI card, but also
found in BCM4701 family SoC's. In BCM5354 it attached to embedded
switch. In BCM5836 it is two independent MAC.
Last one used in D-Link DIR-330, there is one MAC attached to PHY,
second to BCM5325 switch). Since BCM4701 family have internal SSB bus,
a.k.a siba(4), I add only siba(4) bus glue. So if we able to attach
switch driver to regular MAC drivers it will make our life simpler :) 

> It makes me wonder if the understanding of the relationship in FreeBSD
> isn't backwards.  Yes, the MAC sits on a bus and is memory-mapped, but
> you can conceptualize of it as a child of the PHY, rather than the
> parent of it, especially in systems with switch chipsets.  Especially
> in systems where there is a switch chipset attached to multiple MACs.
> In that model, it makes sense to semi-generically attach a
> CPU-to-switch port's pseudo-PHY (or actual PHY, depending on hardware)
> to a MAC generically, but that doesn't meant that the switch itself is
> attached generically to the MAC.
> There are a lot of switches out there that don't look or act much like
> MII-driven PHYs, but which are connected over MDIO, as I've tried to
> stress before.  
Yeah, for that case Marius commit phymask support for our miibus, to
not touch reserved PHY IDs.

>I hope there will be as much separation between the
> MII work that is being done and the switch work that is being done as
> possible.  I think anything else will prove rapidly-obsolete and
> perhaps even obstructive as soon as anyone seeks to add support for
> more switch chipsets to FreeBSD.
> I suppose the most likely reality, though, is that people simply won't
> add switch support to FreeBSD, and will administer them out-of-band
> from userland, using gross kernel shims.  That is probably true
> whether any of the currently-outstanding work is committed or not,
> unfortunately :(  I just hope we'll end up with something flexible
> enough, broad enough in applicability, narrow enough in requirements,
> etc., that we'll have feature-rich support for a few chipsets in tree
> that work in sufficiently-different manners that they can be models
> for other drivers in the future.
> Thanks,
> Juli.

Thank you for comments Juli!

Aleksandr Rybalko <ray at>

More information about the freebsd-net mailing list