From: Naveen Mamindlapalli <naveenm@marvell.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: "Björn Töpel" <bjorn@kernel.org>,
netdev@vger.kernel.org, "Donald Hunter" <donald.hunter@gmail.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Paolo Abeni" <pabeni@redhat.com>,
"Simon Horman" <horms@kernel.org>,
"Saeed Mahameed" <saeedm@nvidia.com>,
"Tariq Toukan" <tariqt@nvidia.com>,
"Leon Romanovsky" <leon@kernel.org>,
"Andrew Lunn" <andrew+netdev@lunn.ch>,
"Maxime Chevallier" <maxime.chevallier@bootlin.com>,
"Michael Chan" <michael.chan@broadcom.com>,
"Hariprasad Kelam" <hkelam@marvell.com>,
"Ido Schimmel" <idosch@nvidia.com>,
"Danielle Ratson" <danieller@nvidia.com>,
linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org,
"Russell King" <linux@armlinux.org.uk>
Subject: Re: [RFC net-next v2 0/6] ethtool: Generic loopback support
Date: Wed, 11 Mar 2026 11:29:20 +0530 [thread overview]
Message-ID: <abEEuPa3/cThM40a@naveenm-PowerEdge-T630> (raw)
In-Reply-To: <de9f5282-6270-4bb5-b9bf-d80cbc977f14@lunn.ch>
On 2026-03-10 at 19:30:14, Andrew Lunn (andrew@lunn.ch) 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
>
next prev parent reply other threads:[~2026-03-11 5:59 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-08 12:40 [RFC net-next v2 0/6] ethtool: Generic loopback support Björn Töpel
2026-03-08 12:40 ` [RFC net-next v2 1/6] ethtool: Add loopback netlink UAPI definitions Björn Töpel
2026-03-09 14:16 ` Maxime Chevallier
2026-03-09 14:59 ` Björn Töpel
2026-03-09 16:45 ` Andrew Lunn
2026-03-10 10:23 ` Maxime Chevallier
2026-03-10 13:56 ` Andrew Lunn
2026-03-08 12:40 ` [RFC net-next v2 2/6] ethtool: Add loopback GET/SET netlink implementation Björn Töpel
2026-03-09 7:34 ` Maxime Chevallier
2026-03-09 8:21 ` Björn Töpel
2026-03-09 14:51 ` Björn Töpel
2026-03-09 16:14 ` Maxime Chevallier
2026-03-08 12:40 ` [RFC net-next v2 3/6] ethtool: add CMIS loopback helpers for module loopback control Björn Töpel
2026-03-08 12:40 ` [RFC net-next v2 4/6] selftests: drv-net: Add loopback driver test Björn Töpel
2026-03-08 12:40 ` [RFC net-next v2 5/6] netdevsim: Add module EEPROM simulation via debugfs Björn Töpel
2026-03-08 12:40 ` [RFC net-next v2 6/6] selftests: drv-net: Add CMIS loopback netdevsim test Björn Töpel
2026-03-09 13:49 ` [RFC net-next v2 0/6] ethtool: Generic loopback support Naveen Mamindlapalli
2026-03-09 14:55 ` Björn Töpel
2026-03-10 7:35 ` Naveen Mamindlapalli
2026-03-10 14:00 ` Andrew Lunn
2026-03-11 5:59 ` Naveen Mamindlapalli [this message]
2026-03-11 12:32 ` Andrew Lunn
2026-03-11 16:52 ` Russell King (Oracle)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=abEEuPa3/cThM40a@naveenm-PowerEdge-T630 \
--to=naveenm@marvell.com \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=bjorn@kernel.org \
--cc=danieller@nvidia.com \
--cc=davem@davemloft.net \
--cc=donald.hunter@gmail.com \
--cc=edumazet@google.com \
--cc=hkelam@marvell.com \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=maxime.chevallier@bootlin.com \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeedm@nvidia.com \
--cc=tariqt@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox