Re: [RFC net-next 0/4] ethtool: CMIS module diagnostic loopback support
From: Jakub Kicinski <kuba@kernel.org>
Date: 2026-02-20 00:05:21
Also in:
linux-rdma, lkml
On Thu, 19 Feb 2026 16:51:47 +0100 Andrew Lunn wrote:
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.
Something like:
struct {
enum type; // MAC, PHY, SFP
int type_id; // if type=PHY - phy id
int depth; // counting from CPU, first loopback opportunity is 1
// second is 2, etc.
bool direction; // towards CPU/host vs towards network
char name[16]; // "pcs", "far", "near", "post-fec", whatever
}
?