Re: [PATCH RFC net-next v2 1/2] net: phy: marvell: 88e1111: define gigabit features

[Josua Mayer <josua@solid-run.com>]

On 19/01/2026 11:27, Maxime Chevallier wrote:
> Hi Russell, Josua,
>
> On 02/01/2026 13:47, Russell King (Oracle) wrote:
>
>> If the operational mode of the PHY is reconfigured at runtime, then I
>> think it would be reasonable to re-read the supported linkmodes.
>> However, I think this will cause issues for phylink, as currently it
>> wants to know the link modes that are supported so it can choose an
>> appropriate interface mode.
> Russell, I agree that your patches for phydev->supported_interfaces
> are required, but I also think we need another piece of the puzzle to
> solve Josua's issue.
>
>  From what I get, it's impossible from the PHY driver's perspective only,
> to know which configuration the PHY is in, i.e. is it in :
>
>   1000X to 1000T
>   SGMII to 1000T
>   SGMII to something else ?
The PHY driver cannot know what the media side is,
and it cannot trust the state after initial power-on.

In particular because hardware engineers will refuse to change PCB
just because some bootstrap signals were (un-)intentionally wrong,
when in fact the phy can be reconfigured at runtime.

But the host side can be negotiated with the MAC.
> This is one of the issues I was facing with the SGMII to 100FX adapters.
>
> Selecting the right phy_interface, is one thing, but it doesn't address
> the fact that whe don't know which linkmodes to put in phydev->supported.
>
> The approach I took to address that is in patch 3 of this series [1] :
>
>   - The SFP's eeprom should ideally store information about the MDI of the
>    module, is it outputing fiber at 1G, at 100M, is it BaseT, etc.
>
>   - in sfp_sm_probe_phy(), we have the sfp_module_caps fully parsed, with
>     fixups and quirks applied, so what I do is store a pointer to those in
>     struct phy_device
>
>   - The PHY driver can then use that in its .get_features() to report the
>     proper linkmodes.
>
> Of course, this may not be the right approach. What do we trust more, the SFP
> eeprom, or the PHY's reported linkmodes through features discovery ?
For the type of media I would trust the combination of sfp eeprom + quirks
more than the power-on-reset state of phy inside sfp.

But for the available link modes/speeds I would trust the PHY.

>
> IMO relying on the SFP subsystem to build a proper list of linkmodes we can
> achieve on the module is a bit better, as we have the opportunity to apply
> fixups and quirks.
>
> Maxime
>
> [1] : https://lore.kernel.org/all/20260114225731.811993-1-maxime.chevallier@bootlin.com/#t
>