On 12/03/2026 06:04, Oleksij Rempel wrote:

On Wed, Mar 11, 2026 at 07:50:52PM -0700, Jakub Kicinski wrote:

quoted

On Wed, 11 Mar 2026 20:26:39 +0100 Andrew Lunn wrote:

quoted

quoted

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 :)  

So depth would be local to a component? We could have two PHY
components, each with a different index, and depth = 0?

I _think_ Jakub's depth was more at a global level? But then it would
need to be passed down as we do the enumeration.

Oh, sorry, I responded without reading the whole discussion :)
No, I imagined the depth would be within a single component, 
so under control of a single driver (instance). The ordering
between components should be defined by PHY topology etc so
it's outside of the loopback config.

As for me, it is problematic to help the user to understand the datapath
depth on a switch. For example:

CPU -- xMII --- MAC1 [loop] --- fabric --- MAC2 [loop] --- xMII -- PHY
                                    \----- MACx [loop] ---

... each port has two xMII loop configurations: towards the xMII or towards
the fabric. From a driver perspective, a loop towards the xMII is
"remote." However, from a system perspective, a "remote" loop on MAC1 is
a local loop at depth=0, whereas a "local" loop on MAC2 is a local loop
at depth=1.

What's important is to specify clearly in the documentation from which
end do we start, where representing the topology. From your scenario
here, each block is already well represented and exposed, and if we use
local depth definitions we should be fine ?

Other example would be where we have a chain of components which are
attached on the system in a unexpected direction, where the MDI
interface is pointing towards the main CPU, so the remote loopbacks
became to local loop.

I have a few of these types of setup on my desk, where 3 PHY devices are
daisy-chained, we don't support that for now. If we one day add support
for standalone PHYs acting as media converters, I expect we'll be able
to tell which end is pointing where, and let it up to the user to figure
out what "remote" and "local" means in that case.

One more issue is the test data generator location. The data generator
is not always the CPU. We have HW generators located in components like
PHYs or we may use external source (remote loopback).

There were discussions about PRBS, I think the same idea of "pinpointing
which block we want to use" can be applied for both loopback and
generation ?

Maxime