[RFC net-next] net: loopback: Extend netdev features with new loopback modes

[RFC net-next] net: loopback: Extend netdev features with new loopback modes

[Hariprasad Kelam]

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.

Signed-off-by: Hariprasad Kelam <hkelam@marvell.com>
---
 Documentation/networking/netdev-features.rst  | 15 +++
 .../ethernet/marvell/octeontx2/nic/otx2_pf.c  | 93 ++++++++++++++++++-
 include/linux/netdev_features.h               |  9 +-
 net/ethtool/common.c                          |  3 +
 4 files changed, 116 insertions(+), 4 deletions(-)

diff --git a/Documentation/networking/netdev-features.rst b/Documentation/networking/netdev-features.rst
index 02bd7536fc0c..dcad5e875f32 100644
--- a/Documentation/networking/netdev-features.rst
+++ b/Documentation/networking/netdev-features.rst
@@ -193,3 +193,18 @@ frames in hardware.
 
 This should be set for devices which support netmem TX. See
 Documentation/networking/netmem.rst
+
+* mac-nearend-loopback
+
+This requests that the NIC enables MAC nearend loopback i.e egress traffic is
+routed back to ingress traffic.
+
+* mac-farend-loopback
+
+This requests that the NIC enables MAC farend loopback i.e ingress traffic is
+routed back to egress traffic.
+
+
+* serdes-loopback
+
+This request that the NIC enables SERDES near end digital loopback.
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
index e808995703cf..14be6a9206c8 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
@@ -1316,6 +1316,84 @@ static int otx2_cgx_config_loopback(struct otx2_nic *pf, bool enable)
 	return err;
 }
 
