All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla@dpdk.org
To: dev@dpdk.org
Subject: [DPDK/ethdev Bug 2100] net/ice: ice_get_module_eeprom() silently returns zeroed data when all I2C read retries fail
Date: Mon, 09 Nov 2026 15:43:09 +0000	[thread overview]
Message-ID: <bug-2100-3@https.bugs.dpdk.org/> (raw)

https://bugs.dpdk.org/show_bug.cgi?id=2100

            Bug ID: 2100
           Summary: net/ice: ice_get_module_eeprom() silently returns
                    zeroed data when all I2C read retries fail
           Product: DPDK
           Version: unspecified
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: ethdev
          Assignee: dev@dpdk.org
          Reporter: marcel@telka.sk
  Target Milestone: ---

https://github.com/DPDK/dpdk/blob/a13c1053360ee26bbacca9f883d3f3cb83a0f366/drivers/net/intel/ice/ice_ethdev.c#L6742-L6767

for (j = 0; j < I2C_BUSY_TRY_TIMES; j++) {
        status = ice_aq_sff_eeprom(hw, 0, addr, offset,
                                   page, !is_sfp, value,
                                   SFF_READ_BLOCK_SIZE,
                                   0, NULL);
        PMD_DRV_LOG(DEBUG, "SFF %02X %02X %02X %X = "
                "%02X%02X%02X%02X."
                "%02X%02X%02X%02X (%X)",
                addr, offset, page, is_sfp,
                value[0], value[1],
                value[2], value[3],
                value[4], value[5],
                value[6], value[7],
                status);
        if (status) {
                usleep_range(I2C_USLEEP_MIN_TIME,
                             I2C_USLEEP_MAX_TIME);
                memset(value, 0, SFF_READ_BLOCK_SIZE);
                continue;
        }
        break;
}

/* Make sure we have enough room for the new block */
if ((i + SFF_READ_BLOCK_SIZE) <= info->length)
        memcpy(data + i, value, SFF_READ_BLOCK_SIZE);

Two separate problems in this retry loop's failure handling:

1. Zeroed data accepted as a successful read. status is never checked
after the loop exits. If all I2C_BUSY_TRY_TIMES (4) attempts fail, value
has been memset to zero by the last failed attempt, and that zeroed
block is still unconditionally copied into the output buffer as if
valid. The function falls through to return 0 (success) regardless.
A persistent I2C/admin-queue failure for any single 8-byte block -- the
comment directly above this code acknowledges I2C bus contention with
NIC link management is "normal" -- is therefore silently reported as a
successful read, with that block's bytes coming back all-zero,
indistinguishable from genuine zero-valued EEPROM content.

2. Debug log prints unread data as if it were the read result.
PMD_DRV_LOG fires unconditionally right after the ice_aq_sff_eeprom()
call, before the if (status) check and before the failure-path
memset(value, 0, ...). So on a failed attempt, the log line prints
value alongside the (correctly) failed status -- but value at that
point holds stale data: leftover from the previous block's last
successful read on a block's first failed attempt, or zeros from the
prior attempt's own memset on any subsequent retry of that same block.
Either way, it's never the result of the failed call being logged,
which can mislead debugging by making a failed read look like a
plausible real value.

Suggested fix:

bool block_ok = false;
for (j = 0; j < I2C_BUSY_TRY_TIMES; j++) {
    status = ice_aq_sff_eeprom(...);
    if (status) {
        PMD_DRV_LOG(DEBUG, "SFF %02X %02X %02X %X read failed (%X)",
                    addr, offset, page, is_sfp, status);
        usleep_range(...);
        memset(value, 0, SFF_READ_BLOCK_SIZE);
        continue;
    }                                                                           
    PMD_DRV_LOG(DEBUG, "SFF %02X %02X %02X %X = "
        "%02X%02X%02X%02X.%02X%02X%02X%02X",
        addr, offset, page, is_sfp,
        value[0], value[1], value[2], value[3],
        value[4], value[5], value[6], value[7]);
    block_ok = true;
    break;
}                                                                               
if (!block_ok)
    return -EIO;

-- 
You are receiving this mail because:
You are the assignee for the bug.

                 reply	other threads:[~2026-11-09 15:43 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=bug-2100-3@https.bugs.dpdk.org/ \
    --to=bugzilla@dpdk.org \
    --cc=dev@dpdk.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.