Re: [PATCH net-next v3] net: phy: sfp: detect presence via I2C when no MOD_DEF0 GPIO

[Maxime Chevallier]

Hi,

On 6/11/26 19:53, Greg Patrick wrote:
> An SFP cage (compatible "sff,sfp") whose MOD_DEF0 signal is not wired to a
> GPIO currently falls back to sff_gpio_get_state(), which unconditionally
> reports the module as present. An empty cage therefore fails its probe and
> is parked in SFP_MOD_ERROR forever; because SFP_F_PRESENT never deasserts
> there is no REMOVE event to recover the state machine, so a module inserted
> after boot is never detected, and empty cages spam -EIO at boot.
> 
> This affects boards that route none of the cage presence signal to a
> software-readable input. On the NicGiga S100-0800S-M (RTL9303, 8x SFP+) the
> cage I2C bus is the switch's SMBus master; TX_DISABLE is driven via a
> PCA9534 I/O expander, but no MOD_ABS/MOD_DEF0 line reaches a readable GPIO
> (the RTL9303 gpio0 lines read stuck-low, the single PCA9534 is fully
> consumed by TX_DISABLE, and there is no RTL8231). The Horaco ZX-SW82TS-L2P
> (RTL9302D, 2x SFP+) is independently affected in the same way.
> 
> For such an SFP cage, derive presence from a throttled single-byte I2C read
> of the module EEPROM instead: a successful read asserts SFP_F_PRESENT,
> R_PROBE_ABSENT consecutive failures clear it (to ride out a transient error
> on a live module). The existing poll then emits SFP_E_INSERT / SFP_E_REMOVE
> normally, giving working hot-plug and silencing the boot-time -EIO spam on
> empty cages. Presence is re-probed every T_PROBE_PRESENT, so insertion is
> detected within that interval and removal within
> T_PROBE_PRESENT * R_PROBE_ABSENT.
> 
> A soldered-down module (compatible "sff,sff") has no presence signal and is
> genuinely always present, so it continues to use sff_gpio_get_state(); the
> new path is gated on the cage type advertising SFP_F_PRESENT.
> 
> Signed-off-by: Greg Patrick <gregspatrick@xxxxxxxxxxx>
> Tested-by: Manuel Stocker <mensi@xxxxxxxx>

Reviewed-by: Maxime Chevallier <maxime.chevallier@xxxxxxxxxxx>

And it doesn't regress any boards I've tested this on (although this was
very quick testing), so

Tested-by: Maxime Chevallier <maxime.chevallier@xxxxxxxxxxx>

I'm wondering if a followup could be to add another loud warning to
dmesg that the HW design is broken, leading to potentially quirky behaviour.

We have lots of those for SFP.

Maxime