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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAKgT0Uda5RJxDkfjXGaVtLGNtRxjd95PLsHLtyjqR6CoH0jg=w@mail.gmail.com>
Date: Tue, 28 Oct 2025 15:49:52 -0700
From: Alexander Duyck <alexander.duyck@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Maxime Chevallier <maxime.chevallier@...tlin.com>, 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 3:40 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> On Tue, Oct 28, 2025 at 08:32:03AM +0100, Maxime Chevallier wrote:
> > Hi Alexander,
> >
> > On 24/10/2025 22:40, 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.
> > >
> > > Since 50GBase-CR2 isn't an IEEE standard it doesn't have a value in the
> > > extended capabilities registers. To account for that I am adding a define
> > > that is aliasing the 100GBase-CR4 to represent it as that is the media type
> > > used to carry data for 50R2, it is just that the PHY is carrying two 2 with
> > > 2 lanes each over the 4 lane cable. For now I am representing it with ctrl1
> > > set to 50G and ctrl2 being set to 100R4, and using the 100R4 capability to
> > > identify if it is supported or not.I
> >
> > If 50GBase-CR2 isn't part of IEEE standards and doesn't appear in the
> > C45 ext caps, does it really belong in a genphy helper ?
>
> I agree with you here. We should not pollute our nice clean 802.3
> implementation. If the Ethernet Consortium had defined how these modes
> are represented in MDIO registers, we could of added helpers which
> look at the vendor registers they chose to use. We have done this in
> the past, for the Open Alliance TC14 10BASE-T1S PLCA. But since each
> vendor is going to implement this differently, it should not be in the
> core.
>
> > You should be able to support it through the .config_aneg() callback in
> > the PHY driver.
>
> It is probably a little more than .config_aneg(), but yes.
>
> I assume FB/META have an OUI for their MAC addresses? I _think_ the
> same OUI can be used for registers 2 and 3 in MDIO. So your fake PHY
> can indicate it is a FB/META PHY and cause the FB/META PHY driver to
> load. The .get_features callback can append this 50GBase-CR2 link
> mode. The .read_status() can indicate if it is in use etc. And you can
> do all the other link modes by just calling the helpers. I assume you
> are currently using the genphy_c45_driver? That can be used as a
> template.

Yeah, I was already starting down some of this path as I was going to
have to provide a FB/META PMA ID in order to work with the XPCS driver
in terms of handling the config.

I can probably look at pushing the fixes to get the handling of the
PHY ID sorted out and then look at adding a new driver to handle the
50R2 without touching the genphy code for now.