Hi again Björn, First, thanks for iterating so quick !
On 10/03/2026 11:47, Björn Töpel wrote: > Add the netlink YAML spec and auto-generated UAPI header for a unified > loopback interface covering MAC, PCS, PHY, and pluggable module > components. > > Each loopback point is described by a nested entry attribute > containing: > > - component where in the path (MAC, PCS, PHY, MODULE) > - name subsystem label, e.g. "cmis-host" or "cmis-media" > - id optional instance selector (e.g. PHY id, port id) > - supported bitmask of supported directions > - direction NEAR_END, FAR_END, or 0 (disabled) > > Signed-off-by: Björn Töpel <[email protected]> > --- > Documentation/netlink/specs/ethtool.yaml | 123 ++++++++++++++++++ > .../uapi/linux/ethtool_netlink_generated.h | 59 +++++++++ > 2 files changed, 182 insertions(+) > > diff --git a/Documentation/netlink/specs/ethtool.yaml > b/Documentation/netlink/specs/ethtool.yaml > index 4707063af3b4..8bd14a3c946a 100644 > --- a/Documentation/netlink/specs/ethtool.yaml > +++ b/Documentation/netlink/specs/ethtool.yaml > @@ -211,6 +211,49 @@ definitions: > name: discard > value: 31 > > + - > + name: loopback-component > + type: enum > + doc: | > + Loopback component. Identifies where in the network path the > + loopback is applied. > + entries: > + - > + name: mac > + doc: MAC loopback. Loops traffic at the MAC block. > + - > + name: pcs > + doc: | > + PCS loopback. Loops traffic at the PCS sublayer between the > + MAC and the PHY. > + - > + name: phy > + doc: | > + Ethernet PHY loopback. This refers to the Ethernet PHY managed > + by phylib, not generic PHY drivers. A Base-T SFP module > + containing an Ethernet PHY driven by Linux should report > + loopback under this component, not module. > + - > + name: module > + doc: | > + Pluggable module (e.g. CMIS (Q)SFP) loopback. Covers loopback > + modes controlled via module firmware or EEPROM registers. When > + Linux drives an Ethernet PHY inside the module via phylib, use > + the phy component instead. So to get back on Andrew's remarks, let's see if we can get something closer to 802.3. Here, we have loopback at various locations, which all depends on the Ethernet standard you use. It's usually in the PCS, PMA or PMD components. Thing is, we may have these in multiple places in our link. If we take an example with a 10G PHY, we may have : +----SoC-----+ | | | MAC |- drivers/net/ethernet | | | | Base-R PCS |- could be in drivers/net/pcs, or directly | | | in the MAC driver | | | | SerDes |- May be in drivers/phy, maybe handled by firmware, | | | maybe by the MAC driver, maybe by the PCS driver ? +---|--------+ | | 10GBase-R | +---|-PHY+ | | | | SerDes | \ | | | | | PCS | | | | | > All of that handled by the drivers/net/phy PHY driver | PMA | | | | | | | PMD | / +---|----+ | v 10GBaseT So even the "PCS" loopback component is a bit ambiguous, are we talking about the PHY PCS or the MAC PCS ? Another thing to consider is that there may be multiple PCSs in the SoC (e.g. a BaseX and a BaseR PCS like we have in mvpp2), the one in use depends on the current interface between the MAC and the PHY. Another open question is, do we deal with loopbacks that may affect multi-netdev links ? Like the multi-lane modes we discussed with fbnic, or even for embedded, interfaces such as QSGMII ? As for the SerDes on the MAC side (say, the comphy on Marvell devices), can we say it's a PMA for 10GBase-KR ? Or is it something that's simply out of spec ? So I'd say, maybe we should not have a PCS loopback component at all, but instead loopback at the well-defined components on our link, that is: - MAC => MAC loopack, PCS on the MAC side, SerDes on the SoC, etc. - PHY => Loopbacks on the PCS/PHY/PMA withing the PHY device - Module => For non-PHY (Q)SFPs The important part would therefore to get the "name" part right, making sure we don't fall into driver specific names. We can name that 'pcs', 'pma', 'pmd', or maybe even 'mii' ? Let's see : +----SoC-----+ | | | MAC |- component = MAC, name = 'mac' | | | | Base-R PCS |- component = MAC, name = 'pcs' | | | | | | | SerDes |- component = MAC, name = 'mii' ? | | | +---|--------+ | | 10GBase-R | +---|-PHY+ | | | | SerDes | - component = PHY, name = 'mii' ? | | | | PCS | - component = PHY, name = 'pcs' | | | | PMA | - component = PHY, name = 'pma' | | | | PMD |- component = PHY, name = 'pmd' or 'mdi' ? +---|----+ | v 10GBaseT Sorry that's a lot of questions and I don't expect you to have the answer, but as what you've come-up with is taking a good shape, it's important to decide on the overall design and draw some lines about what do we support, and how :( > + - > + name: loopback-direction > + type: flags > + doc: | > + Loopback direction flags. Used as a bitmask in supported, and as > + a single value in direction. > + entries: > + - > + name: near-end > + doc: Near-end loopback; host-loop-host > + - > + name: far-end > + doc: Far-end loopback; line-loop-line I was browsing 802.3, it uses the terminlogy of "local loopback" vs "remote loopback", I suggest we use those. Maxime
