linux-kernel - Re: [PATCH v2] net: sfp: handle 100G/25G active optical cables in sfp_parse

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 for Android: free password hash cracker in your pocket

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

Message-ID: <ZNs2Sz6iBMnxshKO@vergenet.net>
Date:   Tue, 15 Aug 2023 10:24:43 +0200
From:   Simon Horman <horms@...nel.org>
To:     Josua Mayer <josua@...id-run.com>
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        Russell King <linux@...linux.org.uk>,
        Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH v2] net: sfp: handle 100G/25G active optical cables in
 sfp_parse_support

On Mon, Aug 14, 2023 at 04:17:39PM +0200, Josua Mayer wrote:
> Handle extended compliance code 0x1 (SFF8024_ECC_100G_25GAUI_C2M_AOC)
> for active optical cables supporting 25G and 100G speeds.
> 
> Since the specification makes no statement about transmitter range, and
> as the specific sfp module that had been tested features only 2m fiber -
> short-range (SR) modes are selected.
> 
> The 100G speed is irrelevant because it would require multiple fibers /
> multiple SFP28 modules combined under one netdev.
> sfp-bus.c only handles a single module per netdev, so only 25Gbps modes
> are selected.
> 
> sfp_parse_support already handles SFF8024_ECC_100GBASE_SR4_25GBASE_SR
> with compatible properties, however that entry is a contradiction in
> itself since with SFP(28) 100GBASE_SR4 is impossible - that would likely
> be a mode for qsfp modules only.
> 
> Add a case for SFF8024_ECC_100G_25GAUI_C2M_AOC selecting 25gbase-r
> interface mode and 25000baseSR link mode.
> Also enforce SFP28 bitrate limits on the values read from sfp eeprom as
> requested by Russell King.
> 
> Tested with fs.com S28-AO02 AOC SFP28 module.
> 
> Signed-off-by: Josua Mayer <josua@...id-run.com>
> ---
> V1 -> V2: added separate case SFF8024_ECC_100G_25GAUI_C2M_AOC
> V1 -> V2: added bitrate check for eeprom values
> 
>  drivers/net/phy/sfp-bus.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c
> index e8dd47bffe43..a4b0bb50e2eb 100644
> --- a/drivers/net/phy/sfp-bus.c
> +++ b/drivers/net/phy/sfp-bus.c
> @@ -258,6 +258,17 @@ void sfp_parse_support(struct sfp_bus *bus, const struct sfp_eeprom_id *id,
>  	switch (id->base.extended_cc) {
>  	case SFF8024_ECC_UNSPEC:
>  		break;
> +	case SFF8024_ECC_100G_25GAUI_C2M_AOC:
> +		if (br_min <= 28000 && br_max >= 25000) {
> +			/* 25GBASE-R, possibly with FEC */
> +			__set_bit(PHY_INTERFACE_MODE_25GBASER, interfaces);
> +			/*
> +			 * There is currently no link mode for 25000base
> +			 * with unspecified range, reuse SR.
> +			 */

Hi Josua,

a minor nit from my side: : if you have to re-spin for some other reason,
the multi-line comment style for Networking code is:

	/* This is
	 * something.
	 */

> +			phylink_set(modes, 25000baseSR_Full);
> +		}
> +		break;
>  	case SFF8024_ECC_100GBASE_SR4_25GBASE_SR:
>  		phylink_set(modes, 100000baseSR4_Full);
>  		phylink_set(modes, 25000baseSR_Full);
> -- 
> 2.35.3
> 
>