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

[Naveen Mamindlapalli]

On 2026-03-10 at 19:30:14, Andrew Lunn (andrew@xxxxxxx) wrote:
> > > > 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)?
> > > 
> > 
> > In my earlier comment I mapped the SerDes loopbacks under the MAC
> > component to fit the current model, but a separate SERDES component
> > as Maxime suggests would be a better fit for our hardware.
> > 
> > On OcteonTX2 SoC, MAC (PCS) and SerDes are separate hardware blocks.
> > Each block has its own loopback controls.
> > 
> > With a SERDES component, the mapping becomes cleaner:
> >   component  name         supported
> >   MAC        mac          near-end
> >   SERDES     serdes-ned   near-end
> >   SERDES     serdes-nea   near-end
> >   SERDES     serdes-fed   far-end
> 
> If Linux where to drive the SERDES, what part of Linux would it be?
> Generic PHY? How does your SERDES hardware block fit into 802.3? Which
> clause describes it?

Hi Andrew,

On OcteonTx2 SoC, the SerDes (GSERM) is a HW block integrated into the
SoC die. It is not on an MDIO bus or any bus that Linux can enumerate.
The block is fully managed by the firmware running on the SoC. The NIC
driver configures it indirectly through firmware mailbox commands.

The data path looks like:
  MAC (RPM) --- SerDes (GSERM) --- module/PHY

In 802.3 terms, the closest match would be PMA. The GSERM handles
serialization/deserialization and the analog front-end.

Thanks,
Naveen

> 
> Thanks
> 	Andrew
>