BPI-R3 SFP Module compatibility

With 2500baseX mode I get the following between SFP-2 and a 1g port. Once I got SFP-1 working it performed identically.

[ ID] Interval           Transfer     Bitrate         Retr
[  6]   0.00-10.00  sec  1.10 GBytes   941 Mbits/sec    0             sender
[  6]   0.00-10.00  sec  1.09 GBytes   939 Mbits/sec                  receiver

After getting SFP-1 working, I tested 2.5g between them and that yielded retransmitts, but I’m pretty sure that’s IRQ related. Just for testing I pushed the MTU up and didn’t get retransmitts.

It might be my SFP’s, it is possible they’re different but identifying the same.

My initial go had a lot of mud thrown at the wall, but I’ve finally narrowed down to exactly what got SFP-1 working for me, and it’s odd. sfp-reenable-autoneg.patch (511 Bytes)

-	sfp_quirk_disable_autoneg(id, modes, interfaces);

Of course, as you found, auto-negotiation doesn’t work on SFP-1 or SFP-2, so neither SFP works on boot with that, but once disabled on both of them, they both kick into gear and start working.

ethtool -s eth1 autoneg off speed 2500 duplex full
ethtool -s lan4 autoneg off speed 2500 duplex full

I have similar SFP and after tweaking LAN_SDS_MODE to 4 - sfp module disappeared. Do you have any problems like that?

Were you able to get the 10G one to work in 2.5G mode? What does the following error in your log mean?

[ 1356.020273] mtk_soc_eth 15100000.ethernet eth1: validation with support 0000000,00000000,00000000 failed: -22

I am also getting it with this device

Any updates on the fixes getting into the main branch?

I should finally soon get my BPI-R3 soon and want to start on the correct foot.

I also ordered the recommended optical SFP module. Thank you frank-w and ericwoud!

Are those still the optical modules most likely to work?

The fixes for sfp power and thermaltrips are merged to next,so will land in 6.8.

Which modules do you mean? My h!fibre work without issues.

Thanks - good news!

The ones I was referring to was from an earlier post of yours:

Here is a new sale for 13.22€ and without shipping costs if interested:

https://m.de.aliexpress.com/item/1005005052139284.html

But I now see the H!fibre module you also mentioned:

Amazon.de

The one from ericwoud:

This one has an option to order for banana pi

€ 14,24 59%OFF | SFP-2.5GE-RJ45 Gigabit 2.5G Module SFP To RJ45 Optical Interface Expansion 2500M Rate Compatible Huawei H3C Cisco TPLINK Switch https://a.aliexpress.com/_EyiBS4l 40

Anyone have any experience?

I’ll try the H!fibre first.

Thanks!

The 2g5 modules are copper (rj45) not optical. These need additional patches not yet in mainline. But from software level the cheap oem is better supported than the tplink as it has a phy detected which can be used to show the real speed. On tplink the phy is not yet accessible from software.

Thanks! Got the H!fibre from Amazon: https://www.amazon.com/dp/B07B47SSHH Everything works without a hitch.

Hello Daniel, I use on my BPI R3 a GPON sfp module OEM DFP-34X-2C2 capable of both 1000base-x and 2500base-x. Unfortunately the stable OWRT v23.05.2 only showing 1000base-x then I created following patch as per your suggestion: target/linux/generic/pending-5.15/706-net-sfp-add-quirk-for-DFP-34X-2C2.patch text

Enabling this option makes DFP-34X-2C2 working at 2500baseX

