| 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
| ||
|
Message-ID: <27b6b801c4cfbef1d5da95dab6d0305512874c2b.camel@gmail.com>
Date: Sun, 21 Sep 2025 16:45:12 -0700
From: Alexander H Duyck <alexander.duyck@...il.com>
To: Ido Schimmel <idosch@...sch.org>, 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 Sun, 2025-09-21 at 10:48 +0300, Ido Schimmel 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>
>
> Reviewed-by: Ido Schimmel <idosch@...dia.com>
>
> See a few questions below
>
> > ---
> > .../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) {
>
> What is the reason for this check?
>
> I understand that it's very unlikely to have a transceiver with banked
> pages connected to this NIC (requires more than 8 lanes), but it's
> generally better to not restrict this ethtool operation unless you have
> a good reason to, especially when the firmware seems to support banked
> pages.
>
I believe the origin of this is that for now we don't have any parts
that are making use of that field. If I recall the test systems are
running with QSFP-28.
That said I do agree we would probably change this out. I believe in
the original code we had as set of checks to enforce limitations on the
size and offset like below. Perhaps we would be better off with those:
/* Nothing to do if read size is 0 */
if (size == 0)
return 0;
/* Limit reads to current page only, truncate the size to fit
* current page only
*/
if (offset < 128 && (offset + size) > 128)
size = 128 - offset;
/* If page or bank are set we are in paged mode, only support
* offsets greater than 128
*/
if ((page || bank) && offset < 128)
return -EINVAL;
if (offset + size > 256)
return -EINVAL;
> > + 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,
>
> QSFP is not the most accurate term, but I assume it's named that way to
> be consistent with the HW/FW data sheet.
>
Yeah, it is the way the FW identifies the I2C bus in question. It is
referred to as the "QSFP" bus.
> > + 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;
> > + }
> > +
> > + if (!wait_for_completion_timeout(&fw_cmpl->done, 2 * HZ)) {
> > + err = -ETIMEDOUT;
> > + NL_SET_ERR_MSG_MOD(extack,
> > + "Timed out waiting for firmware response");
> > + goto exit_cleanup;
> > + }
> > +
> > + if (fw_cmpl->result) {
> > + err = fw_cmpl->result;
> > + NL_SET_ERR_MSG_MOD(extack, "Failed to read EEPROM");
> > + goto exit_cleanup;
> > + }
> > +
> > + memcpy(page_data->data, fw_cmpl->u.qsfp.data, page_data->length);
> > +
> > +exit_cleanup:
> > + fbnic_mbx_clear_cmpl(fbd, fw_cmpl);
> > +exit_free:
> > + fbnic_fw_put_cmpl(fw_cmpl);
> > +
> > + return err ? : page_data->length;
> > +}
>
> [...]
>
> > +static int fbnic_fw_parse_qsfp_read_resp(void *opaque,
> > + struct fbnic_tlv_msg **results)
> > +{
> > + struct fbnic_fw_completion *cmpl_data;
> > + struct fbnic_dev *fbd = opaque;
> > + struct fbnic_tlv_msg *data_hdr;
> > + u32 length, offset, page, bank;
> > + u8 *data;
> > + s32 err;
> > +
> > + /* Verify we have a completion pointer to provide with data */
> > + cmpl_data = fbnic_fw_get_cmpl_by_type(fbd,
> > + FBNIC_TLV_MSG_ID_QSFP_READ_RESP);
> > + if (!cmpl_data)
> > + return -ENOSPC;
> > +
> > + bank = fta_get_uint(results, FBNIC_FW_QSFP_BANK);
> > + if (bank != cmpl_data->u.qsfp.bank) {
> > + dev_warn(fbd->dev, "bank not equal to bank requested: %d vs %d\n",
> > + bank, cmpl_data->u.qsfp.bank);
> > + err = -EINVAL;
> > + goto msg_err;
> > + }
> > +
> > + page = fta_get_uint(results, FBNIC_FW_QSFP_PAGE);
> > + if (page != cmpl_data->u.qsfp.page) {
>
> Out of curiosity, can this happen if user space tries to access a page
> that is not supported by the transceiver? I believe most implementations
> do not return an error in this case.
I believe this is meant to handle a possible race or out-of-order
condition on the FW mailbox in which we time-out one request, and then
immediately issue another. Essentially if we end up getting a
completion for a similar message, but it is for a different page/bank
or offset then we return an error instead of reporting it on the
completion.
Powered by blists - more mailing lists