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

Sergio Palumbo
2024-02-02T17:41:56Z

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.
Without applying the patch the module shows up to linux at 1000X
because the EEPROM is not correctly reporting the 2500X speeds.
Ethtool lines in the description repporting only 1000X and host
connecting only at 1000X.
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.
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.

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.

Therefore will all the possible combination the patch allows linux host to
connect at the maximum speed of the host up to 2500X.

Please note that, as exlained in the description, this patch is for the
"OEM"
vendor version.
I posted anothe patch for the "ODI" vendor version.
Harware for both version is the same only vendor name is different.
If better I can post a patch having both quirks in two different places
according
to the alphabetical sorting.
I thought it was bettere to post two patches one for each vendor name.

Hope this clarifies.
I remain at your disposal for any further information.
Thanks and regards

Sergio Palumbo

Il 28/01/2024 15:42, Russell King (Oracle) ha scritto:
> Oh, you re-posted it already...
>
> On Sun, Jan 28, 2024 at 03:06:33PM +0100, Sergio Palumbo wrote:
>> DFP-34X-2C2 is a GPON spf module working at both 1000baseX
>> and 2500baseX.
>> Setting the module to LAN_SDS_MODE=6 the module is working
>> at 2500baseX with auto negotiation see at
>> https://hack-gpon.org/ont-odi-realtek-dfp-34x-2c2/
> Please don't indent commit messages unnecessarily.
>
> Also, good to know what this module *requires* AN with 2500base-X.
>
> However, what mode does this module normally come up in, and does
> it reflect the operating mode in the module EEPROM?
>
> If we accept this patch, and the modules normally come up at 1000base-X
> we will try to use 2500base-X and the link won't come up. So it's
> important to clarify this point.
>
> Thanks.
>