Hello Don! I have read whole discussion and your EEPROM patch proposal. But for me it looks like some kernel glue code for some old legacy / proprietary access method which does not have any usage outside of that old code.
Your code does not contain any quirks which are needed to read different EEPROMs in different SFP modules. As Andrew wrote there are lot of broken SFPs which needs special handling and this logic is already implemented in sfp.c and sfp-bus.c kernel drivers. These drivers then export EEPROM content to userspace via ethtool -m API in unified way and userspace does not implement any quirks (nor does not have to deal with quirks). If you try to read EEPROM "incorrectly" then SFP module with its EEPROM chip (or emulation of chip) locks and is fully unusable after you unplug it and plug it again. Kernel really should not export API to userspace which can cause "damage" to SFP modules. And currently it does *not* do it. I have contributed code for some GPON SFP modules, so their EEPROM can be correctly read and exported to userspace via ethtool -m. So I know that this is very fragile area and needs to be properly handled. So I do not see any reason why can be a new optoe method in _current_ form useful. It does not implemented required things for handling different EEPROM modules. I would rather suggest you to use ethtool -m IOCTL API and in case it is not suitable for QSFP (e.g. because of paging system) then extend this API. There were already proposals for using netlink socket interface which is today de-facto standard interface for new code. sysfs API for such thing really looks like some legacy code and nowadays we have better access methods. If you want, I can help you with these steps and make patches to be in acceptable state; not written in "legacy" style. As I'm working with GPON SFP modules with different EEPROMs in them, I'm really interested in any improvements in their EEPROM area.