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.