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;
> + }
next prev 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).