Hi!

Background
==========

This is the v2 RFC of the CMIS loopback series, reworked based on
feedback from v1 [1].

The main change is that loopback is no longer bolted onto the existing
module interface. Instead, it gets its own netlink commands
(LOOPBACK_GET/SET) with a generic component/name/direction model that
can represent loopback points across the entire data path -- MODULE,
PHY, MAC, and PCS. This series wires up MODULE/CMIS as the first user;
the other component types return -EOPNOTSUPP for now.

The Common Management Interface Specification (CMIS) defines four
diagnostic loopback types, characterized by location (Host or Media
Side) and signal direction:

 - Host Side Input (Rx->Tx) -- near-end
 - Host Side Output (Tx->Rx) -- far-end
 - Media Side Input (Rx->Tx) -- near-end
 - Media Side Output (Tx->Rx) -- far-end

Support is detected via Page 13h Byte 128, and loopback is controlled
via Page 13h Bytes 180-183 (one byte per type, one bit per lane).

The CMIS helpers work entirely over get/set_module_eeprom_by_page, so
any driver that already has EEPROM page access gets module loopback
without new ethtool_ops or driver changes.

Implementation
==============

Patch 1/6 ethtool: Add loopback netlink UAPI definitions
  Adds the YAML spec and generated UAPI header for the new
  LOOPBACK_GET/SET commands. Each loopback entry carries a component
  type, optional id, name string, supported directions bitmask, and
  current direction.

Patch 2/6 ethtool: Add loopback GET/SET netlink implementation
  Implements GET/SET dispatch in a new loopback.c. GET collects
  entries from each subsystem. SET switches on the component and
  calls the right handler per entry. No components are wired yet.

Patch 3/6 ethtool: add CMIS loopback helpers for module loopback control
  Adds cmis_loopback.c with the MODULE component handlers. GET reads
  Page 13h and appends one entry per supported loopback point
  ("cmis-host" and/or "cmis-media"). SET resolves name to control
  byte indices and enforces mutual exclusivity -- switching directions
  first disables the active one in a separate EEPROM write, then
  enables the new one.

Patch 4/6 selftests: drv-net: Add loopback driver test
  Adds loopback_drv.py with generic tests that work on any device
  with module loopback support: enable/disable, direction switching,
  idempotent enable, and rejection while interface is up.

Patch 5/6 netdevsim: Add module EEPROM simulation via debugfs
  Adds get/set_module_eeprom_by_page to netdevsim, backed by a
  256-page x 128-byte array exposed via debugfs. This enables
  testing the CMIS loopback path without hardware.

Patch 6/6 selftests: drv-net: Add CMIS loopback netdevsim test
  Adds loopback_nsim.py with netdevsim-specific tests that seed the
  EEPROM via debugfs: capability reporting, EEPROM byte verification,
  and error paths for unsupported or missing CMIS support.

Limitations
===========

Only MODULE/CMIS is wired up. PHY, MAC, and PCS loopback are defined
in the UAPI but not yet implemented.

No per-lane support -- loopback is all-or-nothing (0xFF/0x00) across
lanes.

Extending to PHY/MAC/PCS
=========================

PHY loopback can walk phy_link_topology to enumerate PHYs by phyindex
and call phy_loopback() directly. MAC and PCS loopback can route
through phylink via new mac_set_loopback()/pcs_set_loopback()
callbacks. Drivers that don't use phylink could add new ethtool_ops.
The dispatch framework already handles all component types.

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)!

 - The MODULE id field is currently unused. For multi-module setups it
   could serve as a port selector. It could also help detect module
   swaps -- a hash of the CMIS vendor serial number (Page 00h, Bytes
   168-183), vendor name, and part number would give userspace a
   stable identifier to verify the module hasn't changed since
   loopback was configured. Worth adding now, or defer until there's a
   concrete user?

 - Are patches 5-6 (netdevsim EEPROM simulation + netdevsim-specific
   tests) worth carrying? They drive the CMIS Page 13h registers from
   debugfs, which gives good coverage without hardware, but it's
   another netdevsim surface to maintain. If the consensus is that the
   generic driver tests (patch 4) are sufficient, I'm happy to drop
   them.

Related work
============

[1] CMIS loopback v1
  https://lore.kernel.org/netdev/20260219130050.2390226-1-bjorn@kernel.org/
[2] New loopback modes
  https://lore.kernel.org/netdev/20251024044849.1098222-1-hkelam@marvell.com/
[3] PHY loopback
  https://lore.kernel.org/netdev/20240911212713.2178943-1-maxime.chevallier@bootlin.com/
[4] bnxt_en: add .set_module_eeprom_by_page() support
  https://lore.kernel.org/netdev/20250310183129.3154117-8-michael.chan@broadcom.com/


