What does/did the label look like?
New image is also working fine with my SFP. Thanks.
Thanks.
Because of the OEM SFP more then one type of PHY under the same vendor name/PN problem, I have submitted the patch-set, but only with 1 original module, not for OEM modules.
Anyway, first see if the patch-set gets accepted, then it is always possible to add fixups for other modules.
So I have received also a SFP module with the YT8821. However it is recognized with a different Vendor PN string:
Vendor name : OEM
Vendor PN : 2.5G-T-Y-RM
So the vendor is messing with the Vendor PN strings, using different values.
It would seem that it is only sometimes the same as other vendor and other hardware.
@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