Re: [RFC PATCH net-next 0/4] ethtool: Add ability to write to transceiver module EEPROMs

On Sunday 27 June 2021 13:33:13 Ido Schimmel wrote:

On Thu, Jun 24, 2021 at 10:27:13PM +0200, Andrew Lunn wrote:

quoted

We have the choice here. We can add a write method to the kAPI, add
open source code to Ethtool using that API, and just accept people are
going to abuse the API for all sorts of horrible things in user space.
Or we can add more restrictive kAPIs, put more code in the kernel, and
probably limit user space doing horrible things. Maybe as a side
effect, SFP vendors contribute some open source code, rather than
binary blobs?

I didn't see any code or binary blobs from SFP vendors and I'm not sure
how they can provide these either. Their goal is - I believe - to sell
as much modules as possible to what the standard calls "systems
manufactures" / "system integrators". Therefore, they cannot make any
assumptions about the I2C connectivity (whether to the ASIC or the CPU),
the operating system running on the host and the user interface (ioctl /
netlink etc).

Hello! This is really happening in GPON world. Most GPON SFP modules are
working only in few devices with SFP cages. And it is either because
GPON SFP module vendor provided to vendor of device with SFP cage how to
"hack", initialize and use that GPON module properly or because we have
figured out how particular GPON modules violate SFF standards and added
special quirks per SFP module or per chipset in SFP module.

And the other thing which is happening. If vendor of GPON SFP module is
the same as vendor of device with SFP cage then it is doing everything
to ensure that only its GPON SFP modules would work in its devices. Or
to ensure that its OLT station (opposite end of GPON client SFP module)
would link only with its branded GPON SFP modules.

Classic vendor lockin. If ISP is using OLT station from vendor A then A
wants that you cannot use GPON SFP modules from vendor B on that
network.

You said that vendor goal is to sell as much modules as possible. Seem
that this is truth and vendors are doing it by above vendor lockin
strategy only.


So at the end I really do not like raw RW access to SFP EEPROM. This
just opens a new door for vendor lockin and vendor blob strategy.

And the last thing is that rewriting EEPROM on arbitrary SFP module may
lead to total damage of SFP. Specially on SFPs with "computer inside"
where parts of (critical) memory is shadowed in SFP EEPROM space.