Ethtool is missing C2C link modes

Ethtool is missing C2C link modes

[D H, Siddaraju]

Hello Linux Ethernet team, Maxime, Andrew & Michal,

The IEEE AUI chip-to-chip (C2C) is the accepted standard for connecting
chips that handle subfunctions within the OSI physical layer. Just to
pick, the C2C is widely used when connecting Ethernet SoCs with retimers
and PCS SerDes terminated external-phys to offload PHY sublayer functions.

With the existing ethtool link modes, we were not able to fit these C2C
interfaces on any others (we fitted **SGMII interfaces to baseT link modes)
and we see this as a gap. If you acknowledge this, we plan to send an
RFC patch to define below listed C2C link modes to ethtool.

	10G_SFI_C2C		SFF-8418
	25G_AUI_C2C		IEEE 802.3 Annex 109A
	CAUI4 C2C		IEEE 802.3 Annex 83D
	LAUI2-C2C		IEEE 802.3 Annex 135B
	50GAUI-1 C2C		IEEE 802.3 Annex 135F
	200GAUI-4 C2C		IEEE 802.3 Annex 120D
	100GAUI-1 C2C		IEEE 802.3ck Annex 120F
	200GAUI-2 C2C		IEEE 802.3ck Clause 162
	400GAUI-4 C2C		IEEE 802.3ck Clause 163

- Thank you,
Siddaraju D H

Re: Ethtool is missing C2C link modes

[Andrew Lunn]

On Fri, Jul 10, 2026 at 09:45:43PM +0000, D H, Siddaraju wrote:
> Hello Linux Ethernet team, Maxime, Andrew & Michal,
> 
> The IEEE AUI chip-to-chip (C2C) is the accepted standard for connecting
> chips that handle subfunctions within the OSI physical layer. Just to
> pick, the C2C is widely used when connecting Ethernet SoCs with retimers
> and PCS SerDes terminated external-phys to offload PHY sublayer functions.

It cannot be that widely used if Linux does not support it yet :-)

> With the existing ethtool link modes, we were not able to fit these C2C
> interfaces on any others (we fitted **SGMII interfaces to baseT link modes)
> and we see this as a gap. If you acknowledge this, we plan to send an
> RFC patch to define below listed C2C link modes to ethtool.
> 
> 	25G_AUI_C2C		IEEE 802.3 Annex 109A

So 109 is about 25GBASE-R. We have the following link modes for that:

       ETHTOOL_LINK_MODE_25000baseCR_Full_BIT  = 31,
       ETHTOOL_LINK_MODE_25000baseKR_Full_BIT  = 32,
       ETHTOOL_LINK_MODE_25000baseSR_Full_BIT  = 33,

Why break the pattern? Why not add:

       ETHTOOL_LINK_MODE_25000baseC2C_Full_BIT

Is C2C that different to CR, KR, DR?

> 	200GAUI-4 C2C		IEEE 802.3 Annex 120D
> 	100GAUI-1 C2C		IEEE 802.3ck Annex 120F
> 	200GAUI-2 C2C		IEEE 802.3ck Clause 162
> 	400GAUI-4 C2C		IEEE 802.3ck Clause 163

If you look at the existing pattern for link modes which need to
specify the number of lanes:

        ETHTOOL_LINK_MODE_800000baseCR8_Full_BIT
        ETHTOOL_LINK_MODE_400000baseDR4_Full_BIT
	ETHTOOL_LINK_MODE_200000baseKR2_Full_BIT

why put the number in the middle?

Since you are breaking the existing pattern, it would be good to
include a justification why you picked your pattern.

Also, an architecture question...

It sounds like you use this between the MAC and the PCS. The PCS can
then be connected to a PHY, and the PHY then has a line side. (I'm
being a bit loose with the terms here, i should probably be saying
PMA, PMD etc.)

Should ethtool be saying:

Settings for eth0:
	Supported ports: [ TP	 MII ]
	Supported link modes:   25000baseC2C

or should it be reporting:

Settings for eth0:
	Supported ports: [ TP	 MII ]
	Supported link modes:   25000baseSR

I _think_ ethtool reports the media, not some intermediary format.

Is ETHTOOL_LINK_MODE_25000baseC2C_Full_BIT actually needed? I suppose
one use case would be when you directly connect two MACs together, PMA
to PMA. So a 25G NIC directly connected to a switch port, with no
'media' in the middle. Then ethtool probably should report
25000baseC2C.

	Andrew