+static int otx2_cgx_mac_nearend_loopback(struct otx2_nic *pf, bool enable)
+{
+	struct msg_req *msg;
+	int err;
+
+	if (enable && !bitmap_empty(pf->flow_cfg->dmacflt_bmap,
+				    pf->flow_cfg->dmacflt_max_flows))
+		netdev_warn(pf->netdev,
+			    "CGX/RPM nearend loopback might not work as DMAC filters are active\n");
+
+	mutex_lock(&pf->mbox.lock);
+	if (enable)
+		msg = otx2_mbox_alloc_msg_cgx_intlbk_enable(&pf->mbox);
+	else
+		msg = otx2_mbox_alloc_msg_cgx_intlbk_disable(&pf->mbox);
+
+	if (!msg) {
+		mutex_unlock(&pf->mbox.lock);
+		return -ENOMEM;
+	}
+
+	err = otx2_sync_mbox_msg(&pf->mbox);
+	mutex_unlock(&pf->mbox.lock);
+	return err;
+}
+
+static int otx2_cgx_mac_farend_loopback(struct otx2_nic *pf, bool enable)
+{
+	struct msg_req *msg;
+	int err;
+
+	if (enable && !bitmap_empty(pf->flow_cfg->dmacflt_bmap,
+				    pf->flow_cfg->dmacflt_max_flows))
+		netdev_warn(pf->netdev,
+			    "CGX/RPM farend loopback might not work as DMAC filters are active\n");
+
+	mutex_lock(&pf->mbox.lock);
+	if (enable)
+		msg = otx2_mbox_alloc_msg_cgx_intlbk_enable(&pf->mbox);
+	else
+		msg = otx2_mbox_alloc_msg_cgx_intlbk_disable(&pf->mbox);
+
+	if (!msg) {
+		mutex_unlock(&pf->mbox.lock);
+		return -ENOMEM;
+	}
+
+	err = otx2_sync_mbox_msg(&pf->mbox);
+	mutex_unlock(&pf->mbox.lock);
+	return err;
+}
+
+static int otx2_cgx_serdes_loopback(struct otx2_nic *pf, bool enable)
+{
+	struct msg_req *msg;
+	int err;
+
+	if (enable && !bitmap_empty(pf->flow_cfg->dmacflt_bmap,
+				    pf->flow_cfg->dmacflt_max_flows))
+		netdev_warn(pf->netdev,
+			    "CGX/RPM serdes loopback might not work as DMAC filters are active\n");
+
+	mutex_lock(&pf->mbox.lock);
+	if (enable)
+		msg = otx2_mbox_alloc_msg_cgx_intlbk_enable(&pf->mbox);
+	else
+		msg = otx2_mbox_alloc_msg_cgx_intlbk_disable(&pf->mbox);
+
+	if (!msg) {
+		mutex_unlock(&pf->mbox.lock);
+		return -ENOMEM;
+	}
+
+	err = otx2_sync_mbox_msg(&pf->mbox);
+	mutex_unlock(&pf->mbox.lock);
+	return err;
+}
+
 int otx2_set_real_num_queues(struct net_device *netdev,
 			     int tx_queues, int rx_queues)
 {
@@ -2363,6 +2441,18 @@ static int otx2_set_features(struct net_device *netdev,
 		return cn10k_ipsec_ethtool_init(netdev,
 						features & NETIF_F_HW_ESP);
 
+	if ((changed & NETIF_F_MAC_LBK_NE) && netif_running(netdev))
+		return otx2_cgx_mac_nearend_loopback(pf,
+						     features & NETIF_F_MAC_LBK_NE);
+
+	if ((changed & NETIF_F_MAC_LBK_FE) && netif_running(netdev))
+		return otx2_cgx_mac_farend_loopback(pf,
+						    features & NETIF_F_MAC_LBK_FE);
+
+	if ((changed & NETIF_F_SERDES_LBK) && netif_running(netdev))
+		return otx2_cgx_serdes_loopback(pf,
+						features & NETIF_F_SERDES_LBK);
+
 	return otx2_handle_ntuple_tc_features(netdev, features);
 }
 
@@ -3249,7 +3339,8 @@ static int otx2_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 	if (pf->flags & OTX2_FLAG_TC_FLOWER_SUPPORT)
 		netdev->hw_features |= NETIF_F_HW_TC;
 
-	netdev->hw_features |= NETIF_F_LOOPBACK | NETIF_F_RXALL;
+	netdev->hw_features |= NETIF_F_LOOPBACK | NETIF_F_RXALL |
+			       NETIF_F_MAC_LBK_NE | NETIF_F_MAC_LBK_FE | NETIF_F_SERDES_LBK;
 
 	netif_set_tso_max_segs(netdev, OTX2_MAX_GSO_SEGS);
 	netdev->watchdog_timeo = OTX2_TX_TIMEOUT;
diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
index 93e4da7046a1..124f83223361 100644
--- a/include/linux/netdev_features.h
+++ b/include/linux/netdev_features.h
@@ -14,7 +14,7 @@ typedef u64 netdev_features_t;
 enum {
 	NETIF_F_SG_BIT,			/* Scatter/gather IO. */
 	NETIF_F_IP_CSUM_BIT,		/* Can checksum TCP/UDP over IPv4. */
-	__UNUSED_NETIF_F_1,
+	NETIF_F_MAC_LBK_NE_BIT,		/* MAC near end loopback */
 	NETIF_F_HW_CSUM_BIT,		/* Can checksum all the packets. */
 	NETIF_F_IPV6_CSUM_BIT,		/* Can checksum TCP/UDP over IPV6 */
 	NETIF_F_HIGHDMA_BIT,		/* Can DMA to high memory. */
@@ -24,8 +24,8 @@ enum {
 	NETIF_F_HW_VLAN_CTAG_FILTER_BIT,/* Receive filtering on VLAN CTAGs */
 	NETIF_F_VLAN_CHALLENGED_BIT,	/* Device cannot handle VLAN packets */
 	NETIF_F_GSO_BIT,		/* Enable software GSO. */
-	__UNUSED_NETIF_F_12,
-	__UNUSED_NETIF_F_13,
+	NETIF_F_MAC_LBK_FE_BIT,		/* MAC far end loopback */
+	NETIF_F_SERDES_LBK_BIT,		/* SERDES loopback */
 	NETIF_F_GRO_BIT,		/* Generic receive offload */
 	NETIF_F_LRO_BIT,		/* large receive offload */
 
@@ -165,6 +165,9 @@ enum {
 #define NETIF_F_HW_HSR_TAG_RM	__NETIF_F(HW_HSR_TAG_RM)
 #define NETIF_F_HW_HSR_FWD	__NETIF_F(HW_HSR_FWD)
 #define NETIF_F_HW_HSR_DUP	__NETIF_F(HW_HSR_DUP)
+#define NETIF_F_MAC_LBK_NE	__NETIF_F(MAC_LBK_NE)
+#define NETIF_F_MAC_LBK_FE	__NETIF_F(MAC_LBK_FE)
+#define NETIF_F_SERDES_LBK	__NETIF_F(SERDES_LBK)
 
 /* Finds the next feature with the highest number of the range of start-1 till 0.
  */
diff --git a/net/ethtool/common.c b/net/ethtool/common.c
index 55223ebc2a7e..4a6a400a7c69 100644
--- a/net/ethtool/common.c
+++ b/net/ethtool/common.c
@@ -77,6 +77,9 @@ const char netdev_features_strings[NETDEV_FEATURE_COUNT][ETH_GSTRING_LEN] = {
 	[NETIF_F_HW_HSR_TAG_RM_BIT] =	 "hsr-tag-rm-offload",
 	[NETIF_F_HW_HSR_FWD_BIT] =	 "hsr-fwd-offload",
 	[NETIF_F_HW_HSR_DUP_BIT] =	 "hsr-dup-offload",
+	[NETIF_F_MAC_LBK_NE_BIT] =	 "mac-nearend-loopback",
+	[NETIF_F_MAC_LBK_FE_BIT] =	 "mac-farend-loopback",
+	[NETIF_F_SERDES_LBK_BIT] =	 "serdes-loopback",
 };
 
 const char
-- 
2.34.1

Re: [RFC net-next] net: loopback: Extend netdev features with new loopback modes

[Eric Dumazet]

On Thu, Oct 23, 2025 at 9:49 PM Hariprasad Kelam <hkelam@marvell.com> wrote:
>
> 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.
>
> Signed-off-by: Hariprasad Kelam <hkelam@marvell.com>
> ---
>  Documentation/networking/netdev-features.rst  | 15 +++
>  .../ethernet/marvell/octeontx2/nic/otx2_pf.c  | 93 ++++++++++++++++++-
>  include/linux/netdev_features.h               |  9 +-
>  net/ethtool/common.c                          |  3 +
>  4 files changed, 116 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/networking/netdev-features.rst b/Documentation/networking/netdev-features.rst
> index 02bd7536fc0c..dcad5e875f32 100644
> --- a/Documentation/networking/netdev-features.rst
> +++ b/Documentation/networking/netdev-features.rst
> @@ -193,3 +193,18 @@ frames in hardware.
>
>  This should be set for devices which support netmem TX. See
>  Documentation/networking/netmem.rst
> +
> +* mac-nearend-loopback
> +
> +This requests that the NIC enables MAC nearend loopback i.e egress traffic is
> +routed back to ingress traffic.
> +
> +* mac-farend-loopback
> +
> +This requests that the NIC enables MAC farend loopback i.e ingress traffic is
> +routed back to egress traffic.
> +
> +
> +* serdes-loopback
> +
> +This request that the NIC enables SERDES near end digital loopback.
> diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
> index e808995703cf..14be6a9206c8 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
> @@ -1316,6 +1316,84 @@ static int otx2_cgx_config_loopback(struct otx2_nic *pf, bool enable)
>         return err;
>  }
>
> +static int otx2_cgx_mac_nearend_loopback(struct otx2_nic *pf, bool enable)
> +{
> +       struct msg_req *msg;
> +       int err;
> +
> +       if (enable && !bitmap_empty(pf->flow_cfg->dmacflt_bmap,
> +                                   pf->flow_cfg->dmacflt_max_flows))
> +               netdev_warn(pf->netdev,
> +                           "CGX/RPM nearend loopback might not work as DMAC filters are active\n");
> +
> +       mutex_lock(&pf->mbox.lock);
> +       if (enable)
> +               msg = otx2_mbox_alloc_msg_cgx_intlbk_enable(&pf->mbox);
> +       else
> +               msg = otx2_mbox_alloc_msg_cgx_intlbk_disable(&pf->mbox);
> +
> +       if (!msg) {
> +               mutex_unlock(&pf->mbox.lock);
> +               return -ENOMEM;
> +       }
> +
> +       err = otx2_sync_mbox_msg(&pf->mbox);
> +       mutex_unlock(&pf->mbox.lock);
> +       return err;
> +}
> +
> +static int otx2_cgx_mac_farend_loopback(struct otx2_nic *pf, bool enable)
> +{
> +       struct msg_req *msg;
> +       int err;
> +
> +       if (enable && !bitmap_empty(pf->flow_cfg->dmacflt_bmap,
> +                                   pf->flow_cfg->dmacflt_max_flows))
> +               netdev_warn(pf->netdev,
> +                           "CGX/RPM farend loopback might not work as DMAC filters are active\n");
> +
> +       mutex_lock(&pf->mbox.lock);
> +       if (enable)
> +               msg = otx2_mbox_alloc_msg_cgx_intlbk_enable(&pf->mbox);
> +       else
> +               msg = otx2_mbox_alloc_msg_cgx_intlbk_disable(&pf->mbox);
> +
> +       if (!msg) {
> +               mutex_unlock(&pf->mbox.lock);
> +               return -ENOMEM;
> +       }
> +
> +       err = otx2_sync_mbox_msg(&pf->mbox);
> +       mutex_unlock(&pf->mbox.lock);
> +       return err;
> +}
> +
> +static int otx2_cgx_serdes_loopback(struct otx2_nic *pf, bool enable)
> +{
> +       struct msg_req *msg;
> +       int err;
> +
> +       if (enable && !bitmap_empty(pf->flow_cfg->dmacflt_bmap,
> +                                   pf->flow_cfg->dmacflt_max_flows))
> +               netdev_warn(pf->netdev,
> +                           "CGX/RPM serdes loopback might not work as DMAC filters are active\n");
> +
> +       mutex_lock(&pf->mbox.lock);
> +       if (enable)
> +               msg = otx2_mbox_alloc_msg_cgx_intlbk_enable(&pf->mbox);
> +       else
> +               msg = otx2_mbox_alloc_msg_cgx_intlbk_disable(&pf->mbox);
> +
> +       if (!msg) {
> +               mutex_unlock(&pf->mbox.lock);
> +               return -ENOMEM;
> +       }
> +
> +       err = otx2_sync_mbox_msg(&pf->mbox);
> +       mutex_unlock(&pf->mbox.lock);
> +       return err;
> +}
> +
>  int otx2_set_real_num_queues(struct net_device *netdev,
>                              int tx_queues, int rx_queues)
>  {
> @@ -2363,6 +2441,18 @@ static int otx2_set_features(struct net_device *netdev,
>                 return cn10k_ipsec_ethtool_init(netdev,
>                                                 features & NETIF_F_HW_ESP);
>
> +       if ((changed & NETIF_F_MAC_LBK_NE) && netif_running(netdev))
> +               return otx2_cgx_mac_nearend_loopback(pf,
> +                                                    features & NETIF_F_MAC_LBK_NE);
> +
> +       if ((changed & NETIF_F_MAC_LBK_FE) && netif_running(netdev))
> +               return otx2_cgx_mac_farend_loopback(pf,
> +                                                   features & NETIF_F_MAC_LBK_FE);
> +
> +       if ((changed & NETIF_F_SERDES_LBK) && netif_running(netdev))
> +               return otx2_cgx_serdes_loopback(pf,
> +                                               features & NETIF_F_SERDES_LBK);
> +
>         return otx2_handle_ntuple_tc_features(netdev, features);
>  }
>
> @@ -3249,7 +3339,8 @@ static int otx2_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>         if (pf->flags & OTX2_FLAG_TC_FLOWER_SUPPORT)
>                 netdev->hw_features |= NETIF_F_HW_TC;
>
> -       netdev->hw_features |= NETIF_F_LOOPBACK | NETIF_F_RXALL;
> +       netdev->hw_features |= NETIF_F_LOOPBACK | NETIF_F_RXALL |
> +                              NETIF_F_MAC_LBK_NE | NETIF_F_MAC_LBK_FE | NETIF_F_SERDES_LBK;
>
>         netif_set_tso_max_segs(netdev, OTX2_MAX_GSO_SEGS);
>         netdev->watchdog_timeo = OTX2_TX_TIMEOUT;
> diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
> index 93e4da7046a1..124f83223361 100644
> --- a/include/linux/netdev_features.h
> +++ b/include/linux/netdev_features.h
> @@ -14,7 +14,7 @@ typedef u64 netdev_features_t;
>  enum {
>         NETIF_F_SG_BIT,                 /* Scatter/gather IO. */
>         NETIF_F_IP_CSUM_BIT,            /* Can checksum TCP/UDP over IPv4. */
> -       __UNUSED_NETIF_F_1,
> +       NETIF_F_MAC_LBK_NE_BIT,         /* MAC near end loopback */
>         NETIF_F_HW_CSUM_BIT,            /* Can checksum all the packets. */
>         NETIF_F_IPV6_CSUM_BIT,          /* Can checksum TCP/UDP over IPV6 */
>         NETIF_F_HIGHDMA_BIT,            /* Can DMA to high memory. */
> @@ -24,8 +24,8 @@ enum {
>         NETIF_F_HW_VLAN_CTAG_FILTER_BIT,/* Receive filtering on VLAN CTAGs */
>         NETIF_F_VLAN_CHALLENGED_BIT,    /* Device cannot handle VLAN packets */
>         NETIF_F_GSO_BIT,                /* Enable software GSO. */
> -       __UNUSED_NETIF_F_12,
> -       __UNUSED_NETIF_F_13,
> +       NETIF_F_MAC_LBK_FE_BIT,         /* MAC far end loopback */
> +       NETIF_F_SERDES_LBK_BIT,         /* SERDES loopback */
>         NETIF_F_GRO_BIT,                /* Generic receive offload */
>         NETIF_F_LRO_BIT,                /* large receive offload */
>
> @@ -165,6 +165,9 @@ enum {
>  #define NETIF_F_HW_HSR_TAG_RM  __NETIF_F(HW_HSR_TAG_RM)
>  #define NETIF_F_HW_HSR_FWD     __NETIF_F(HW_HSR_FWD)
>  #define NETIF_F_HW_HSR_DUP     __NETIF_F(HW_HSR_DUP)
> +#define NETIF_F_MAC_LBK_NE     __NETIF_F(MAC_LBK_NE)
> +#define NETIF_F_MAC_LBK_FE     __NETIF_F(MAC_LBK_FE)
> +#define NETIF_F_SERDES_LBK     __NETIF_F(SERDES_LBK)
>

I do not think we want to burn three generic bits in netdev_features_t
for something which seems device specific.

You have not shown any change for taking care of these features in net/core.

Re: [RFC net-next] net: loopback: Extend netdev features with new loopback modes

[Maxime Chevallier]

Hi,

+Russell +Oleksij

On 24/10/2025 06:48, Hariprasad Kelam wrote:
> 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.

Maxime

Re: [RFC net-next] net: loopback: Extend netdev features with new loopback modes

[Oleksij Rempel]

On Fri, Oct 24, 2025 at 10:46:14AM +0200, Maxime Chevallier wrote:
> Hi,
> 
> +Russell +Oleksij
> 
> On 24/10/2025 06:48, Hariprasad Kelam wrote:
> > 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

Best Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [RFC net-next] net: loopback: Extend netdev features with new loopback modes

[Hariprasad Kelam]

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:
> > Hi,
> > 
> > +Russell +Oleksij
> > 
> > On 24/10/2025 06:48, Hariprasad Kelam wrote:
> > > 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