From: Leon Romanovsky <leon@kernel.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Alexander Duyck <alexander.duyck@gmail.com>,
netdev@vger.kernel.org, linux@armlinux.org.uk,
hkallweit1@gmail.com, davem@davemloft.net, pabeni@redhat.com,
kuba@kernel.org, Jiri Pirko <jiri@nvidia.com>
Subject: Re: [net-next PATCH 0/6] Add support for 25G, 50G, and 100G to fbnic
Date: Fri, 13 Jun 2025 19:00:24 +0300 [thread overview]
Message-ID: <20250613160024.GC436744@unreal> (raw)
In-Reply-To: <52be06d0-ad45-4e8c-9893-628ba8cebccb@lunn.ch>
On Thu, Jun 12, 2025 at 08:29:07PM +0200, Andrew Lunn wrote:
> > > > 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?
>
> You obviously did not spend time to look at the code and understand
> what it is doing. This is used to map the EEPROM contents of the SFP
> to how the PCS etc should be configured. So far, this has only been
> used for speeds up to 10Gbps. This code is mostly used by SoCs, and at
> the moment most SoCs inbuilt interfaces top out at 10G. fbnic is
> pushing this core code to higher speeds.
>
> You can easily hide speed declarations in firmware and still support
> it because we are not talking about the ethtool API here. This is a
> lower level. A FW driven device will have its own code for parsing the
> SFP EEPROM and configuring the PCS etc, without needing anything from
> Linux.
Excellent, like you said, no one needs this code except fbnic, which is
exactly as was agreed - no core in/out API changes special for fbnic.
>
> > In addition, it is unclear what the last sentence means. FBNIC has FW like
> > any other device.
>
> From what i have seen, it has a small amount of firmware.
Initial claim was no-FW, now we are talking about "small amount".
There is no fbnic devices in the market, FW is not open-source to
justify the last claim.
> However, Linux is actually controlling most of the hardware.
Even this claim contradicts their own press releases:
https://www.marvell.com/company/newsroom/marvell-delivers-custom-ethernet-network-interface-controller-solution-at-ocp.html
"Complete firmware control with access to all hardware internals enabling the ability
to deliver innovative customized capabilities and reduce mean time to resolve potential
issues."
Thanks
next prev parent reply other threads:[~2025-06-13 16:00 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-10 14:51 [net-next PATCH 0/6] Add support for 25G, 50G, and 100G to fbnic Alexander Duyck
2025-06-10 14:51 ` [net-next PATCH 1/6] net: phy: Add interface types for 50G and 100G Alexander Duyck
2025-06-10 14:51 ` [net-next PATCH 2/6] fbnic: Do not consider mailbox "initialized" until we have verified fw version Alexander Duyck
2025-06-10 14:51 ` [net-next PATCH 3/6] fbnic: Replace 'link_mode' with 'aui' Alexander Duyck
2025-06-11 21:00 ` Jakub Kicinski
2025-06-11 21:17 ` Alexander Duyck
2025-06-10 14:51 ` [net-next PATCH 4/6] fbnic: Set correct supported modes and speeds based on FW setting Alexander Duyck
2025-06-10 14:51 ` [net-next PATCH 5/6] fbnic: Add support for reporting link config Alexander Duyck
2025-06-10 14:51 ` [net-next PATCH 6/6] fbnic: Add support for setting/getting pause configuration Alexander Duyck
2025-06-12 9:42 ` [net-next PATCH 0/6] Add support for 25G, 50G, and 100G to fbnic Leon Romanovsky
2025-06-12 12:41 ` Andrew Lunn
2025-06-12 17:31 ` Leon Romanovsky
2025-06-12 18:29 ` Andrew Lunn
2025-06-13 16:00 ` Leon Romanovsky [this message]
2025-06-13 22:43 ` Russell King (Oracle)
2025-06-14 16:26 ` Alexander Duyck
2025-06-16 9:49 ` Russell King (Oracle)
2025-06-16 15:27 ` Alexander Duyck
2025-06-16 10:33 ` Leon Romanovsky
2025-06-16 11:35 ` Russell King (Oracle)
2025-06-16 15:19 ` Leon Romanovsky
2025-06-16 14:39 ` Alexander Duyck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250613160024.GC436744@unreal \
--to=leon@kernel.org \
--cc=alexander.duyck@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=hkallweit1@gmail.com \
--cc=jiri@nvidia.com \
--cc=kuba@kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).