Re: Query regarding Phy loopback support

[Maxime Chevallier <maxime.chevallier@bootlin.com>]

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@lunn.ch) 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@fedora.home/
[2]: https://lore.kernel.org/netdev/ZuJyJT-HgXJFe5ul@pengutronix.de/

Thanks,

Maxime