Re: Ethtool is missing C2C link modes
From: Andrew Lunn <andrew@lunn.ch>
Date: 2026-07-14 19:43:59
Siddaraju: baseR is an end-to-end physical layer type that clearly defines the interface & components stating from MAC RS(Reconciliation Sublayer) till the PMD + MDI signallings. AUI is an intermediate electrical interface layer(simplified KR) that connects 2 PMAs (PMA <=== AUI ===> PMA). AUI is a split function design approach where subfunction implementation from multiple vendors come together to exploit their domain expertise to produce a best Ethernet interconnect.
Andrew: I _think_ ethtool reports the media, not some intermediary format. Is ETHTOOL_LINK_MODE_25000baseC2C_Full_BIT actually needed? Siddaraju: We are here to find out that Andrew :). If we are following the strict convention that ethtool link modes report & represents the end-to-end flow "ONLY", then yes, AUI doesn't fit there. We are exploring phy_interface_t for intermediate interfaces and we hope we don't hit any roadblocks. Let's see.
Given these two answer, phy_interface_t is a better fit. I'm however not sure it is fully correct. Historically, it was used to indicate the interface between the MAC and base-T PHYs. PCS and PMD either did not exist, or was an invisible layer, back in those days. At that point phy_interface_t was the bottom of the reconciliation layer? The introduction of SGMII and 1000BaseX made PCS a thing, even if initially it was generally hidden away. PHY_INTERFACE_MODE_SGMII then corresponds to the bottom of the PCS, with the Base-T PHY also talking SGMII. phy_interface_t then moves from the reconciliation layer to a lower layer? So what exactly does phy_interface_t mean? And historically, we have only had a single phy_interface_t value. Are there use cases for needing different C2C values are different layers? Could you have a single lane 100G C2C split into 4 lanes of 25G C2C? Another thing we should consider. Most NICs above 10G currently don't have Linux controlling the hardware. These lower layers are all hidden away in firmware. For you hardware, is Linux actually controlling any of this? Are you adding support to phylink for these intermediary building blocks? Should Linux currently care about C2C? Andrew