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

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

Date: Sat, 3 Feb 2024 10:16:47 +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,
I understand your point on third line, but I quite sure that it is 
working at
1000-X because with LAN_SDS_MODE=1 makes the module to show up
at 1000-X to Linux host, but now you made me doubtful.
I'm now out of home and cannot do this test. I will test it on monday 
evening
when will be back at home.
Unfortunately not so skilled to:
"Add #define DEBUG in phylink.c, rebuild and run that kernel. Try
that exact configuration. Report to me the kernel messages."
Would it be enough to check if using LAN_SDS_MODULE=1 with the quirk, the
confirmation that  ethtool will report 1000-X only and speed connectioin
reported by ethtool will be 1000?
Will let you know the result of this test.
Thanks for your kind support.
Regards

Sergio Palumbo

Il 03/02/2024 00:45, Russell King (Oracle) ha scritto:
> On Sat, Feb 03, 2024 at 12:18:13AM +0100, Sergio Palumbo wrote:
>> 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
> Your third line is just wrong. Given the capabilities of the host
> _and_ the capabilities of the module adjusted by your quirk, phylink
> _will_ choose 2500base-X _not_ 1000base-X for that. With your quirk,
> there is no way for Linux to know what LAN_SDS_MODE has been set
> in the module. Even without your quirk, _unless_ the module updates
> the EEPROM contents which is unlikely, there isn't a way to know.
>
>
> Adding a quirk that makes it not work in its default state is
> technically a regression. We can't know whether people are already
> using this module with Linux in this state. Adding this change
> potentially breaks users setups.
>
>> 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
> There is no way for Linux to know what LAN_SDS_MODE the module is
> in.
>