From: jeffd@silicom-usa.com
To: dev@dpdk.org
Cc: Stephen Douthit <stephend@silicom-usa.com>,
Jeff Daly <jeffd@silicom-usa.com>,
Haiyue Wang <haiyue.wang@intel.com>
Subject: [PATCH v4] net/ixgbe: retry SFP ID read to handle misbehaving SFPs
Date: Fri, 25 Mar 2022 05:54:13 -0400 [thread overview]
Message-ID: <20220325095414.12854-1-jeffd@silicom-usa.com> (raw)
In-Reply-To: <20220307223337.27876-1-jeffd@silicom-usa.com>
From: Stephen Douthit <stephend@silicom-usa.com>
Some XGS-PON SFPs have been observed ACKing I2C reads and returning
uninitialized garbage while their uC boots. This can lead to the SFP ID
code marking an otherwise working SFP module as unsupported if a bogus
ID value is read while its internal PHY/microcontroller is still
booting.
Retry the ID read several times looking not just for NAK, but also for a
valid ID field.
Since the device isn't NAKing the trasanction the existing longer retry
code in ixgbe_read_i2c_byte_generic_int() doesn't apply here.
Signed-off-by: Stephen Douthit <stephend@silicom-usa.com>
Signed-off-by: Jeff Daly <jeffd@silicom-usa.com>
---
Notes:
v4:
* Fixed git summary
v3:
* Removed extra braces around single statement if
v2:
* Removed superfluous DEBUGOUT
* Renamed id_reads to retries
* Don't assume status == 0 means IXGBE_SUCCESS
drivers/net/ixgbe/base/ixgbe_phy.c | 27 ++++++++++++++++++++++++---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ixgbe/base/ixgbe_phy.c b/drivers/net/ixgbe/base/ixgbe_phy.c
index 8d4d9bbfef..74c5db16fa 100644
--- a/drivers/net/ixgbe/base/ixgbe_phy.c
+++ b/drivers/net/ixgbe/base/ixgbe_phy.c
@@ -1267,6 +1267,7 @@ s32 ixgbe_identify_sfp_module_generic(struct ixgbe_hw *hw)
u8 cable_tech = 0;
u8 cable_spec = 0;
u16 enforce_sfp = 0;
+ u8 retries;
DEBUGFUNC("ixgbe_identify_sfp_module_generic");
@@ -1279,9 +1280,29 @@ s32 ixgbe_identify_sfp_module_generic(struct ixgbe_hw *hw)
/* LAN ID is needed for I2C access */
hw->mac.ops.set_lan_id(hw);
- status = hw->phy.ops.read_i2c_eeprom(hw,
- IXGBE_SFF_IDENTIFIER,
- &identifier);
+ /* Need to check this a couple of times for a sane value.
+ *
+ * SFPs that have a uC slaved to the I2C bus (vs. a dumb EEPROM) can be
+ * poorly designed such that they will ACK I2C reads and return
+ * whatever bogus data is in the SRAM (or whatever is backing the target
+ * device) before things are truly initialized.
+ *
+ * In a perfect world devices would NAK I2C requests until they were
+ * sane, but here we are.
+ *
+ * Give such devices a couple tries to get their act together before
+ * marking the device as unsupported.
+ */
+ for (retries = 0; retries < 5; retries++) {
+ status = hw->phy.ops.read_i2c_eeprom(hw,
+ IXGBE_SFF_IDENTIFIER,
+ &identifier);
+
+ DEBUGOUT("status %d, SFF identifier 0x%x\n", status, identifier);
+ if (status == IXGBE_SUCCESS &&
+ identifier == IXGBE_SFF_IDENTIFIER_SFP)
+ break;
+ }
if (status != IXGBE_SUCCESS)
goto err_read_i2c_eeprom;
--
2.25.1
next prev parent reply other threads:[~2022-03-25 9:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-07 22:33 [PATCH] net/ixgbe: Retry SFP ID read field " jeffd
2022-03-17 6:55 ` Wang, Haiyue
2022-03-17 7:39 ` Wang, Haiyue
2022-03-22 15:24 ` [PATCH v2] " jeffd
2022-03-23 0:59 ` Wang, Haiyue
2022-03-23 20:03 ` [PATCH v3] " jeffd
2022-03-24 1:00 ` Wang, Haiyue
2022-03-24 8:40 ` Zhang, Qi Z
2022-03-25 9:54 ` jeffd [this message]
2022-03-26 12:15 ` [PATCH v4] net/ixgbe: retry SFP ID read " Wang, Haiyue
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=20220325095414.12854-1-jeffd@silicom-usa.com \
--to=jeffd@silicom-usa.com \
--cc=dev@dpdk.org \
--cc=haiyue.wang@intel.com \
--cc=stephend@silicom-usa.com \
/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).