Re: Query regarding Phy loopback support

[Maxime Chevallier]

Hi,

On 22/09/2025 00:12, Andrew Lunn wrote:
> On Sun, Sep 21, 2025 at 11:14:55PM +0530, Hariprasad Kelam wrote:
> > On 2025-09-16 at 22:13:20, Andrew Lunn (andrew@xxxxxxx) wrote:
> > > On Tue, Sep 16, 2025 at 04:48:56PM +0530, Hariprasad Kelam wrote:
> > > > We're looking for a standard way to configure PHY loopback on a network
> > > > interface using common Linux tools like ethtool, ip, or devlink.
> > > >
> > > > Currently, ethtool -k eth0 loopback on enables a generic loopback, but it
> > > > doesn't specify if it's an internal, external, or PHY loopback.
> > > > Need suggestions to implement this feature in a standard way.
> > >
> > > What actually do you mean by PHY loopback?
> >
> > The Octeon silicon series supports both MAC (RPM) and PHY (GSERM) loopback
> > modes for testing.
> >
> > We are seeking a solution to support the following loopback types:
> >
> > MAC Level
> >
> > Far-end loopback: Ingress data is routed back to egress data (MAC-to-MAC).
> >
> > Near-end external loopback: Egress traffic is routed back to ingress traffic at the PCS layer.
> >
> > PHY Level
> >
> > Near-end digital loopback
> >
> > Near-end analog loopback
> >
> > Far-end digital loopback
> >
> > Far-end analog loopback
> >
> > We need suggestions on how to enable and manage these specific modes.
>
> Whatever you put in place, it needs to be generic to support other
> modes. So you need some sort of enum which can be extended. When
> describing the different modes, please try to reference 802.3, so it
> is clear what each actually means. And if it is a vendor mode, please
> describe it well, so other vendors know what it is, and can match
> their vendor names to it.
>
> Frames received on the Media loopback vs host transmitted frames
> should be another property.
>
> Are you wanting to use this with ethtool --test? That operation is
> still using IOCTL. So you will want to add netlink support, both in
> ethtool(1) and net/ethtool/netlink.c, so you can add the extra
> optional parameters to indicate where loopback should be
> performed. And them plumb this through the MAC ethtool to phylink and
> phylib, and maybe the PCS layer, if you have a linux PCS involved.

There were some previous discussions here [1] and [2] for more pointers 
on what to support with such a loopback feature. I'd be happy to help 
testing that work should you send any series.

[1]: https://lore.kernel.org/netdev/20240913093453.30811cb3@xxxxxxxxxxx/
[2]: https://lore.kernel.org/netdev/ZuJyJT-HgXJFe5ul@xxxxxxxxxxxxxx/

Thanks,

Maxime