linux-kernel - Re: [PATCH v1] net: sfp: add quirks for ODI DFP-34X-2C2

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: Mon, 26 Feb 2024 22:16:46 +0800
From: Shengyu Qu <wiagn233@...look.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: wiagn233@...look.com, andrew@...n.ch, hkallweit1@...il.com,
 davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
 pabeni@...hat.com, netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 stable@...r.kernel.org
Subject: Re: [PATCH v1] net: sfp: add quirks for ODI DFP-34X-2C2

Hi Russell,

> On Mon, Feb 26, 2024 at 09:23:46PM +0800, Shengyu Qu wrote:
>> ODI DFP-34X-2C2 is capable of 2500base-X, but incorrectly report its
>> capabilities in the EEPROM.
>> So use sfp_quirk_2500basex for this module to allow 2500Base-X mode.
> This was previously submitted by Sergio Palumbo, and comes in two
> different forms - an OEM version and non-OEM. There was extensive
> discussion about this, and the result is that I'm not accepting this
> quirk for this module.
>
> The reason is that the module _defaults_ to 1000base-X and requires
> manual reconfiguration by the user to operate at 2500base-X.
> Unfortunately, there is no way for the kernel to know whether that
> reconfiguration has occurred.
No, In the firmware of this stick, the speed rate is configured to auto
negotiation rather than fixed 1000base-X. I tried 3 different versions 
of the firmware and gets the same result. Also, user can plug in and out 
the optic fiber for five times in 30 seconds to trigger a force factory 
reset.This function is also enabled by default. This would also reset 
the speed configuration to auto negotiation but still keeps LOID config. 
Best regards, Shengyu
> The addition of this quirk makes the kernel select 2500base-X when
> the module is plugged in to a host that supports both 2500base-X
> and 1000base-X, resulting in the link with the module never coming
> up. (2500base-X is 1000base-X clocked 2.5x faster, and there is
> nothing in the line protocol that identifies this.)
>
> Consequently, adding this quirk makes modules in their default
> configuration not link with the host, and thus be inaccessible.
>
> Therefore, for the best user experience (in terms of having a working
> module when it turns up at the doorstep) the only option is to refuse
> this quirk.
>
> Now, what I really don't like is that I had a lengthy discussion over
> this with Sergio, and it seems from a mainline developer point of view
> that "oh, Sergio wasn't successful in getting this merged, someone else
> can have a go".
>
> It _isn't_ the person who is the problem - it is the principle and the
> confusion this will cause to users who receive modules in their default
> configuration (1000base-X), and then plug them in with this quirk in
> place, and the kernel selects 2500base-X resulting in no link and *no*
> access to the module.
>


Download attachment "OpenPGP_0xE3520CC91929C8E7.asc" of type "application/pgp-keys" (6869 bytes)

Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (841 bytes)