netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ido Schimmel <idosch@idosch.org>
To: Mohsin Bashir <mohsin.bashr@gmail.com>
Cc: netdev@vger.kernel.org, alexanderduyck@fb.com, kuba@kernel.org,
	andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
	gustavoars@kernel.org, horms@kernel.org,
	jacob.e.keller@intel.com, kees@kernel.org, kernel-team@meta.com,
	lee@trager.us, linux@armlinux.org.uk, pabeni@redhat.com,
	sanman.p211993@gmail.com, suhui@nfschina.com,
	vadim.fedorenko@linux.dev
Subject: Re: [PATCH net-next] eth: fbnic: Read module EEPROM
Date: Sun, 21 Sep 2025 10:48:48 +0300	[thread overview]
Message-ID: <aM-t4IBZFFHE9f-V@shredder> (raw)
In-Reply-To: <20250919191624.1239810-1-mohsin.bashr@gmail.com>

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@kernel.org>
> Signed-off-by: Mohsin Bashir <mohsin.bashr@gmail.com>

Reviewed-by: Ido Schimmel <idosch@nvidia.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.

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

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

> +		dev_warn(fbd->dev, "page not equal to page requested: %d vs %d\n",
> +			 page, cmpl_data->u.qsfp.page);
> +		err = -EINVAL;
> +		goto msg_err;
> +	}

  parent reply	other threads:[~2025-09-21  7:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-19 19:16 [PATCH net-next] eth: fbnic: Read module EEPROM Mohsin Bashir
2025-09-19 19:25 ` Andrew Lunn
2025-09-21 23:36   ` Alexander H Duyck
2025-09-21  7:48 ` Ido Schimmel [this message]
2025-09-21 23:45   ` Alexander H Duyck
2025-09-22 16:56   ` Mohsin Bashir

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=aM-t4IBZFFHE9f-V@shredder \
    --to=idosch@idosch.org \
    --cc=alexanderduyck@fb.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gustavoars@kernel.org \
    --cc=horms@kernel.org \
    --cc=jacob.e.keller@intel.com \
    --cc=kees@kernel.org \
    --cc=kernel-team@meta.com \
    --cc=kuba@kernel.org \
    --cc=lee@trager.us \
    --cc=linux@armlinux.org.uk \
    --cc=mohsin.bashr@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sanman.p211993@gmail.com \
    --cc=suhui@nfschina.com \
    --cc=vadim.fedorenko@linux.dev \
    /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).