Re: Ethtool is missing C2C link modes

[David Laight]

On Sat, 11 Jul 2026 00:54:00 +0200
Andrew Lunn <andrew@lunn.ch> wrote:

> On Fri, Jul 10, 2026 at 09:45:43PM +0000, D H, Siddaraju wrote:
> > Hello Linux Ethernet team, Maxime, Andrew & Michal,
> > 
> > The IEEE AUI chip-to-chip (C2C) is the accepted standard for connecting
> > chips that handle subfunctions within the OSI physical layer. Just to
> > pick, the C2C is widely used when connecting Ethernet SoCs with retimers
> > and PCS SerDes terminated external-phys to offload PHY sublayer functions.  
> 
> It cannot be that widely used if Linux does not support it yet :-)

It also seems like something that is fixed for a physical board.
So while a common MAC driver would need to be told how to configure
its output, the user wouldn't be changing the value so it would
be more of a DT parameter than an ethtool one.

...
> Also, an architecture question...
> 
> It sounds like you use this between the MAC and the PCS. The PCS can
> then be connected to a PHY, and the PHY then has a line side. (I'm
> being a bit loose with the terms here, i should probably be saying
> PMA, PMD etc.)
> 
> Should ethtool be saying:
> 
> Settings for eth0:
> 	Supported ports: [ TP	 MII ]
> 	Supported link modes:   25000baseC2C
> 
> or should it be reporting:
> 
> Settings for eth0:
> 	Supported ports: [ TP	 MII ]
> 	Supported link modes:   25000baseSR
> 
> I _think_ ethtool reports the media, not some intermediary format.

You'd want to use ethtool to set the final link parameters of the
external phy?
So I think you's still want to be able to select (say) 100MHDX
for a TP link.

Remember the history.
The parameter was originally used to select between the the AUI, COAX and TP
connectors on a 10M ethernet card.
Then the internal TP gained extra speeds.
We then get MII for external 10M and 100M PHY, later RGMII for external Ge PHY.
But you rarely get boards (not MAC chips) that have a choice of interfaces
any more.

> Is ETHTOOL_LINK_MODE_25000baseC2C_Full_BIT actually needed? I suppose
> one use case would be when you directly connect two MACs together, PMA
> to PMA. So a 25G NIC directly connected to a switch port, with no
> 'media' in the middle. Then ethtool probably should report
> 25000baseC2C.

That might be similar to using RGMII crossover to connect to MAC together
(Which does get used on-board).
I'm not sure how we selected that, but overloading the media is 'sort of'
ok because there is no media in that case.

	David

> 
> 	Andrew
> 

Re: Ethtool is missing C2C link modes

[Maxime Chevallier]

Hi,

On 7/11/26 08:31, David Laight wrote:
> On Sat, 11 Jul 2026 00:54:00 +0200
> Andrew Lunn <andrew@lunn.ch> wrote:
> 
>> On Fri, Jul 10, 2026 at 09:45:43PM +0000, D H, Siddaraju wrote:
>>> Hello Linux Ethernet team, Maxime, Andrew & Michal,
>>>
>>> The IEEE AUI chip-to-chip (C2C) is the accepted standard for connecting
>>> chips that handle subfunctions within the OSI physical layer. Just to
>>> pick, the C2C is widely used when connecting Ethernet SoCs with retimers
>>> and PCS SerDes terminated external-phys to offload PHY sublayer functions.  
>>
>> It cannot be that widely used if Linux does not support it yet :-)
> 
> It also seems like something that is fixed for a physical board.
> So while a common MAC driver would need to be told how to configure
> its output, the user wouldn't be changing the value so it would
> be more of a DT parameter than an ethtool one.
> 
> ...
>> Also, an architecture question...
>>
>> It sounds like you use this between the MAC and the PCS. The PCS can
>> then be connected to a PHY, and the PHY then has a line side. (I'm
>> being a bit loose with the terms here, i should probably be saying
>> PMA, PMD etc.)
>>
>> Should ethtool be saying:
>>
>> Settings for eth0:
>> 	Supported ports: [ TP	 MII ]
>> 	Supported link modes:   25000baseC2C
>>
>> or should it be reporting:
>>
>> Settings for eth0:
>> 	Supported ports: [ TP	 MII ]
>> 	Supported link modes:   25000baseSR
>>
>> I _think_ ethtool reports the media, not some intermediary format.
> 
> You'd want to use ethtool to set the final link parameters of the
> external phy?
> So I think you's still want to be able to select (say) 100MHDX
> for a TP link.
> 
> Remember the history.
> The parameter was originally used to select between the the AUI, COAX and TP
> connectors on a 10M ethernet card.
> Then the internal TP gained extra speeds.
> We then get MII for external 10M and 100M PHY, later RGMII for external Ge PHY.
> But you rarely get boards (not MAC chips) that have a choice of interfaces
> any more.

