Hi Elad,
On Thu, Nov 12, 2026, at 09:22, Elad Nachman wrote:
quoted
quoted
From my experience, if you take the port down, it takes time for the firmware
state machine to act accordingly, so you need some significant delay here
(1-3 seconds) before you write the new configuration.
Thanks Elad. I found this bringing up the SFP+ ports on a Delta TN48M
(98DX3265) with firmware 4.1.0. With an S-RJ01 module in sfp-52,
the port came up in 30 of 30 boots with this patch, about 2.1 s after
link up, and in 21 of 30 without it. The disable write waits for the
firmware’s acknowledgement, and I saw no failures without a delay.
Is the delay needed on particular firmware versions or devices? This
path runs under rtnl when an SFP module changes the mode, so I would
rather not sleep for seconds there. If the firmware reports when the
port is really down, I can wait for that instead, with a bounded
timeout.
Your best shot is monitoring what *prestera_hw_port_phy_mode_get*
<https://elixir.bootlin.com/linux/v7.3.1/C/ident/prestera_hw_port_phy_mode_get>()
returns as mdix status.
Thanks. I looked at prestera_hw_port_phy_mode_get(): it only maps the
firmware's mdix byte to ETH_TP_MDI/MDI_X/AUTO, anything else becoming
ETH_TP_MDI_INVALID, and the driver never calls it for SFP ports (the
sfp-52 port goes through phylink and the MAC mode attribute only).
Two things the code cannot tell me: which mdix value does the firmware
report while the port is admin down (INVALID?), and does that attribute
carry anything for an SFP port in SGMII mode with a copper module, where
the PHY sits in the module?
Thanks,
Imre