From: Marcus Hughes marcus.hughes@betterinternet.ltd
[ Upstream commit 71cfa7c893a05d09e7dc14713b27a8309fd4a2db ]
Some Potron SFP+ XGSPON ONU sticks are shipped with different EEPROM vendor ID and vendor name strings, but are otherwise functionally identical to the existing "Potron SFP+ XGSPON ONU Stick" handled by sfp_quirk_potron().
These modules, including units distributed under the "Better Internet" branding, use the same UART pin assignment and require the same TX_FAULT/LOS behaviour and boot delay. Re-use the existing Potron quirk for this EEPROM variant.
Signed-off-by: Marcus Hughes marcus.hughes@betterinternet.ltd Link: https://patch.msgid.link/20251207210355.333451-1-marcus.hughes@betterinterne... Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
## SUMMARY
**What the commit does**: Adds a single entry to the SFP quirks array for hardware that has a different vendor/part ID ("BIDB"/"X-ONU-SFPP") but requires identical handling to already-supported Potron modules.
**Does it meet stable kernel rules?**
1. ✅ **Obviously correct**: It's a one-line addition using existing, proven quirk infrastructure 2. ✅ **Fixes a real bug**: Without this quirk, the hardware doesn't work properly (TX_FAULT/LOS pins are misinterpreted) 3. ✅ **Important issue**: Hardware that users have purchased doesn't function 4. ✅ **Small and contained**: Single line addition to an array 5. ✅ **No new features**: Just extends existing quirk to another device ID
**Dependency check**: The `sfp_fixup_potron()` function was introduced in commit `dfec1c14aece` (June 2025) and has already been backported to stable trees (confirmed by seeing backport commit `34a890983183`). This commit requires that parent commit to be present.
**Risk vs Benefit**: - **Risk**: Near zero - only affects specific hardware identified by exact vendor/part match - **Benefit**: High for affected users - enables hardware to work properly
## CONCLUSION
This commit is a textbook example of a hardware quirk addition that IS appropriate for stable backporting. It: - Uses existing, tested infrastructure - Has minimal code change (1 line) - Enables real hardware that users have in the field - Has zero risk of regression for anyone else - The parent quirk function is already in stable trees
The only caveat is that stable kernels must have the original Potron quirk commit (`dfec1c14aece`) first, which based on the git history appears to have already been backported.
**YES**
drivers/net/phy/sfp.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c index 0401fa6b24d2..6166e9196364 100644 --- a/drivers/net/phy/sfp.c +++ b/drivers/net/phy/sfp.c @@ -497,6 +497,8 @@ static const struct sfp_quirk sfp_quirks[] = { SFP_QUIRK("ALCATELLUCENT", "3FE46541AA", sfp_quirk_2500basex, sfp_fixup_nokia),
+ SFP_QUIRK_F("BIDB", "X-ONU-SFPP", sfp_fixup_potron), + // FLYPRO SFP-10GT-CS-30M uses Rollball protocol to talk to the PHY. SFP_QUIRK_F("FLYPRO", "SFP-10GT-CS-30M", sfp_fixup_rollball),