Ethernet Switch Framework

[Marius Strobl]

On Sun, Jan 29, 2012 at 11:00:22AM -0800, Adrian Chadd wrote:
> I think for switches, that doesn't necessarily hold.

Err, what exactly doesn't hold? The suggestion about using multi-pass
probing was just for the case when there's a separate MDIO master
other drivers depend on. The latter would just use the default ordering
(unless there are again ordering constraints whithin them). So if
there's no separate MDIO master driver invovled that is attached first,
the other drivers would still just be attached in the default ordering.

> 
> ie, mii_attach() for single-PHY devices may work that way, but the weird

What way?

> and wonderful world of embedded switch SoC's doesn't. You're lucky in most
> instances since the bootloader does give you a mostly-working switch
> config. But I doubt that's a guarantee on all platforms.
> 
> So for those (ethernet) devices, splitting out the mii/mdio stuff and _not_
> necessarily presenting a working PHY may be acceptable. For now it's going

If there isn't a single working PHY, why would one want to attach
miibus(4) in the first place?
What is about the opposite case, when all you have is a MDIO master
and a switch connected to it, but no MAC on the MII lines of the
switch?

> to be a subset, to having it export an MDIO bus and doing late MII
> attachment may not be as architecturally "no-no" as I interpret your post.
> 

Originally, Stefan said that he wants to find a way to support all
the odd combinations found in the embedded-world and I try to come
up with model that is able to do that without needing hacks and
hints left and right. As imp@ said, interrupt controllers and
GPIO basically suffer the same dependency constraints across
otherwise unrelated devices there, so we really should find a way
to properly deal with that situation without again needing another
set of hacks and hints in other types of drivers.
As for MDIO you actually can have another layer of dependencies
between MDIO master, Ethernet switch and PHY, f.e. at work we use
a single MDIO master and switch it to different slave busses using
a multiplexer managed via GPIO ... not that I'd ever wanted to
support this via generic means in FreeBSD.

Marius