Björn Töpel (6):
  ethtool: Add loopback netlink UAPI definitions
  ethtool: Add loopback GET/SET netlink implementation
  ethtool: add CMIS loopback helpers for module loopback control
  selftests: drv-net: Add loopback driver test
  netdevsim: Add module EEPROM simulation via debugfs
  selftests: drv-net: Add CMIS loopback netdevsim test

 Documentation/netlink/specs/ethtool.yaml      | 115 ++++++
 drivers/net/netdevsim/ethtool.c               |  79 ++++
 drivers/net/netdevsim/netdevsim.h             |  11 +
 include/linux/ethtool.h                       |  28 ++
 .../uapi/linux/ethtool_netlink_generated.h    |  52 +++
 net/ethtool/Makefile                          |   2 +-
 net/ethtool/cmis_loopback.c                   | 338 ++++++++++++++++++
 net/ethtool/loopback.c                        | 248 +++++++++++++
 net/ethtool/netlink.c                         |  20 ++
 net/ethtool/netlink.h                         |   8 +
 .../selftests/drivers/net/hw/loopback_drv.py  | 227 ++++++++++++
 .../selftests/drivers/net/hw/loopback_nsim.py | 249 +++++++++++++
 12 files changed, 1376 insertions(+), 1 deletion(-)
 create mode 100644 net/ethtool/cmis_loopback.c
 create mode 100644 net/ethtool/loopback.c
 create mode 100755 tools/testing/selftests/drivers/net/hw/loopback_drv.py
 create mode 100755 tools/testing/selftests/drivers/net/hw/loopback_nsim.py


base-commit: 0bcac7b11262557c990da1ac564d45777eb6b005
-- 
2.53.0

On 2026-03-08 at 18:10:06, Björn Töpel (bjorn@kernel.org) wrote:
> Hi!
> 
> Background
> ==========
> 
> This is the v2 RFC of the CMIS loopback series, reworked based on
> feedback from v1 [1].
> 
> The main change is that loopback is no longer bolted onto the existing
> module interface. Instead, it gets its own netlink commands
> (LOOPBACK_GET/SET) with a generic component/name/direction model that
> can represent loopback points across the entire data path -- MODULE,
> PHY, MAC, and PCS. This series wires up MODULE/CMIS as the first user;
> the other component types return -EOPNOTSUPP for now.
> 
> The Common Management Interface Specification (CMIS) defines four
> diagnostic loopback types, characterized by location (Host or Media
> Side) and signal direction:
> 
>  - Host Side Input (Rx->Tx) -- near-end
>  - Host Side Output (Tx->Rx) -- far-end
>  - Media Side Input (Rx->Tx) -- near-end
>  - Media Side Output (Tx->Rx) -- far-end
> 
> Support is detected via Page 13h Byte 128, and loopback is controlled
> via Page 13h Bytes 180-183 (one byte per type, one bit per lane).
> 
> The CMIS helpers work entirely over get/set_module_eeprom_by_page, so
> any driver that already has EEPROM page access gets module loopback
> without new ethtool_ops or driver changes.
> 
> Implementation
> ==============
> 
> Patch 1/6 ethtool: Add loopback netlink UAPI definitions
>   Adds the YAML spec and generated UAPI header for the new
>   LOOPBACK_GET/SET commands. Each loopback entry carries a component
>   type, optional id, name string, supported directions bitmask, and
>   current direction.
> 
> Patch 2/6 ethtool: Add loopback GET/SET netlink implementation
>   Implements GET/SET dispatch in a new loopback.c. GET collects
>   entries from each subsystem. SET switches on the component and
>   calls the right handler per entry. No components are wired yet.
> 
> Patch 3/6 ethtool: add CMIS loopback helpers for module loopback control
>   Adds cmis_loopback.c with the MODULE component handlers. GET reads
>   Page 13h and appends one entry per supported loopback point
>   ("cmis-host" and/or "cmis-media"). SET resolves name to control
>   byte indices and enforces mutual exclusivity -- switching directions
>   first disables the active one in a separate EEPROM write, then
>   enables the new one.
> 
> Patch 4/6 selftests: drv-net: Add loopback driver test
>   Adds loopback_drv.py with generic tests that work on any device
>   with module loopback support: enable/disable, direction switching,
>   idempotent enable, and rejection while interface is up.
> 
> Patch 5/6 netdevsim: Add module EEPROM simulation via debugfs
>   Adds get/set_module_eeprom_by_page to netdevsim, backed by a
>   256-page x 128-byte array exposed via debugfs. This enables
>   testing the CMIS loopback path without hardware.
> 
> Patch 6/6 selftests: drv-net: Add CMIS loopback netdevsim test
>   Adds loopback_nsim.py with netdevsim-specific tests that seed the
>   EEPROM via debugfs: capability reporting, EEPROM byte verification,
>   and error paths for unsupported or missing CMIS support.
> 
> Limitations
> ===========
> 
> Only MODULE/CMIS is wired up. PHY, MAC, and PCS loopback are defined
> in the UAPI but not yet implemented.
> 
> No per-lane support -- loopback is all-or-nothing (0xFF/0x00) across
> lanes.
> 
> Extending to PHY/MAC/PCS
> =========================
> 
> PHY loopback can walk phy_link_topology to enumerate PHYs by phyindex
> and call phy_loopback() directly. MAC and PCS loopback can route
> through phylink via new mac_set_loopback()/pcs_set_loopback()
> callbacks. Drivers that don't use phylink could add new ethtool_ops.
> The dispatch framework already handles all component types.
> 
> 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,

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.

