On 2025-10-24 at 14:41:09, Oleksij Rempel (o.rempel@pengutronix.de) wrote:

On Fri, Oct 24, 2025 at 10:46:14AM +0200, Maxime Chevallier wrote:

quoted

Hi,

+Russell +Oleksij

On 24/10/2025 06:48, Hariprasad Kelam wrote:

quoted

This patch enhances loopback support by exposing new loopback modes
(e.g., MAC, SERDES) to userspace. These new modes are added extension
to the existing netdev features.

This allows users to select the loopback at specific layer.

Below are new modes added:

MAC near end loopback

MAC far end loopback

SERDES loopback

Depending on the feedback will submit ethtool changes.

Good to see you're willing to tackle this work. However as Eric says,
I don't think the netdev_features is the right place for this :
 - These 3 loopback modes here may not be enough for some plaforms
 - This eludes all PHY-side and PCS-side loopback modes that we could
   also use.

If we want to expose these loopback modes to userspace, we may actually
need a dedicated ethtool netlink command for loopback configuration and
control. This could then hit netdev ethtool ops or phy_device ethtool
ops depending on the selected loopback point.

If you don't want to deal with the whole complexity of PHY loopback, you
can for now only hook into a newly introduced netdev ethtool ops dedicated
to loopback on the ethnl side, but keep the door open for PHY-side
loopback later on.

Ack, I agree. I would be better to have information and configuration
for all loopbacks in one place.
Will it be possible to reflect the chain of components and level of
related loopbacks? I guess, at least each driver would be able to know
own loopback levels/order.

Please add me in CC if you decide to jump in to this rabbit hole :D

    ACK, will define new ethtool ops for loopback as a first step.
 Will try to add generic loopback modes to the list.

Thanks,
Hariprasad k