Note that there's ongoing work[1] to better support nics with multiple connectors,
which also includes reporting what the 'media-side' of a MAC / PHY can do :

[1]: https://lore.kernel.org/netdev/20260701110427.143945-1-maxime.chevallier@bootlin.com/#t

Taking the example of a combo-port (SFP + RJ45), it would look like that :

 ethtool --show-ports eth1

Port for eth1:
	Port id: 1
	Supported link modes:  10baseT/Half 10baseT/Full
	                       100baseT/Half 100baseT/Full
	                       1000baseT/Full
	                       10000baseT/Full
	                       2500baseT/Full
	                       5000baseT/Full
	Port type: mdi

Port for eth1:
	Port id: 2
	Supported MII interfaces : 10gbase-r
	Port type: sfp

or even

# ethtool --show-ports eth3

Port for eth3:
	Port id: 1
	Supported MII interfaces : sgmii, 1000base-x, 2500base-x
	Port type: sfp


Now, with this infrastucture also comes the ability to list the media-side
interfaces that are not MDI but rather MII.

The main goal is combo-port support, but also media-converters, e.g. things
like :

MAC ------ PHY ------- <something>
     rgmii      sgmii

(for now, the ongoing series focus on supporting this through SFP, but extending
that to other link types is something I'd like to achieve)

As Andrew says, when you use "ethtool ethX", the list you get is the media-side
modes that you can use at the connector, so it's an aggregated list of the MDI
that are usable based on the MAC, PCS, PHY you're using (MAC and PCS would limit
speed/encoding, PHY defines the actual MDI modes)

For the C2C modes, it's not clear to me if these are MDI modes, i.e:

  ETHTOOL_LINK_MODE_25000baseC2C

Or a phy_interface_t, i.e:

  PHY_INTERFACE_MODE_25GAUI

We already have XAUI and RXAUI as phy_interface_t as of today, so it looks like
we don't want an ethool linkmode for that but rather a phy_interface_t

Maxime

RE: Ethtool is missing C2C link modes

[D H, Siddaraju]

Thank you Andrew, David for bringing up all your questions.
We feel we are trending towards Maxime's intermediate link & reporting
changes but for completeness, we will start answering the open questions,
so you guys can also come up to speed and help make better design choices.

The typical AUI-C2C looks like this
RS <-MII-> PCS - PMA <-AUI-C2C-> PMA ... PMA <-AUI-C2C-> PMA - PMD <-MDI->

Andrew: Is C2C that different to CR, KR, DR?
Siddaraju: Chip-to-Chip(C2C) is simplified version of the complex KR.
	IEEE defined C2C to connect chips that cannot do KR/CR/.., especially
	the complex ANLT state-machine to negotiate, adjust equalizers, etc.

Andrew: Why break the pattern? NNbaseXY vs NN-AUI-C2C
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: Lane numbering at the end-to-end and other patterns..
Siddaraju: The names were just a clean copy-paste from IEEE specs Andrew.
	That was to give a clear pointings to specs and avoid confusions with
	rename/rewordings. Yes, will follow the conventions for the ethtool
	patch sets.

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.

David: fixed, *** more of a DT parameter than an ethtool one.
Siddaraju: I don't think so David, AUI-C2C is not a fixed/one-time config.
	All the HW offload chips that we came across so far and connects over
	AUI are multi-speed capable and depending on the MDI line rate,
	the AUI also needs reconfig/runtime	update to match the speed.
	Say if the SFP is 25G, AUI needs to be set to 25G-AUI-C2C and
	if SFP is 50G, we need 50G-AUI1-C2C.

