On 11/03/2026 16:22, Andrew Lunn wrote:
>> 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?
Good point indeed
>
> 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?
So, the same name + depth ?
+---|-PHY+
| | |
| SerDes |
| | |
| PCS | component = PHY, name = "pcs", depth = 0
| | |
| MAC |
| | |
| packet |
| buffer |
| | |
| MAC |
| | |
| PCS | component = PHY, name = "pcs", depth = 1
| | |
| PMA |
| | |
| PMD |
+---|----+
|
v 10GBaseT
I think I like this idea of depth + name, as we can consider omitting
the depth information when it's not needed (e.g. simple PHY with 1 PCS),
to keep the API simple.
To continue with your example, with combo-port PHYs we may get multiple
PMA/PMD instances, one per port, that's even more loopback points.
We could potentially associate these with phy_port though ?
> 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.
For that we have what we need with phy_link_topology, as each PHY has
its index, we should be good to go in that regard hopefully :)
Maxime
