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

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20251223100518.2383364-11-sashal@kernel.org>
Date: Tue, 23 Dec 2025 05:05:15 -0500
From: Sasha Levin <sashal@...nel.org>
To: patches@...ts.linux.dev,
	stable@...r.kernel.org
Cc: Marcus Hughes <marcus.hughes@...terinternet.ltd>,
	Jakub Kicinski <kuba@...nel.org>,
	Sasha Levin <sashal@...nel.org>,
	linux@...linux.org.uk,
	andrew@...n.ch,
	hkallweit1@...il.com,
	netdev@...r.kernel.org
Subject: [PATCH AUTOSEL 6.18-6.12] net: sfp: extend Potron XGSPON quirk to cover additional EEPROM variant

From: Marcus Hughes <marcus.hughes@...terinternet.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@...terinternet.ltd>
Link: https://patch.msgid.link/20251207210355.333451-1-marcus.hughes@betterinternet.ltd
Signed-off-by: Jakub Kicinski <kuba@...nel.org>
Signed-off-by: Sasha Levin <sashal@...nel.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