SFP OEM SFP-2.5G-T kernel PHY?

New version of patch set on the gists page. It will give a better idea of how it will look like.

Turns out that it was not replugging or a delay, but certain registers are not supposed to be read. Depending on the timing, it could severally upset the PHY.

Fixed in:

https://gist.github.com/ericwoud/d912301a93cd41b39621a65cc372a5c0#file-0005-net-phy-phy_device-do-not-probe-or-read-c45_id-from-patch

This means the patch-set should be stable and ready to test… Apply it to the latest netdev/net-next, as it relies on a very recent patch from Russell.

I also need to test it, only just fixed this last issue…

1 Like

so now in your current tests the phy is recognized every time without re-plug? and recognizes the link without any autoneg tricks? have added the new patches now, but i guess i’m able to test only next days

It should all work, but because I was bug hunting, I have not really tested it thoroughly.

Also needs this patch, if not build on netdev/net-next.

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=f4bf467883f2

May need some other I am not aware of, only used netdev/net-next

Edit:

This one is also quite new, may need to add it if phy_id_compare() is not there:

https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/

Edit 2:

The matching functions are updated

So the rough version is finished, basically it all works as I wanted. So maybe some minor changes, but basically this is it.

Repo/Branch here SFP-2.5G-T net-next

Some help with testing and some improvement suggestion would be appreciated.

So, the kernel now has the phydev->possible_interfaces which is something we asked for, but now it is there…

Anyway, most of the above is obsolete with:

https://patchwork.kernel.org/project/netdevbpf/list/?series=811867

But then remains the issue that MediaTek LynxI PCS, 2500Base-X will only work without inband status due to hardware limitation.

Previous attempts to tackle this were not approved here

So I have thought of this:

https://github.com/ericwoud/linux/commits/net-next-marek-mtk2500/

It works with the rtl8221b on the BPI-R3, but still need to test with an optical module at 2500, which I do not have…

Edit:

I guess I could test the in-band-status quirk with the rtl8221b, without the sfp-quirk, so it would be handled as if it is optical…

Well, 2500base-x is broken for the BPI-R3 on net-next… Even with unaltered code, and the sfp module with the autoneg-off quirk (without phy). I found we still need a part of the previously submitted “net: pcs: pcs-mtk-lynxi: use 2500Base-X without AN”:

So only in the mtk_pcs_lynxi_get_state() function.

So net-next really needs this fix:

Edited the commit message.

1 Like

As pointed out, the fix for handling 2500base-x without autoneg should be done in phylink.c, not in any device driver.

So now I have a simple patch (which won’t be upstreamable, but it works on R3). Now the 2.5G sfp works in optical mode, even without disabling autoneg from the sfp-quirk. It also works when the module’s phy is recognised and used.

See: new patch

One can see that phylink_pcs_neg_mode() has moved already to phylink.c in net-next, to provide for a solution something similar to this.

So this patch-set was rejected because of:

In order not to break handling of the RTL8125-internal PHY’s, we have to keep the access to the vendor-specific registers. What could be done: Split the PHY driver for e.g. RTL8226B into one for the RTL8125-internal version and one for the standalone version (using match_phy_device and maybe using the MMD read result as differentiating criteria). Then the one for the standalone version could use core c45 functions.

So this means that we could use the extra driver instance, as I had in my patchset.

I contacted Marek, but he did not find the time to continue on that patchset. I asked him if I could and that is ok. So I have prepared a new version here:

https://github.com/ericwoud/linux/commits/net-next-realtek-phy-v3/

Mind you that the last commit is not part of the patchset. It is called net: phylink: add support for disabling in-band-status for base-x It will not be accepted upstream. It is needed to handle the fact that the R3 does not support inband negotiation at 2500base-x. It has to be switched off. So either use this patch, or the one from @dangowrt that modifies the pcs driver.

So if anyone would like to test this, give some feedback from the community here, that would be great.

To make the RTL8221B work on systems where the PHY is on-board rather than inside an SFP module (like GL-iNet MT-6000 or TP-LINK XDR608x) I still have to either patch phylink to enable in-band-status on the MAC/PCS side anyway (rather than relying only on out-of-band status which seems to be what Linux usually does) or configure the PHY to not use in-band-status as in this patch:

(it may need some love to conditionally enable/disable SGMII in-band-status)

Yep, solving the inband status/an issue is something that I would like to have also. But because the standard for it came very late, now all hardware handles it in different ways, and it now cannot be solved easily.

To get this patch-set to be accepted, I’ll leave the entire inband issue out of this patch-set, same as Marek’s patch-set.