| 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: <aM-t4IBZFFHE9f-V@shredder>
Date: Sun, 21 Sep 2025 10:48:48 +0300
From: Ido Schimmel <idosch@...sch.org>
To: 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, 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.
> + 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;
> + }
Powered by blists - more mailing lists