netdev - Re: [net-next PATCH 0/6] Add support for 25G, 50G, and 100G to fbnic

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: <daa8bb61-5b6c-49ab-8961-dc17ef2829bf@lunn.ch>
Date: Thu, 12 Jun 2025 14:41:33 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Leon Romanovsky <leon@...nel.org>
Cc: Alexander Duyck <alexander.duyck@...il.com>, netdev@...r.kernel.org,
	linux@...linux.org.uk, hkallweit1@...il.com, davem@...emloft.net,
	pabeni@...hat.com, kuba@...nel.org, Jiri Pirko <jiri@...dia.com>
Subject: Re: [net-next PATCH 0/6] Add support for 25G, 50G, and 100G to fbnic

On Thu, Jun 12, 2025 at 12:42:34PM +0300, Leon Romanovsky wrote:
> On Tue, Jun 10, 2025 at 07:51:08AM -0700, Alexander Duyck wrote:
> > The fbnic driver up till now had avoided actually reporting link as the
> > phylink setup only supported up to 40G configurations. This changeset is
> > meant to start addressing that by adding support for 50G and 100G interface
> > types as well as the 200GBASE-CR4 media type which we can run them over.
> > 
> > With that basic support added fbnic can then set those types based on the
> > EEPROM configuration provided by the firmware and then report those speeds
> > out using the information provided via the phylink call for getting the
> > link ksettings. This provides the basic MAC support and enables supporting
> > the speeds as well as configuring flow control.
> > 
> > After this I plan to add support for a PHY that will represent the SerDes
> > PHY being used to manage the link as we need a way to indicate link
> > training into phylink to prevent link flaps on the PCS while the SerDes is
> > in training, and then after that I will look at rolling support for our
> > PCS/PMA into the XPCS driver.
> 
> <...>
> 
> > Alexander Duyck (6):
> >       net: phy: Add interface types for 50G and 100G
> 
> <...>
> 
> >  drivers/net/phy/phy-core.c                    |   3 +
> >  drivers/net/phy/phy_caps.c                    |   9 ++
> >  drivers/net/phy/phylink.c                     |  13 ++
> >  drivers/net/phy/sfp-bus.c                     |  22 +++
> >  include/linux/phy.h                           |  12 ++
> >  include/linux/sfp.h                           |   1 +
> >  14 files changed, 257 insertions(+), 88 deletions(-)
> 
> when the fbnic was proposed for merge, the overall agreement was that
> this driver is ok as long as no-core changes will be required for this
> driver to work and now, year later, such changes are proposed here.

I would say these are natural extensions to support additional speeds
in the 'core'. We always said fbnic would be pushing the edges of the
linux core support for SFP, because all other vendors in this space
reinvent the wheel and hide it away in firmware. fbnic is different
and Linux is actually driving the hardware.

There are no algorithmic changes here, no maintenance burden, it is
following IEEE, and it will be useful for other devices in the
future. So as one of the Maintainers of this code, i'm happy to accept
this, with the usual proviso it compiles without warnings, checkpatch
clean, Russell is also happy with it, etc.

	Andrew