Adopt the generic SFP framework (drivers/net/phy/sfp.c)

[kayoub5]

Problem

ice manages SFP/QSFP modules entirely through its own bespoke path —
ethtool -m → ice_get_module_eeprom() → ice_aq_sff_eeprom() — with no
participation in the kernel's generic SFP subsystem (drivers/net/phy/sfp.c

• phylink). Every piece of module handling has to be built and maintained inside ice itself, rather than reusing what's already upstream.

What adopting sfp.c gets for free

sfp.c is a mature, community-hardened module-lifecycle subsystem that already solves problems ice currently has to handle on its own, or doesn't handle at all:

• Presence/hotplug state machine — insert/remove detection, debounce,
  and retry handling, independent of GPIO or i2c-probe wiring.
• TX fault detection and recovery — automatic retry/reinit logic for
  laser faults.
• TX_DISABLE / rate-select control — laser safety (disabling the
  transmitter when the interface is down) handled automatically.
• Link-mode/capability derivation — EEPROM transceiver codes parsed
  into ethtool link modes and phy_interface_t automatically.
• A large, maintained quirks database — known-broken modules (bad
  EEPROM data, broken TX_FAULT signaling, RollBall PHYs, etc.) already
  handled, benefiting every new adopter for free.
• Copper SFP PHY access — transparent MDIO-over-i2c for RJ45/copper
  modules via mdio-i2c.
• hwmon integration — DDM sensor data exposed via standard hwmon
  sysfs, not just ethtool -m.

Precedent

Microchip's lan743x — a comparable discrete PCIe NIC — already integrates with phylink/sfp.c, showing this is achievable on NIC silicon of this class.

Ask

Wire ice into the generic SFP framework rather than continuing to extend its private Admin-Queue-only module path. This inherits presence handling, fault recovery, quirks, and hwmon integration — all already implemented and maintained upstream — instead of ice needing to duplicate or go without each of them individually.