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

[Leon Romanovsky <leon@kernel.org>]

On Thu, Jun 12, 2025 at 02:41:33PM +0200, Andrew Lunn wrote:
> 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.

How exactly they can hide speed declarations in the FW and still support it?

In addition, it is unclear what the last sentence means. FBNIC has FW like
any other device. The main difference is that Meta doesn't need to support
gazillion customers and can use same FW across their fleet without need
to configure it, (According to open source information).
https://docs.kernel.org/networking/device_drivers/ethernet/meta/fbnic.html

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

I didn't expect anything different here. This is exactly how agreed
boundaries are pushed - salami slicing.

Thanks

> 
> 	Andrew
>