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/
Unfortunatly the module's PHY is accessible at 1000baseX only.
ethtool returning:
Supported ports: [ Fibre ]
Supported link modes: 1000baseX/Full
After applying the quirk:
Supported ports: [ Fibre ]
Supported link modes: 1000baseX/Full
2500baseX/Full
Tested on BANANA PI R3 in OpenWRT v 23.05.2 Kernel 5.15.137
Tested on sfp to ethernet Media Converter.
Autonegotiating 1000baseX or 2500baseX according to the
connected host speed.
This module is existing in 2 versions:
Vendor = "ODI"
Vendor = "OEM"
This is the patch for vendor "OEM"
Patch has been inserted keeping the list in alphabetical order
first by vendor first and then by part string.
Signed-off-by: Sergio Palumbo <[email protected]>
---
drivers/net/phy/sfp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index f75c9eb3958e..3c0028a4af92 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -502,6 +502,9 @@ static const struct sfp_quirk sfp_quirks[] = {
SFP_QUIRK_F("Walsun", "HXSX-ATRC-1", sfp_fixup_fs_10gt),
SFP_QUIRK_F("Walsun", "HXSX-ATRI-1", sfp_fixup_fs_10gt),
+ // OEM DFP-34X-2C2 GPON ONU support 2500base-X
+ SFP_QUIRK_M("OEM", "DFP-34X-2C2", sfp_quirk_2500basex),
+
SFP_QUIRK_F("OEM", "SFP-10G-T", sfp_fixup_rollball_cc),
SFP_QUIRK_M("OEM", "SFP-2.5G-T", sfp_quirk_oem_2_5g),
SFP_QUIRK_F("OEM", "RTSFP-10", sfp_fixup_rollball_cc),
--
2.34.1
On Fri, Feb 02, 2024 at 06:41:51PM +0100, Sergio Palumbo wrote:
> 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.
Okay, so this requires manual configuration to switch the module into
2500base-X.
> Without applying the patch the module shows up to linux at 1000X
> because the EEPROM is not correctly reporting the 2500X speeds.
Okay, so in its default as-new state without reconfiguring the module,
it reports 1000base-X and Linux drives it as such. This sounds fine.
> Ethtool lines in the description repporting only 1000X and host
> connecting only at 1000X.
That would be expected.
> 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.
Yes, adding the quirk will have that effect, but it will also have the
effect that we will choose 2500base-X for host interfaces that support
it, whether or not the module has been reconfigured to operate at
2500base-X. This will result in a mismatch between the module and the
host, and the link will not come up.
> 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.
The current situation:
Host supports Module Mode Functional
1000base-X default 1000base-X Yes
1000base-X LAN_SDS_MODE=6 1000base-X No
1000base-X + 2500base-X default 1000base-X Yes ***
1000base-X + 2500base-X LAN_SDS_MODE=6 1000base-X No
With the quirk:
Host supports Module Mode Functional
1000base-X default 1000base-X Yes
1000base-X LAN_SDS_MODE=6 1000base-X No
1000base-X + 2500base-X default 2500base-X No ***
1000base-X + 2500base-X LAN_SDS_MODE=6 2500base-X Yes
The lines marked "***" are what I'm concerned about - by adding this
quirk, it has the effect of trading one working configuration (the
one where the module is in its default factory configuration) for one
which requires special configuration of the module _and_ which breaks
the factory configuration.
On the plus side, ethtool _can_ be used to switch the interface mode
back to 1000base-X, but given that this was working it seems backwards
to need manual intervention.
> 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.
No it won't. The module will still be detected, the quirk will be used,
which will indicate to the kernel that the module supports both
1000base-X and 2500base-X. With a host interface that supports both,
the kernel will choose 2500base-X, but the module will be using
1000base-X - and the link will not come up.
At the very least, this needs to be mentioned in the commit message,
so that the implications of this can be properly considered.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Hi Sergio,
I did ask for the kernel messages from a specific scenario:
- host that supports 1000base-X and 2500base-X with your quirk
- SFP inserted with LAN_SDS_MODE=1
What I expet to see in the kernel messages is that the system will
use 2500base-X, and a failure.
You claim that the kernel will link at 1000base-X. There is no
mechanism in the kernel for this to happen, and I believe that
if you look at the kernel messages, this will prove my point.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
On Thu, Feb 08, 2024 at 09:30:48AM +0100, Sergio Palumbo wrote:
> Hello Russell,
> I did the requested test
I asked for it with a kernel that has #define DEBUG in phylink.c, but I
see no debug messages from phylink in your quoted output. There's no
mention of what's going on behind the scenes, so this gives me
absolutely no new information.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
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.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
On Thu, Feb 08, 2024 at 05:19:24PM +0100, Sergio Palumbo wrote:
> 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
MA5671A is configured by the OLT. The user can't configure it.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
On Sat, Feb 17, 2024 at 11:13:14AM +0100, Sergio Palumbo wrote:
> [ 15.459629] sfp sfp-1: module OEM DFP-34X-2C2 rev sn XPONxxxxxxxx dc 230912
> [ 15.469121] mtk_soc_eth 15100000.ethernet eth1: requesting link mode inband/2500base-x with support 0000000,00000200,0000e440
> [ 15.509967] sfp sfp-2: module rev 1.0 sn 2307210038 dc 230721
> [ 15.519434] mt7530-mdio mdio-bus:1f sfp2: requesting link mode inband/2500base-x with support 0000000,00000000,0000e440
> [ 24.360320] mt7530-mdio mdio-bus:1f sfp2: configuring for inband/2500base-x link mode
> [ 24.368145] mt7530-mdio mdio-bus:1f sfp2: major config 2500base-x
> [ 24.374258] mt7530-mdio mdio-bus:1f sfp2: phylink_mac_config: mode=inband/2500base-x/Unknown/Unknown adv=0000000,00000000,0000e440 pause=04 link=0 an=1
> [ 24.389679] br-lan: port 5(sfp2) entered blocking state
> [ 24.394948] br-lan: port 5(sfp2) entered disabled state
> [ 24.402405] device sfp2 entered promiscuous mode
This shows that the interface has been configured for 2500base-X.
However, there is no link report.
> A stated by you the system is still connecting at 2500base-X even if the
> module is set for 1000base-X, as far as I can see, without any error.
Right, because, as I've said many times, the kernel has *no* idea that
the module internals has been configured to operate at 1000base-X.
> My assumption that the module could have forced the speed down to
> 1000base-X was completely wrong.
Correct - considering that I wrote all this code, it is insulting to
have to go to this extent to get the point across.
So now that we have agreement that the kernel is trying to use
2500base-X, you now need to get off your high horse and accept that
it isn't working because there is _no_ _link_ with the module.
In other words, you need to accept that I'm right and you're wrong.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!