Hi all, On Wed, Mar 11, 2026 at 08:33:26AM +0100, Maxime Chevallier wrote: > 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.
I do not want to overload this initial series with complex topology problems, but we must ensure the proposed UAPI does not block future extensions. I am currently investigating automated datapath diagnostic, and a flat component + name model will eventually fail us. Looking at the current patch: - component (MAC, PCS, PHY, MODULE) - name (subsystem label) - id (local instance selector) - direction (near-end / far-end): These terms become highly ambiguous in branching topologies (like CPU port on DSA switches). mixed loopbacks across complex interconnects, userspace will eventually need a Directed Acyclic Graph (DAG) model. By adopting a DAG topology now, we can reduce the load on the initial implementation and bypass much of the ongoing naming discussions, as components are identified by their topological relations rather than arbitrary string labels. Can we design the netlink attributes now to ensure we are not blocked from adding the following fields later: - node_id: Global system ID. This also allows us to attach more diagnostic points (e.g., hardware counters) to exact subcomponents. - parent_node_id: Upstream pointer for tree reconstruction. - action: Bitmask of hardware modes (e.g., LOOPBACK, GENERATE) to allow simultaneous operations on a single node. See 6.3.1.3.1 Loopback Modes in: https://www.ti.com/lit/ds/symlink/dp83tg720s-q1.pdf?ts=1773225830126 - supported_actions: Bitmask of capabilities (e.g., can this node do LOOPBACK and GENERATE simultaneously?). - direction: Towards parent / from parent. - operational_constraints: MTU limits (e.g., FEC corrupts loopbacks >1522 bytes), clock injection requirements (e.g., stmmac requires external Rx clocks), and required interface modes (e.g. loopback on FEC works only in MII mode) If we hardcode a flat list assumption into the framework now, it will break when we try to automate tests across datapath forks (e.g., SoC -> DSA Switch -> PHYs) or handle complex industrial PHYs... :) Best Regards, Oleksij -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
