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