Ethernet Switch Framework

[Stefan Bethke]

Thank you for the update, that clears up a number of questions I had.

Here's a couple of questions and comments.

Which devices can this code be run on?  For example, can the AR7240 config run on an TL-WR3420?

Would you mind giving an overview of how the various parts fit together, how they are probed and attached?  I think I understand from you explanations on IRC, but not everbody had that chance.

Am 20.01.2012 um 21:13 schrieb Aleksandr Rybalko:

> get/set reg:
> Generic access to registers. Have 2 address modifiers:
> 0x00000000(no modifiers) - access to parent space (parent MDIO bus, if
> switchX attaches to miibusX)
> 0x40000000 - access to switch MDIO bus
> 0x80000000 - access to switch registers.

Wouldn't it be better to have a proper API to select the various busses and device register files?

> FloatPHY
> pseudo driver which attach to miibus like normal PHY, but do find
> master switchX device and ask his PHY reg's. Main problem with that
> driver - is usage of newbus calls between independent device (not a
> parent <-> child), since floatphyX query set/get methods of switchX.

The general approach has a number of problems, as far as I understand the miibus code.  miibus assumes that only one of the PHYs on the MII is active concurrently (since that's a requirement of the MII/GMII/... bus).  If I read your code correctly, you have one miibus that has all the PHYs for all switch ports on them.  Won't miibus just isolate all but one PHY?

In your current implementation, you've reimplented ukphy (in a limited fashion).  One of the advantages of reusing the mii framework is being able to use all the PHYs, in case a switch chip would include a quirky PHY.  Extending floatphy to work as a full proxy for any phy driver looks non-trivial to me due to the API constraints the mii framework imposes.


Stefan

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