linux-kernel - Re: [PATCH net-next] ixgbe: Add 10G-BX support

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>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <3a936cc6-14e7-49f8-b312-d66330f955d7@lunn.ch>
Date: Mon, 13 Oct 2025 19:48:40 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Birger Koblitz <mail@...ger-koblitz.de>
Cc: Tony Nguyen <anthony.l.nguyen@...el.com>,
	Przemek Kitszel <przemyslaw.kitszel@...el.com>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	intel-wired-lan@...ts.osuosl.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] ixgbe: Add 10G-BX support

On Mon, Oct 13, 2025 at 07:17:18PM +0200, Birger Koblitz wrote:
> On 13/10/2025 6:31 pm, Andrew Lunn wrote:
> > > @@ -1678,6 +1679,26 @@ int ixgbe_identify_sfp_module_generic(struct ixgbe_hw *hw)
> > >   			else
> > >   				hw->phy.sfp_type =
> > >   					ixgbe_sfp_type_1g_bx_core1;
> > > +		/* Support Ethernet 10G-BX, checking the Bit Rate
> > > +		 * Nominal Value as per SFF-8472 to be 12.5 Gb/s (67h) and
> > > +		 * Single Mode fibre with at least 1km link length
> > > +		 */
> > > +		} else if ((!comp_codes_10g) && (bitrate_nominal == 0x67) &&
> > > +			   (!(cable_tech & IXGBE_SFF_DA_PASSIVE_CABLE)) &&
> > > +			   (!(cable_tech & IXGBE_SFF_DA_ACTIVE_CABLE))) {
> > > +			status = hw->phy.ops.read_i2c_eeprom(hw,
> > > +					    IXGBE_SFF_SM_LENGTH,
> > > +					    &sm_length);
> > 
> > It seems like byte 15, Length (SMF), "Link length supported for single
> > mode fiber, units of 100 m" should be checked here. A 255 * 100m would
> > be more than 1Km, the condition you say in the comment.
> > 
> > 	Andrew
> 
> Bytes 14 and 15 refer to the same information, just in different units. Byte
> 14 is the SM link length in km, byte 15 the same in 100m units. BX offers a
> link length of at least 1km, up to at least 40km, which would overflow to
> 255 in byte 15. In theory one could make a consistency check between bytes
> 14 and 15 by dividing byte 15 by 10 and comparing the result with byte 14,
> but in terms of identifying link lengths of >=1km, checking byte 14 is
> probably enough, in particular as rounding of byte 14 could be
> inconsistently done, making the consistency check difficult. One could also
> check for byte 14 to be 0 and byte 15 to be < 10 to identify SM links <1km,
> but I do not believe such BX modules exist and again, there would be the
> issue of rounding for link lengths >=500m.

Hi Birger

Byte 15 containing 10 would be a Single Mode Fibre which is 1Km long.

You also say:

> BX offers a
> link length of at least 1km, up to at least 40km

which is ambiguous, you use at least twice. Should it actually be:

BX offers a link length of at least 1km, up to at a maximum of 40km.

So a 10GBase-BX module with 1Km would be allowed by the standard? A
10km 10GBase-BX using 100 in byte 15 would also be valid? A 20KM by
using 200?

Is there anything in the standard which says you must use byte 14 for 
10GBase-BX?

I think to fully comply with the standard, you probably want to look
at both bytes, and if either indicate > 1Km, enable the feature. And
if the two contradict each other, whats just OEMs making the usual
mess of SFP EEPROM contents.

	Andrew