[PATCH AUTOSEL 6.18-6.12] net: sfp: extend Potron XGSPON quirk to cover additional EEPROM variant

[Sasha Levin <sashal@kernel.org>]

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@betterinternet.ltd
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),
 
-- 
2.51.0