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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2f83f4ee-4655-4d0d-a655-55ced2af190d@solid-run.com>
Date: Wed, 21 Jan 2026 09:52:54 +0000
From: Josua Mayer <josua@...id-run.com>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>, "Russell King (Oracle)"
	<linux@...linux.org.uk>
CC: Andrew Lunn <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>,
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC net-next v2 1/2] net: phy: marvell: 88e1111: define
 gigabit features

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
>