Naveen!

Naveen Mamindlapalli [off-list ref] writes:

quoted

Open questions
==============

 - Is this the right extensibility model? I'd appreciate input from
   other NIC vendors on whether component/name/direction is flexible
   enough for their loopback implementations. Also, from the PHY/port
   folks (Maxime, Russell)!

Hi Bjorn,

The component/name/direction model in v2 fits our hardware well.

I am working on loopback support for Marvell OcteonTX2.
The MAC (RPM block) supports a PCS-level loopback. In addition,
the on-chip SerDes (GSERM) is managed by embedded firmware and
supports three more loopback modes:
  NED (Near-End Digital) -- digital domain, before the analog front-end
  NEA (Near-End Analog) -- through the full analog front-end
  FED (Far-End Digital) -- line-side traffic looped back

Since the GSERM is not a phylib phy_device, both the MAC PCS
loopback and the SerDes loopbacks fall under the MAC component
in your model.

Mapped to the v2 model:
  component  name         supported    description
  MAC        mac          near-end     PCS-level loopback
  MAC        serdes-ned   near-end     digital only
  MAC        serdes-nea   near-end     analog
  MAC        serdes-fed   far-end      line-side

The SerDes NED and NEA both have the same (component, direction).
Both are (MAC, near-end) -- but exercise fundamentally different
hardware paths. The name field distinguishes them as per your model,

Ok! ...and MAC+serdes makes sense from your PoV? Or do we need a new
component "SERDES" (as Maxime points out in another reply)?

I can work on MAC + SerDes loopback driver support for CN10K and
post patches on top of your series once MAC component dispatch is
in place.

Got it! Thanks!