> If we take an example with a 10G PHY, we may have :
>
> +----SoC-----+
> | |
> | MAC |- drivers/net/ethernet
> | | |
> | Base-R PCS |- could be in drivers/net/pcs, or directly
> | | | in the MAC driver
> | | |
> | SerDes |- May be in drivers/phy, maybe handled by firmware,
> | | | maybe by the MAC driver, maybe by the PCS driver ?
> +---|--------+
> |
> | 10GBase-R
> |
> +---|-PHY+
> | | |
> | SerDes | \
> | | | |
> | PCS | |
> | | | > All of that handled by the drivers/net/phy PHY driver
> | PMA | |
> | | | |
> | PMD | /
> +---|----+
> |
> v 10GBaseT
We should also keep in mind this is a "simple" PHY. If you have a PHY
which does rate adaptation it looks more like:
+---|-PHY+
| | |
| SerDes |
| | |
| PCS |
| | |
| MAC |
| | |
| packet |
| buffer |
| | |
| MAC |
| | |
| PCS |
| | |
| PMA |
| | |
| PMD |
+---|----+
|
v 10GBaseT
So there is potentially 5 more loopback points?
Jakub proposal had the concept of 'depth'. Maybe we need that to
handle having the same block repeated a few times as you go towards
the media?
We should also think about when we have a PHY acting as a MII
converter. You see the Marvell PHY placed between the MAC and the SFP
cage. That has a collection of blocks which can do loopback. And then
we could have either a Base-T module/PHY in the cage, with more of the
same blocks, or a fibre modules with loopback.
Andrew
