@ericwoud So it seems that using the Vendor name and Vendor PN is not very reliable. Maybe we should find some other method to base our quirks from? Would using i2c 0x56 offset 4,5,6,7 (The PHYS IDs) be better to base the quirks from? Does your YT8821 have 4f 51 ea 19 there ? I.e. Have the quirks based from an actually PHY ID detected, rather than what appears to be random OEM vendor names?
The patch-set [PATCH v4 net-next] rtl8226b/8221b add C45 instances and SerDes switching
Has been appied to net-next!
Currently only:
SFP_QUIRK_F("Turris", "RTSFP-2.5G", sfp_fixup_rollball),
Hello, i have a question, can ethtool be used to modify the vendor name or pn?
I don’t think so…vendor/pn is stored in eeprom of the sfp and ethtool only reads this data and configures (temporary) the hardware/system,not writing anything in eeprom
1 Like
i remember someone used ethtool to change some values in the eeprom…
but now i also remember that you have to know a “magic key” to do it, which depends on the manufacturer.
in this case i guess : 8086 is the PCI Vendor id for INTEL and 10fb is the device id
with a little more digging, it may be possible to change the vendorid and pn of this transceiver.
I just opened a new topic for a tool that can edit the eeprom…
USE AT YOUR OWN RISK, it is still beta-stage.
1 Like
Maybe this should be discussed on mailinglist…changing vendor/pn of sfp in eeprom is imho not the right way more like a workaround. Maybe there are other fields readable in sfp.c to detect the right type
Maybe there is. But vendors are using any string here without thinking of this problem.
So from another point of view, the id strings are the root-cause and anything else a work around.
Will be an interesting discussion.
I just ordered some of the RJ45 SFPs of the Bananapi AliExpress store. What is the current state of the various patches?
Is there some Linux kernel version/commit that now has all these issues fixed?
It depends what os you are using. Openwrt may have all commits build in.
I am planning to use Debian or Ubuntu so I am more interested in which kernel release I will need to wait for before bothering to use them - or I might just patch up the kernel module until it hits a release
It is in 6.10
Fixups for vendor OEM are not mainlined, as we do not know beforehand which phy chip is on the module, only looking at vendor/product strings.
Also no commit mainline for handling 2500base-x inband negotiation for mediatek mac.
You will find these commits in Frank and my linux forks for debian/ubuntu and archlinuxarm.
Thanks, at this stage I will be happy if it just connects. Don’t need autonegotiation etc to get the basic functionality working.
Where do I find your Linux fork?
My 6.9 kernel should work
Contains the 2g5 phylink fix
If your module is rollball, you can also edit eeprom to match existing quirk or fixup. I have a tool for it called i2csfp.The one from bpi store was reported as rollball by a user on the forum
The modules turned up. Shows up as “SFP-2.5G-T-R-RM” in the kernel boot log.
I will try the kernels later in the week.
It looks like I’ve added that to the bpir-rolling-stable branch:
https://github.com/ericwoud/linux/commit/76d617875f2a4849bc2f3bf03358ff7f23fda339
Thanks I will try that out.