[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <9e837217-3f93-402d-a6e6-02c419618ca5@bootlin.com>
Date: Mon, 22 Sep 2025 20:44:27 +0530
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: Andrew Lunn <andrew@...n.ch>, Hariprasad Kelam <hkelam@...vell.com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org, kuba@...nel.org,
davem@...emloft.net, sgoutham@...vell.com, gakula@...vell.com,
sbhatta@...vell.com, naveenm@...vell.com, edumazet@...gle.com,
pabeni@...hat.com, andrew+netdev@...n.ch, bbhushan2@...vell.com
Subject: Re: Query regarding Phy loopback support
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@...n.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
Powered by blists - more mailing lists