Andrew!

Thanks for the swift response!

On Thu, 19 Feb 2026 at 16:51, Andrew Lunn [off-list ref] wrote:

Great to see you looked around at the problem space.

quoted

[2] https://lore.kernel.org/netdev/20240911212713.2178943-1-maxime.chevallier@bootlin.com/ (local)

Quoting myself from this thread:

quoted

We might want to take a step back and think about loopback some more.

Loopback can be done at a number of points in the device(s). Some
Marvell PHYs can do loopback in the PHY PCS layer. Some devices also
support loopback in the PHY SERDES layer. I've not seen it for Marvell
devices, but maybe some PHYs allow loopback much closer to the line?
And i expect some MAC PCS allow loopback.

So when talking about loopback, we might also want to include the
concept of where the loopback occurs, and maybe it needs to be a NIC
wide concept, not a PHY concept?

I still think this is true. We want a generic kAPI for loopback, not a
PHY loopback kAPI, and a MAC loopback kAPI, a PCS loopback kAPI, and
an SFP loopback kAPI, and a CAN bus transceiver loopback kAPI,
assuming CAN bus supports loopback?

So i think we need one ethtool API for loopback. We probably want an
API call to enumerate what loopbacks are supported for a netdev. The
MAC will fill in bits indicating what it can do. If the MAC has a PCS,
it will ask the PCS what it can do. If there is a PHY, it will ask the
PHY to fill in the bits indicating what it can do, if there is an SFP,
it will ask it what it can do, and if there is a CAN bus transceiver,
it will fill in its bits. And we probably want two values for each
loopback location, is it looping the media side, or the MAC side?

So the return value lists all the different loopbacks associated to a
netdev.

And then we need a set operation, to enable/disable a specific
loopback, and a get operation to return the status of all the
different loopbacks of a netdev. The MAC will again need to call into
the PCS, the PHY, the SFP to implement these.

I'm not saying you need to implement all these, you just need to make
what you do implement generic, and plumb it through the network stack
so that others can later easily add PHY, PCS, and MAC loopback
support. And from your background research, you know others are
interested in this, so you might be able get some help with parts you
are not particularly interested in.

All good points here; Thanks for the elaborative feedback. I like the
idea of a generic loopback API. Back to the drawing board!


Björn