netdev - Re: [PATCH net-next] eth: fbnic: Read module EEPROM

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: <fe7eb1335c11ae91cf6b28d37d1f24daccb2c65d.camel@gmail.com>
Date: Sun, 21 Sep 2025 16:36:58 -0700
From: Alexander H Duyck <alexander.duyck@...il.com>
To: Andrew Lunn <andrew@...n.ch>, Mohsin Bashir <mohsin.bashr@...il.com>
Cc: netdev@...r.kernel.org, alexanderduyck@...com, kuba@...nel.org, 
	andrew+netdev@...n.ch, davem@...emloft.net, edumazet@...gle.com, 
	gustavoars@...nel.org, horms@...nel.org, jacob.e.keller@...el.com,
 kees@...nel.org, 	kernel-team@...a.com, lee@...ger.us,
 linux@...linux.org.uk, pabeni@...hat.com, 	sanman.p211993@...il.com,
 suhui@...china.com, vadim.fedorenko@...ux.dev
Subject: Re: [PATCH net-next] eth: fbnic: Read module EEPROM

On Fri, 2025-09-19 at 21:25 +0200, Andrew Lunn wrote:
> On Fri, Sep 19, 2025 at 12:16:24PM -0700, Mohsin Bashir wrote:
> > Add support to read module EEPROM for fbnic. Towards this, add required
> > support to issue a new command to the firmware and to receive the response
> > to the corresponding command.
> > 
> > Create a local copy of the data in the completion struct before writing to
> > ethtool_module_eeprom to avoid writing to data in case it is freed. Given
> > that EEPROM pages are small, the overhead of additional copy is
> > negligible.
> > 
> > Signed-off-by: Jakub Kicinski <kuba@...nel.org>
> > Signed-off-by: Mohsin Bashir <mohsin.bashr@...il.com>
> > ---
> >  .../net/ethernet/meta/fbnic/fbnic_ethtool.c   |  66 +++++++++
> >  drivers/net/ethernet/meta/fbnic/fbnic_fw.c    | 135 ++++++++++++++++++
> >  drivers/net/ethernet/meta/fbnic/fbnic_fw.h    |  22 +++
> >  3 files changed, 223 insertions(+)
> > 
> > diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_ethtool.c b/drivers/net/ethernet/meta/fbnic/fbnic_ethtool.c
> > index b4ff98ee2051..f6069cddffa5 100644
> > --- a/drivers/net/ethernet/meta/fbnic/fbnic_ethtool.c
> > +++ b/drivers/net/ethernet/meta/fbnic/fbnic_ethtool.c
> > @@ -1635,6 +1635,71 @@ static void fbnic_get_ts_stats(struct net_device *netdev,
> >  	}
> >  }
> >  
> > +static int
> > +fbnic_get_module_eeprom_by_page(struct net_device *netdev,
> > +				const struct ethtool_module_eeprom *page_data,
> > +				struct netlink_ext_ack *extack)
> > +{
> > +	struct fbnic_net *fbn = netdev_priv(netdev);
> > +	struct fbnic_fw_completion *fw_cmpl;
> > +	struct fbnic_dev *fbd = fbn->fbd;
> > +	int err;
> > +
> > +	if (page_data->i2c_address != 0x50) {
> > +		NL_SET_ERR_MSG_MOD(extack,
> > +				   "Invalid i2c address. Only 0x50 is supported");
> > +		return -EINVAL;
> > +	}
> > +
> > +	if (page_data->bank != 0) {
> > +		NL_SET_ERR_MSG_MOD(extack,
> > +				   "Invalid bank. Only 0 is supported");
> > +		return -EINVAL;
> > +	}
> > +
> > +	fw_cmpl = __fbnic_fw_alloc_cmpl(FBNIC_TLV_MSG_ID_QSFP_READ_RESP,
> > +					page_data->length);
> > +	if (!fw_cmpl)
> > +		return -ENOMEM;
> > +
> > +	/* Initialize completion and queue it for FW to process */
> > +	fw_cmpl->u.qsfp.length = page_data->length;
> > +	fw_cmpl->u.qsfp.offset = page_data->offset;
> > +	fw_cmpl->u.qsfp.page = page_data->page;
> > +	fw_cmpl->u.qsfp.bank = page_data->bank;
> > +
> > +	err = fbnic_fw_xmit_qsfp_read_msg(fbd, fw_cmpl, page_data->page,
> > +					  page_data->bank, page_data->offset,
> > +					  page_data->length);
> > +	if (err) {
> > +		NL_SET_ERR_MSG_MOD(extack,
> > +				   "Failed to transmit EEPROM read request");
> > +		goto exit_free;
> > +	}
> 
> At some point, you are going to hand off control of the I2C bus to
> phylink, so it can drive the SFP. I know Alex at least had a plan how
> that will work. At that point, will you just throw this away, and let
> sfp_get_module_eeprom_by_page() implement this?
> 
> 	Andrew

That would be the general idea. The fbnic_fw_xmit_qsfp_read_msg will
still have to exist as it is essentially the firmware provided front
end to issue a I2C read request to the QSFP module.

I have code that essentially does that somewhere in one of my patch
sets as I had coded it up as proof-of-concept. I am hoping to wrap up
the phydev/phylink code this half. Unfortunately I haven't had a ton of
time as I have been getting pulled in several different directions
lately.

The larger hurdles I am still trying to sort out are adding support for
25/50/100G to a generic clause 45 phydev support in order to support
the fact that we need to deal with a 4s delay due to the PMD needing
time for link training, and then I have to go through and sort out the
PCS/PMA code which may be a bit messy as it looks like XPCS was already
added, but it only seems to support 40G so I will have to sort that
out.