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: <b1a3229b-50cc-4f99-a5fd-54335f1a8f83@lunn.ch>
Date: Tue, 28 Oct 2025 23:40:14 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>
Cc: Alexander Duyck <alexander.duyck@...il.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 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.

	Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