| Message ID | AS1PR03MB8189AD85CEB6E139F27307D3827F2@AS1PR03MB8189.eurprd03.prod.outlook.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [net-next] net: sfp: add quirk for OEM DFP-34X-2C2 GPON ONU SFP | expand |
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.
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. >
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.
Hello Russell, thanks for your explanation. I have to say that: Module default is LAN_SDS_MODE=1 Host banana PI R3 supporting 1000base-X + 2500base-X I would update the table as follows: The current situation: Host supports Module Mode Functional 1000base-X LAN_SDS_MODE=1 1000base-X Not tested, but expect to work as 1000base-X + 2500base-X 1000base-X LAN_SDS_MODE=6 1000base-X Not tested, but expect to work as 1000base-X + 2500base-X 1000base-X + 2500base-X LAN_SDS_MODE=1 1000base-X Yes 1000base-X + 2500base-X LAN_SDS_MODE=6 1000base-X Yes (host forcing module at 1000base-X) I suppose that Banana PI R3 host is forced by linux drivers at 1000base-X so first two cases should be same as second two cases. With the quirk: Host supports Module Mode Functional 1000base-X LAN_SDS_MODE=1 1000base-X Not tested, but expect to work as 1000base-X + 2500base-X host 1000base-X LAN_SDS_MODE=6 1000base-X Not tested, but expect to work as 1000base-X + 2500base-X host 1000base-X + 2500base-X LAN_SDS_MODE=1 1000base-X Yes (module forcing host at 1000base-X) 1000base-X + 2500base-X LAN_SDS_MODE=6 2500base-X Yes I suppose Banana PI R3 forcing Linux drivers at 1000-X when module in LAN_SDS_MODE=1 and expect it should work alpso with hosts at 1000base-X only in LAN_SDS_MODE=1 and LAN_SDS_MODE=6 I also tested them a Linux PC with ethernet at 1GB (Host) attached to a media converter ethertnet <-> sfp 2.5G module working at 1000base-X (speed of the host ehternet) with module set at both LAN_SDS_MODE=1 and LAN_SDS_MODE=6 Do you think this could be enough? Waitng your comments. Best regards Sergio Palumbo Il 02/02/2024 19:01, Russell King (Oracle) ha scritto: > 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. >
On Sat, Feb 03, 2024 at 12:18:13AM +0100, Sergio Palumbo wrote: > Hello Russell, > thanks for your explanation. I have to say that: > Module default is LAN_SDS_MODE=1 > Host banana PI R3 supporting 1000base-X + 2500base-X > I would update the table as follows: > > The current situation: > Host supports Module Mode Functional > 1000base-X LAN_SDS_MODE=1 1000base-X Not tested, but expect to work as 1000base-X + 2500base-X > 1000base-X LAN_SDS_MODE=6 1000base-X Not tested, but expect to work as 1000base-X + 2500base-X > 1000base-X + 2500base-X LAN_SDS_MODE=1 1000base-X Yes > 1000base-X + 2500base-X LAN_SDS_MODE=6 1000base-X Yes (host forcing module at 1000base-X) > > I suppose that Banana PI R3 host is forced by linux drivers > at 1000base-X so first two cases should be same as second two cases. > > > With the quirk: > Host supports Module Mode Functional > 1000base-X LAN_SDS_MODE=1 1000base-X Not tested, but expect to work as 1000base-X + 2500base-X host > 1000base-X LAN_SDS_MODE=6 1000base-X Not tested, but expect to work as 1000base-X + 2500base-X host > 1000base-X + 2500base-X LAN_SDS_MODE=1 1000base-X Yes (module forcing host at 1000base-X) > 1000base-X + 2500base-X LAN_SDS_MODE=6 2500base-X Yes Your third line is just wrong. Given the capabilities of the host _and_ the capabilities of the module adjusted by your quirk, phylink _will_ choose 2500base-X _not_ 1000base-X for that. With your quirk, there is no way for Linux to know what LAN_SDS_MODE has been set in the module. Even without your quirk, _unless_ the module updates the EEPROM contents which is unlikely, there isn't a way to know. Add #define DEBUG in phylink.c, rebuild and run that kernel. Try that exact configuration. Report to me the kernel messages. Adding a quirk that makes it not work in its default state is technically a regression. We can't know whether people are already using this module with Linux in this state. Adding this change potentially breaks users setups. > I suppose Banana PI R3 forcing Linux drivers at 1000-X when > module in LAN_SDS_MODE=1 and expect it should work alpso with > hosts at 1000base-X only in LAN_SDS_MODE=1 and LAN_SDS_MODE=6 There is no way for Linux to know what LAN_SDS_MODE the module is in.
Hello Russell, I understand your point on third line, but I quite sure that it is working at 1000-X because with LAN_SDS_MODE=1 makes the module to show up at 1000-X to Linux host, but now you made me doubtful. I'm now out of home and cannot do this test. I will test it on monday evening when will be back at home. Unfortunately not so skilled to: "Add #define DEBUG in phylink.c, rebuild and run that kernel. Try that exact configuration. Report to me the kernel messages." Would it be enough to check if using LAN_SDS_MODULE=1 with the quirk, the confirmation that ethtool will report 1000-X only and speed connectioin reported by ethtool will be 1000? Will let you know the result of this test. Thanks for your kind support. Regards Sergio Palumbo Il 03/02/2024 00:45, Russell King (Oracle) ha scritto: > On Sat, Feb 03, 2024 at 12:18:13AM +0100, Sergio Palumbo wrote: >> Hello Russell, >> thanks for your explanation. I have to say that: >> Module default is LAN_SDS_MODE=1 >> Host banana PI R3 supporting 1000base-X + 2500base-X >> I would update the table as follows: >> >> The current situation: >> Host supports Module Mode Functional >> 1000base-X LAN_SDS_MODE=1 1000base-X Not tested, but expect to work as 1000base-X + 2500base-X >> 1000base-X LAN_SDS_MODE=6 1000base-X Not tested, but expect to work as 1000base-X + 2500base-X >> 1000base-X + 2500base-X LAN_SDS_MODE=1 1000base-X Yes >> 1000base-X + 2500base-X LAN_SDS_MODE=6 1000base-X Yes (host forcing module at 1000base-X) >> >> I suppose that Banana PI R3 host is forced by linux drivers >> at 1000base-X so first two cases should be same as second two cases. >> >> >> With the quirk: >> Host supports Module Mode Functional >> 1000base-X LAN_SDS_MODE=1 1000base-X Not tested, but expect to work as 1000base-X + 2500base-X host >> 1000base-X LAN_SDS_MODE=6 1000base-X Not tested, but expect to work as 1000base-X + 2500base-X host >> 1000base-X + 2500base-X LAN_SDS_MODE=1 1000base-X Yes (module forcing host at 1000base-X) >> 1000base-X + 2500base-X LAN_SDS_MODE=6 2500base-X Yes > Your third line is just wrong. Given the capabilities of the host > _and_ the capabilities of the module adjusted by your quirk, phylink > _will_ choose 2500base-X _not_ 1000base-X for that. With your quirk, > there is no way for Linux to know what LAN_SDS_MODE has been set > in the module. Even without your quirk, _unless_ the module updates > the EEPROM contents which is unlikely, there isn't a way to know. > > > Adding a quirk that makes it not work in its default state is > technically a regression. We can't know whether people are already > using this module with Linux in this state. Adding this change > potentially breaks users setups. > >> I suppose Banana PI R3 forcing Linux drivers at 1000-X when >> module in LAN_SDS_MODE=1 and expect it should work alpso with >> hosts at 1000base-X only in LAN_SDS_MODE=1 and LAN_SDS_MODE=6 > There is no way for Linux to know what LAN_SDS_MODE the module is > in. >
Hello Russell, I back home and did the test for line 3 after the quirk: SFP module still showing up Supported ports: [ FIBRE ] Supported link modes: 2500baseX/Full 1000baseX/Full Speed: 2500Mb/s Duplex: Full Probably auto-negotiating at 2500base-X Tried to change speed to 1000 using ethtool, but retuning an error. However taking in consideration that without the quirk the module is working at 1000base-X with both LAN_SDS_MODE=1 and LAN_SDS_MODE=6 on my host 1000+2500 there i no reason why it should not work at 1000base-X with an host only supporting 1000. Unfortunately I do not have any host only supporting 1000base-X. Awaiting your comments regards Sergio Palumbo Il 03/02/2024 10:16, Sergio Palumbo ha scritto: > Hello Russell, > I understand your point on third line, but I quite sure that it is > working at > 1000-X because with LAN_SDS_MODE=1 makes the module to show up > at 1000-X to Linux host, but now you made me doubtful. > I'm now out of home and cannot do this test. I will test it on monday > evening > when will be back at home. > Unfortunately not so skilled to: > "Add #define DEBUG in phylink.c, rebuild and run that kernel. Try > that exact configuration. Report to me the kernel messages." > Would it be enough to check if using LAN_SDS_MODULE=1 with the quirk, the > confirmation that ethtool will report 1000-X only and speed connectioin > reported by ethtool will be 1000? > Will let you know the result of this test. > Thanks for your kind support. > Regards > > Sergio Palumbo > > Il 03/02/2024 00:45, Russell King (Oracle) ha scritto: >> On Sat, Feb 03, 2024 at 12:18:13AM +0100, Sergio Palumbo wrote: >>> Hello Russell, >>> thanks for your explanation. I have to say that: >>> Module default is LAN_SDS_MODE=1 >>> Host banana PI R3 supporting 1000base-X + 2500base-X >>> I would update the table as follows: >>> >>> The current situation: >>> Host supports Module Mode Functional >>> 1000base-X LAN_SDS_MODE=1 1000base-X Not tested, but >>> expect to work as 1000base-X + 2500base-X >>> 1000base-X LAN_SDS_MODE=6 1000base-X Not tested, but >>> expect to work as 1000base-X + 2500base-X >>> 1000base-X + 2500base-X LAN_SDS_MODE=1 1000base-X Yes >>> 1000base-X + 2500base-X LAN_SDS_MODE=6 1000base-X Yes (host >>> forcing module at 1000base-X) >>> >>> I suppose that Banana PI R3 host is forced by linux drivers >>> at 1000base-X so first two cases should be same as second two cases. >>> >>> >>> With the quirk: >>> Host supports Module Mode Functional >>> 1000base-X LAN_SDS_MODE=1 1000base-X Not tested, but >>> expect to work as 1000base-X + 2500base-X host >>> 1000base-X LAN_SDS_MODE=6 1000base-X Not tested, but >>> expect to work as 1000base-X + 2500base-X host >>> 1000base-X + 2500base-X LAN_SDS_MODE=1 1000base-X Yes >>> (module forcing host at 1000base-X) >>> 1000base-X + 2500base-X LAN_SDS_MODE=6 2500base-X Yes >> Your third line is just wrong. Given the capabilities of the host >> _and_ the capabilities of the module adjusted by your quirk, phylink >> _will_ choose 2500base-X _not_ 1000base-X for that. With your quirk, >> there is no way for Linux to know what LAN_SDS_MODE has been set >> in the module. Even without your quirk, _unless_ the module updates >> the EEPROM contents which is unlikely, there isn't a way to know. >> >> >> Adding a quirk that makes it not work in its default state is >> technically a regression. We can't know whether people are already >> using this module with Linux in this state. Adding this change >> potentially breaks users setups. >> >>> I suppose Banana PI R3 forcing Linux drivers at 1000-X when >>> module in LAN_SDS_MODE=1 and expect it should work alpso with >>> hosts at 1000base-X only in LAN_SDS_MODE=1 and LAN_SDS_MODE=6 >> There is no way for Linux to know what LAN_SDS_MODE the module is >> in. >> >
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.
Hello Russell, I did the requested test - host that supports 1000base-X and 2500base-X with your quirk (Banana PI R3) - SFP inserted with LAN_SDS_MODE=1 (DFP-34X-2C2 and here below system messages concerning sfp: Sun Feb 4 00:35:06 2024 kern.info kernel: [ 14.686771] sfp sfp-1: Host maximum power 3.0W Sun Feb 4 00:35:06 2024 kern.info kernel: [ 14.692137] sfp sfp-2: Host maximum power 3.0W Sun Feb 4 00:35:06 2024 kern.info kernel: [ 15.029727] sfp sfp-1: module OEM DFP-34X-2C2 rev sn XPONxxxxxxxx dc 230912 Sun Feb 4 00:35:06 2024 kern.info kernel: [ 15.068806] sfp sfp-2: module rev 1.0 sn 2307210038 dc 230721 Sun Feb 4 00:35:08 2024 kern.info kernel: [ 22.767328] mt7530-mdio mdio-bus:1f sfp2: configuring for inband/2500base-x link mode Sun Feb 4 00:35:08 2024 kern.info kernel: [ 22.777097] br-lan: port 5(sfp2) entered blocking state Sun Feb 4 00:35:08 2024 kern.info kernel: [ 22.782390] br-lan: port 5(sfp2) entered disabled state Sun Feb 4 00:35:12 2024 kern.info kernel: [ 26.970294] mt7530-mdio mdio-bus:1f sfp2: Link is Up - 2.5Gbps/Full - flow control off Sun Feb 4 00:35:12 2024 kern.info kernel: [ 26.978403] br-lan: port 5(sfp2) entered blocking state Sun Feb 4 00:35:12 2024 kern.info kernel: [ 26.983623] br-lan: port 5(sfp2) entered forwarding state Sun Feb 4 00:35:12 2024 daemon.notice netifd: Network device 'sfp2' link is up Sun Feb 4 00:35:08 2024 kern.info kernel: [ 22.834307] mtk_soc_eth 15100000.ethernet eth1: configuring for inband/2500base-x link mode Sun Feb 4 00:35:08 2024 kern.info kernel: [ 22.846214] device eth1 entered promiscuous mode Sun Feb 4 00:35:58 2024 kern.info kernel: [ 72.800035] mtk_soc_eth 15100000.ethernet eth1: Link is Up - 2.5Gbps/Full - flow control off sfp-1 is linked to eth1 eth1 is running at 2500base-x Same result with ethtool: Settings for eth1: Supported ports: [ FIBRE ] Supported link modes: 2500baseX/Full 1000baseX/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 2500baseX/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Speed: 2500Mb/s Duplex: Full Auto-negotiation: on Port: FIBRE PHYAD: 0 Transceiver: internal Current message level: 0x000000ff (255) drv probe link timer ifdown ifup rx_err tx_err Link detected: yes Please let me have your comments. Sergio Palumbo Il 06/02/2024 15:15, Russell King (Oracle) ha scritto: > 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. >
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.
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 do I have to change both adding a line: #define DEBUG before the first #define line: #define SUPPORTED_interfaces \ and then rebuild the system? Thanks in advance for your patience in teaching me something totally new to me. Best regards Sergio Palumbo Il 08/02/2024 10:07, Russell King (Oracle) ha scritto: > 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. >
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.
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. >
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.
Hi Russell, GPON modules we are talking about are all ONT/ONU and all the ONT ONU are configured by OLT unless you have a modded firmware. ODI DFP-34X-2C2 is an ONT/ONU. https://hack-gpon.org/ont-huawei-ma5671a/ https://hack-gpon.org/ont-fs-com-gpon-onu-stick-with-mac/ https://hack-gpon.org/ont-odi-realtek-dfp-34x-2c2/ I think the discussion on LAN_SDS_MODE=1 or LAN_SDS_MODE=6, started by me is not part of the problem as the system after the quirk is working at 2500-X with both settings. My fault! The problem for these kind of modules is simply that they are not showing up at 2500-X because EEPROM or Virtual EEPROM (in case of MA5671A) failure to provide the correct speed to the linux driver. Huawei MA5671A and Fiberstone GPON-ONU-34-20BI require: "sfp_quirk_2500basex" and "sfp_fixup_ignore_tx_fault" quirks ODI DFP-34X-2C2 only require "sfp_quirk_2500basex" Hope this may help. Regards Sergio Palumbo Il 08/02/2024 17:28, Russell King (Oracle) ha scritto: > 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. >
Hello Russell, unfortunately I did not have time imediately to run tests. Now I had some time available to run some more test, this is the result: The current situation: Host supports Module Mode Functional 1000base-X LAN_SDS_MODE=1 1000base-X Not tested 1000base-X LAN_SDS_MODE=6 1000base-X Not tested 1000base-X + 2500base-X LAN_SDS_MODE=1 1000base-X Yes 1000base-X + 2500base-X LAN_SDS_MODE=6 1000base-X Yes I recompiled the linux firmware with the #define DEBUG in phylink.c With the quirk: Host supports Module Mode Functional 1000base-X LAN_SDS_MODE=1 1000base-X Not tested 1000base-X LAN_SDS_MODE=6 1000base-X Not tested 1000base-X + 2500base-X LAN_SDS_MODE=1 2500base-X Yes 1000base-X + 2500base-X LAN_SDS_MODE=6 2500base-X Yes From the above it is clear that: - using the quirk the module is always working at 2500base-X if the host is capable of 2500base-X - the internal settings of te module does not affect the speed Here below an extract of the kernel log with phylink debug for 1000base-X + 2500base-X LAN_SDS_MODE=1 2500base-X : sfp-1/eth1= DFP-34X-2C2 module sfp-2/lan = sfp/ethernet copper module working at 2500base-X Sat Feb 10 19:17:29 2024 kern.info kernel: [ 2.111137] mt7530-mdio mdio-bus:1f: configuring for fixed/2500base-x link mode Sat Feb 10 19:17:29 2024 kern.debug kernel: [ 2.118440] mt7530-mdio mdio-bus:1f: major config 2500base-x Sat Feb 10 19:17:29 2024 kern.debug kernel: [ 2.124099] mt7530-mdio mdio-bus:1f: phylink_mac_config: mode=fixed/2500base-x/2.5Gbps/Full adv=0000000,00008000,00006240 pause=03 link=0 an=1 Sat Feb 10 19:17:29 2024 kern.info kernel: [ 2.138585] mt7530-mdio mdio-bus:1f: Link is Up - 2.5Gbps/Full - flow control rx/tx Sat Feb 10 19:17:29 2024 kern.info kernel: [ 2.147273] mt7530-mdio mdio-bus:1f wan (uninitialized): PHY [mt7530-0:00] driver [MediaTek MT7531 PHY] (irq=146) Sat Feb 10 19:17:29 2024 kern.debug kernel: [ 2.157515] mt7530-mdio mdio-bus:1f wan (uninitialized): phy: setting supported 0000000,00000000,000062ef advertising 0000000,00000000,000062ef Sat Feb 10 19:17:29 2024 kern.info kernel: [ 2.180320] mt7530-mdio mdio-bus:1f lan1 (uninitialized): PHY [mt7530-0:01] driver [MediaTek MT7531 PHY] (irq=147) Sat Feb 10 19:17:29 2024 kern.debug kernel: [ 2.190651] mt7530-mdio mdio-bus:1f lan1 (uninitialized): phy: setting supported 0000000,00000000,000062ef advertising 0000000,00000000,000062ef Sat Feb 10 19:17:29 2024 kern.info kernel: [ 2.213265] mt7530-mdio mdio-bus:1f lan2 (uninitialized): PHY [mt7530-0:02] driver [MediaTek MT7531 PHY] (irq=148) Sat Feb 10 19:17:29 2024 kern.debug kernel: [ 2.223598] mt7530-mdio mdio-bus:1f lan2 (uninitialized): phy: setting supported 0000000,00000000,000062ef advertising 0000000,00000000,000062ef Sat Feb 10 19:17:29 2024 kern.info kernel: [ 2.246219] mt7530-mdio mdio-bus:1f lan3 (uninitialized): PHY [mt7530-0:03] driver [MediaTek MT7531 PHY] (irq=149) Sat Feb 10 19:17:29 2024 kern.debug kernel: [ 2.256552] mt7530-mdio mdio-bus:1f lan3 (uninitialized): phy: setting supported 0000000,00000000,000062ef advertising 0000000,00000000,000062ef Sat Feb 10 19:17:29 2024 kern.info kernel: [ 2.279159] mt7530-mdio mdio-bus:1f lan4 (uninitialized): PHY [mt7530-0:04] driver [MediaTek MT7531 PHY] (irq=150) Sat Feb 10 19:17:29 2024 kern.debug kernel: [ 2.289490] mt7530-mdio mdio-bus:1f lan4 (uninitialized): phy: setting supported 0000000,00000000,000062ef advertising 0000000,00000000,000062ef Sat Feb 10 19:17:29 2024 kern.info kernel: [ 7.482162] mtk_soc_eth 15100000.ethernet eth0: configuring for fixed/2500base-x link mode Sat Feb 10 19:17:29 2024 kern.debug kernel: [ 7.490445] mtk_soc_eth 15100000.ethernet eth0: major config 2500base-x Sat Feb 10 19:17:29 2024 kern.debug kernel: [ 7.497041] mtk_soc_eth 15100000.ethernet eth0: phylink_mac_config: mode=fixed/2500base-x/2.5Gbps/Full adv=0000000,00008000,00006240 pause=03 link=0 an=1 Sat Feb 10 19:17:29 2024 kern.info kernel: [ 7.510911] mtk_soc_eth 15100000.ethernet eth0: Link is Up - 2.5Gbps/Full - flow control rx/tx Sat Feb 10 19:17:29 2024 kern.info kernel: [ 7.556750] mt7530-mdio mdio-bus:1f lan1: configuring for phy/gmii link mode Sat Feb 10 19:17:29 2024 kern.debug kernel: [ 7.563831] mt7530-mdio mdio-bus:1f lan1: major config gmii Sat Feb 10 19:17:29 2024 kern.debug kernel: [ 7.569386] mt7530-mdio mdio-bus:1f lan1: phylink_mac_config: mode=phy/gmii/Unknown/Unknown adv=0000000,00000000,00000000 pause=00 link=0 an=0 Sat Feb 10 19:17:29 2024 kern.debug kernel: [ 7.585159] mt7530-mdio mdio-bus:1f lan1: phy link up gmii/1Gbps/Full/rx/tx Sat Feb 10 19:17:29 2024 kern.info kernel: [ 7.586893] mt7530-mdio mdio-bus:1f lan1: Link is Up - 1Gbps/Full - flow control rx/tx Sat Feb 10 19:17:29 2024 kern.info kernel: [ 15.122661] sfp sfp-1: Host maximum power 3.0W Sat Feb 10 19:17:29 2024 kern.info kernel: [ 15.127875] sfp sfp-2: Host maximum power 3.0W Sat Feb 10 19:17:29 2024 kern.info kernel: [ 15.459629] sfp sfp-1: module OEM DFP-34X-2C2 rev sn XPONxxxxxxxx dc 230912 Sat Feb 10 19:17:29 2024 kern.debug kernel: [ 15.469121] mtk_soc_eth 15100000.ethernet eth1: requesting link mode inband/2500base-x with support 0000000,00000200,0000e440 Sat Feb 10 19:17:29 2024 kern.info kernel: [ 15.509967] sfp sfp-2: module rev 1.0 sn 2307210038 dc 230721 Sat Feb 10 19:17:29 2024 kern.debug kernel: [ 15.519434] mt7530-mdio mdio-bus:1f sfp2: requesting link mode inband/2500base-x with support 0000000,00000000,0000e440 Sat Feb 10 19:17:31 2024 kern.info kernel: [ 24.360320] mt7530-mdio mdio-bus:1f sfp2: configuring for inband/2500base-x link mode Sat Feb 10 19:17:31 2024 kern.debug kernel: [ 24.368145] mt7530-mdio mdio-bus:1f sfp2: major config 2500base-x Sat Feb 10 19:17:31 2024 kern.debug kernel: [ 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 Sat Feb 10 19:17:31 2024 kern.info kernel: [ 24.389679] br-lan: port 5(sfp2) entered blocking state Sat Feb 10 19:17:31 2024 kern.info kernel: [ 24.394948] br-lan: port 5(sfp2) entered disabled state Sat Feb 10 19:17:31 2024 kern.info kernel: [ 24.402405] device sfp2 entered promiscuous mode Sat Feb 10 19:17:31 2024 kern.info kernel: [ 24.414853] mt7530-mdio mdio-bus:1f wan: configuring for phy/gmii link mode Sat Feb 10 19:17:31 2024 kern.debug kernel: [ 24.421873] mt7530-mdio mdio-bus:1f wan: major config gmii Sat Feb 10 19:17:31 2024 kern.debug kernel: [ 24.427355] mt7530-mdio mdio-bus:1f wan: phylink_mac_config: mode=phy/gmii/Unknown/Unknown adv=0000000,00000000,00000000 pause=00 link=0 an=0 Sat Feb 10 19:17:31 2024 kern.debug kernel: [ 24.443005] mt7530-mdio mdio-bus:1f wan: phy link down gmii/Unknown/Unknown/off Sat Feb 10 19:17:31 2024 kern.info kernel: [ 24.472639] mtk_soc_eth 15100000.ethernet eth1: configuring for inband/2500base-x link mode Sat Feb 10 19:17:31 2024 kern.debug kernel: [ 24.481074] mtk_soc_eth 15100000.ethernet eth1: major config 2500base-x Sat Feb 10 19:17:31 2024 kern.debug kernel: [ 24.487693] mtk_soc_eth 15100000.ethernet eth1: phylink_mac_config: mode=inband/2500base-x/Unknown/Unknown adv=0000000,00000000,0000e440 pause=04 link=0 an=1 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. My assumption that the module could have forced the speed down to 1000base-X was completely wrong. Making a final recap: - The module without the quirk is only showing up at 1000base-X due to a wrong EEPROM data - The module without the quirk is working at 1000base-X in both of the 2 internal configurations - The module with the quirk is only showing up at 1000base-X and 2500base-X - The module with the quirk is working at 2500base-X in both of the 2 internal configurations This module as is a GPON-ONU/ONT and is configured by the OLT same as FS GPON-INU-34-20BI and HUAWEI MA5671A already validated for the quirk. Thanks for your patience and suggestions. I remain at your disposal for any further test I can do. I hope that with the above evidence the patch could be acceptable for both OEM and ODI vendor. Sergio Palumbo
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.
Hello Russell, I never wanted to discuss your skills and I bag your pardon if this was your perception. My skills are not so high and my horse is not so high (probably lower than a pony). My intention was simply to give the possibility to other users to get the module working at the higher speed in order to support internet connections at 2500 kb without recompling the system with a patch. If this is not possible I can accept it without problems and I bag your pardon again for the waste of time this can have generated. I thank you for the time you spent with me (I learned a lot) and for the great job you and the net-dev group are doing for the linux community. Best regards Sergio Palumbo Il 17/02/2024 11:28, Russell King (Oracle) ha scritto: > 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. >
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),
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 <palumbo.ser@outlook.it> --- drivers/net/phy/sfp.c | 3 +++ 1 file changed, 3 insertions(+)