Messages in this thread |  | | From | Björn Töpel <> | | Subject | Re: [RFC net-next v2 0/6] ethtool: Generic loopback support | | Date | Mon, 09 Mar 2026 15:55:51 +0100 |
| |
Naveen!
Naveen Mamindlapalli <naveenm@marvell.com> writes:
>> 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!
|  |