netdev - Re: [PATCH net] net: explicitly check in of_phy_is_fixed

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250812115220.x23sfyerozalklgt@skbuf>
Date: Tue, 12 Aug 2025 14:52:20 +0300
From: Vladimir Oltean <vladimir.oltean@....com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: netdev@...r.kernel.org, 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>,
	Stas Sergeev <stsp@...t.ru>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net] net: explicitly check in of_phy_is_fixed_link() for
 managed = "in-band-status"

On Tue, Aug 12, 2025 at 12:22:39PM +0100, Russell King (Oracle) wrote:
> On Tue, Aug 12, 2025 at 01:59:28PM +0300, Vladimir Oltean wrote:
> > And the other sub-case is when the MDIO-less PHY is also silent on the
> > in-band autoneg front. In that case, the firmware description would look
> > like this (b):
> > 
> > 	mac {
> > 		phy-mode = "sgmii";
> > 
> > 		fixed-link {
> > 			speed = <10000>;
> > 			full-duplex;
> > 		};
> > 	};
> > 
> > (side note: phylink would probably have something to object against the
> > PHY not reporting its state in any way, and would consider the setup
> > invalid, even if in some cases it would work. This is because its
> > configuration may not be fixed, and there would be no way to be notified
> > of updates)
> 
> Both of these are fully supported by phylink, and your side note is
> incorrect. Phylink provides all the functionality.
> 
> With the description in (b), if a MAC driver wishes to, it can provide
> phylink_config->get_fixed_state() and override the speed, duplex and
> pause in the same way that is possible with fixed PHY.
> 
> So, unless I missed something, I don't think your commit description
> is correct. If it is correct, it is ambiguous.

Hmm, ok, it seems I was missing something very fundamental, thanks for
pointing me in the correct direction. I'll remove the side note altogether.

I didn't make the connection with phylink_config->get_fixed_state()
because I didn't realize it can overwrite more than state->link.

So I see the txgbe driver implements get_fixed_state() to report the
status of the firmware-managed PHY to phylink, in MLO_AN_FIXED mode.
That's interesting. I think dpaa2 could also do that for its
DPMAC_LINK_TYPE_FIXED mode. Currently it avoids instantiating a phylink.

(I realize we're diverging, but is the initial speed passed to
phylink_set_fixed_link() particularly relevant, or can it be arbitrary
as long as it's supported by the mac_capabilities, and as long as
get_fixed_state() can overwrite it? Can the speed be SPEED_UNKNOWN?
I don't understand why txgbe passes SPEED_25000 if it provides
get_fixed_state())

By the way, while reviewing implementations, I found bcm_sf2_sw_fixed_state()
to manually call netif_carrier_off(). Is that valid, to alter the
phylink-managed carrier state? Doesn't phylink_resolve() ->
phylink_link_down() call netif_carrier_off() already?