linux-kernel - Re: [PATCH net-next] net: sfp: add quirk for OEM DFP-34X-2C2 GPON ONU SFP

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

Date: Sat, 3 Feb 2024 00:18:13 +0100
From: Sergio Palumbo <palumbo.ser@...look.it>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: 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>,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] net: sfp: add quirk for OEM DFP-34X-2C2 GPON ONU
 SFP

Hello Russell,
thanks for your  explanation. I have to say that:
Module default is LAN_SDS_MODE=1
Host banana PI R3 supporting 1000base-X + 2500base-X
I would update the table as follows:

The current situation:
Host supports		Module		Mode		Functional
1000base-X		LAN_SDS_MODE=1	1000base-X	Not tested, but expect to work as 1000base-X + 2500base-X
1000base-X		LAN_SDS_MODE=6	1000base-X	Not tested, but expect to work as 1000base-X + 2500base-X
1000base-X + 2500base-X	LAN_SDS_MODE=1	1000base-X	Yes
1000base-X + 2500base-X	LAN_SDS_MODE=6	1000base-X	Yes (host forcing module at 1000base-X)

I suppose that Banana PI R3 host is forced by linux drivers
at 1000base-X so first two cases should be same as second two cases.


With the quirk:
Host supports		Module		Mode		Functional
1000base-X		LAN_SDS_MODE=1	1000base-X	Not tested, but expect to work as 1000base-X + 2500base-X host
1000base-X		LAN_SDS_MODE=6	1000base-X	Not tested, but expect to work as 1000base-X + 2500base-X host
1000base-X + 2500base-X	LAN_SDS_MODE=1	1000base-X	Yes (module forcing host at 1000base-X)
1000base-X + 2500base-X	LAN_SDS_MODE=6	2500base-X	Yes


I suppose Banana PI R3 forcing Linux drivers at 1000-X when
module in LAN_SDS_MODE=1 and expect it should work alpso with
hosts at 1000base-X only in LAN_SDS_MODE=1 and LAN_SDS_MODE=6



I also  tested them a Linux PC with ethernet at 1GB (Host) attached to
a media converter ethertnet <-> sfp 2.5G module working at 1000base-X
(speed of the host ehternet) with module set at both LAN_SDS_MODE=1 and
LAN_SDS_MODE=6

Do you think this could be enough?

Waitng your comments.

Best regards

Sergio Palumbo


Il 02/02/2024 19:01, Russell King (Oracle) ha scritto:
> On Fri, Feb 02, 2024 at 06:41:51PM +0100, Sergio Palumbo wrote:
>> Dear Russell,
>> sorry for the indenting. I will no longer use indenting in future postings.
>> As explained in the description setting up the module via telnet with
>> LAN_SDS_MODE=6 puts the module in 2500X autonegotiating mode.
> Okay, so this requires manual configuration to switch the module into
> 2500base-X.
>
>> Without applying the patch the module shows up to linux at 1000X
>> because the EEPROM is not correctly reporting the 2500X speeds.
> Okay, so in its default as-new state without reconfiguring the module,
> it reports 1000base-X and Linux drives it as such. This sounds fine.
>
>> Ethtool lines in the description repporting only 1000X and host
>> connecting only at 1000X.
> That would be expected.
>
>> After the quirk as you can see from the ethtool lines I put in the
>> description the module shows up to linux with both speeds 1000X and 2500X.
> Yes, adding the quirk will have that effect, but it will also have the
> effect that we will choose 2500base-X for host interfaces that support
> it, whether or not the module has been reconfigured to operate at
> 2500base-X. This will result in a mismatch between the module and the
> host, and the link will not come up.
>
>> According to the above if the host has the ability to connect at 2500X
>> the module is connecting at 2500X, if the host has the ability to connect
>> at 1000X only it will connect at 1000X.
> The current situation:
>
> Host supports		Module		Mode		Functional
> 1000base-X		default		1000base-X	Yes
> 1000base-X		LAN_SDS_MODE=6	1000base-X	No
> 1000base-X + 2500base-X	default		1000base-X	Yes	***
> 1000base-X + 2500base-X	LAN_SDS_MODE=6	1000base-X	No
>
> With the quirk:
> Host supports		Module		Mode		Functional
> 1000base-X		default		1000base-X	Yes
> 1000base-X		LAN_SDS_MODE=6	1000base-X	No
> 1000base-X + 2500base-X	default		2500base-X	No	***
> 1000base-X + 2500base-X	LAN_SDS_MODE=6	2500base-X	Yes
>
> The lines marked "***" are what I'm concerned about - by adding this
> quirk, it has the effect of trading one working configuration (the
> one where the module is in its default factory configuration) for one
> which requires special configuration of the module _and_ which breaks
> the factory configuration.
>
> On the plus side, ethtool _can_ be used to switch the interface mode
> back to 1000base-X, but given that this was working it seems backwards
> to need manual intervention.
>
>> On the other side after the quirk and the module set to LAN_SDS_MODE=1
>> 1000X mode. Linux host is connecting at 1000X only.
> No it won't. The module will still be detected, the quirk will be used,
> which will indicate to the kernel that the module supports both
> 1000base-X and 2500base-X. With a host interface that supports both,
> the kernel will choose 2500base-X, but the module will be using
> 1000base-X - and the link will not come up.
>
> At the very least, this needs to be mentioned in the commit message,
> so that the implications of this can be properly considered.
>