--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -383,6 +366,12 @@ static const struct sfp_quirk sfp_quirks
		.part = "MXPD-483II",
		.modes = sfp_quirk_2500basex,
 	}, {
+		// OEM DFP-34X-2C2 GPON ONU can operate at 2500base-X, but report 1.2GBd
+		// NRZ in their EEPROM	
+		.vendor = "OEM",
+		.part = "DFP-34X-2C2",
+		.modes = sfp_quirk_2500basex,
+	}, {
 		// Huawei MA5671A can operate at 2500base-X, but report 1.2GBd
 		// NRZ in their EEPROM
 		.vendor = "HUAWEI",

and after the compilation with patch ethtool correctly showing:

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

Can you please add the patch for this stick in the openwrt development so that it will be embedded in next versions? Thanks in advance from all DFP-34X-2C2 users.

As I don’t have the hardware myself for testing the best would be you submitted this patch to upstream Linux mailing lists. As things have advanced in upstream Linux since v5.15, the equivalent patch you should submit to netdev mailing list would look like that:

diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 2abc155dc5cf8..a14f61bab256f 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -495,6 +495,9 @@ static const struct sfp_quirk sfp_quirks[] = {
        // 2500MBd NRZ in their EEPROM
        SFP_QUIRK_M("Lantech", "8330-262D-E", sfp_quirk_2500basex),
 
+       // DFP-34X-2C2 GPON ONU supports 2500base-X
+       SFP_QUIRK_M("OEM", "DFP-34X-2C2", sfp_quirk_2500basex),
+
        SFP_QUIRK_M("UBNT", "UF-INSTANT", sfp_quirk_ubnt_uf_instant),
 
        // Walsun HXSX-ATR[CI]-1 don't identify as copper, and use the

Once sent to Linux netdev kernel mailing list, the patch will show up in Netdev + BPF - Patchwork

From there, download the patch file and add it to (including the complete patch description and X-Patchwork* headers, so we can track it and remove it once we move to newer kernels which will then include it) to both target/linux/generic/pending-5.15 and target/linux/generic/pending-6.1. Then make change both patches so they actually build and work on Linux 5.15 and Linux 6.1 (ie. the patch content will then look like what you are suggesting above, but include a patch description and X-Patchwork… headers), commit that to your local openwrt.git checkout and submit the resulting patch to OpenWrt’s openwrt-devel mailing list or open a pull request on Github.

If you face any difficulties or have questions, please ask, I will help and assist you along the process.

Hi Daniel, this is the first time fo me to submit a patch. Can you please explain what do you mean for “send to Linux netdev”. Do I have to use

git send-email [email protected] --to="[email protected]" 001-description.patch

or do I have to send to

[email protected]

or do I have to subscribe:

openwrt-devel

Thanks in advance for your help. Best regards and Merry Christmas Sergio

https://www.kernel.org/doc/html/v5.3/networking/netdev-FAQ.html

So this is linux not openwrt specific…openwrt then adds the patches from linux

You send patches to the recipients listed by get_maintainer.pl script of linux source. Get net-next source first,add your changes and use git format-patch to get patchfile

If 1000M is not an issue, here is a nice offer €5,92 (buy 2 for free shipping):

https://nl.aliexpress.com/item/1005006169925450.html

It says i2c access to phy, so should be ok…

1 Like

Submitted the patch and shown in Patchwork Netdev+BPF as success. What is now the next step? Thanks for your kind help.

waiting for the patch to be reviewed and applied :slight_smile:

can you post link to the patch (patchwork)?

Hi Frank, here the link. https://patchwork.kernel.org/project/netdevbpf/patch/AS1PR03MB8189F6C1F7DF7907E38198D382672@AS1PR03MB8189.eurprd03.prod.outlook.com/

Some information additional (or shorter) to the readme you already got in the Mailinglist:

Look for previous commits on this file to get the right subsystem prefix and gives you some examples how commits should look like…

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/log/drivers/net/phy/sfp.c

As you see,commits here are like this

net: sfp: add support for xyz module

you can change commit with

git commit --amend -s

If it is your topmost commit (i guess it is in your tree). The s flag adds the signed-off-by if not already there.

Then add a commit message explaining why this patch is needed (see also previous commits as example).

Then use “git format-patch HEAD~1” and check the resulting file with scripts/checkpatch.pl and use get_maintainers.pl to get recipients (maintainer,reviewers and mailinglists only - exclude commit signers). Then you can use git send-email to send the patch to the adresses you’ve got

Hi Frank, I struggled all day in order to understand how to proceed without success. Unfortunately I started from patch already prepared without creating it from scratch and mailed it without applying it in the system. However I cloned kernel/git/netdev/net-next.git - Netdev Group's -next networking tree and tryed to apply the patch without success (errors reported which I could not understand). It is still not clear to me how to create (diff ?) the patch and/or apply it, when to commit and how to sned it to the maintainers mailing list. I read documents suggested, but still need some very basic help in order to understand how to proceed. Still not clear to me if I can do the requested changes directly on the patch file and send it to the maintaines mailing list or if I have to create, apply, commit it in the system and use the git commands to proceed. Your and Daniel’s help would be much apreciated.

your patch does not apply because you have used spaces instead of tabs for the existing lines (Lantech and UBNT SFP)

then i would align the quirks by vendor so it should imho be near the other OEM quirks

so codechange is more like this:

diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index f75c9eb3958e..1a447e3567c8 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -506,6 +506,9 @@ static const struct sfp_quirk sfp_quirks[] = {
        SFP_QUIRK_M("OEM", "SFP-2.5G-T", sfp_quirk_oem_2_5g),
        SFP_QUIRK_F("OEM", "RTSFP-10", sfp_fixup_rollball_cc),
        SFP_QUIRK_F("OEM", "RTSFP-10G", sfp_fixup_rollball_cc),
+       // DFP-34X-2C2 GPON ONU supports 2500base-X
+       SFP_QUIRK_M("OEM", "DFP-34X-2C2", sfp_quirk_2500basex),
+
        SFP_QUIRK_F("Turris", "RTSFP-10", sfp_fixup_rollball),
        SFP_QUIRK_F("Turris", "RTSFP-10G", sfp_fixup_rollball),
 };

so now look how the commits look like for older sfp support

$ git log --oneline -10 drivers/net/phy/sfp.c
e9301af385e7 net: sfp: fix PHY discovery for FS SFP-10G-T module
bb1afee98466 net: sfp: Convert to platform remove callback returning void
2f3ce7a56c6e net: sfp: rework the RollBall PHY waiting code
dd9d75fcf0f4 net: phy: fill in missing MODULE_DESCRIPTION()s
5ffe330e40bd net: sfp: improve Nokia GPON sfp fixup
e184e8609f8c net: sfp: re-implement ignoring the hardware TX_FAULT signal
e27aca3760c0 net: sfp: add quirk for FS's 2.5G copper SFP
d387e34fec40 net: sfp: add quirk for Fiberstone GPON-ONU-34-20BI
f4bf467883f2 net: phy: move marking PHY on SFP module into SFP code
ac2e8e3cfe48 net: sfp: add support for HXSX-ATRI-1 copper SFP+ module

e.g. e27aca3760c0 looks good so far, so use e.g. git show e27aca3760c0 to look how commit message is written (you can copy the text and modify it to match your SFP without the indent added by git show).

git commit -s drivers/net/phy/sfp.c

something like this (signed-off-by is added with the -s switch of git commit):

net: sfp: add quirk for DFP-34X-2C2 GPON ONU SFP

Add a quirk for a GPON SFP that identifies itself as "OEM", "DFP-34X-2C2".
This module's PHY is inaccessible, and can only run at 2500base-X.

then you have the commit like it should be on top of your tree (you can use “git show” without ref to see it)…lets make a patch from it, check this and get maintainers

$ git format-patch HEAD^
0001-net-sfp-add-quirk-for-DFP-34X-2C2-GPON-ONU-SFP.patch

$ scripts/checkpatch.pl 0001-net-sfp-add-quirk-for-DFP-34X-2C2-GPON-ONU-SFP.patch
total: 0 errors, 0 warnings, 0 checks, 9 lines checked

0001-net-sfp-add-quirk-for-DFP-34X-2C2-GPON-ONU-SFP.patch has no obvious style problems and is ready for submission.
$ scripts/get_maintainer.pl 0001-net-sfp-add-quirk-for-DFP-34X-2C2-GPON-ONU-SFP.patch
...

you can add these adresses directly to patch-file or inserting them when running git send-email (maybe needs to be installed - sudo apt install git-email in debian/ubuntu)

to add to Patch-File you can open your created patch in editor of your choice and add To: and Cc: headers between Date and Subject without the part in parenthesis (no blank line). add a comma at the end of line except the last recipient per header and a space before emails not prefixed by email-Header-Tag

so it should look like (maintainers in “To”, all other - except commit signers - in “Cc”):

Date: Sat, 6 Jan 2024 12:31:35 +0100
To: Russell King <email>,
 Andrew Lunn <email>,
 Heiner Kallweit <email>,
 "David S. Miller" <email>,
 Eric Dumazet <email>,
 Jakub Kicinski <email>,
 Paolo Abeni <email>
Cc: [email protected],
 [email protected]
Subject: [PATCH] net: sfp: add quirk for DFP-34X-2C2 GPON ONU SFP

after saving you can send your patch

$ git send-email 0001-net-sfp-add-quirk-for-DFP-34X-2C2-GPON-ONU-SFP.patch
0001-net-sfp-add-quirk-for-DFP-34X-2C2-GPON-ONU-SFP.patch
To whom should the emails be sent (if anyone)? 
Message-ID to be used as In-Reply-To for the first email (if any)?
...
From: Frank Wunderlich <email>
To: Russell King <email>,
	Andrew Lunn <email>,
	Heiner Kallweit <email>,
	"David S. Miller" <email>,
	Eric Dumazet <email>,
	Jakub Kicinski <email>,
	Paolo Abeni <email>
Cc: Frank Wunderlich <enail>,
	[email protected],
	[email protected]
Subject: [PATCH] net: sfp: add quirk for DFP-34X-2C2 GPON ONU SFP
Date: Sat,  6 Jan 2024 12:40:12 +0100
Message-Id: <20240106114012.10761-1-...>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

    The Cc list above has been expanded by additional
    addresses found in the patch commit message. By default
    send-email prompts before sending whenever this occurs.
    This behavior is controlled by the sendemail.confirm
    configuration setting.

    For additional information, run 'git send-email --help'.
    To retain the current behavior, but squelch this message,
    run 'git config --global sendemail.confirm auto'.

Send this email? ([y]es|[n]o|[e]dit|[q]uit|[a]ll):

make sure the To- and Cc-headers are displayed correctly (not merged 2 adresses or similar)

you may need to setup your mail-provider before if not done already

$ nano ~/.gitconfig

and add a section with you data:

[sendemail]
        #from = Name <email> #optional if not matching the senders email
        smtpencryption = ssl
        smtpserver = <mailserver>
        smtpServerPort = 465
        smtpuser = <loginuser>
        composeencoding = UTF-8

Hi Frank, thanks very much for your complete explanationss. This made me clear on actions to be performed. So:

- I made changes on the file deivers/net/phy/sfp.c
- I committed the changes using the format message needed for netdev
- I formatted the patch using git format-patch as per instructions
- I got the list of the recipients to be emailed
- I added the To and the Cc to the file
- I sent the email using git send-email
- Patch showed up at netdev + bpf

Let me know if any further action is needed.