netdev - Re: [net-next PATCH 3/8] net: phy: Add 25G-CR, 50G-CR, 100G-CR2 support to C45 genphy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKgT0UduBJYty0WRzQMuzg64rbdMyZ_ubhgOh-q_Df6NPXsA9A@mail.gmail.com>
Date: Tue, 28 Oct 2025 08:25:56 -0700
From: Alexander Duyck <alexander.duyck@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org, kuba@...nel.org, kernel-team@...a.com, 
	andrew+netdev@...n.ch, hkallweit1@...il.com, linux@...linux.org.uk, 
	pabeni@...hat.com, davem@...emloft.net
Subject: Re: [net-next PATCH 3/8] net: phy: Add 25G-CR, 50G-CR, 100G-CR2
 support to C45 genphy

On Tue, Oct 28, 2025 at 5:57 AM Andrew Lunn <andrew@...n.ch> wrote:
>
> On Fri, Oct 24, 2025 at 01:40:53PM -0700, Alexander Duyck wrote:
> > From: Alexander Duyck <alexanderduyck@...com>
> >
> > Add support for 25G-CR, 50G-CR, 50G-CR2, and 100G-CR2 the c45 genphy. Note
> > that 3 of the 4 are IEEE compliant so they are a direct copy from the
> > clause 45 specification, the only exception to this is 50G-CR2 which is
> > part of the Ethernet Consortium specification which never referenced how to
> > handle this in the MDIO registers.

I will go ahead and split this up as you suggested in the other email.

> Does the Ethernet Consortium have other media types which are not in
> 802.3? Does your scheme work for all of them?
>
>         Andrew

Looking at the latest spec on the consortium website
(https://ethernettechnologyconsortium.org/wp-content/uploads/2021/10/Ethernet-Technology-Consortium_800G-Specification_r1.1.pdf)
it looks like they are adding 800G-KR8/CR8 and 400G-KR8/CR8. In the
case of these two we would have to come up with a different approach
as the implementation for them appears to be doing some sort of
bonding of a pair of 4 lane links.

The only other "consortium mode" is another implementation of
25G-KR/CR which I could have followed the same approach on. The IEEE
mode is close enough for now that there wasn't a point in splitting it
off as a type of its own. In fact I got this idea from copying how the
SFP bus code handles this
(https://elixir.bootlin.com/linux/v6.18-rc3/source/drivers/net/phy/sfp-bus.c#L251).
There is already logic that is setting the 25G link capability when it
detects the 100G cable. The general idea would be that we would end up
with the 50R2 eventually slipping in there as well since the same
cable can support all 3 types.

I suppose if we wanted to be more consistent between these setups we
could treat this more like the setup described for the 400/800 setup
and instead of having one PHY doing 1/2 of 100G we could treat it as a
bonded pair of PHYs doing 25G. As it stands I am going to have to
present 2 instances of the PCS/PMA anyway as the vendor config and
RSFEC ultimately has to be setup twice even though we are managing the
core PCS logic through only the first instance.