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: Thu, 8 Feb 2024 17:19:24 +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

Dear Russell,
I understand your point, but I think ODI DFP-34X-2C2 situation is quite 
similar to:
FS GPON-INU-34-20BI
HUAWEI MA5671A
which are incorrectly reporting the speed in their EEPROM
These modules are working at both 1000-X and 2500-X but in order to work 
at 2500-X they need the quirk.
Same as ODI DFP-34X-2C2
I'm also quite sure that those modules are used and working in openwrt 
being GPON modules.
Was this test also done before accepting the patch/quirk for those modules?
Thanks for your help and regards

Sergio Palumbo

Il 08/02/2024 16:28, Russell King (Oracle) ha scritto:
> On Thu, Feb 08, 2024 at 03:00:08PM +0100, Sergio Palumbo wrote:
>> Dear Russel,
>> this is the first time I do such a test and kindly ask you to help me in
>> preparing it.
>> In my openwrt environment I have found phylink.c file in two different
>> directories:
>> /build_dir/toolchain-aarch64_cortex-a53__gcc-112.30_musl/linux-5.15.137/drivers/net/phy
>> /build_dir/toolchain-aarch64_cortex-a53__gcc-112.30_musllinux-mediatek_filogic/linux-5.15.137/drivers/net/phy
> Oh, openwrt. That means I need to re-understand their build system to
> advise how to do it. I only know the mainline kernel.
>
>> do I have to change both adding a line:
>> #define DEBUG
>>
>> before the first #define line:
>> #define SUPPORTED_interfaces \
> Mainline has never had "SUPPORTED_interfaces" in phylink.c, so I'm
> wondeirng what that's about. I'm also wondering what other changes
> there are to it. I'm also wondering whether the behaviour you're
> seeing is somehow special to openwrt. Too many things to wonder about
> and effectively means there's too much that I don't know.
>
> Therefore, I don't think I can help you, and I don't think I can
> possibly accept your proposal for this quirk. For mainline, as far
> as I'm aware, it will cause these modules to regress when they are
> in the manufacturer default state when used with a host that supports
> both 1000base-X and 2500base-X.
>