RFC: symmetric SET_MODULE_EEPROM_BY_PAGE with i2c_address for non-SFF pages

Hi,

Raising a gap in the ethtool netlink module-EEPROM API and asking whether a symmetric write-side command would be considered upstream.

Background:
ETHTOOL_MSG_MODULE_EEPROM_GET (net/ethtool/eeprom.c) already accepts an explicit i2c_address attribute alongside page/bank/offset/length, not just the SFF-8472 0x50/0x51 pair.

For SFP cages backed by phy/sfp.c + phylink with a real i2c_adapter, this lets userspace read arbitrary vendor-specific I2C addresses on the module through a standard interface, which is useful well beyond SFF-8472.

There is no equivalent SET. ethtool --set-module-eeprom (both netlink and the legacy ioctl fallback)

Concrete use case:

We (Technica Engineering) manufacture automotive SFP/SFP+ modules for 100/1000BASE-T1 and multi-gig automotive Ethernet (TE-1441, PT-1445). Alongside the standard SFF-8472 EEPROM at 0x50, these modules expose an I2C-to-MDIO gateway at I2C address 0x40 (0x80/0x81 as 8-bit read/write):

Writes to that address are relayed by the module's own logic as MDIO Clause 22/45 transactions to the embedded automotive PHY, giving access to link speed, master/slave mode, and other PHY configuration without needing register-level documentation of the PHY itself.


This isn't a one-off design choice -- at least two other automotive SFP vendor use similar patterns
    * Intrepid Control Systems: https://guide.intrepidcs.com/docs/1000BASE-T1-SFP/A-Tour-of-1G-SFP-Hardware.html#i2c-communication
    * FL3X: https://flex-product.com/assets/produkte/fl3x_sfp_1000base-t1/instruction_for_use_fl3x_sfp_1000base-t1.pdf

This suggests this is a de facto convention among automotive Ethernet SFP vendors rather than something specific to us. The framing on top of the raw MDIO transaction is vendor-specific, but the kernel doesn't need to understand that -- we just need raw byte-level write access to a non-default I2C address on the module, symmetric to what MODULE_EEPROM_GET already provides for reads.

Today there's no standard kernel path for this write from userspace on phylink/sfp.c-backed ports. Where the SFP's I2C bus happens to be a directly exposed i2c_adapter (board-dependent), i2c-tools works, but that's not guaranteed, and on the phylink-managed path the bus is typically owned/locked by the sfp driver rather than freely available via /dev/i2c-N.

Ask:
Would a SET_MODULE_EEPROM_BY_PAGE netlink command, mirroring the existing GET (same page/bank/offset/length/i2c_address attributes, same 128-byte half-page constraint), be something you'd consider taking?
Wanted to check direction first given Andrew's existing work on the generic SFP GET path before spending time on an RFC series that goes against the intended design.

Thanks.


 
Ayoub Kaanich
Principal Software Engineer
Engineering Department
 
Technica Engineering GmbH
Leopoldstr. 236
D - 80807 München/Munich
 
Telefon:
+49 89 200 07 24-XX

Fax: +49 89 200 07 24-30
E-Mail:
ayoub.kaanich@technica-engineering.de
Website: www.technica-engineering.de

________________________________________
Technica Engineering GmbH is based in Munich | Managing Directors: Pankaj Sathe, Anup Sable, Thomas Königseder | Register Court: Munich Local Court, HRB 172
 759 | Ust-ID.: DE-260220745
 
The information contained in this e-mail is intended solely for the use of the individual or entity to whom it is addressed, and others authorized to receive
 it. It may contain confidential or privileged information. If you are not the intended recipient you are notified that any disclosure, copying, distribution or taking any action in reliance on the content of this email is strictly prohibited and may be unlawful.
 If you have received this communication in error, please notify us immediately by responding to this email and then delete it. Technica Engineering GmbH is neither liable for the proper and complete transmission of the information obtained or for any delay
 in this receipt.