David: Remember the history......
Siddaraju: Thank you David for highlighting this. We are in alignment with
	you and we are following a strict process to review and gain as much as
	history and conventions especially when dealing with Ethernet. We are
	reaching to multiple folks internally and Vijay Srinivasan(also CC'ed)
	is one such key contributors for us.
	From SW point of view, we are reaching to our internal Linux mailing
	threads and finally coming here for final guidance.
	
Eric: what about AOC, ACC, AEC, etc..?
Siddaraju: that's next for us Eric. We will definitely keep this in mind
	especially while modelling these offloaders.

Maxime: there's ongoing work[1] to *support nics with multiple connectors..
Siddaraju: Thanks Maksim. We are exploring and evaluating this. Meanwhile, 
	hope the above C2C related details helps you make more finer
	recommendation and we hope to hear more.

- Thank you,
Siddaraju D H

Re: Ethtool is missing C2C link modes

[Andrew Lunn]

> 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

Re: Ethtool is missing C2C link modes

[Srinivasan, Vijay]

>From: Andrew Lunn <andrew@lunn.ch>
>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?
From what I can tell, phy_interface_t seems to map to the interface
between PHY and Reconciliation Sublayer (RS). 
The PHY includes PCS, PMA and PMD. PCS was always present (implicit).
Depending on the data rate/throughput this interface could be one of many - 
MII, RMII, GMII, RGMII, SGMII, XGMII, XLGMI, 25GMII, 50GMII, CGMII, 200GMII, 400GMII...
So phy_interface_t will map to one of these.

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

Yes, one lane 100G C2C can be split into 4x25G C2C where both will use CGMII
(notation for 100GMII). The difference is that one lane 100G C2C uses PAM4 modulation
while 25G C2C uses NRZ so the PMD within the PHY changes. Since the throughput is same , 100G, phy_interface_t will be CGMII for both. In order to distinguish how we achieve the 
intended throughput using one or more lanes (n=1/2/4/8 ), AUI-n is defined accordingly
which in turn may be used by FW to select modulation.

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

As for your comment/question about FW vs linux controiling the HW, the intent here
is to use linux to tell FW where to go based on user input.
How the link is eventually achieved is all in FW.  

Vijay

Re: Ethtool is missing C2C link modes

[Andrew Lunn]

> As for your comment/question about FW vs linux controiling the HW, the intent here
> is to use linux to tell FW where to go based on user input.
> How the link is eventually achieved is all in FW.  

I don't see how that works. ethtool has no APIs around
phy_interface_t.  All ethtool offers is link modes. How do you see
this working?

     Andrew

Re: Ethtool is missing C2C link modes

[Srinivasan, Vijay]

> As for your comment/question about FW vs linux controiling the HW, the intent here
> is to use linux to tell FW where to go based on user input.
> How the link is eventually achieved is all in FW.  

> I don't see how that works. ethtool has no APIs around
> phy_interface_t.  All ethtool offers is link modes. How do you see
> this working?

Correct me if I am wrong but isn't that the role of the driver?  
I expect device driver to translate Ethtool link mode argument and pass it to 
FW via driver-FW handshake (device specific SET/GET functions). 
MAC and PHY config. which includes phy_interface_t for that specific link speed 
is then implicitly handled by FW. No other intervention from user should be 
required.

 Vijay

Re: Ethtool is missing C2C link modes

[Andrew Lunn]

On Tue, Jul 21, 2026 at 11:29:05PM +0000, Srinivasan, Vijay wrote:
> > As for your comment/question about FW vs linux controiling the HW, the intent here
> > is to use linux to tell FW where to go based on user input.
> > How the link is eventually achieved is all in FW.  
> 
> > I don't see how that works. ethtool has no APIs around
> > phy_interface_t.  All ethtool offers is link modes. How do you see
> > this working?
> 
> Correct me if I am wrong but isn't that the role of the driver?  
> I expect device driver to translate Ethtool link mode argument and pass it to 
> FW via driver-FW handshake (device specific SET/GET functions). 
> MAC and PHY config. which includes phy_interface_t for that specific link speed 
> is then implicitly handled by FW. No other intervention from user should be 
> required.

It is. But if the driver is talking to firmware, it is using whatever
proprietary values defined by the firmware.

It only makes sense to use phy_interface_t for communication between
different Linux components, or uAPI and a Linux component.

	  Andrew

Re: Ethtool is missing C2C link modes

[Srinivasan, Vijay]

> > As for your comment/question about FW vs linux controiling the HW, the intent here
> > is to use linux to tell FW where to go based on user input.
> > How the link is eventually achieved is all in FW.  
> 
> > I don't see how that works. ethtool has no APIs around
> > phy_interface_t.  All ethtool offers is link modes. How do you see
> > this working?
> 
> Correct me if I am wrong but isn't that the role of the driver?  
> I expect device driver to translate Ethtool link mode argument and pass it to 
> FW via driver-FW handshake (device specific SET/GET functions). 
> MAC and PHY config. which includes phy_interface_t for that specific link speed 
> is then implicitly handled by FW. No other intervention from user should be 
> required.

> It is. But if the driver is talking to firmware, it is using whatever
> proprietary values defined by the firmware.

> It only makes sense to use phy_interface_t for communication between
> different Linux components, or uAPI and a Linux component.

To be precise, what I meant by FW will handle phy_interface_t implicitly is that the
*MII selection (from long list I included in a prior post) is automatically done by 
device FW and not via Linux components or APIs. This step of *MII selection or
configuration may have been handled by Linux components historically (legacy 
implementations) but it is no longer the case with device FW capabilities to manage
link we have today (as someone alluded to in a prior post this being the case
even at the onset of 10G era >20 years ago). 

Vijay

RE: Ethtool is missing C2C link modes

[D H, Siddaraju]

After evaluating the current trends in C2C use-cases (for 10G & higher,
especially the latest gen firmware orchestrated high speed PAM4
signaling), and distinguishing between the ethtool link mode and
the phy_interface_t, we think the ethtool link-mode is still the
correct fit for C2C protocol to model it as the electrical domain
channel/media for establishing links over the following primary use-cases.

 1. System-A <== C2C ==> System-B
    Direct connection with no intermediates. This is clean replacement of
    KR link and user can choose to operate the ethernet interface at all
    various speed and modes of link that exists in KR.

 2. C2C as simplified KR with fixed speed & low reach => no need of ANLT
    The on-board copper-electrical trace interfaces are so well designed,
    and optimized to operate for particular speed by offloading the
    analog signal integrity into the on-board "redriver" chip like
    TI's DS560MB410 or DS560DF410 - like the electrical repeater

- Thank you,
Siddaraju D H

Re: Ethtool is missing C2C link modes

[Eric Joyner]

On 7/10/2026 2:45 PM, D H, Siddaraju wrote:
> Hello Linux Ethernet team, Maxime, Andrew & Michal,
> 
> The IEEE AUI chip-to-chip (C2C) is the accepted standard for connecting
> chips that handle subfunctions within the OSI physical layer. Just to
> pick, the C2C is widely used when connecting Ethernet SoCs with retimers
> and PCS SerDes terminated external-phys to offload PHY sublayer functions.
> 
> With the existing ethtool link modes, we were not able to fit these C2C
> interfaces on any others (we fitted **SGMII interfaces to baseT link modes)
> and we see this as a gap. If you acknowledge this, we plan to send an
> RFC patch to define below listed C2C link modes to ethtool.
> 
> 	10G_SFI_C2C		SFF-8418
> 	25G_AUI_C2C		IEEE 802.3 Annex 109A
> 	CAUI4 C2C		IEEE 802.3 Annex 83D
> 	LAUI2-C2C		IEEE 802.3 Annex 135B
> 	50GAUI-1 C2C		IEEE 802.3 Annex 135F
> 	200GAUI-4 C2C		IEEE 802.3 Annex 120D
> 	100GAUI-1 C2C		IEEE 802.3ck Annex 120F
> 	200GAUI-2 C2C		IEEE 802.3ck Clause 162
> 	400GAUI-4 C2C		IEEE 802.3ck Clause 163
> 
> - Thank you,
> Siddaraju D H
> 

I'll piggyback on this thread because I have a related question about missing
ethtool link modes: what about entries for various Active Cable types? e.g. AOC,
ACC, and AEC for the appropriate speeds.

I see some drivers (like i40e and ice) detect these and map them to SR or DA/CR
types, but I don't see them do it in a consistent pattern, either. I couldn't
find anything that suggested a precedent on how to handle these.

- Eric