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

[Greg Patrick]

Hi Maxime,

Thanks for the review.

> I'm genuinly wondering if 2s for this isn't too slow. With a 4s total
> including the retry, this definitely leaves time for a user to swap the
> module with another different one, and we wouldn't see the hotswap from
> linux here, leading to very interesting problems. I think we need a
> faster removal-detection time.

Agreed. v3 drops the re-probe interval to 500ms and keeps a 3-failure
debounce, so removal is detected in ~1.5s instead of ~4s, while still
riding out a transient I2C error on a live module:

  https://lore.kernel.org/netdev/20260611175341.2223184-1-gregspatrick@xxxxxxxxxxx/

I've now validated v3 on the hardware (it's running from flash). Some real
numbers from physically pulling/inserting modules:

 - Insertion into a cage that was empty at boot: detected and linked in ~1s.
 - Removal, clean pull: 1.2-1.5s (the design floor, 3 x 500ms).
 - Removal, slow manual extraction: 2.6-3.5s. A human sliding a module out
   chatters the I2C contacts (intermittent ACKs), and the 3-NAK debounce
   deliberately rides that out rather than false-flagging the live link.
   Tightening the debounce below this trades directly against spurious
   removals on a good link, so I've kept it where it reliably never flapped.

On the same-cage swap-to-a-different-module-within-the-window case you
raised: that one is inherent to a polled scheme with no presence edge - we
can narrow the window but not close it without a readable MOD_ABS line,
which this hardware doesn't have. I've noted it as a known limitation in
the commit.

Manuel Stocker independently confirmed the I2C-presence mechanism on a
second board (Horaco ZX-SW82TS-L2P, RTL9302D); his Tested-by is carried on
v3.

No rush at all on your end - whenever you get a chance to try it is
appreciated.

Thanks,
Greg