Thanks,
Naveen

> 
>  - The MODULE id field is currently unused. For multi-module setups it
>    could serve as a port selector. It could also help detect module
>    swaps -- a hash of the CMIS vendor serial number (Page 00h, Bytes
>    168-183), vendor name, and part number would give userspace a
>    stable identifier to verify the module hasn't changed since
>    loopback was configured. Worth adding now, or defer until there's a
>    concrete user?
> 
>  - Are patches 5-6 (netdevsim EEPROM simulation + netdevsim-specific
>    tests) worth carrying? They drive the CMIS Page 13h registers from
>    debugfs, which gives good coverage without hardware, but it's
>    another netdevsim surface to maintain. If the consensus is that the
>    generic driver tests (patch 4) are sufficient, I'm happy to drop
>    them.
> 
> Related work
> ============
> 
> [1] CMIS loopback v1
>   https://lore.kernel.org/netdev/20260219130050.2390226-1-bjorn@kernel.org/
> [2] New loopback modes
>   https://lore.kernel.org/netdev/20251024044849.1098222-1-hkelam@marvell.com/
> [3] PHY loopback
>   https://lore.kernel.org/netdev/20240911212713.2178943-1-maxime.chevallier@bootlin.com/
> [4] bnxt_en: add .set_module_eeprom_by_page() support
>   https://lore.kernel.org/netdev/20250310183129.3154117-8-michael.chan@broadcom.com/
> 
> 
> Björn Töpel (6):
>   ethtool: Add loopback netlink UAPI definitions
>   ethtool: Add loopback GET/SET netlink implementation
>   ethtool: add CMIS loopback helpers for module loopback control
>   selftests: drv-net: Add loopback driver test
>   netdevsim: Add module EEPROM simulation via debugfs
>   selftests: drv-net: Add CMIS loopback netdevsim test
> 
>  Documentation/netlink/specs/ethtool.yaml      | 115 ++++++
>  drivers/net/netdevsim/ethtool.c               |  79 ++++
>  drivers/net/netdevsim/netdevsim.h             |  11 +
>  include/linux/ethtool.h                       |  28 ++
>  .../uapi/linux/ethtool_netlink_generated.h    |  52 +++
>  net/ethtool/Makefile                          |   2 +-
>  net/ethtool/cmis_loopback.c                   | 338 ++++++++++++++++++
>  net/ethtool/loopback.c                        | 248 +++++++++++++
>  net/ethtool/netlink.c                         |  20 ++
>  net/ethtool/netlink.h                         |   8 +
>  .../selftests/drivers/net/hw/loopback_drv.py  | 227 ++++++++++++
>  .../selftests/drivers/net/hw/loopback_nsim.py | 249 +++++++++++++
>  12 files changed, 1376 insertions(+), 1 deletion(-)
>  create mode 100644 net/ethtool/cmis_loopback.c
>  create mode 100644 net/ethtool/loopback.c
>  create mode 100755 tools/testing/selftests/drivers/net/hw/loopback_drv.py
>  create mode 100755 tools/testing/selftests/drivers/net/hw/loopback_nsim.py
> 
> 
> base-commit: 0bcac7b11262557c990da1ac564d45777eb6b005
> -- 
> 2.53.0
> 
> 

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!

On 2026-03-09 at 20:25:51, Björn Töpel (bjorn@kernel.org) wrote:
> 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)?
> 

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

Thanks,
Naveen

> > 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!
> 
> 

> > > 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?

Thanks
	Andrew

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
>

> > > 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.

A Linux Generic PHY is probably also PMA.

802.3 says very little about SERDES, it is not a well defined term. So
i think we want PCS and PMA, not SERDES as a loopback point.

       Andrew

On Wed, Mar 11, 2026 at 01:32:09PM +0100, Andrew Lunn wrote:
> > > > 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.
> 
> A Linux Generic PHY is probably also PMA.
> 
> 802.3 says very little about SERDES, it is not a well defined term. So
> i think we want PCS and PMA, not SERDES as a loopback point.

That's a good point. I'm wondeirng whether to change "serdes" /
"SerDes" in my stmmac patches to be "pma".

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!