There seems no way to lock it from userland.
I use a devicetree overlay, to disable the sfp-cage. I set the compatible string of &sfp1 and/or &sfp2 to skip
For the “i2csfp eeprom” command, does it redo the checksum and also the Vendor specific checksum, like Cisco use?
I calculate and fix 2 chacksums: at device 0x50 registers 0x3f and 0x5f.
Hi,
I have tried contacting the seller on aliexpress. They don’t even read messages sent to them. So they are probably totally unaware of the problem we are having with all the SFP units they sell. I was thinking that if they at least knew of the problem, they could maybe fix it in future units. I guess not.
Kind Regards
James
I guess, because, as long as the phy is not being attached by the kernel, there is no problem…
Because all vendors can change these values, this will become a more common problem with these OEM modules I think.
@ericwoud Maybe in the detection code in the kernel, have it detect Read Only 0x56, and treat all transceivers like that the same, ignoring the name fields. We could add module parameters to the sfp.ko module, so that a user could statically configure the quirk/fixup to use for each slot, bypassing any sfp auto-detect logic.
E,g, modprobe sfp type=0,1
0 meaning first sfp slot, use auto-detect
1 meaning second sfp slot, use quirk 1 etc.
Then users could select quirks without even needing to recompile the kernel.
We use that approach for the Linux Sound ALSA because new variants are arriving all the time, and it allows us to get the user sound working, until the permanent quirk is added for that specific motherboard.
Why do you need to lock the i2c bus? Just unbind the SFP device in /sys/bus/platform/drivers/sfp/. For example if your device is called sfp-1, you do
echo sfp-1 >/sys/bus/platform/drivers/sfp/unbind
You can list bound devices by listing the symlinks in that folder.
This is cool! Is this tool available for experiments?
The tool does just that now 
Any news about this?
I have no news on the yt8821 nor the sfp module.