Re: [EXTERNAL] [PATCH net] net: marvell: prestera: disable port before changing its MAC mode

["Imre Kaloz" <kaloz@kernel.org>]

Hi Elad,

On Thu, Nov 12, 2026, at 09:22, Elad Nachman wrote:

>> > 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