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