Re: [RFC net-next v2 0/6] ethtool: Generic loopback support

[Björn Töpel]

Naveen!

Naveen Mamindlapalli <naveenm@xxxxxxxxxxx> 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!